We are mostly using fake nRF24L01+'s, but worse fakes are emerging.
-
(see new links at end of this post)
(see earlier thread about nRF24l01(no plus) substitutes - not quite the same topic as this thread but related; from a comment below)
(see newer thread on finding the best nRF24L01+)
First off, it appears that most of the cheap nRF's have been fakes (not genuine Nordic chips). There is some indication that they may use somewhat more power and be somewhat less sensitive, than the real thing - and may be more sensitive to power supplies. Not a big problem, since that level of performance is what we're used to (many of us have probably never used a Nordic nRF24L01+).
However, there are even cheaper fakes hitting the market, with inferior specs and outright incompatibilities. In particular, the Si24R1 got the ACK bit inverted (following an error in the datasheet), so it's incompatible with the real nRF24L01+ (and good clones) in ESB mode. (The Si24R1 is often falsely labeled as nRF24L01+). In some cases you can build a network of such variants that work OK together, but a node with the other chip won't work right (at least in ESB mode). There are several other clones too, with whatever changes they happen to have.
And clone chips weren't enough, there is a new cheap module with the chip under an epoxy blob (no biggee per se), which also omits a number of the passive components in the Nordic reference design used by most modules (caps, resistors, inductors). This seems to have problems with the ACK bit due to the chip itself (see avove), but due to module design also probably has reduced actual transmit power, less power filtering, etc. (And would even if it had a good chip in it).
I'm mentioning this because chips that don't work right in some circumstances (depending on which features are used), or which are electrically marginal and thus have intermittent problems, can lead to serious hair loss. And this is probably going to be an increasing problem in our niche, as our vendors switch to the cheapest suppliers.
If you are having odd problems, sometimes it may be that you have one of the clone chips or cost reduced modules.
Perhaps we need to find a good supplier who knows we want only "genuine" high quality clones
and who will not suddenly switch to less compatible ones. In the DIY christmas lighting community many people patronize one particular Ali Express vendor (Ray Wu) who has an overall good reputation within that community, who is aware that many people in that community communicate frequently, and who wants to keep a good reputation. He gets enough volume from that community to have incentive to keep up his quality and to fix problems (at least in relative terms among Ali Express vendors).Some background:
http://hackaday.com/2015/02/23/nordic-nrf24l01-real-vs-fake/
http://ncrmnt.org/wp/2015/03/13/how-do-i-cost-optimize-nrf24l01/
Updates:
List of related chips (if not mislabeled as Nordic these would be clones, derivatives or compatibles, not fakes per se, but I'll list them here as some fakes may really be one of these chips or closer to it): http://sigrok.org/wiki/Protocol_decoder:Nrf24l01
Info about Si24R01 and power: https://github.com/solarkennedy/equail/tree/master/Libraries/RF24
-
The other thing we might do is get into the habit of immediately quality testing new batches of nRF24L01+ modules.
First thing is just to see if it works in ESB mode with our existing chips, and that it works on all channels (some clones are reported to be marginal at the ends of the band).
I wonder how else to test RF quality. Maybe have a standard test location - like test it from a particular place in the garage against a known existing node, where we know that our old nodes would work but maybe barely. If the new batch fails from that location, we won't waste too much time with weak chips confusing our debugging in the middle of a more complex project.
-
I am a victim of those fake clones. As I was just starting with nrf, it took me 3 days of debugging to figure out that issue is with the RF module itself, it wont send ACK, altogether.I bought 5 of then for $4.
The other one I am using is little better but its not a nrf+, I had to disable the isPvariant(), check to solve the check wires problem.
-
Unsettling stuff. Thanks for the warning. Makes me wonder exactly how advanced the Chinese clone factories are, I mean, if they are making this relatively advanced IC, is any IC safe from China? Granted that only high volume stuff is worth cloning.
Another reason to move away from the NRF24 if opportunity arises. Genuine (?) RFM69 are looking better and better.
-
@mainali The chips on your first picture I got also one time. IMO it is the nRF24L01 without the plus '+' - I detect it by comparing the register resonses with there datsheets.
-
Yes, some might be clones of the nRF24L01 (no +). Others have bugs.
And at least some modules with epoxy blobs rather than chips may also be missing some of the normal external passive components leading to reduced performance - in addition to questionable chips per se. This is almost worse for our sanity - being flakey rather than outright failing some digital aspect (like ESB) 100% of the time.
One commenter in one of the above referenced threads mentioned having one module which seemed unusually tolerant of the power supply quality - which he believed was a genuine Nordic chip. Maybe the PS issues we've all adapted to are largely due to our using clones (even the relatively good clones).
-
@mainali said:
I am a victim of those fake clones.
Well said. We've grown used to the quality clones, now there are "fake" clones on the market.
Sort of like cheap cheeses. In the US there used to be "natural" cheese, and "pasturized process" cheese (like "American cheese", a sad thing to have named after your nation). Then there was a brand of semi-soft block cheese called "Velveeta" which was labeled as "pasturized process cheese food". And some off-brand variants of that were labeled "imitation pasturized process cheese food". (These were all legal distinctions based on US Gov't standards, and the terminology has since changed).
So our nRF modules started out at "pasturized process cheese", and now there's "imitation pasturized process cheese food" entering the market - without such honest labeling.
-
So can we identify the "fakes" vs "real fakes" by dumping chip info or is that 100% faked to?
-
Emailed my contact at Nordic about this a month ago.
There are unfortunately little they can do about the problem. There is almost a zero cost to open an Aliexpress shop and there the chinese goverment/Alibaba does not care enough.
http://resources.alibaba.com/topic/801220532/What_to_do_if_you_ve_received_fake_products.htm
-
Probably we could open a permanent thread where we can post our experiences with different aliexpress shops regarding nrf24l01+?
Is there a chance to write a short arduino program to check the identity of the nrf chip used? Then we could check the ones we receive and put this experience also in the above mentioned thread?
-
A fake chip test program would be great. If someone would like to take a stab at it many would be happy here.
Guess the members could help sending sample fake chips to someone interested in the "fakalyzer"-project.
-
Ran the nRF24 GettingStarted and got this from two different nRF24's
Standard nRF24L01+
STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 = 0xa8a8e1fc62 0xf0f0f0f0d2
RX_ADDR_P2-5 = 0xff 0xc4 0xc5 0xc6
TX_ADDR = 0xa8a8e1fc00
RX_PW_P0-6 = 0x20 0x20 0x20 0x00 0x00 0x00
EN_AA = 0x3b
EN_RXADDR = 0x07
RF_CH = 0x4c
RF_SETUP = 0x07
CONFIG = 0x0f
DYNPD/FEATURE = 0x00 0x06
Data Rate = 1MBPS
Model = nRF24L01+
CRC Length = 16 bits
PA Power = PA_HIGHnRF24L01+ with Antenna
STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 = 0xe7e7e7e7e7 0xf0f0f0f0d2
RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6
TX_ADDR = 0xe7e7e7e7e7
RX_PW_P0-6 = 0x00 0x20 0x00 0x00 0x00 0x00
EN_AA = 0x3f
EN_RXADDR = 0x03
RF_CH = 0x4c
RF_SETUP = 0x07
CONFIG = 0x0f
DYNPD/FEATURE = 0x00 0x00
Data Rate = 1MBPS
Model = nRF24L01+
CRC Length = 16 bits
PA Power = PA_HIGHThe one with antenna's adresse looks kind of "strange", but don't know if we can read anything out of this ????
-
@phil83 said:
Probably we could open a permanent thread where we can post our experiences with different aliexpress shops regarding nrf24l01+?
I'd be interested to see a list of "good" sellers from aliexpress and not just for the radios. It seems like the store links just point to the cheapest one with free shipping some times. I haven't bought enough stuff to get burnt (7 orders of which 2 have come in and the rest should be in a week or 2) but it is one of the things that keeps me wary.
-
@chaotic I would also be interested and could contribute to a complete list. But for reading and finding it would be much easier to open several threads dealing with different parts or groups of parts.
-
As I get my fakes I open a dispute and add this info - it war clear enough to get my money back ;-):
So, the chips differ in the register number 09 (CD/RPD).
-
I just used the GettingStarted and got the following reply from a nrf24l01+ with antenna:
RF24/examples/GettingStarted/
ROLE: Pong back
*** PRESS 'T' to begin transmitting to the other node
STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 x00 = 0xe7e7e7e7e7 0xf0f0f0f0d2
RX_ADDR_P2-5 x00 = 0xc3 0xc4 0xc5 0xc6
TX_ADDR = 0xe7e7e7e7e7
RX_PW_P0-6 x00 = 0x00 0x20 0x00 0x00 0x00 0x00
EN_AA = 0x3f
EN_RXADDR x00 = 0x03
RF_CH = 0x4c
RF_SETUP x00 = 0x07
CONFIG = 0x0f
DYNPD/FEATURE x00 = 0x00 0x00
Data Rate = 1MBPS
Model = nRF24L01+
CRC Length = 16 bits
PA Power = PA_HIGHSo it's the same like @Magiske.
-
Am I the only one missing references to earlier discussions in this subject? Like this one..
-
This is the first time I'm putting anything here. I also have been developing a C based library for one of the NRF24L01 (no plus) devices.. I used a Stellaris Launchpad to interface with the chip. Eventhough most of the functionality work correctly I saw the CD (Carrier Detect) is not functioning properly. Once it is high it is always high. To make it low I had to flush the RX buffer. It is really strange. I bought my sensors from e-Bay. So they must be clones :D. Can someone try this CD thing and see whether it is working properly?
-
Has anyone here found a good vendor for modules that use genuine Nordic NRF24L01+ chips?
-
You could buy your modules from Itead. They have promised us to only source genuine Nordic chips. They are a little higher in price/shipping but you could also take the opportunity to buy a MySensors Micro board to support the project
The ebay/aliexpress shops is a bit of a chance-taking as they might switch sourcing partner at any time.
-
@hek said:
You could buy your modules from Itead. They have promised us to only source genuine Nordic chips. They are a little higher in price/shipping but you could also take the opportunity to buy a MySensors Micro board to support the project
The ebay/aliexpress shops is a bit of a chance-taking as they might switch sourcing partner at any time.
Fair enough. I just now ordered some allegedly Itead NRF24L01+ modules from an Itead distributor, but I suppose there's a risk the distributor might get greedy and ship me something else. On a different thread, someone mentioned that the Itead modules each come in their own box. Would someone please post a photo of the individualized packaging for the Itead modles? If it's distinctive, it might serve as a kind of "certificate of authenticity." I realize that could be faked also, but it would make it a little harder for someone to fake, and so it's better than nothing.
-
Would the following might work as a way to separate good modules from bad modules, therefore also separate out the fakes?
- Set up a looping ping-pong link between two "known good" modules and measure the % packet losses.
- Unplug a reference module and then plug a test modules into the same setup. If the packet loss percentage is significantly worse, then the test module is either bad or a fake.
-
@NeverDie said:
Fair enough. I just now ordered some allegedly Itead NRF24L01+ modules from an Itead distributor, but I suppose there's a risk the distributor might get greedy and ship me something else. On a different thread, someone mentioned that the Itead modules each come in their own box. Would someone please post a photo of the individualized packaging for the Itead modles? If it's distinctive, it might serve as a kind of "certificate of authenticity." I realize that could be faked also, but it would make it a little harder for someone to fake, and so it's better than nothing.
Here's an image:
http://imall.itead.cc/media/catalog/product/cache/1/image/1800x/040ec09b1e35df139433887a97daa66f/i/m/im120606002_2.jpgCheers
Al
-
@Sparkman said:
@NeverDie said:
Fair enough. I just now ordered some allegedly Itead NRF24L01+ modules from an Itead distributor, but I suppose there's a risk the distributor might get greedy and ship me something else. On a different thread, someone mentioned that the Itead modules each come in their own box. Would someone please post a photo of the individualized packaging for the Itead modles? If it's distinctive, it might serve as a kind of "certificate of authenticity." I realize that could be faked also, but it would make it a little harder for someone to fake, and so it's better than nothing.
Here's an image:
http://imall.itead.cc/media/catalog/product/cache/1/image/1800x/040ec09b1e35df139433887a97daa66f/i/m/im120606002_2.jpgCheers
AlThanks! Pooling our information should reveal who the good vendors are.
After I receive the modules I ordered today, I'll post which vendor I purchased them from, the price, and whether or not I think they're real (i.e. what tests I ran to make that determination). I would encourage others to do the same.
-
Judging from the current banter on this other thread, it sounds as though if a module is powered directly from a fully charged battery pack (so that there's no voltage ripple) but it has fewer lost packets after installing a 10uF capacitor, then it's probably a fake.
I'm guessing you could make a test rig by soldering a capacitor across the Vcc and Ground legs of one of these:
Then just plug the module into it, and then it into the usual arduino socket that you'd ordinarily plug the module into.Would that work?
-
I'm trying to get gc_supermarket to refund me or send working ones.. the nrf's I got from them, marked "GOOD QUALITY" has a range of a few meters in open space. Cap adds another meter or so.
I've ordered nrf's from itead too, hopefully good ones.
-
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
-
@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
AndreasSo 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.
-
@Stric said:
I'm trying to get gc_supermarket to refund me or send working ones.. the nrf's I got from them, marked "GOOD QUALITY" has a range of a few meters in open space. Cap adds another meter or so.
That sounds awful. Have you tried other channels and locations and power supplies to rule out heavy interference or noise? If none of that makes any difference, would you please post a photo? Perhaps someone will notice something distinctively different that we can then all use to hopefully avoid a similar disappointment.
Also, I suggest ordering a minimum of 3 modules (from whomever you order), rather than only two, just to rule out the chance possibility that a botched module is to blame. This is what I did on my most recent order. It wouldn't rule out the possibility of getting 2 botched modules in the same order, but the odds of that should be very small if only random luck is involved.
-
I also ordered those "good quality" from gc_supermarket. I havent made any test yet but on the chip it says NRF M, 24L01+ 1429AF
On my other radios it says 1242AF.
-
It's a manufacturing date stamp. 29th week of 2014
Don't know what AF stands for. Anyone know?
-
@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
AndreasSo 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
-
- It is possible to detect when an ACK is received? (RFToy or MySensor libraries)
When ACK/autoretry (ESB mode) is enabled, the transmit is not indicated as complete until an ACK is received or all retries are exhausted.
- 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
People could define RTT in several ways for different purposes. You describe one way one could define it. For the most part tho people are going to measure the times between two events that are visible in the chip registers. So if you want the RTT for a message with an ACK (and no retries), you might measure the time from when the transmit is triggered, to the time that the chip considered it complete (ack received), which will be shortly after the last bit of the ACK is processed.
Another way to define RTT would involve a software ACK at a higher network level being received - master uC sends to slave uC, slave parses and sends a new packet to the master uC. Again, it's going to tend to be measured via the visible registered (from transmit fired to packet received).
- The payload used being the max allowed of 32bit for one packet, does it not overflow? does this cause problems? (need to test)
The nRF24L01+ has a maximum payload of 32 bytes (a protocol layered on top of that, like MySensors, may have it's own smaller maximum payload at that level, after its own protocol overhead). Not sure what you are asking but maybe NeverDie will.
- Is there a way to be sure that there is enough time for the receiver node to switch between modes (receiving/transmitting)?
If you are using hardware ACK, that switchover (primary transmitter into receive mode temporarily for receiving the ACK, primary receiver into transmit mode temporarily for sending the ack) is handled automatically, including the 130 uS or so needed to switch the radio. If you are using a software ACK, you would need appropriate delays and/or timeouts.
-
@NeverDie Yes, I've tried various things. The modules from gc_supermarket were crap. I ordered 10, so it's not an "oops, you got a bad one".
1420JB.
In the ebay shop, the module PCB had markings. The ones I got had none.
-
@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
AlPS 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.
-
@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
AndreasSo 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.
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.
-
@Sparkman I asked them what to do about the situation, and they said "we'll send 10 new". Should arrive soon..
-
@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
-
-
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:FPARThanks in advance,
Gennaro
-
@gtortone Maybe worth trying the dev branch, I've updated the RF24 driver to better support certain clones
-
@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 downIf I replace the Si24R1 with genuine NRF24L01+ everything works... (also with MySensors master branch)
-
@gtortone Try dev branch + 1Mbps data rate setting:
#define MY_RF24_DATARATE RF24_1MBPS
-
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:PDTI realized that if I disable broadcast search of parent node with:
#define MY_PARENT_NODE_ID 0
#define MY_PARENT_NODE_IS_STATICthe Si24R1 works fine !
but I don't know if this can be a problem for other features of MySensors...
-
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
-
@gtortone said:
- dev branch => works fine with Si24R1 disabling broadcast search of parent.
This applies to all radios being genuine or clones, not mixed?
-
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...
