Eachine H1 a.k.a. Mini Ninja

Turns out the 2.2-2.4 one works fine if it's assembled. Now I really feel stupid for ordering the other one. The 2.4-2.6 one would probably work even better, since it wouldn't be out of spec, but I've already successfully captured nRF24 packets on channel 0x3c (2460MHz, IIRC) and I think I've got a bunch of bind requests from the H1.

Also, I made a mistake in my earlier assupmtions that the sync word would consist of the values in registers 36 and 37. According to the datasheet registers 36 and 39 are used with a 32 bit sync word, so the symbols to loook for are 0xfd, 0x07, 0x04 and 0x05 (not necessarily in that order).

A link to the Aliexpress listing is in one of my earlier posts.

victzh wrote: Why 2.4-2.6GHz when the guys article specifically mentions 2.2-2.4GHz?

And do you have a link to it - I failed to find it on aliexpress.

The frequency range covered by the nRF24 is 2.4-2.525GHz, so the 2.2-2.4GHz downconverter still works, since its filters aren't too tight, but the 2.4-2.6GHz one would still work better.

Here's the link to the one from the blog post: www.aliexpress.com/item/2012-best-sellin...erter/670265064.html

and here the 2.4-2.6GHz one: www.aliexpress.com/snapshot/6446024564.h...derId=65416792994677

OK, buying 2.4-2.6 then.

I've got a bit of progress to report:

I managed to capture and decode a bunch of valid data packets, but I can't make sense of the CRC.


Here's what goes in on the SPI bus:

and here are a few valid data packets captured with gnuradio. Mind the last byte of the CRC:

See?

I haven't tried to reproduce the CRC itself yet, but a quick search for statistical distribution was inclonclusive:

Does anybody have an idea what's going on here?

Edit: I do. Turns out I can't count to two. It's a 16 bit CRC, hence it's two bytes, not four. Duh!

BTW, here are my wire/air dumps and my crude tools, so you can play around with them.

I can't upload the file, maybe it's too big.

I figured out the CRC:

It's a KERMIT model with 0x1021 as polynomial. At least that model yields the same results as the CRC in the captures I made.

Now I've got to figure out how to correctly implement this and then I'd say it's testing time again. Only this time around there's a real chance it'll work.

alibenpeng wrote: I figured out the CRC:

It's a KERMIT model with 0x1021 as polynomial. At least that model yields the same results as the CRC in the captures I made.

Now I've got to figure out how to correctly implement this and then I'd say it's testing time again. Only this time around there's a real chance it'll work.

Great work .... you are close ....

another progress report:

I'm sending valid bind packets wich are getting ACKed wnenever the RX listens in on that channel. Here are the packet counts after a few seconds of listening in:

Now comes another tricky part, which is reading the ACK with the NRF. Also, I haven't figured out yet if the data channels are related to the data in the ACK.

I'm afraid I've hit a dead end. I can't seem to manage to receive the ACK with the nRF.

I am examining a bitstream I dumped with the gnuradio gfsk demodulator, and the average number of noise bits between transmission of a bind packet and reception of an ack is 1834. With a bitrate of 1MBit/s that would be one bit per microsecond. So the length of the gap between packet and ACK is just shy of 2ms.

It takes the nRF about 130us (add a bit to account for overhead) to switch to receive mode, so there should be plenty of time to catch the ACK. But still, it doesn't.

The bind sequence goes like this:

1. TX sends bind packet
2. TX checks for an ACK by polling the status register of the lt9010 32 times.
3. If an ACK is received, continue, else go to step 1.
4. TX sends data packet on the first channel of the hopping sequence.
5. TX checks for an ACK by polling the status register of the lt9010, but this time only twice.
6. If an ACK is received, continue, else go to step 4.
7. TX sends data packet on the next channel of the hopping sequence.
8. TX checks twice for ACKs again.
9. If ACK, goto 7, else send on last channel again.

The last step is only a guess, because I didn't bother to look for that specific case, but the rest is double checked and confirmed.

Either way, being able to receive ACKs is crucial for knowing what to do next. Without it, there is no way this is going to work.

If we don't get this resolved, the only other way to make this work will be using the real thing. LT8900 modules are available at Aliexpress ( www.aliexpress.com/snapshot/6474280604.h...derId=65629096534677 ), although I haven't seen any offers for singles. I ordered a lot of 10, so if anybody wants one, drop me a PM (be patient, though, deliveries from China can take up to two months).

With the original chip, building a working driver should be trivial, since I don't believe the data in the ACK packets to be relevant, other than letting the TX know the last packet was received correctly. This way it wouldn't even be necessary to understand how the hopping channels are chosen, because we know which bind packets relate to which data channels, so we could just choose one of the captured sequences.

I know, this is technically cheating, but unless someone figures out how to receive the lt8910 ACKs with an nRF, it's the only way I see.

I've added an attachment with all my code and a bit of sample data, so you can verify my findings and process.

alibenpeng wrote: I'm afraid I've hit a dead end. I can't seem to manage to receive the ACK with the nRF.

I am examining a bitstream I dumped with the gnuradio gfsk demodulator, and the average number of noise bits between transmission of a bind packet and reception of an ack is 1834. With a bitrate of 1MBit/s that would be one bit per microsecond. So the length of the gap between packet and ACK is just shy of 2ms.

It takes the nRF about 130us (add a bit to account for overhead) to switch to receive mode, so there should be plenty of time to catch the ACK. But still, it doesn't.

The bind sequence goes like this:

1. TX sends bind packet
2. TX checks for an ACK by polling the status register of the lt9010 32 times.
3. If an ACK is received, continue, else go to step 1.
4. TX sends data packet on the first channel of the hopping sequence.
5. TX checks for an ACK by polling the status register of the lt9010, but this time only twice.
6. If an ACK is received, continue, else go to step 4.
7. TX sends data packet on the next channel of the hopping sequence.
8. TX checks twice for ACKs again.
9. If ACK, goto 7, else send on last channel again.

The last step is only a guess, because I didn't bother to look for that specific case, but the rest is double checked and confirmed.

Either way, being able to receive ACKs is crucial for knowing what to do next. Without it, there is no way this is going to work.

If we don't get this resolved, the only other way to make this work will be using the real thing. LT8900 modules are available at Aliexpress ( www.aliexpress.com/snapshot/6474280604.h...derId=65629096534677 ), although I haven't seen any offers for singles. I ordered a lot of 10, so if anybody wants one, drop me a PM (be patient, though, deliveries from China can take up to two months).

With the original chip, building a working driver should be trivial, since I don't believe the data in the ACK packets to be relevant, other than letting the TX know the last packet was received correctly. This way it wouldn't even be necessary to understand how the hopping channels are chosen, because we know which bind packets relate to which data channels, so we could just choose one of the captured sequences.

I know, this is technically cheating, but unless someone figures out how to receive the lt8910 ACKs with an nRF, it's the only way I see.

I've added an attachment with all my code and a bit of sample data, so you can verify my findings and process.

File Attachment:

File Name: h1.tar.gz
File Size:170 KB

Really bad news ....
Sorry to say a mistake but I guess you checked that you are listening on the right channel for the ACK ?. Can you monitor the detection part of the nRF24L01 ?

alibenpeng wrote: 1. TX sends bind packet
2. TX checks for an ACK by polling the status register of the lt9010 32 times.
3. If an ACK is received, continue, else go to step 1.
4. TX sends data packet on the first channel of the hopping sequence.
5. TX checks for an ACK by polling the status register of the lt9010, but this time only twice.
6. If an ACK is received, continue, else go to step 4.
7. TX sends data packet on the next channel of the hopping sequence.
8. TX checks twice for ACKs again.
9. If ACK, goto 7, else send on last channel again.

You might try at steps 3, 6, and 9 just proceeding to the next step if an ACK is not received (maybe extend the number of retries in 3 and 6 to give the receiver a better chance to catch the packets). If no information is being passed back to the tx in the ACK it may be possible to "fly blind".

I don't want to dismiss the possibillity of an error on my part, so all suggestions are valid.

There's one thing I haven't tried yet, and that is trying to sniff packets with another nrf, the way it's done here: travisgoodspeed.blogspot.de/2011/02/prom...-nrf24l01s-duty.html

If that yields results, there's definetively a way to make this work.

But I've got my plate quite full atm, so it might be I while until I can try this. But since no special hardware (other than an nrf and an Arduino/MCU board of choice) is required to do this, anyone is invited to give it a try. The protocol code I posted works up to the point where the ACK would be received, so it could be used to try this.

Meanwhile I've got a XN297 to fight (working on a write-up of my findings, will publish in the JD395/CX10 thread, soon) and a reflow oven to finish.

About "flying blind": I doubt that will work, since the whole channel hopping logic seems to depend on receiving ACKs, so the TX knows when to change to the next channel.

After all I've read about the nrf, I'm quite confident that the last word on this hasn't been spoken yet.

What looks suspicious from what I've seen is the address. It is written in the datasheet that for 32-bit address (or SYNCWORD in terms of this datasheet) it is taken from Reg39[15:0],Reg36[15:0]. See description of register 32. That means address for nRF24L01 should be FD070405 (or some permutation thereof), not FD075501. What address do you actually see on the SDR?

I already got that one, look at my first post on this page.

Oh, sorry. I overlooked this part.

So have you seen this address on the radio waves? Judging by the documentation it is most likely in the order 0405FD07 or 050407FD.

I'm seeing this:

Have a look at the files I posted, it's all there.