Which are the *best* NRF24L01+ modules?

[NeverDie]

I just now noticed where you put your markers on your o-scope plot. There are two voltage increases, the second settles out higher than the first, and it looks like you're counting both. I would guess transmission doesn't really start until the higher voltage is reached, though, wouldn't you? That also is a better match to your 112us number. Perhaps the lower voltage corresponds to loading the buffer or something like that that doesn't need the higher transmit power.

If you don't mind my asking, why the interest in the transmission length? Doesn't it have to be pretty similar from one type of chip to another, or else they won't interoperate?

[NeverDie]

I think that's probably what's happening. I'm running on an 8Mhz Pro Mini (effectively), and you're running on a 16Mhz Uno. So, your first hump takes about half the time mine does ( is that right?), whereas both our second humps should take about the same amount of time. Ahhhhh..., except they don't. Your second hump appears to take longer than my blob module's second hump does. Mine is about 100us, and yours is about 150us? Is that what interests you?

[Zeph]

We would expect the data transmission per se to include a fixed prefix byte, 5 bytes of address, 9 bits of control, 4 bytes of payload, and 2 bytes of CRC (I think). 105 bits = 105uS. (I'm not sure where the 14 bytes in the calculation @Yveaux presented comes from. Either the nRF sends a 16 bit control but only documents 9 bits of it, or the nRF actually sends 9 bits but some software translates the 9th bit into a second byte for analysis purposes)

Before that there's something like 130 uS to power up and stabilize. And there could be additional time gaps before or after the data per se.

And of course before all that, there is the time to load the data and commands via SPI; power might potentially rise during that, I suppose.

Only the time to load commands and data would seem to care whether the uC is running at 8 or 16 MHz. The 105 uS data time should be the same, if they are OTA compatible. The 130 uS power up and stabilizing time could vary between chip designs.

Any way to see if the fake chip is one of those transmitting with more RF power output? (If it wastes more power doing the same job, not good. If it has the ability to run at higher power but can also be reduced to sip more carefully, that could be a win).

I look forward to your further testing. Maybe worth checking how much supply current is saved in the other transmit power settings.

[Zeph]

@NeverDie said:

It turns out my scope can do better than I thought. Here's the blob module again, but this time at 5mv/div.

How did you reduce the noise so much in your later scope captures?

[NeverDie]

@Zeph said:

@NeverDie said:

It turns out my scope can do better than I thought. Here's the blob module again, but this time at 5mv/div.

How did you reduce the noise so much in your later scope captures?

http://www.eevblog.com/forum/testgear/how-do-i-get-1mvdiv-on-the-1054z-i'm-only-getting-10mvdiv/
Also,
https://www.youtube.com/watch?v=DMXiD3dKYJc
How's that for timely?

[Zeph]

Suggestion: for the clone/fake chips, could you test whether they have the SI24R01 power control?

That is, set bit 1 of register 6 and see if they draw even more current. That should set the SI24R01 - or perhaps a derivative or clone of it - from 2-3 dBm to 7 dBm, which will probably mean using more supply current when the bit is 1 than when it's 0.

See the (currently) last couple of links in the OP of the fakes thread.

[Zeph]

You might also see if the second register bank can be selected (ACTIVATE+0x53) and read. See http://sigrok.org/wiki/Protocol_decoder:Nrf24l01#Variants_and_clones_of_the_chip from the penultimate link on the fakes thread.

If it has a second register bank then it's probably a BK24* series or a clone/derivative thereof. (Note that the contents of that second bank seem to be undocumented, at least in English). This niche is apparently popular enough that there are second level derivatives - for example advertised as being BK24* compatible which is in turn nRF24 compatible with extensions!

I did catch a reference somewhere that implied there was a real RSSI in the second register bank in some derivative; that could be handy if true.

---

There's a reference at that same link to the Nordic nRF24L01 (no plus) needing an ACTIVATE+0x73 command to enable certain features that are automatically available in the nRF24l01+.

This is not something I am aware of. I wonder if some features like ESB can be enabled on the non-plus version? Anyway, if so, this might also be a test which helps sort out clones - if they look like a non-plus derivative, do they respond to ACTIVATE+0x73? (the linked source does not suggest that 250 Kbps mode is one of the features which could be activated)

[NeverDie]

@Zeph: I'll may attempt those things tonight, though I'll be giving priority to moving over to TBRH20 first, as it will be better for comparisons if we minimize platform differences, as well as run the same library.

[Zeph]

@NeverDie said:

@Zeph: I'll may attempt those things tonight, though I'll be giving priority to moving over to TBRH20 first, as it will be better for comparisons if we minimize platform differences, as well as run the same library.

I agree that using the same library is good for cross comparison among multiple experimenters.

However, if it turns out that the power profile differs between libraries, on the same hardware sending the same packet, that would be worth some investigation as well to understand why (and perhaps learn how to optimize power). Yeah, that's a different question than detecting variants and understanding their advantages/disadvantages, but the same measurement hardware can be used.

---

I was wondering if a small cap across your sense resistor might smooth the traces a bit, and still tell us what we want to know - which is about average power, on a multi-microsecond timescale.

[Stric]

Using a non-scientific method; looking at the angle of battery discharge graphs over a week, I've noticed that the modules I got from ITEAD are draining batteries at about half the rate compared to an unknown (but probably fake) pretty good module.
ITEAD module; slightly under 1% per day
"other modules"; about 2% per day
This is when measuring and transmitting DHT21 data every minute.

[NeverDie]

@Zeph said:

@NeverDie said:

@Zeph: I'll may attempt those things tonight, though I'll be giving priority to moving over to TBRH20 first, as it will be better for comparisons if we minimize platform differences, as well as run the same library.

I agree that using the same library is good for cross comparison among multiple experimenters.

However, if it turns out that the power profile differs between libraries, on the same hardware sending the same packet, that would be worth some investigation as well to understand why (and perhaps learn how to optimize power). Yeah, that's a different question than detecting variants and understanding their advantages/disadvantages, but the same measurement hardware can be used.

---

I was wondering if a small cap across your sense resistor might smooth the traces a bit, and still tell us what we want to know - which is about average power, on a multi-microsecond timescale.

Sounds plausible. What cap value would you suggest? I pretty much skipped over learning analog electronics and haven't yet found the time to backfill that gap in my knowledge.

I've been collecting on eevblog and elsewhere some seemingly good on-point advice about how to improve my scope captures in this situation. I'll probably learn one technique at a time, as time permits, and phase it in gradually.

[Zeph]

I don't really know what a good value would be. Since it's across a 1 ohm resistor (in one case), and you probably want an RC time in the vicinity of microseconds, I'd start with around 1 uF and move up or down from there based on the scope trace. You may be able to just clamp the (short) leads of a cap to your probes to get a look, before soldering.

And I'll be interested in what other tips you collect that are useful.

[Zeph]

@Stric said:

Using a non-scientific method; looking at the angle of battery discharge graphs over a week, I've noticed that the modules I got from ITEAD are draining batteries at about half the rate compared to an unknown (but probably fake) pretty good module.
ITEAD module; slightly under 1% per day
"other modules"; about 2% per day
This is when measuring and transmitting DHT21 data every minute.

Good information. Hopefully, the scope will help sort out whether that faster drain is mostly during transmit/receive activity, or mostly during the idle time, or both.

[NeverDie]

@Zeph said:

I don't really know what a good value would be. Since it's across a 1 ohm resistor (in one case), and you probably want an RC time in the vicinity of microseconds, I'd start with around 1 uF and move up or down from there based on the scope trace. You may be able to just clamp the (short) leads of a cap to your probes to get a look, before soldering.

And I'll be interested in what other tips you collect that are useful.

Sounds good. We'll solve for the cap value using empiricism. :smile:

Also, I want to start measuring sleep current soon, because it may prove decisive as to whether a module must be rejected from further consideration because of its potential impact on battery life. Stric's data suggests there are significant differences to be found there. I suspect saving power is one of the harder engineering challenges--or, if not, at least an area where clones may get sloppy--and it might serve as a good separator.

[Zeph]

Agreed. If the module takes more power during transmit because it's putting out more RF, we might be able to back it off by using less than the maximum power settings, or use it in applications where it more rarely transmits.

But if it uses too much sleep current, it's a bad option for battery power.

[NeverDie]

@Zeph said:

Agreed. If the module takes more power during transmit because it's putting out more RF, we might be able to back it off by using less than the maximum power settings, or use it in applications where it more rarely transmits.

But if it uses too much sleep current, it's a bad option for battery power.

Exactly! You said it better than I did.

[AWI]

@NeverDie It should be possible to get some better (noiseless) measurements on the rigol scope.... at least if I look at what HARI is measuring on the ESP8266 current...

[NeverDie]

I hooked up the uCurrent inline with the Itead NRF24L01+ module, measured using a Fluke 87V multimeter, and I got these measurements:

Powered Down (Sleep): 0.6uA
Standby: 22.6uA

I'm satisfied that these are within error tolerances for the expected results.

Prior to that, I tested the blob module and seemed to get bizarre results. I'm going to go back and re-test now that I'm reasonably confident the test setup and measurements are working right.

I'm using an Arduino Uno. This was the test code I used:

/* Adapted by NeverDie on 8/11/2015 to facilitate uCurrent measurements.

/*
 Copyright (C) 2011 J. Coliz <maniacbug@ymail.com>

 This program is free software; you can redistribute it and/or
 modify it under the terms of the GNU General Public License
 version 2 as published by the Free Software Foundation.
 
 TMRh20 2014 - Updates to the library allow sleeping both in TX and RX modes:
      TX Mode: The radio can be powered down (.9uA current) and the Arduino slept using the watchdog timer
      RX Mode: The radio can be left in standby mode (22uA current) and the Arduino slept using an interrupt pin
 */

/**
 * Example RF Radio Ping Pair which Sleeps between Sends
 *
 * This is an example of how to use the RF24 class to create a battery-
 * efficient system.  It is just like the GettingStarted_CallResponse example, but the
 * ping node powers down the radio and sleeps the MCU after every
 * ping/pong cycle, and the receiver sleeps between payloads.
 *
 * Write this sketch to two different nodes,
 * connect the role_pin to ground on one.  The ping node sends the current
 * time to the pong node, which responds by sending the value back.  The ping
 * node can then see how long the whole cycle took.
 */

#include <SPI.h>
#include <avr/sleep.h>
#include <avr/power.h>
#include "nRF24L01.h"
#include "RF24.h"
#include "printf.h"


// Set up nRF24L01 radio on SPI bus plus pins 7 & 8
RF24 radio(7,8);

// sets the role of this unit in hardware.  Connect to GND to be the 'pong' receiver
// Leave open to be the 'ping' transmitter
const int role_pin = 5;

const uint64_t pipes[2] = { 0xF0F0F0F0E1LL, 0xF0F0F0F0D2LL };   // Radio pipe addresses for the 2 nodes to communicate.

// Role management
// Set up role.  This sketch uses the same software for all the nodes
// in this system.  Doing so greatly simplifies testing.  The hardware itself specifies
// which node it is.

// The various roles supported by this sketch
typedef enum { role_ping_out = 1, role_pong_back } role_e;

// The debug-friendly names of those roles
const char* role_friendly_name[] = { "invalid", "Ping out", "Pong back"};

// The role of the current running sketch
role_e role;

void setup(){

  // set up the role pin
  pinMode(role_pin, INPUT);
  digitalWrite(role_pin,HIGH);
  delay(20); // Just to get a solid reading on the role pin

  // read the address pin, establish our role
  if ( digitalRead(role_pin) )
    role = role_ping_out;
  else
    role = role_pong_back;

  Serial.begin(57600);
  printf_begin();
  printf("\n\rRF24/examples/pingpair_sleepy/\n\r");
  printf("ROLE: %s\n\r",role_friendly_name[role]);

  radio.begin();

  // Open pipes to other nodes for communication

  // This simple sketch opens two pipes for these two nodes to communicate
  // back and forth.
  // Open 'our' pipe for writing
  // Open the 'other' pipe for reading, in position #1 (we can have up to 5 pipes open for reading)

  if ( role == role_ping_out ) {
    radio.openWritingPipe(pipes[0]);
    radio.openReadingPipe(1,pipes[1]);
  } else {
    radio.openWritingPipe(pipes[1]);
    radio.openReadingPipe(1,pipes[0]);
  }

  
  // Dump the configuration of the rf unit for debugging
  radio.printDetails();
}

void loop(){

  radio.powerDown();              // NOTE: The radio MUST be powered back up again manually
  delay(5000);
  radio.powerUp();                // Power up the radio after sleeping
  delay(5000);
 
}

[NeverDie]

Yup, same as before. The measurements on the blob module are:
-43.3ua and -42.8ua.

I'm not sure which is standby current and which is sleep current. I definitely was not expecting a negative current. There's not much difference in magnitude between the two currents.

So, I tried it on a different blob module:
-43.5ua and -42.9ua.
Essentially the same results.

Truly bizarre. What's going on? I'm powering the Uno through a roughly 9V battery pack of Eneloop batteries via its barrel jack, as with the earlier measurement of the Itead module, whose measurements not only met expected value, but they were positive currents, not negative ones.

Here's the red module:
Powered Down (Sleep): 1.6uA
Standby: 13.9uA

Here's an Addicore module from Amazon:
Powered Down (Sleep): 1.8uA
Standyby: 16.3uA

It's a very simple test. I'd say anyone can do these measurements, provided they have a good way to measure microamps.

[rvendrame]

@NeverDie said:

-43.3ua and -42.8ua.

So the blob module is so good that it is charging your batteries ;-)