We are mostly using fake nRF24L01+'s, but worse fakes are emerging.

[Sparkman]

@Stric Interesting as the ones I ordered from them are working great with good range. Mine do have the markings on the back. The problem with all of the eBay sellers (and likely the AliExpress ones too), is that they are just resellers and sometimes they change suppliers or will use multiple suppliers at the same time. I found gc_supermarket good to deal with. Did you ask them to refund your money or send replacements?

Cheers
Al

PS My chips have the 1420JB markings as well, but the board itself is different and looks much higher quality than the ones you received so I'm wondering if the difference in performance that you are seeing is is actually caused by the board, rather than the chip.

[NeverDie]

@Daniel-Oliveira said:

@NeverDie said:

@sundberg84 said:

Explaining to a electronic newbie, how do I test them?
All i can do now is prette much see if they work or not within my house.

I would be good if someone could create a little how-to so all can participate in these test.

Regards
Andreas

So far, I've mainly compared packet loss rates (as well as packet roundtrip times) for different types of modules. I think both are important, but if I had to pick just one or the other, I would pick packet loss rates.

I'm defining packet loss rate as: (# lost packets) divided by (total packets sent)

Anyone have ideas/opinions/thoughts/suggestions/recommendations as to whether there are better discriminating metrics to measure?

In terms of test setup, it would be ideal if the two arduinos running the test were screwed down to their test locations so that they couldn't be budged, so that almost the only thing that can change when testing different NRF modules is which NRF module is plugged into it. That way the antenna orientation will hopefully be effectively the same, or at least as close to that as we can hope to get without using an anachoic chamber--something which probably no one here would have access to.

Hi @NeverDie,

As mentioned in another thread I'm (slowly) re-writing the RFToy code to use the MySensor lybrary instead. By doing so I believe that we can do a direct relation between MySencor configs and performance. (It will take a while as I'm waiting for the sensors to test the code)

Anyway I would like to make some question to better understand the tests being made and the scenarios.
Here it goes:

• Does the RFToy code have the ACK messages activated?
• It is possible to detect when an ACK is received? (RFToy or MySensor libraries)
• How was defined the timeout of 8 micro seconds?

At the moment my concerns with the current code are:

• The value used for timeout (above mentioned 8ms)
• The measure of the RTT (Round trip time), by it's definition if the ACK messages are used the RTT should be the time difference between the first bit of the message sent and the first bit of the received ACK message
• The payload used being the max allowed of 32bit for one packet, does it not overflow? does this cause problems? (need to test)
• Is useless to compare if the received message is equal to the message sent as this (most probably) is handled by hardware (CRC check?)
• Is there a way to be sure that there is enough time for the receiver node to switch between modes (receiving/transmitting)?

Sorry for the long post and for the possible inaccuracy of my statements but this is my first contact with arduino so far, so I just hope to help and to learn with it.

Regards

You're asking the right questions. :smile:

I don't know to what extent ACK's played a role in Mirf, at least as far as the defaults were concerned as used in the RFToy Example. I suspect there were ACK's and retries too, but I never delved into, for instance, how many retries might be the default. On some other thread Zeph gave a good argument for doing the tests without any ACK's, and I believe he's right. Therefore, I wouldn't worry about how Mirf did it. Rather, consider how TBRH20 should do it instead.

The 8ms figure was simply a "magic number" I threw in based on initial observations. It was long enough that if there were going to be an echo packet received at all, it would be received in under 8ms. A smaller figure like 4ms or 5ms might have sufficed, but I threw in some extra headroom just to be sure, as I didn't want the next packet being sent, and possibly colliding with the previous echo packet. If after 8ms no echo packet is received, then the sent packet is declared lost and the lost packet counter is incremented. If ACK's are eliminated, then the timeout value could probably be driven much lower.

Hardware CRC checks can fail, and (I'm assuming they were turned on by Mirf as a default) definitely did. When they did, the packet difference counter got incremented and the binary representation of both the sent data and the received data were displayed for comparison. I don't know whether Mirf defaulted to CRC-8 or CRC-16. I'd suggest CRC-16, but that's me, and perhaps there's a good argument for something else that I'm not aware of.

[Stric]

@Sparkman I asked them what to do about the situation, and they said "we'll send 10 new". Should arrive soon..

[Sparkman]

@Stric Thanks, let us know what they send and how well they work. From what they told me, they are currently shipping the ones with the markings, so if your experience will show that as well, I'll order another batch or two from them.

Cheers
Al

[NeverDie]

http://forum.mysensors.org/topic/1664/which-are-the-best-nrf24l01-modules/160

[gtortone]

Hi,
I just received five NRF24L01+ clones (Si24R1) but on website it is reported and I did not realize it when I bought these modules...

anyway is there a 'recipe' to have a Si24R1 working with MySensors ?
I tested them with ping-pong examples and they work fine... but if I try to use a Si24R1 with MySensors libraries it does not work..

Starting sensor (RNNNA-, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=1)
TSM:FPAR
TSP:MSG:SEND 1-1-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 1-1-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 1-1-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 1-1-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:FAIL
!TSM:FAILURE
TSM:PDT
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=1)
TSM:FPAR

Thanks in advance,
Gennaro

[tekka]

@gtortone Maybe worth trying the dev branch, I've updated the RF24 driver to better support certain clones :)

[gtortone]

@tekka Hi, thanks for the suggestion - I checked with MySensors dev branch from github but results are the same:

15007 RF24:read register, reg=23, value=17
15013 RF24:read register, reg=23, value=17
15017 RF24:read register, reg=23, value=17
15022 RF24:read register, reg=23, value=17
15026 RF24:read register, reg=23, value=17
15030 RF24:read register, reg=23, value=17
15036 !TSM:FPAR:FAIL
15038 TSM:FAIL:CNT=1
15040 TSM:FAIL:PDT
15042 RF24:write register, reg=0, value=12
15046 RF24:power down

If I replace the Si24R1 with genuine NRF24L01+ everything works... (also with MySensors master branch)

[tekka]

@gtortone Try dev branch + 1Mbps data rate setting:

#define MY_RF24_DATARATE RF24_1MBPS

[gtortone]

Hi tekka, thanks again but result is always the same...

0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.0.1-beta
4 TSM:INIT
10 TSM:INIT:TSP OK
12 TSF:SID:OK,ID=1
14 TSM:FPAR
1697 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
3706 !TSM:FPAR:NO REPLY
3708 TSM:FPAR
5392 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
7399 !TSM:FPAR:NO REPLY
7401 TSM:FPAR
9084 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
11094 !TSM:FPAR:NO REPLY
11096 TSM:FPAR
12779 TSF:MSG:SEND,1-1-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
14788 !TSM:FPAR:FAIL
14790 TSM:FAIL:CNT=1
14792 TSM:FAIL:PDT

I realized that if I disable broadcast search of parent node with:

#define MY_PARENT_NODE_ID 0
#define MY_PARENT_NODE_IS_STATIC

the Si24R1 works fine !

but I don't know if this can be a problem for other features of MySensors...

[gtortone]

Hi tekka, just for information:

• master branch => does not work with Si24R1 also disabling broadcast search of parent.
• dev branch => works fine with Si24R1 disabling broadcast search of parent.

Thanks,
Gennaro

[tekka]

@gtortone said:

• dev branch => works fine with Si24R1 disabling broadcast search of parent.

This applies to all radios being genuine or clones, not mixed?

[gtortone]

Hi,
on gateway I'm using a NRF24L01+PA+LNA and everything works fine if I use NRF24L01+ or SI24R1 on sensor side.

If I replace NRF24L01+PA+LNA with something different (NRF24L01+ or SI24R1 module) the communication does not work...