Which are the *best* NRF24L01+ modules?

[NeverDie]

I was able to sharpen my o-scope pictures by turning on Hi-Res mode. With this better detail, a lot more is apparently different between the genuine modules and the blob modules.

Here are some transmit shots of the new genuine modules:

and here are some shots of the blob module, also now taken at Hi-Res on the o-scope:

As you can see now that I'm using Hi-Res mode, even the shapes of the waveforms are completely different looking.

Reminder: because I'm now using a 1/2 ohm sense resister, each verticle devision now represents 4ma.
So, eyeballing it, the genuine chips are using about 12ma for their transmit current, whereas the blob module chips are closer to about 18ma.

Also, the second peak after the first peak is higher on the genuine chips, whereas it is lower on the blob chips. I don't know what those peaks represent.

[NeverDie]

So, for completeness, here's the Hi-Res o-scope pictures of the red module, whose tracecode suggests it may be fake, as previously noted:

In this case, one thing that jumps out as different than the other two is that the height of the second tall peak is much lower than the first tall peak. In the genuine chip, the second tall peak is actually higher than the first tall peak, so it's quite a distinctive difference.

[NeverDie]

I have a hypothesis for what's going on. According to the NRF24L01+ datasheet,

• 11.3mA TX at 0dBm output power
• 13.5mA RX at 2Mbps air data rate

Therefore, I think Mirf probably does a TX, waits for an ACK, and if it isn't found, it tries 3 more times. Therefore, on the genuine chip, you see one tall peak for TX, followed by a second taller peak for RX. It does it again3 times, because, for measurement repeatability, I deliberately removed anything that might receive or ACK its transmissions. So, all the ACKs fail and it transmits 3 more times after the first transmission. That's the hypothesis.

Anyhow, now that I've switched over to the TBRH20 library, this could be checked more easily.

Although already shown above, here it is again for easy reference:

If the hypothesis is true, then the TX and RX currents measure out to exactly what one would expect based on the above specs in the datasheet.

Also, it would explain why it is that before and after the transmission burst, the measured current is the same as the second peak current. That's because the chip is in RX mode between transmissions.

So, from the looks of things, if it doesn't receive an ACK within 250uSeconds (as measured above) after transmission ends, it tries again (up to 3 times). In fact, according to the datasheet, the default for ARD (automatic retransmission delay) is 250 uSeconds. It appears to match up exactly!

[NeverDie]

So, indeed, that's what's happening.

I just switched to TBRH20 and wrote a simple loop to send a packet every 100ms, and to not be listening inbetween. Apparently the default behavior for TBRH20 is to try 16 times to send the packet before giving up!

As before, this is just one shot on the oscilliscope. I'm zooming in on each successive screen by adjusting the time base. I did the measurement on one of the modules with a "genuine" Nordic chip.

I would guess that in this case TBRH20 is managing the retries in software on the Arduino rather than utilizing the radio chip, because the time between retries is much larger: about 1.5ms.

BTW, I switched to a Mega2560 to do the testing, and, although I haven't yet investigated it, I think the new type of noise that's now evident is probably from the 5v and/or 3v voltage regulator. It doesn't obscure the view, so for now I'm not really concerned.

[NeverDie]

Nailed it. If I explicitly turn ACKing off, then:

What's shown is just a single transmit pulse at 100ms intervals, and with no RX current afterward, as would be required if an ACK was being listened for.

Bottom line: now that the anatomy of the Tx current is known, it should help spot and identify clone chips by comparing their Tx current waveform against that of chips known to be genuine.

[Zeph]

You've nailed it indeed.

I'm guessing that the first peak on the blob chips is higher because it has higher RF output as well.

If you set bit 0 of register 6 to a 1 on the Blob (unused on the nRF24L01+), and if this chip is a Si24R01 or derivative, it will switch from +2~3dBm to +7dBm RF output, and probably draw even more power.

[Zeph]

@TD22057 said:

I'm seeing similar results with my radios. ... The two types seem to be able to talk to each other OK but if set two modules at opposite ends of the house (with 2 exterior walls in between as well), the cheap modules still connect and the genuine ones don't. I'm assuming this is similar to what you're seeing with the real modules having a lower transmit power.

My hypothesis: The blob units have more transmit power (perhaps being Si24R01 or related) and thus a higher first peak, but perhaps no better receive sensitivity.

If so a blob to genuine would have at least as good a range as blob to blob, and a genuine to blob would have similar range as a genuine to genuine.

Of course testing that may involve a one way transmission, where we check for lost packets on the receive side (without expecting a round trip).

If however the blobs have managed to beat the genuine receive sensitivity, then they are really hot stuff!

[NeverDie]

@Zeph said:

@TD22057 said:

I'm seeing similar results with my radios. ... The two types seem to be able to talk to each other OK but if set two modules at opposite ends of the house (with 2 exterior walls in between as well), the cheap modules still connect and the genuine ones don't. I'm assuming this is similar to what you're seeing with the real modules having a lower transmit power.

My hypothesis: The blob units have more transmit power (perhaps being Si24R01 or related) and thus a higher first peak, but perhaps no better receive sensitivity.

If so a blob to genuine would have at least as good a range as blob to blob, and a genuine to blob would have similar range as a genuine to genuine.

Of course testing that may involve a one way transmission, where we check for lost packets on the receive side (without expecting a round trip).

If however the blobs have managed to beat the genuine receive sensitivity, then they are really hot stuff!

@Zeph I'm pretty sure the blob modules are using the RFM75 die because the above mA and uA measurements appear to be a good match for the electrical specification on page 22 of http://www.hoperf.com/upload/rf/RFM75 Datasheet v1.0.pdf

Makes me wonder if it would perform the same or differently if it were installed on the manufacturer recommended PCB along with all the recommended passive components, because you can buy proper RFM75 modules cheaper than "genuine" NRF24L01+ modules.

[gbfromhb]

Look at this RFM75 module. It's got the blob. It sounds like a bad horror movie.

http://m.ebay.com/itm/171874462905

[NeverDie]

I've since learned that "COB Module" would be a more proper term, but I didn't know that when I started this thread. COB = "Chip on Board" The bare semiconductor die is wire bonded directly to the board. I don't know why, but apparently that's cheaper by what, a penny or two? Once that work is done, the epoxy goes on to protect it.

[NeverDie]

@Zeph said:

You've nailed it indeed.

I'm guessing that the first peak on the blob chips is higher because it has higher RF output as well.

If you set bit 0 of register 6 to a 1 on the Blob (unused on the nRF24L01+), and if this chip is a Si24R01 or derivative, it will switch from +2~3dBm to +7dBm RF output, and probably draw even more power.

Based on the mA and uA measurements above, it's likely that the Addicore modules and the red modules are based on the Si24R01, because they are a reasonably good match for the electrical specifications on page 22 of the Si24R01 datasheet: https://www.dropbox.com/sh/kdenpdg60v5hzbd/AACG1jxQR71fkzX-U4a7CIh0a/SI24R1 (cn).pdf?dl=0

That's all the modules that I have. I'm pretty confident everything has been properly ID'd. :smile:

[Zeph]

@NeverDie said:

@Zeph I'm pretty sure the blob modules are using the RFM75 die because the above mA and uA measurements appear to be a good match for the electrical specification on page 22 of http://www.hoperf.com/upload/rf/RFM75 Datasheet v1.0.pdf

Could you see if they work on channels above 84? The RFM75 lists fewer channels than the nRF24L01+, which is probably for regulatory rather than technical reasons (the frequency band does extend further in another part of the spec). I would be curious to know if channel 125 works, for example.

[NeverDie]

I previously tested the COB modules as working on channel 112, both with each other and interoperating with "genuine" NRF24L01+ modules.

This is one of the areas where there's a disconnect between what the HopeRF website says and what the electrical specs on the datasheet I referenced above say regarding the RFM75. The website says it only goes up to 2.450Ghz or something, and the datasheet specs say it goes all the way to 2.5Ghz. I'm assuming the datasheet is right, not the website.

The modules are cheap enough that I may order a couple, just to see if they perform a whole lot better when soldered to proper PCBs and the correct passives are used. It may be moot though if I decide to use RFM69x's instead.

[robosensor]

Is it possible to use NRF24LE1 (L01+MCU) as simple NRF24L01+? Are there any of these LE1 modules fake too?

Question inspired by this topic: http://forum.mysensors.org/topic/1774/introducing-mysensors-on-nrf24le1

[Avamander]

Would it be possible that someone would create a sketch that would detect fake modules and warn about discrepancies? I would hate to spend more money on fake modules.

[Yveaux]

@Avamander said:

Would it be possible that someone would create a sketch that would detect fake modules and warn about discrepancies?

Yes, but currently the 'scene' is not aware of a decent way to distinguish fake from real.
As soon as we know how to determine this a sketch can be written.

[Avamander]

Speed is one thing that can be tested, fakes are slower. Packet loss too. ACK with dynamic payloads too. Registers that exist only on fakes (the datasheet error one for example).

[Yveaux]

@Avamander said:

Speed is one thing that can be tested, fakes are slower.

I suppose you mean the maximum bitrate possible?
Most fakes will handle all nRF bitrates flawlessly.

Packet loss too

I have not seen any proof of differences in reception between reals & fakes.
The construction & orientation of the module on which the nRF is mounten will IMHO mostly determine the transmission quality.
I'd like to see an algorithm which reliably determines fakes from real using packet loss.

ACK with dynamic payloads too.

This is claimed to be a difference and it might be true for some modules, but all my fakes behave identical on-air compared with real nRF's (verified by sniffer)

Registers that exist only on fakes (the datasheet error one for example).

Again, the web is full of contradictory reports...

Most of these fakes are very good copies and I doubt if anyone can find a software-only solution to determine real from fakes reliably.
Our best bet would be to create an accurate power fingerprint of a genuine module and compare the fakes to it -- that's the only more or less consistent difference I've seen so far.

Remember that even Nordic will perform an X-Ray on a suspicious nRF to be absolutely sure if its genuine or not.

That said -- be my guest and try to create a sketch. The scene will thank you for it if you succeed ;-)

[NeverDie]

The power fingerprint seems to work very well. I suggest you use that. The work is already done (see above).

[nftrix]

Lots of useful info here, thanks everyone for the hard work!

Based on the findings, are the NRF24L01+ modules linked on the shop page still the best recommendation? Is it worth adding the cap as a required part of the setup to increase reliability?

Just received 20 units from the vendor linked through aliexpress and am working through issues which appear to be related to the radios (not using cap's currently)

Starting...
find parent
send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:
find parent
send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:
find parent
send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:
find parent
send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:
find parent
send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:
sensor started, id=255, parent=255, distance=255