Which are the *best* NRF24L01+ modules?
-
I understand about other deadlines - I appreciate the efforts you have made so far.
Sounds like all that's needed in the final version of your testing is a bent-pin 2x8 connector test shim such as you have described and photographed, and a $400 DVM
-
@Zeph said:
Sounds like all that's needed in the final version of your testing is a bent-pin 2x8 connector test shim such as you have described and photographed,
Yes, a 2x4 connector, or I actually used (2) 1x6 female headers (I didn't have 1x4 female headers readily at hand)
and a $400 DVM
I imagine some of the cheaper DVM's would get the job done too. That's another topic entirely though.
I'm not sure where you draw the line on how much testing is enough. I think it probably already is enough. 80/20 rule.
-
Have you decided to toss the blob modules (or put them in the back of the drawers), in favor of genuine Nordic only?
-
@Zeph said:
Have you decided to toss the blob modules (or put them in the back of the drawers), in favor of genuine Nordic only?
No, at present I still prefer the blob modules. It may yet turn out that there's a better PCB or antenna or something for the genuine chips that will make a huge difference in their effective performance, but so far I'm underwhelmed by the modules with genuine chips. Also, modules with the genuine chips seem to cost around ~$3/each, and so for about only an extra dollar I could have an RFM69HW. Yesterday I ordered a couple Moteino's with the RFM69HW, and so after they arrive I'll see how that goes rather than re-invent the wheel. They were kinda pricey, which is my main reservation about them.
If others are happy with their genuine chip NRF24L01+ modules, then good for them. Unfortunately I can't count myself among them, and so I'm restless to find something and settle on it. My guess is it may be the blob module, or it may be the RFM69.
-
Ah, OK.
I saw the testing as serving two purposes:
- Learning a "power signature" to distinguish variations on the chips
- Finding out how bad (or good) the variants are in regard to power usage
Seems like the first is nailed. The latter has begun to be characterized (thanks to you). The idle and sleep power is substantially greater on the blobs (for example). If the 8.4 ma for Receive is for the blobs, that doesn't sound bad, don't know about transmit.
And if powered by the mains, it doesn't much matter.
-
@Zeph said:
....don't know about transmit.
Blob module transmit current was about 20ma, (my interpretation of the oscilliscope pictures I posted). I was surprised that the "listening" current was just 8.4ma, because that's lower than the spec sheet for "receiving" current. I don't know, but perhaps "receiving" consumes more current than just "listening."
On a relative scale compared to the other modules, the blob modules obviously consume more current. However, on an absolute scale, they seem like they may be good enough..
And if powered by the mains, it doesn't much matter.
-
@Zeph Looks as though you could use the LTC2440 to measure the sleep and standby currents and read the results with your arduino: http://dangerousprototypes.com/forum/viewtopic.php?f=2&t=4247#p45583
or maybe use one of these breakout boards to similar effect:
http://www.ebay.com/itm/LTC2400-24bit-analog-to-digital-converter-ADC-module-temp-sensor-SPI-AVR-arduino-/111005456125?pt=LH_DefaultDomain_0&hash=item19d870d6fd
-
I'm seeing similar results with my radios. I bought these from aliexpress and then after reading the various threads about fakes and the problems people were having, I bought a bunch of authentic modules from ITEAD just to avoid those headaches. The real modules have much cleaner PCB's and better looking solder joints. 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. I'm now regretting spending the extra money on the genuine modules (if anyone in the CONUS wants some genuine modules, PM me and I'll sell you some at my cost).
-
Thank you! Finally some confirmation of what I've been saying.
I received some "genuine" modules from AliExpress today: http://www.aliexpress.com/item/Free-shipping-Original-Genuine-NRF24L01-Wireless-Module-2-4G-wireless-communication-module-2-54mm-Interface-2/1781618813.html
Power Down (Sleep): 0.5uA
Standby: 23.5uA
Listening: 8.6ma
The transmit waveform looks exactly the same as the the module from Itead.Therefore, I deem them genuine.
-
I was able to sharpen my o-scope pictures by turning on Hi-Res mode. With this better detail, a lot more is apparently different between the genuine modules and the blob modules.
Here are some transmit shots of the new genuine modules:
and here are some shots of the blob module, also now taken at Hi-Res on the o-scope:
As you can see now that I'm using Hi-Res mode, even the shapes of the waveforms are completely different looking.
Reminder: because I'm now using a 1/2 ohm sense resister, each verticle devision now represents 4ma.
So, eyeballing it, the genuine chips are using about 12ma for their transmit current, whereas the blob module chips are closer to about 18ma.Also, the second peak after the first peak is higher on the genuine chips, whereas it is lower on the blob chips. I don't know what those peaks represent.
-
So, for completeness, here's the Hi-Res o-scope pictures of the red module, whose tracecode suggests it may be fake, as previously noted:
In this case, one thing that jumps out as different than the other two is that the height of the second tall peak is much lower than the first tall peak. In the genuine chip, the second tall peak is actually higher than the first tall peak, so it's quite a distinctive difference.
-
I have a hypothesis for what's going on. According to the NRF24L01+ datasheet,
• 11.3mA TX at 0dBm output power
• 13.5mA RX at 2Mbps air data rateTherefore, I think Mirf probably does a TX, waits for an ACK, and if it isn't found, it tries 3 more times. Therefore, on the genuine chip, you see one tall peak for TX, followed by a second taller peak for RX. It does it again3 times, because, for measurement repeatability, I deliberately removed anything that might receive or ACK its transmissions. So, all the ACKs fail and it transmits 3 more times after the first transmission. That's the hypothesis.
Anyhow, now that I've switched over to the TBRH20 library, this could be checked more easily.
Although already shown above, here it is again for easy reference:
If the hypothesis is true, then the TX and RX currents measure out to exactly what one would expect based on the above specs in the datasheet.
Also, it would explain why it is that before and after the transmission burst, the measured current is the same as the second peak current. That's because the chip is in RX mode between transmissions.
So, from the looks of things, if it doesn't receive an ACK within 250uSeconds (as measured above) after transmission ends, it tries again (up to 3 times). In fact, according to the datasheet, the default for ARD (automatic retransmission delay) is 250 uSeconds. It appears to match up exactly!
-
So, indeed, that's what's happening.
I just switched to TBRH20 and wrote a simple loop to send a packet every 100ms, and to not be listening inbetween. Apparently the default behavior for TBRH20 is to try 16 times to send the packet before giving up!
As before, this is just one shot on the oscilliscope. I'm zooming in on each successive screen by adjusting the time base. I did the measurement on one of the modules with a "genuine" Nordic chip.
I would guess that in this case TBRH20 is managing the retries in software on the Arduino rather than utilizing the radio chip, because the time between retries is much larger: about 1.5ms.
BTW, I switched to a Mega2560 to do the testing, and, although I haven't yet investigated it, I think the new type of noise that's now evident is probably from the 5v and/or 3v voltage regulator. It doesn't obscure the view, so for now I'm not really concerned.
-
Nailed it. If I explicitly turn ACKing off, then:
What's shown is just a single transmit pulse at 100ms intervals, and with no RX current afterward, as would be required if an ACK was being listened for.
Bottom line: now that the anatomy of the Tx current is known, it should help spot and identify clone chips by comparing their Tx current waveform against that of chips known to be genuine.
-
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.
-
@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.
-
@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.
-
@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
-
@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.
-
@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).
-
@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.
-
@NeverDie
ok, thank you. using Nano's work. getting 13% loss is not too bad
-
@GertSanders
In your experience, which of the SMD modules have you found work the best?
-
-
@GertSanders
Are you happy with their performance? I imagine the answer is yes, but I thought I'd ask just to be sure.
-
@NeverDie
I am, there is one on my front door, which needs to cross two floors to get to the gateway in the attic. Bleeps every time. Range (as far as I can see) is close to the classic small version.
Good enough for me.
-
@GertSanders
Thanks! I just now ordered some of the same SMD modules using the link you provided. The last time I looked into this (at the start of this thread), it seemed as though just about everyone was using a different mix of modules and platforms. and that made an apples-to-apples performance comparison quite difficult. However, this time around, I'll be running the same modules as you on the same hardware platform as you (well, nearly so, assuming I build it to spec), and so if it works well for you it presumably should work the same for me too.
-
Good morning together, iam very new in mysensors forum, so this is my first post, and i have a question: a want to buy these NRF's can somebody tell me if they are okay?
https://www.amazon.de/Kuman-nRF24L01-Wireless-Transceiver-Compatible/dp/B01BVAAASY/ref=sr_1_fkmr0_1?ie=UTF8&qid=1464158231&sr=8-1-fkmr0&keywords=nordic+nrf24l01+10pcsThank you!
-
@HarrySteff There is no way (that I know of) to determine in advance if the modules work according to specification. Even different lots from the same supplier can vary in performance. I have a 5 out of 6 succes rate with different suppliers.
-
Thank you @AWI i will Order them to Test...
-
I have had an excellent experience with the SMD version. I cannot say if there are different versions of it, but all transceivers I purchased from different suppliers work flawlessly.
-
@alexsh1 Do you have any links for the SMD versions that you can recommend, i'm wanting to try these now. Thanks.
-
@Samuel235 these were the ones I ordered last time. Tested all of them and very much pleased
Look what I found on AliExpress
http://s.aliexpress.com/ZfArmaqe
-
@alexsh1
At which settings do you use them?
I have those http://www.aliexpress.com/item/10PCS-LOT-NRF24L01-wireless-data-transmission-module-2-4G-the-NRF24L01-upgrade-version/1593276910.html
And not so happy as they seem to loose connection from time to time over distance of 4-5m
I set them at 250 and have good power & caps attachedAt least the chip seems to be original but not soldered very well
-
@parachutesj I'll be honest with you - so far I had more luck with the SMD version which works 20m+ across a few walls than with a regular transceivers. Sometimes one needs to invite a shaman to make sure that nrf24l01+ works.
I have 250kb rate on all nodes + caps. All works fine. With some regular nrf24l01+ I had issues with some batches and claimed money back successfully after ditching the whole batch. Luckily, this bad batch has not been working at all rather than working intermittently.
Just a suggestion - did you change any settings on your gateway nrf24l01+? I'm using the amplified version by the way feeding it through AMS1117 LDO
-
@alexsh1 said:
I switched to ampliefied nrf24 with antenna from the link in the shop but this seemed to make it even worse. It was powered externally and tried to shield it with no real luck. I ordered some shielded ones from ICstation which are still in customs process and hope to get them by the weekend. I also ordered a bunch of others and I will try which are the best for my operations.
Just today I hade the closest node getting stuck. I wasn't able to send any from controller to the node. After triggering a signal from the node (it is a rollershutter) it came back to live and was able to send via controller again. Quite annoying...
Maybe I need to try some different caps and voltage regulators, actually got "good" ones from my local electronics shop.
-
Do the amplified modules simply always function at full amplification, or is there a code change that's needed to adjust the Tx power? Towards the start of this thread I tried some amplified modules from ICStation, but I was hugely disappointed with them. In fact, I don't think I saw any improvement at all, which greatly contradicted the experience that some others appeared to be getting. At least at that time, though, there was no real guidance on how to use them effectively, and so maybe I wasn't driving them right. Maybe there's more information now.
-
@parachutesj What settings do you have on your gateway please?
-
@NeverDie In MyConfig.h there are settings:
#define RF24_PA_LEVEL RF24_PA_MAX #define RF24_PA_LEVEL_GW RF24_PA_LOWThe second one is for the amplified version (RF24_PA_MAX can used)
Please check out this:
https://forum.mysensors.org/topic/653/nrf24l01-pa
-
@alexsh1 I have this
#define RF24_PA_LEVEL_GW RF24_PA_MAXon the GW
Maybe I need to try RF24_PA_HIGH if it changes anything. However still waiting for the "good" radios to arrive
-
@parachutesj First things first:
- Good transceiver
- decent 3.3V feed
- settings MAX or HIGH etc
-
All of my ~20 NRF24's from 5 different dealers are consuming 15mA when the node is in sleep mode. Is this really a radio problem, or a software problem?
By pulling out the radio, current drops below 1mA.
- 2.0.0beta binarySwitchSleep sketch
- My-Slim-2AA-Battery-Node
- bootloader from My-Slim-2AA-Battery-Node OpenHardware source
- BOD disabled by fuses, 1MHz internal
- current messuered with Fluke multimeter
-
@rollercontainer
Have you tried to measure the power consumption whithout radio, and just putting the atmega328 in deep sleep (sleep(0)) ?
Normally you should then see something less then 10 micro amperes.
If the node still consumes around 1mA in this situation, then I would advise to look at the soldering and the other components.
With BOD disabled, an atmega328p in deep sleep consumes around 1 micro Ampere,.
Did you use the atmea328P version or the standard atmega328 (without the P) ?
-
@GertSanders I wrote "below 1mA" because I couln't recal the exact value, just for pointing to the relation between radio consumption and idle without radio.
I've got 328P from Reichelt.de and messured again withoput mysensors.h and with SLEEP_MODE_PWR_DOWN. The multimeter reads 0,09mA at 60.00mA range set. Looks valid to me.
-
@rollercontainer
If you are using the internal pull up resistors on the switch input pins, then indeed you will get something like 30-60mA.
That is why we use external pull up resistors for switches when we want to go for lowest possible power consumption.The internal pul up resistors have a value around 30K-45K (there is some variation). The pull up resistors I use are 1MOhm, this cuts the current consumption by two factors.
-
@rollercontainer : you cannot get a proper measurement using only just a multimeter. Fluke or no Fluke, it just isn't going to happen. Lookup "burden voltage." Enough said, as this has been covered in-depth all over the place.
-
You both missed the point. My problem isnt the idle consumption yet. My problem is, that all the radios consume too much. Is there a way to get it down, or do I have to dump them all?
-
@rollercontainer are you using the Arduino SLEEP_MODE_PWR_DOWN ? If so, the radio will still be active because the Arduino library isn't aware of the radio. Use the MySensors gw.sleep instead.
-
Holidays are over, back to work ^^
To clarify it again:
First I tried with complete 2AA slim node, several radios, sensor and the default binarySwitchSleep 2.0.0beta sketch. (15mA)
For the second run: NO radio, sensor or MySensors.h were used. Therefore I wrote a minimal sketch with SLEEP_MODE_PWR_DOWN to ensure that the AVR is going to sleep mode. (< 0,1 mA)
This leads me to the conclusion, that every of my ~20 radios is faulty. Are there any ways to prove this?
-
@rollercontainer
Sure. Buy a "known good" radio for comparison.
-
Are the radios in the store here known as good and working now? I know we had issues with a bad seller previously, has this been sorted now?
-
@NeverDie are you sure the node enters deep sleep? The current you measure is typical for a non sleeping radio. Main problems I have with the bad radio's is that these stay awake until they "found a parent". Where do you live? If you drop me a message I can send a tested one.
-
@AWI said:
@NeverDie are you sure the node enters deep sleep?
I don't recall. It's been a while since I ran the tests. Presently I'm using RFM69's, which draw about 100na when sleeping, but at some point this summer I hope to revisit using NRF24L01's. I've already received the SMD modules that Gert Sanders is using, and I'll be giving them a try on the boards he designed, so the odds are favorable that I'll be getting the same or similar results. I received the boards from the fab, so after I receive the remaining parts I'll do the assembly.
Earlier in this thread it was advised to order direct from Itead, on the grounds that they were manufacturing them. So, going directly to a reputable source might increase your confidence of getting what's advertised. Frankly, these things are cheap enough that I'd suggest going to several different such sources and then vet what you get using an oscilloscope. I did that earlier in this thread, and you can compare your results with the screenshots I posted to ID your chip. Of course, that by itself doesn't guarantee that the antenna was properly matched, which is why I think comparing the ranges of different modules from different sources is probably still a good idea. Even if the components are right, the dielectric of the PCB could throw off the match, and you won't know that just by looking at it.
-
Unfortunately i don't have an oscilloscope at the moment. So i have to just test them in the circuit as intended to be used.
-
@NeverDie I already bought these ~20 radios from 5 different dealers...
@AWI I am not sure, therefore I am asking here. But what more can I do? I am using a default sketch with only this modification:#define MY_NODE_ID 70 #define MY_PARENT_NODE_ID 0 #define MY_REPEATER_FEATURE falseThe node is useable, so it sends reed contact changes to the mqttClientGateway which sends it to my raspi. Is the static method preventing the node from deep sleep?
I live in northern germany. Thx for the offer. But I dont really believe, that all radios are faulty by now.
-
@rollercontainer
I still suspect either a configuration or a measurement error. I suggest you photograph in detail everything you're doing and post it. If you're overlooking something, maybe somebody will spot it. Otherwise, there's just not much to go on.
-
I setup a new Arduino IDE 1.6.9 portable with MySensors 1.5 and flashed a standard 8MHz bootloader with BOD off.
Idle current is nearly unmessureable by my MM, showing only 0,01 mA at 60,00 mA range.
Next step is to get a 1MHz bootloader to work with low current.Thx for your words, guys.
-
flashed the 1MHz Optiboot again, compiled the sketch and loaded it up. Idle current is staying under 0,01mA. So, looks like the 2.0.0beta libs are "guilty".
-
@rollercontainer Interesting...with 2.0b I have 6uA consumption in a sleep mode on Pro Mini + nrf24l01+
-
hi.
there is no interest to use 1mhz during sleep mode because in this mode clock is stopped. No matter the freq, if you have no problem in your circuit and software is well configured and bod disabled, just the atmel in standalone is consuming 140nA in deep sleep.
1mhz can be helpful during active mode but it reacts slower, wake up slower, and can cause trouble for communication like serial... and sometimes it can be less effective vs keeping internal rc.
But 1mhz is useful, used in certain ways of course, i use it too
-
it is working with lower voltages at 1mhz, thats the reason I use it on a 2 AA node.
-
But @scalz is saying that only in sleep mode the frequency does not matter, it has no effect on the power consumption. However, it will effect your power consumption while the MCU is awake, but there're discussions regarding the length of time its awake some times means that it uses less power if using a higher frequency due to it performing its tasks quicker and then returning to sleep.
-
So, I guess the question is whether waking up at 8mhz on 1.8v will be a problem or not. It's out of spec according to the datasheet. I'd certainly much prefer to wake-up the atmega328p at 8mhz than 4mhz or 1mhz, because then the wake-up time can be very, very short (<4us). No other setting that I know of comes anywhere close to 4us.
-
@rollercontainer I have 8Mhz working below 1.8V. The problem is that below 1.9V, it is unstable as the radio may be working intermittently. I think @GertSanders reported his node running down to 1.6V at 8Mhz. In any case, I do not think one has to run 1Mhz as power saving compare to 8Mhz is not massive and clock is not working - the latter is by far important for my needs.
-
I have found that the NRF24L01+ PA LNA radios I have, have 100% packet loss and will not sleep if driven with voltages over 3.0v I have dropped the supply to 2.7v and now have minimal packet loss and the radios will sleep at all power level settings.
Current draw is 4.7uA including 328P + RTC when asleep as measured with a uCurrent Gold.
-
@doug That is an interesting observation. Was there a specific reason to test this? Have you tried other voltages also?
-
I was building a boost converter with one of these Texas TPS61097A-33DBVT the NRF I was using on battery didn't work with the boost CCT. I tried with 4-5 of these modules all from the same supplier and none of them worked. My scope showed they were transmitting and the uGold was showing sleep mode was not happening. When connected to an adjustable converter I notice that if I wound down the voltage under 3.0v they would spark into life. Its the same with all the NRF PA LNA modules I tried.
-
I bought my first NRF24L01+ modules from cg market and I created some simple nodes (temp/hum and binary switch) using 3V coin battery, and they are up since last January. Than, I'm wondering why
, I bought other modules from another seller and I got a lot of problem: the binary switch (same of the other one in software and hardware) fails many times in sending communications to the gateway and after just 1 month I had to replace the battery; another node cannot even communicate at all if I move it in another room different from the gateway (of course I tried different values of decoupling-capacitors) 
I have to get new modules
-
@doug said:
I have found that the NRF24L01+ PA LNA radios I have, have 100% packet loss and will not sleep if driven with voltages over 3.0v I have dropped the supply to 2.7v and now have minimal packet loss and the radios will sleep at all power level settings.
Current draw is 4.7uA including 328P + RTC when asleep as measured with a uCurrent Gold.
Would you please post a photo of what the module looks like? It might offer up some clues.
-
Here is a photo of the module
-
@doug I do have the same ones bought at alice from the shop link. I also have issues and basically not functioning. I will try your "fix" and see how it goes. Did you do some shielding?
Cheers,
SJ
-
@doug I did some quick tests and I can confim that the modules work better with less voltage. I made best experience with 2.5-2.6V. However they are still much much worse than all others I have and not worth the hassle IMHO.
-
@parachutesj said:
. However they are still much much worse than all others I have and not worth the hassle IMHO.
Which other ones do you have that perform better? It would be very useful to know.
-
@parachutesj said:
@doug I do have the same ones bought at alice from the shop link. I also have issues and basically not functioning. I will try your "fix" and see how it goes. Did you do some shielding?
Cheers,
SJFWIW, I use these exact ones and I get very good range with them, without additional shielding.
Cheers
Al
-
@NeverDie
I have the shielded ones from IC-Station:
http://www.icstation.com/22dbm-100mw-nrf24l01ppalna-wireless-transmission-module-p-4677.htmlBack to the ones discussed here:
When doing the basic test from earlier in this thread I am getting massive packet loss even if the modules are very close together. Ok, maybe it needs to be shielded, power too high etc and tried having them separated with no luck, still massive packet losses. Of course this is no scientific research.Without tweaking, modifications, special antenna orientation the shielded IC-Station ones just worked for me. I am not saying the others don't work, they just perform not in my setup very well.
Also as a comparison, I have some cheep modules from Aliexpress they outperform the ampliefied ones (at least within the house):
http://www.aliexpress.com/item/10PCS-LOT-NRF24L01-wireless-data-transmission-module-2-4G-the-NRF24L01-upgrade-version/1593276910.html
Those modules look very poor build to be honest but seem to be ok. They came in one single back, some pins bent but nothing which couldn't be fixed. Minor packet losses and antenna orientation seems to be key.
In comparison, I also bought some more expensive ones, which claim to be original:
http://www.aliexpress.com/item/Free-shipping-Original-Genuine-NRF24L01-Wireless-Module-2-4G-wireless-communication-module-2-54mm-Interface-2/1781618813.html
Those came in a nice protected box and look very well made.
They work, I even think better than the others - but I already blew two of them. Not sure what went wrongJust received some SMD ones which haven't been tested yet.
-
Does anyone know if the NRF24L01 and the +PA+LNA modules can be mixed and matched? Will the regular modules and the longer range versions talk to each other? I would like to use one of the long range modules on my gateway in the house and on some sensors around my yard that are a fair distance from my house. But then to save some money I was wondering if I could use the regular modules around the rest of my house. My concern is if I use regular modules on the sensors in my house if they will still be able to communicate with the longer range version module I have on my gateway?
-
@loralg I successfully use a nRF24L01+PA+LNA on the gateway and regular nRF24L01+ on the sensors.
There is a lot of information and hints available in the forum regarding the nRF24L01+PA+LNA . See e.g. here:
https://forum.mysensors.org/topic/3719/nrf24l01-vs-nrf24l01-pa-lna/2In my case, however, the nRF24L01+PA+LNA works fine without any fix or special attention.
-
Hello,
What is the best way to measure the performance of one module at a given distance? I mean, how can I measure the number of packets lost?
Does anybody already created a "performace test sketch" to perofrm a better test?
-
@afeno said:
Hello,
What is the best way to measure the performance of one module at a given distance? I mean, how can I measure the number of packets lost?
Does anybody already created a "performace test sketch" to perofrm a better test?I posted a sketch earlier in this thread.
-
@parachutesj said:
@doug I did some quick tests and I can confim that the modules work better with less voltage. I made best experience with 2.5-2.6V. However they are still much much worse than all others I have and not worth the hassle IMHO.
How did you decrease the voltage on nrf24l01+ PA? I have a voltage regulator providing 3.3V.
-
I have also found that the higher the voltage the more capacitance you need. Guess that makes sense. Still can't get them to work reliably at 3.3v though.
I am realising the important thing is a good power supply you need to choose the right regulator to ensure the voltage doesn't tank too far when the current spikes (~180mA). caps help to some degree and I have found ceramic are better than the aluminium ones.
I am now using a single cell lipo and 2 regulators one at 3.3 and one at 2.7 for the radio. Also easier to get a low IQ with 2 regulators rather than one big one.
I am still learning and need to start doing some playing with a greater range of modules. Especially as your experience of these is that they are pretty poor.
-
I'm wondering the same as @alexsh1 . How can I get 2.5-2.6V? There is an easy/cheap way to do it?
-
@afeno The cheap way is a diode in the vcc line. The voltage drop over a normal silicon diode (i.e. 1N4001) is around 0.7V. This has proven to be a working solution.
-
@alexsh1
as it was just a test, I used a table power supply to have the exact voltages.
-
Hello,
I'm creating a "ping" sketch to measure the % of packet lost using the tmrh20 library. I will post it once it is finished but it is just a modification of the "GettingStarted" sketch.It is very simple:
- Node 1 send a value to node 2.
- Node 2 receive the message and send it back to node 1.
- Node 1 receive the message.
I'm measuring the number of packets lost and the turnaround time.
But doing some tests, I realised about something very strange that I don't understand...
Based on the sketch described above, both the node 1 and 2 are sending and receiving the same amount of data.
They both use the same commands to send and receive.
I have two hardware sensors/devices (let's call it A and B ) based on arduinos nano.When I use A as Node 1 it gets 0.2% of packets lost. (B is used as Node 2)
When I use B as Node 1 it gets 15% of packets lost!! (A is used as Node 2)Remember: Both nodes are sending and receiving the same amount of data.
I understand that the current, radio, noise, etc. might have an impact on the performance and range but why it is working fine on one way? And not in the other way? This is making me crazy. Both sensors are sending and receiving the same data. If one of them is not sending (or receiving) well, the performance still should be the same independent on who is acting as node 1 or 2.
What I am missing?
Thank you!
