EAchine E012

updated again, I made a mistake with the power limitation.
www.dropbox.com/sh/8dd1hvli0qt7fw4/AABlW...kQJymHNNEfjViga?dl=0

Power is now limited to 30mW for this protocol.

Have you tried 10mW or lower ?
Mine is working fine up to 30mW, but seems ymmv :/

edit: I'll take a look at the signal with the hackrf to try to understand what's happening, but I doubt I can do anything ... Maybe use the cc2500 instead of the nrf24l01 as it can be fine-tuned, but I'm not sure it can do gfsk @ 1Mbps (edit2: no it can't ...).

Also, try with a few different transmitter IDs to check if some frequencies are working better than others.

I had a look at the signals, perhaps that explains the issue.
During bind, expected center frequency is 2460 MHz.

With the nrf24l01, there's a +33 kHz drift:


While with the hs6200 there's a -44 kHz drift (also, the signal is pretty dirty ):


Those drifts in opposite direction (77 kHz) could explain the problem, maybe a RF expert can confirm that ?

What do you mean ?
The only way to fine-tune the drift on the nrf24l01 would be to replace the load capacitors that are around its crystal, but that's not a proper solution, except if the only model you want to control with the nrf24 is the E012

I'll also trim the antenna on the Rx, I noticed it's almost 40mm long ...

Ah Ok, that's not possible, we only have 1 MHz granularity.

Have you tried with 10mW TX power and a few different TX IDs ?

I confirm link quality is very dependent of the frequency, I uploaded 2 special builds to my dropbox folder with a protocol option to directly set the frequency used by the protocol, give it a try, mine work best around 2430 MHz + 10mW Tx power.
www.dropbox.com/sh/8dd1hvli0qt7fw4/AABlW...kQJymHNNEfjViga?dl=0

Ok, I can't do anything better with the nrf24l01 ...
I consider it's not good enough to be pushed into main branch for now.

The CYRF6936 can do gfsk @ 1 Mbps, I've to check if it can be fine-tuned ...

Ah, looks like the cyrf6936 could be a good candidate:

In GFSK mode, data is transmitted at 1 Mbps, without any DSSS: cool, that's exactly what we need, no DSSS and no Pseudo Noise !

Registers 0x1b & 0x1c: TX_OFFSET
Synthesizer offset value. This is a 12 bit 2’s complement signed number, which may be used to offset the transmit frequency of the device by up to ±1.5 MHz. A positive value increases the transmit frequency, and a negative value reduces the transmit frequency. A value of +1 increases the transmit frequency by 732.6 Hz; a value of –1 decreases the transmit frequency by 732.6 Hz

I've never worked with the cyrf6936 yet, that's a good opportunity, but it might take some time

If only the nrf24l01 had this feature as well ...

Hack in progress, I still can't promise I'll be able to make it work, I've to circumvent some issues, but first results seem promising




cyrf in gfsk mode, SOP & CRC disabled, transmitting 0x55aa preamble (customable) + 00 ff 00 ff 00 ... 16 byte payload

... now I've to be able to send a payload longer than 16 bytes (27 bytes are needed in total for the E012 protocol, including HS6200 preamble), with the cyrf that's possible to send a payload up to 255 bytes (or 40, that's not clear ...) but it has to be done in 16 byte bursts, the fifo has to be refilled while the radio is transmitting ... Fortunately interrupts are triggered to find out when half or all bytes-1 of the fifo have been sent. I've to experiment and get the timing right.

I think I've hit a wall

I'm somewhat able to receive packets sent by the cyrf with a nrf24l01, but they're corrupt and I think I understand why, nrf24l01 (and hs6200) has ±160 kHz gfsk deviation while the cyrf has ~±300 kHz... and it's not customable.

So, in the end I can't do anything better than with the nrf24l01, they're the 2 only radio we're supporting that can do gfsk @ 1 Mbps.

Oh well, at least I've learned how to use the cyrf, I did not waste my time ...

So:
- it kinda works with the nrf24l01
- no way to make it work with the cyrf6936
- now let's try with gnuradio / HackRF


Seems to work but there's a 1 second latency, probably because hackrf/osmocom buffer is too large. I think I've found someone that should be able to help me with that...

I got it working perfectly with the BladeRF, no more latency:

This is known issue with the hackrf (no customable USB buffer size), but it should be fixed eventually.

Still, I'm not really sure of what the problem is with hs6200/nrf24l01 as they both can work with quite a bit of frequency drift, I've checked with SDR ...