Which are the *best* NRF24L01+ modules?
-
@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 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.
-
Look at this RFM75 module. It's got the blob. It sounds like a bad horror movie.
-
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.
-
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 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 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.
@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.
-
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.
-
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
-
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.
@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. -
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).
@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 ;-)
-
The power fingerprint seems to work very well. I suggest you use that. The work is already done (see above).
-
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 -
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@nftrix I'm using nRF24L01+'s for all of my applications at the moment still with no issues at all. They are running perfectly smooth, without interference off of anything. I personally just soldered my caps straight onto my radios when they arrived, before even testing them. If you're not restricted by space, just solder/attach them straight to the module as they arrive through your door.
As with your issue that you have shown, i would say give the cap a try before jumping to conclusions as it appears that its sending out a message asking the gateway to reply back with a connection package but its not finding it (I may be wrong, but that is what i see there). Give it a try and report back with your findings :)
-
@nftrix Another way to deal with the fact that some nrf24l01+ modules can not find the gateway, is by reducing the transmit powerlevel. Some of these modules "scream" so loud, that the receiver on the gateway gets a distorted signal and fails to recognise a proper packet.
In my house I have had to reduce the transmit levels of most of my modules, and as a result they now all connect to the gateway without any caps.
The NRF24 on the gateway does have a potent powersupply and caps on the board it is mounted on, but my sensornodes do not need it. -
@samuel235 @GertSanders thanks for the feedback. I'm picking up some caps from the store today and will try them out. As for the power settings, I've been adjusting the data rate settings between 250kbs, 1 and 2Mbps but am seeing the same results. If the caps don't fix the issue, i'll start another thread to work through the problem, don't want to hijack this thread.
Just wanted to confirm that the findings here did not make the NRF's on the store "not recommended" or anything.
-
@samuel235 @GertSanders thanks for the feedback. I'm picking up some caps from the store today and will try them out. As for the power settings, I've been adjusting the data rate settings between 250kbs, 1 and 2Mbps but am seeing the same results. If the caps don't fix the issue, i'll start another thread to work through the problem, don't want to hijack this thread.
Just wanted to confirm that the findings here did not make the NRF's on the store "not recommended" or anything.
@nftrix said:
Just wanted to confirm that the findings here did not make the NRF's on the store "not recommended" or anything.
Most definitely not. They're more than recommended from most of us i think, from a quick look at the forum topics anyway.
-
The speeds settings (250k, 1M, 2M) are not the same as the power settings (Low, Med, High, Max).
-
@Fabien said:
@NeverDie : Can you please post the sketch you use to test your NRFs modules. I just recieve 10 today from Itead. Same packaging that the ones you recieve. I just want to compare result in same conditions.
OK, sure. It started out as RF toy code, and then I just evolved it. It contains a lot of commented out code that I haven't bothered to delete. If that gets in the way of your understanding, just delete the code that's commented out. Aside from that, it's straightforward.
Here's the main transmitter code. After compiling and uploading, you should open a serial window on your computer to read the statistics it prints out:
/* 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++; packetLost = false; //It can't be lost, because it hasn't even been sent yet. temp = txCounter; //getTemp(resistance); temp1=temp; timeTxSent=micros(); Mirf.send((byte *)&temp); while(Mirf.isSending()){ } /* Serial.write("temp="); Serial.print(temp,DEC); Serial.write("\r\n"); Serial.write("temp1="); Serial.print(temp1,DEC); Serial.write("\r\n"); Serial.write("Finished sending.\r\n"); */ //delay(10); unsigned long time = millis(); while ((!packetLost) && (!Mirf.dataReady())){ //Serial.println("Waiting"); if ( ( millis() - time ) > 8 ) { //Serial.println("Timeout on response from Rx Echo Reflector!"); lostCount++; packetLost=true; } } if (!packetLost) { Mirf.getData((byte *) &temp); timeRxReceived=micros(); temp2 = temp; roundTrip = timeRxReceived - timeTxSent; if (roundTrip < minRoundTrip) { minRoundTrip=roundTrip; } if (roundTrip > maxRoundTrip) { maxRoundTrip = roundTrip; } if(temp1 == temp2){ matchCount++; cumulativeRoundTrip += roundTrip; averageRoundTrip = cumulativeRoundTrip/(txCounter-lostCount-differentCount); } else { differentCount++; Serial.println("***DIFFERENT**"); Serial.write("temp1="); Serial.println(temp1, BIN); Serial.write("temp2="); Serial.println(temp2, BIN); } if ((txCounter%statusFrequency)==0) { /* if(temp1 == temp2){ Serial.print("Match"); } else { Serial.println("***DIFFERENT**"); } Serial.write(","); */ } } lostPacketRate = 100*((float)(lostCount))/((float)txCounter); if ((txCounter%statusFrequency)==0) { Serial.print(txCounter); Serial.write(",lost="); Serial.print(lostPacketRate); /* Serial.write("%,T="); Serial.print(temp,DEC); //Serial.write(". "); Serial.write(",T1="); Serial.print(temp1,DEC); //Serial.write(". "); Serial.write(",T2="); Serial.print(temp2,DEC); */ Serial.write("%,RT="); Serial.print(roundTrip,DEC); Serial.write(",minRT="); Serial.print(minRoundTrip); Serial.write(",maxRT="); Serial.print(maxRoundTrip); Serial.write(",aRT="); Serial.print(averageRoundTrip,DEC); Serial.print(",#lost="); Serial.print(lostCount); //Serial.write(",mat="); //Serial.print(matchCount); Serial.write(",diff="); Serial.print(differentCount); Serial.write("\r\n"); delay(100); //give time for it to print out //txCounter = 0; //restart gathering statistics } /* delay(1000); // keep the 'sending' message displayed on OLED for 1 sec u8g.firstPage(); do{ } while(u8g.nextPage()); delay(2000); // wait for 2 seconds till next transmission */ } //End of main loop.Here's the code for the receiver node. It doesn't need to be plugged into a computer:
/* nRF24Receiver Demo for RFToy This demo shows how to use RFToy to make a wireless temperature sensor. This is the receiver module which displays the received temperature value to OLED. The demo uses the Mirf library. 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("Echo Receiver. Listening"); Mirf.cePin = 17; //??? Mirf.csnPin = 16; //??? /* * Set the SPI Driver. */ Mirf.spi = &MirfHardwareSpi; /* * Setup pins / SPI. */ Mirf.init(); /* * Configure reciving address. */ Mirf.setRADDR((byte *)"serv1"); /* * 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); /* * Write channel and payload config then power up reciver. */ // 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 ); u8g.firstPage(); do{ uint8_t h; u8g.setFont(u8g_font_10x20); u8g.setFontRefHeightText(); u8g.setFontPosTop(); h = u8g.getFontAscent()-u8g.getFontDescent(); u8g.drawStr(19,(u8g.getHeight()-h)/2,"Echo Rx"); } while(u8g.nextPage()); } //End of *Setup* procedure void loop(){ /* * A buffer to store the data. */ byte data[Mirf.payload]; /* * If a packet has been recived. * * isSending also restores listening mode when it * transitions from true to false. */ if(!Mirf.isSending() && Mirf.dataReady()){ //Serial.print("Got packet: "); /* * Get load the packet into the buffer. */ Mirf.getData(data); // Set the send address. Mirf.setTADDR((byte *)"clie1"); /* * Send the data back to the client. */ Mirf.send(data); /* * Wait untill sending has finished * * NB: isSending returns the chip to receving after returning true. */ //Serial.println("Reply sent."); } }As background, here's a link to the RFToy:
http://rayshobby.net/rftoy/
Links to the RFToy library, as well as the hardware design, can be found there. It's all open source.This shows the pin assignments: https://github.com/rayshobby/rftoy-hw/blob/master/RFToy.png
You'll need a pinout diagram to match-up those internal pins to the physical pins of whatever Arduino you're using. For instance, for an Uno, here's a pinout diagram which maps internal pins to physical pins:
http://marcusjenkins.com/wp-content/uploads/2014/06/ARDUINO_V2.png
That way you'll know how to properly wire-up your NRF24L01+ so that it works properly with the library code.So, I did that just now and tested it on the UNO, and so for the UNO the simplified wiring directions are:
NRF24L01+Pin --- --> Uno Female Header Pin
GND (1) ----------------------------> GND
VCC (2) -----------------------------> 3.3V
CE (3) ------------------------------> A3
CSN (4) -------------------------------> A2
SCK (5) --------------------------------> D13
MOSI (6) --------------------------------> D11
MISO (7) --------------------------------> D12
IRQ(8) ---------------------------------> n/aThe RFToy has an OLED screen that gets written to. You can remove that code if you wish, but leaving it in does no harm, even if you don't have an OLED screen on your arduino. I modified the code so that it's only written to during the setup loop, so regardless it shouldn't interfere with any of the measurements taken in the main loop..
Hope that helps!
-
@NeverDie
I just compiled and uploaded your code to two uno's and all I am getting is
OTA datarate set to 1Mbps. Transmit Power set to Maximum.
rf_setup = 111
Sending...how long does it take to get any output on the serial monitor?
@parachutesj
I was using 3.3v pro mini's, not uno's. Maybe you have a level shift problem.
