Which are the *best* NRF24L01+ modules?
-
@NeverDie said:
Did you use the microscope for the module shots also, or just the NRF chip
Only the chips were shot using my microscope. The field of view is simply too small to shoot the whole module.
Only > Since you have a nice module collection that spans different NRF chips and also different module types, have you noticed whether any of your modules stand out head-and-shoulders above the others as having clearly better performance?
No, but I had troubles mixing different modules in the past (even the NO_ACKs were involved iirr), so I'm very interested to know which ones are genuine.
@NeverDie said:
Anyone know by what method Nordic prints the lettering on the chips?
Yes, it's in the data sheet. The date code is in YYWWLL which stands for year & week of production, an LL indicates wafer lot. The top right code indicates the production location (first letter) followed by optional letter indicating engineering sample.
Nordic is fabless so only they know what the location letters mean.
The text is normally written using a laser scriber, so no ink is involved.
Thinking of it, differences in font/thickness etc. can be caused by different laser scribers at different production facilities (or even within one facility) so I'm starting to doubt if it will help us in distinguishing fakes from genuine. -
@NeverDie said:
Anyone know by what method Nordic prints the lettering on the chips?
Yes, it's in the data sheet. The date code is in YYWWLL which stands for year & week of production, an LL indicates wafer lot. The top right code indicates the production location (first letter) followed by optional letter indicating engineering sample.
Nordic is fabless so only they know what the location letters mean.
The text is normally written using a laser scriber, so no ink is involved.
Thinking of it, differences in font/thickness etc. can be caused by different laser scribers at different production facilities (or even within one facility) so I'm starting to doubt if it will help us in distinguishing fakes from genuine.@Yveaux said:
@NeverDie said:
Anyone know by what method Nordic prints the lettering on the chips?
Yes, it's in the data sheet. The date code is in YYWWLL which stands for year & week of production, an LL indicates wafer lot. The top right code indicates the production location (first letter) followed by optional letter indicating engineering sample.
Nordic is fabless so only they know what the location letters mean.
The text is normally written using a laser scriber, so no ink is involved.
Thinking of it, differences in font/thickness etc. can be caused by different laser scribers at different production facilities (or even within one facility) so I'm starting to doubt if it will help us in distinguishing fakes from genuine.Thanks for pointing that out. Looking at the version 1.0 spec sheet (available at http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24L01P), I see it covered in section 13.1 and 13.2.
Curiously, according to the spec sheet, the chips should be marked "nRF", not "NRF".
-
@Yveaux said:
@NeverDie said:
Anyone know by what method Nordic prints the lettering on the chips?
Yes, it's in the data sheet. The date code is in YYWWLL which stands for year & week of production, an LL indicates wafer lot. The top right code indicates the production location (first letter) followed by optional letter indicating engineering sample.
Nordic is fabless so only they know what the location letters mean.
The text is normally written using a laser scriber, so no ink is involved.
Thinking of it, differences in font/thickness etc. can be caused by different laser scribers at different production facilities (or even within one facility) so I'm starting to doubt if it will help us in distinguishing fakes from genuine.Thanks for pointing that out. Looking at the version 1.0 spec sheet (available at http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24L01P), I see it covered in section 13.1 and 13.2.
Curiously, according to the spec sheet, the chips should be marked "nRF", not "NRF".
-
My "regular" modules were bought from gc_supermarket and the NRF chips all have the following printing. There is no circle in the center of the +.
. NRF T 24L01+ 1420JBMy LNA/PA modules were bought from alice11011983 and the NRF chips have the following printing. There is a circle in the center of the + on the first set, but not the second set.
. NRF M 24L01+ 1431FC. NRF O 24L01+ 1417GPI'll try to grab some pics this weekend.
Cheers
Al@Sparkman said:
My "regular" modules were bought from gc_supermarket and the NRF chips all have the following printing. There is no circle in the center of the +.
. NRF T 24L01+ 1420JBMy LNA/PA modules were bought from alice11011983 and the NRF chips have the following printing. There is a circle in the center of the + on the first set, but not the second set.
. NRF M 24L01+ 1431FC. NRF O 24L01+ 1417GPI'll try to grab some pics this weekend.
Cheers
AlHi Al,
Funny that you happen to mention gc_supermarket, because just yesterday I was noticing that they had good pricing on blob modules. These visually resemble the two blob modules I have and which seem to perform quite well at 1mbps air datarate. Intriguingly, the listing title says "Power enhanced version Compatible NRF24L01" and in the description it says:
"This module is design to solve the problem of small power in NRF24L01 module, its distance is far away than NRF24L01
Please download the data in below link
http://www.ai-thinker.com/forum.php?mod=viewthread&tid=411&extra=page%3D1 "It would be easy to dismiss this as gibberish or as a failed attempt at chinglish, except for the fact that my two blob modules do, in fact, seem to have much better range than any of the "regular" NRF24L01+ modules I've tried so far. So, whether deserved or not, that does seem to give gc_supermarket more credability in my eyes than a lot of other re-sellers. Also, whether by luck or intent, they referred to it as "NRF24L01", not "NRF24L01+", which is also closer to reality, as it doesn't support 250kbps. So, in my book they get some credibility points for that also.
Have your transactions to date with gc_supermarket gone well?
-
@Sparkman said:
My "regular" modules were bought from gc_supermarket and the NRF chips all have the following printing. There is no circle in the center of the +.
. NRF T 24L01+ 1420JBMy LNA/PA modules were bought from alice11011983 and the NRF chips have the following printing. There is a circle in the center of the + on the first set, but not the second set.
. NRF M 24L01+ 1431FC. NRF O 24L01+ 1417GPI'll try to grab some pics this weekend.
Cheers
AlHi Al,
Funny that you happen to mention gc_supermarket, because just yesterday I was noticing that they had good pricing on blob modules. These visually resemble the two blob modules I have and which seem to perform quite well at 1mbps air datarate. Intriguingly, the listing title says "Power enhanced version Compatible NRF24L01" and in the description it says:
"This module is design to solve the problem of small power in NRF24L01 module, its distance is far away than NRF24L01
Please download the data in below link
http://www.ai-thinker.com/forum.php?mod=viewthread&tid=411&extra=page%3D1 "It would be easy to dismiss this as gibberish or as a failed attempt at chinglish, except for the fact that my two blob modules do, in fact, seem to have much better range than any of the "regular" NRF24L01+ modules I've tried so far. So, whether deserved or not, that does seem to give gc_supermarket more credability in my eyes than a lot of other re-sellers. Also, whether by luck or intent, they referred to it as "NRF24L01", not "NRF24L01+", which is also closer to reality, as it doesn't support 250kbps. So, in my book they get some credibility points for that also.
Have your transactions to date with gc_supermarket gone well?
@NeverDie said:
Have your transactions to date with gc_supermarket gone well?
Overall yes. First shipment from them got lost, but they replaced the shipment right away without any argument and it showed up ok. The modules seem to be a good quality with nice soldering and the flux cleaned up properly. I haven't done any packet loss testing with them, but have had good range with them (@250kbps).
Cheers
Al -
Here's a link which lists chips similar to the NRF24L01+ (there are many more than I had supposed), and it also highlights some of their differences: http://sigrok.org/wiki/Protocol_decoder:Nrf24l01
Especially useful is the mirror of the datasheets.I have a hunch that a simple way to differentiate among the various chips might be to measure the amount of current consumed in various modes (e.g. standby, powerdown, etc), because those numbers are also given in the datasheets. Anyone tried that?
-
I just placed an order on Ali Express for four NRF24L01+ modules that look similar to the one Hek says is genuine: http://www.aliexpress.com/item/Free-shipping-Original-Genuine-NRF24L01-Wireless-Module-2-4G-wireless-communication-module-2-54mm-Interface-2/1781618813.html I mainly picked this seller because he will be sending by ePacket for only 4 cents extra, and that should mean much faster delivery (5 to 15 days). Also, the seller has decent feedback and is promising that the chips are "original" and "genuine." So, with shipping, the modules will be costing me an average of $2.82 each. I hope they're worth not just the money, but also the wait.
I would have preferred to first receive and then test the modules I've already ordered to see if they are genuine, but given the shipping time from Asia, I'm doing parallel orders in the hope of getting at least one shipment of genuine NRF24l01+ modules up and working fairly soon. Doing the orders serially would have run the risk of the procurement process taking too long.
-
@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.
@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!
-
I just finish some tests with your sketch. With ITead Modules, I have 0.05% packet loss at 1mbps and about 15 meters with 1 wall.
aRT is 1700. With NRF from electrodragon, I have same results aRT is a bit higher eg 2000.
But during my tests, I found some issues :- With UNO I have more lost packets without extra capacitor. I think 3.3V output is not enough good. With Arduino Nano, it's ok
- Quite different results when touching my dupont wires ...
- When I let temp1 and temp2 output, there's a bug with synchro. It says it's always different but it's only dure to a shift with comparaison. If i just comment serial.output of temp1 an temp2 diff is always equal to 0
I will make a test with RF24 from TMRh20 (used in MySensors).
About Mysensors, I have a question : is there a configuration to retry packet sending and delay bewteen resend like radio.setRetries(2,15); ?So for me the Itead modules are good and electrodragon too.
-
I just finish some tests with your sketch. With ITead Modules, I have 0.05% packet loss at 1mbps and about 15 meters with 1 wall.
aRT is 1700. With NRF from electrodragon, I have same results aRT is a bit higher eg 2000.
But during my tests, I found some issues :- With UNO I have more lost packets without extra capacitor. I think 3.3V output is not enough good. With Arduino Nano, it's ok
- Quite different results when touching my dupont wires ...
- When I let temp1 and temp2 output, there's a bug with synchro. It says it's always different but it's only dure to a shift with comparaison. If i just comment serial.output of temp1 an temp2 diff is always equal to 0
I will make a test with RF24 from TMRh20 (used in MySensors).
About Mysensors, I have a question : is there a configuration to retry packet sending and delay bewteen resend like radio.setRetries(2,15); ?So for me the Itead modules are good and electrodragon too.
@Fabien said:
I just finish some tests with your sketch. With ITead Modules, I have 0.05% packet loss at 1mbps and about 15 meters with 1 wall.
aRT is 1700. With NRF from electrodragon, I have same results aRT is a bit higher eg 2000.
But during my tests, I found some issues :- With UNO I have more lost packets without extra capacitor. I think 3.3V output is not enough good. With Arduino Nano, it's ok
- Quite different results when touching my dupont wires ...
- When I let temp1 and temp2 output, there's a bug with synchro. It says it's always different but it's only dure to a shift with comparaison. If i just comment serial.output of temp1 an temp2 diff is always equal to 0
I will make a test with RF24 from TMRh20 (used in MySensors).
About Mysensors, I have a question : is there a configuration to retry packet sending and delay bewteen resend like radio.setRetries(2,15); ?So for me the Itead modules are good and electrodragon too.
Interesting! Thanks for reporting the results. I'm sure Itead will be happy to hear about it. :smile: BTW, what lettering is printed on the NRF24L01+ chips? Also, from where did you procure the modules (Itead headquarters?) and how long ago?
Prior to this morning, I had been using only an RFToy (which is effectively an 8Mhz 3.3V Arduino Mini Pro), and differences between the number transmitted (temp1) and the number echoed back (temp2) were fairly rare. Because probably no one but me has an RFToy, I setup and tested using an Uno this morning to verify that I was giving the correct wiring instructions (above). I did notice a much greater rate of differences reported by the Uno than the RFToy, but I didn't pay attention to the details. From what you're saying, it sounds like it hasn't finished shifting all the bits from the Rx buffer before comparing temp1 to temp2? Am I understanding you right? If so, you could try adding, say, a 2ms delay before doing the comparison to allow the received data to fully settle before the comparison. It wouldn't affect the roundtrip timing, because it would be happening after the elapsed microseconds had been recorded. Without looking into it, I had thought that my use on the Uno of fairly long dupont jumper cables was injecting noise. On the RFToy, the connections are shorter, and no jumper wires are used.
What size capacitor (how many Farads) have you found works best? What type (e.g. electrolytic, ceramic, film, etc.)?
If you move the code over to TMRh20, would you mind posting it back to this thread? I think more people will be familiar with it than with the Mirf library. I only used Mirf because the RFToy code used it, and for simplicity that was my starting point.
Is this the electrodragon NRF24L01+ module that you tested? http://www.electrodragon.com/product/nrf24l01/
-
-
@hek : Yes but I havn't notable difference with the one from itead ! And you know it is clone.
@NeverDie : The first 2 chip from Itead : 1443IA , not a dot but a square and too small to see if there is a hole inside the +. I think i don't investigate more with others sketch because with my dupont cable error rate can increase a lot when just touching a cable.
I just setup a Iboard with PA+LNA from electrodragon and all my sensebender with clone from electrodragon too, and everything is working fine, up 20 meters without any problems.
For security I will change my NRF with the ones from Itead and will keep my PA+LNA for milight gateway emulation. -
@hek : Yes but I havn't notable difference with the one from itead ! And you know it is clone.
@NeverDie : The first 2 chip from Itead : 1443IA , not a dot but a square and too small to see if there is a hole inside the +. I think i don't investigate more with others sketch because with my dupont cable error rate can increase a lot when just touching a cable.
I just setup a Iboard with PA+LNA from electrodragon and all my sensebender with clone from electrodragon too, and everything is working fine, up 20 meters without any problems.
For security I will change my NRF with the ones from Itead and will keep my PA+LNA for milight gateway emulation.@Fabien said:
@hek : Yes but I havn't notable difference with the one from itead ! And you know it is clone.
Move your test nodes further apart, and keep increasing the distance until you start losing a higher percentage of packets. Most likely, as the separation distance and/or RF impairments increase, at some point one module or the other is going to perform much better than the other--that is unless they're using the same type of NRF chip. At least to date that's been my experience with the very few datapoints I've collected so far.
-
@Fabien said:
@hek : Yes but I havn't notable difference with the one from itead ! And you know it is clone.
Move your test nodes further apart, and keep increasing the distance until you start losing a higher percentage of packets. Most likely, as the separation distance and/or RF impairments increase, at some point one module or the other is going to perform much better than the other--that is unless they're using the same type of NRF chip. At least to date that's been my experience with the very few datapoints I've collected so far.
@NeverDie If/when you get contact with nordic rep, it would be great if they can provide a sketch that does the testing. they probably have one...
