Which are the *best* NRF24L01+ modules?

[NeverDie]

@Yveaux said:

@NeverDie just some tips when measuring small currents:

• use a stable power supply (e.g lab supply). Don't power from you pc or cheap switching powersupply.
• twist the leads to the current.
• use your scope to filter noise or add a lowpass filter using a capicitor+resistor on the signal going from the ucurrent to your scope

Thanks! Those are useful suggestions on how to proceed.

On my first attempt last night I used an Arduino Uno to drive the NRF24L01+. I eventually noticed that even without plugging the USB cable into my computer that the USB cable was a big source of noise when plugged into the Uno. When I did plug the USB cable into my computer, the noise got much worse. So, the USB cable has got to go.

New plan for the second attempt::

• Use an RFToy, instead of Uno, because it's a more compact way to plug-in the NRF24L01+ without having wires dangling all over, and because it can run off a coin cell battery, again without wires.

• Plug the NRF24L01+ into "tall" female header pins, and then plug those into the usual 2x4 header on the RFToy. Why? Because the leg of the tall VCC header pin I'm going to snip and (hopefully) replace with a 1 ohm sense resister. With luck there will be enough room on either side of the inline sense resister to connect up the oscilloscope and thereby do measurements without introducing long wires that might pick up noise.

[NeverDie]

BTW, I notice ManiacBug measures transmitter current with just a $50 multimeter and setting "endless trasmitter" mode. https://maniacbug.wordpress.com/2011/10/19/sensor-node/

Not sure how accurate that is though.

[NeverDie]

Lastly, I notice these "Noise Cancelling Techniques" from an Attiny datasheet, regtarding ADC measurements:
"Digital circuitry inside and outside the device generates EMI which might affect the accuracy of
analog measurements. When conversion accuracy is critical, the noise level can be reduced by
applying the following techniques:
• Keep analog signal paths as short as possible.
• Make sure analog tracks run over the analog ground plane.
• Keep analog tracks well away from high-speed switching digital tracks.
• If any port pin is used as a digital output, it mustn’t switch while a conversion is in progress.
• Place bypass capacitors as close to VCC and GND pins as possible."

[Zeph]

@NeverDie said:

@Zeph said:

@NeverDie

So, for the NRF24L01+, if you can call it that, this "blob module" is my final choice.

They are sounding potentially attractive. Here is some of what I am wondering.

1. Do they take more power when transmitting? When receiving? (Should be fairly easy to test) When sleeping? (Harder, needs micropower sensor)

2. Do they test (via registers) as nRF24L01 or nRF24L01+? And in particular, do they implement all the plus features (like ESB mode) other than the missing 250 Kbps data rate?

3. Are they compatible over the air with the Nordic chips (at 1Mbps/2Mbps)? In general, and in terms of using ESB mode. At least one clone/derivative chip got the NoAck bit (as sent over the air) reversed from Nordic, due to an error in the Nordic datasheet. (We don't see that in the registers, it only shows up in the OTA packet).

It would be good to be compatible with Nordic (and good clones), so that (1) we can swap in/out with other nRF chips we already have or purchase in the future and (2) in particular we can use the higher powered LNA+PA+antenna versions for a gateway or hub, which are not available in blob form AFAIK.

Do you have any answers to any of these yet? Anybody else? If they have ESB and are compatible OTA with Nordic, I think they are very attractive; the power usage is a secondary concern, and only for some nodes.

@Zeph: Regarding #2: What is ESB mode?

Enhanced ShockBurst, which is a mode added to the plus version by Nordic (nRF24L01+). Many of the clones and derivatives have it, some may not. It adds automatic ack and retry, and perhaps other features.

@hek is ESB mode still used in MySensors?

So far I haven't noticed incompatibility between the blob modules and other modules. I haven't extensively tested, though, so it's more of a casual observation. The data seems to get through. That said, I'm going to use only blob modules, so it's a moot issue to me. If it were a concern for you, they're cheap enough you could probably just replace whatever modules you have with blob modules, and then those potential issues disappear.

Have you found compatible blob modules with external antennas and/or LNA+PA (Low Noise Amplifier + Power Amplifier)?

Ironically, the only way to be certain all your modules are of the same type may be to use blob modules!

Until a new blob module type shows up.

Otherwise, as you outlined earlier, it's really hard to know what chip you actually have on any given module. I have less confidence in how randomly different chips might interoperate than when chps are all of one type, whatever that may be.

People here and elsewhere have had a lot of success in interoperation. However, that could be becoming more difficult, if too many fake chips get on the market.

BTW - I consider an openly described "nRF24L01+ compatible" chip to be a "derivative" if it openly modifies or extends the Nordic functions, a "clone" if it attempts to exactly mimic the Nordic chips. A "fake" is mislabeled and deceptive rather than being openly described as not Nordic.

I'm going to switchover from using Mirf (which got me started) to the same library mySensors uses :tmrh20. Then I'll be better able to run more detailed tests that are directly relevant. Either before or after that I'll try to measure power consumption, especially transmit power.

Good idea. I think TMRH20 has the best RF24 fork, and I've contributed slightly to it in its early days.

I look forward to your measurements. For battery operation with long sleep periods, the sleep current is also important.

If your module has higher RF transmit power (as I suspect), it might also be interesting to see what the current drain is when you drop the power a notch (ie: bring it closer to the Nordic part's RF output). The ideal might be if it can be run at about the same RF power as Nordic with similar PS current, OR could be boosted for more RF power at the cost of more PS current.

Bu the way, you might have a version which can boost its power still further. For example, the Si24R01 has a default boost of about 2-3 dBm over the Nordic, but can be set for 7 dBm! See https://github.com/solarkennedy/equail/tree/master/Libraries/RF24

Since transmit power is likely over 10mA you may be able to measure that without a MicroPower device. But you'll need such a device to measure sleep currents.

[NeverDie]

@Zeph said:

Have you found compatible blob modules with external antennas and/or LNA+PA (Low Noise Amplifier + Power Amplifier)?

Interesting idea. I don't recollect seeing any LNA+PA modules with blobs on them, but then again I haven't tried looking for such a thing. At least so far the simple blob module appears to have all the range I need.

[NeverDie]

@Zeph said:

For battery operation with long sleep periods, the sleep current is also important.

Good point. Noise might present a problem with measuring it, but I'll make an attempt. Perhaps a regular multimeter would be good enough for that, since (presumably) it would average any spikes? The result might be higher than the true number, and so be a worst case number. That's possibly OK though: if it turns out the worst case number is acceptable, then all is good.

[NeverDie]

@Zeph said:

I think TMRH20 has the best RF24 fork, and I've contributed slightly to it in its early days.

Excellent! In that case, do you happen to know off the top of your head: what's the simplest method or function call in TMRH20 for putting the NRF24L01+ to sleep? If I don't have to research that, I can jump ahead to taking a measurement of it sleeping, as per the above.

[Zeph]

@NeverDie
http://tmrh20.github.io/RF24/classRF24.html#aa0a51923a09ba4f3478aba9be0f8a6a1

You are going to need your Davy Jones uCurrent to measure sleeping current!

[NeverDie]

So, here are the current measurements on the blob module. I used a 1 ohm sense resister, so 1mv=1ma.

I wrote a short script to transmit a packet once every 10 milliseconds:

Now I'll zoom in progressively so you can see for yourself what the current is:

Doing this measurement is the first time I've ever used an oscilliscope (a Rigole 1054Z). Because the lines are kinda thick (noise, I guess), what would you say the current draw is during a transmission?

In this case, there is no echo receiver, and so whatever gets sent isn't received by anything.

[NeverDie]

Here is the simple test jig that I made, using a 1 ohm resistor:

Here it is mounted on the RFToy:

Here is how I hooked up the oscilloscope probe:

[NeverDie]

For comparison, here are the measurements taken on an ITEAD module:

So, purely eyeballing it, I'd say the Itead uses about, what, 13ma? The blob module is using maybe 20ma. Perhaps that difference in transmitter current, at least in part, explains the range difference that I observed.

[NeverDie]

For further comparison, here are the measurements taken on the red module from earlier in the thread:

Again, just eyeballing it, that looks like, what, maybe 23ma? Acually more than the blob module, it would seem.

[Yveaux]

@NeverDIe Very intersting measurements dude!
I have a gut feeling for some time that accurately measuring the transmission/reception current of a chip could be used to distinguish fake from real (and of course xray/boiling acid, which is impossible to do for the average consumer).
Both the width and level of the current spikes are different for each module.
Could you post the sketch used for measurement somewhere, so I can repeat your measurements?
I have some 100% genuine Nordic modules, which can be used for reference.

[NeverDie]

@Yveaux said:

@NeverDIe Very intersting measurements dude!
I have a gut feeling for some time that accurately measuring the transmission/reception current of a chip could be used to distinguish fake from real (and of course xray/boiling acid, which is impossible to do for the average consumer).
Both the width and level of the current spikes are different for each module.
Could you post the sketch used for measurement somewhere, so I can repeat your measurements?
I have some 100% genuine Nordic modules, which can be used for reference.

Here it is:

/*
 nRF24Sender Demo for RFToy
 
 This demo shows how to use RFToy to make a
 wireless temperature sensor. This is the
 sender module which transmits the current
 temperature value to a receiver module. The
 demo uses the Mirf library.
 
 This demo uses a 100K resistor and 100K
 thermistor to form a simple temperature 
 sensor. Pin A1 is used to read the value. 
 The connection is:
 VCC->100K->A1->thermistor->GND
  
 Written by Jonathan Goldin @ Rayshobby LLC
 Nov 2014
 For details, visit http://rayshobby.net/rftoy
*/

#include <SPI.h>
#include <Mirf.h>
#include <nRF24L01.h>
#include <MirfHardwareSpiDriver.h>
#include <U8glib.h>

U8GLIB_SSD1306_128X64 u8g(U8G_I2C_OPT_NONE);	// I2C / TWI 

void setup(){
  Serial.begin(115200);
  Serial.println("Starting...");
   
  /*
   Set ce and csn pins
   */
  
  Mirf.cePin = 17;
  Mirf.csnPin = 16;
  
  Mirf.spi = &MirfHardwareSpi;
  Mirf.init();
  
  /*
   * Configure reciving address.
   */
   
  Mirf.setRADDR((byte *)"clie1");
  
  /*
   * Set the payload length to sizeof(unsigned long) the
   * return type of millis().
   *
   * NB: payload on client and server must be the same.
   */
   
  //Mirf.payload = sizeof(long);
  Mirf.payload = sizeof(long);  
  /*
   * Write channel and payload config then power up reciver.
   */
   
  /*
   * To change channel:
   * 
   * Mirf.channel = 10;
   *
   * NB: Make sure channel is legal in your area.
   */
   
    // we use channel 90 as it is outside of WLAN bands 
  // or channels used by wireless surveillance cameras 
  //Mirf.channel = 90;
  
  Mirf.config();
  
    
  //This register value is not remembered between power cycles.
  //It defaults to 0x0F.
  //It should be initialized each time if different than 0x0F.
  Mirf.configRegister(RF_SETUP,0x07); //0x0F is 2mbps, max Tx power 
                                      //0x07 is 1mbps, max Tx power
                                      //0x2F is 250kbps, max Tx power.
  Serial.println("OTA datarate set to  1Mbps.  Transmit Power set to Maximum.");
  
  // Read and print RF_SETUP
 byte rf_setup = 0;
 Mirf.readRegister( RF_SETUP, &rf_setup, sizeof(rf_setup) );
 Serial.print( "rf_setup = " );
 Serial.println( rf_setup, BIN );
  // OLED
  u8g.firstPage();
  do{
    uint8_t h;
    u8g.setFont(u8g_font_10x20);
    u8g.setFontRefHeightText();
    u8g.setFontPosTop();
    h = u8g.getFontAscent()-u8g.getFontDescent();
    u8g.drawStr(29,(u8g.getHeight()-h)/2,"Tx Sender");
  } 
  while(u8g.nextPage());
  Mirf.setTADDR((byte *)"serv1");
  
  Serial.write("Sending...\r\n"); 
  delay(200);
} // End of *Setup*


long temp;
  int temp1;
  int temp2;
  long timeTxSent;
  long timeRxReceived;
  long roundTrip;
  byte age1=52;
  byte age2=11;
  long txCounter=0;
  long matchCount=0;
  long differentCount=0;
  long lostCount=0;
  long cumulativeRoundTrip=0;
  long averageRoundTrip=0;
  boolean packetLost=false;
  float packetErrorRate=0;  //no errors yet, and maybe there never will be.
  float lostPacketRate=0;  //no packets lost yet.
  const int statusFrequency=500;  //How many iterations of main loop before printing status info.
  long minRoundTrip=9999; //value will be driven down when program runs
  long maxRoundTrip=0;  //value will be driven up when program runs
  
void loop(){
   
  txCounter++;
  
  temp = txCounter;  //getTemp(resistance);
  
  
  timeTxSent=micros();
  Mirf.send((byte *)&temp);  

  while(Mirf.isSending()){
  }

  while ((micros() - timeTxSent) < 10000) {  //send at intervals of 10 milliseconds = 10,000 microseconds.
  }
 
}  //End of main loop. 

By the way, an RFToy is, from an IDE perspective, basically an 8Mhz Pro Mini.

[Yveaux]

@NeverDie Thanks, but it has quite some dependencies: Mirf, MirfHardwareSpiDriver & u8glib... I guess I have to strip it first.
Furthermore, which nrf24 library did you use? The one from tmrh20?

[NeverDie]

@Yveaux said:

@NeverDie Thanks, but it has quite some dependencies: Mirf, MirfHardwareSpiDriver & u8glib...
Furthermore, which nrf24 library did you use? The one from tmrh20?

Mirf is the nrf24 library. It's what the RFToy example used, so I started with it, because it "just worked" out of the box. It just happens to be as far as I've gotten so far. I haven't yet converted to tmrh20, which would look more familiar to you.

The start loop is just a left-over from when I was doing echo testing. I removed the OLED for this test because it was a potential source of interference, so any code related to that could be deleted. Obviously, most of the global variables aren't needed either. As far as transmitting once every 10ms, all the action happens in the main loop, which is pretty simple. It's all fairly basic, because up until I actually did it, I wasn't sure I could even get a sufficiently noiseless signal to measure. Luckily, running the RFtoy on a coincell, and because it's compact and without dangling wires, made that possible.

So, in terms of which library to install, at the moment the easiest would be to load the RFToy library.

Or you can wait until I convert over to tmrh20, and then you can follow along that way. I'll need to do that to do the sleep measurement, and because TMRH20 is currently the leading library to use--at least that's what ManiacBug seems to think.

Or, if you already know tmrh20, you could code it yourself. The pseudo-code is quite simple:

1. Note the time in microseconds.
2. Send a packet with a 4 byte data payload (i.e. a LONG)
3. Wait until the current time exceeds the time in step 1 by at least 10,000 microseconds.
4. Goto Step 1

What I don't know are the defaults for ACK's and # of retries, if any, in Mirf and in TMRH20. Aside from that possible difference, I would imagine the current draws are going to be the same in either library, wouldn't you?

Perhaps the cleanest thing would be to skip the libraries entirely and do it all purely by register manipulations. That'd probably be a diversion from where I want to go, but maybe not a huge diversion. After all, how hard could it be? Since the guys doing the mysensors library for the attiny85 appear to be stuck, I may eventually have to do it that way if I want to use an attiny85 (which I do).

[Yveaux]

@NeverDIe I committed a small sketch + NRF24 library which should essentially do the same as your sketch.
Please find it at https://github.com/Yveaux/NRF24_CurrentFingerprint.
I verified its behavior using the NRF24 sniffer:

Maybe we could compare register settings to be absolutely sure settings are identical:

Maybe you can repeat one of your measurements with this sketch, just to make sure we're measuring in the same way?

Currently I'm having a hard time measuring the actual current during transmit. I've not been able to get the individual spikes on the scope, not by using a uCurrent nor a single 1ohms resistor.

This is a uCurrent plot, set at 1mV/uA:

That boils down to 1.3mA peak during transmission... That can't be right?!

[Yveaux]

Small update: using a 10ohms resitor, the current profile looks like:

10mV/mA, so my module peaks at 11.7 mA. This module contains a 100% genuine Nordic nRF24L01+.

A module containing a proven fake nRF24L01+ (marked 1242AF), reveals following current profile:

This one peaks at 19.8mA !!

Register settings and on-air packets are identical.

For completenes my measurement setup:

• Lab supply, which powers USB isolator
• USB isolator between PC & Arduino (otherwise ground-loops mess things up when using a USB scope on the same PC)
• 10 ohms resistor

[NeverDie]

That's great!

The red module I tested (above) also used 1242AF. So, asuming the NRF chip in the Itead is genuine (which seems increasingly likely), then proportionately speaking, we're getting similar measurements.

Aside from the Picoscope, what is your test setup? You don't seem to be experiencing the fat scope lines that I am. Where is the NRF module in your photo? Is it being levitated by the wires in the photo? I'm surprised the wires don't seem to be picking up noise.

[Yveaux]

@NeverDie I added it to my previous post.

Overview of whole setup:

I never had issues with the wires picking up noise; at least not enough to distort communication. They're approx. 20cm long.

One more:

Module with nRF marked 1322DQ, supposedly genuine.
Also 11.2mA

Tried it with another, random 1242AF, which gave 21.4mA