Which are the *best* NRF24L01+ modules?
-
@NeverDie So you've received two orders of blob modules which work well, from different sources?
Where did you order them from? I'm interested.
@Zeph said:
@NeverDie So you've received two orders of blob modules which work well, from different sources?
Where did you order them from? I'm interested.
I originally received two modules from: http://rayshobby.net/rftoy/ when I purchased my RFToy.
I received 10 from http://www.ebay.com/itm/301378218320, of which I've tested two, and they seem the same.
These I haven't tried: http://www.ebay.com/itm/301402792434 but looking at the photos they look the same to me.
So, for the NRF24L01+, if you can call it that, this "blob module" is my final choice. In my rough-and-ready testing, it stood out from the rest. If you decide to get it, I'd be curious if you, or anyone, can figure out what it actually is. It can't do 250Kbps. I anticipate I would run it at 1Mbps only.
If it weren't for the RFM69HW, I would buy more. I'm waiting to see whether I like it more.
-
Looking at the datasheet for the RFM69, I notice the maximum datarate is 300kbps. So, at least on paper, I get the impression the NRF24L01+ wins on power efficiency, but the RFM69 can offer greater range. Is that right? Is that the main tradeoff between the two?
-
The RFM69x operates in one of three smaller frequency bands (ie: fewer available frequencies): 433MHz, 868 MHz (Europe), 915 MHz (US).
While there are supposed to be scores of independent channels for the nRF24 on the wider 2.4GHz band, there isn't as much room on the lower frequency bands. So 300 KBps is more of a theoretical limit; mostly the RFM69 is used for lower bit rates than that, with correspondingly lower bandwidth - and thus higher range! Unlike the nRF, you can trade off bit rate & bandwidth vs range (at any given power).
For most sensor networks, I think the RFM69 will have plenty of data bandwidth and better range (at say 56Kbps or so). For a good example, see the JeeNodes (which used the RFM12B but are migrating to the RFM69x which fits the same niche but is a better chip). JeeNodes fit a niche very similar to MySensors in that there are distributed sensor nodes communicating with a central hub, with some of the sensor nodes sleeping most of the time to save battery power. (JeeNodes are not as well integrated into common Home Automation systems, but we are now talking more about hardware and protocols).
I also use the nRF for holiday lighting control, which is more bandwidth hungry. For that the higher speeds are required. In this case a master is blasting data as fast as it can to one or more slaves; the slaves don't need to respond much, and if they do they can be polled with the Master so the master doesn't broadcast at the same time. (If using nRF for MySensors too, obviously they need to be on different channels).
There is some usefulness to me in using nRF24L01+ for both, so the same node hardware can potentially be re-purposed; it's only a firmware (and channel) change to switch between these networks. But I'm rethinking this and wondering about switching sensors to the RFM68x.
I'm not sure about power efficiency. An analysis will depend on how often the node needs to be powered up and for how long, as well as the sleep current. JeeNodes are also pretty careful about power.
-
So, for the NRF24L01+, if you can call it that, this "blob module" is my final choice.
They are sounding potentially attractive. Here is some of what I am wondering.
-
Do they take more power when transmitting? When receiving? (Should be fairly easy to test) When sleeping? (Harder, needs micropower sensor)
-
Do they test (via registers) as nRF24L01 or nRF24L01+? And in particular, do they implement all the plus features (like ESB mode) other than the missing 250 Kbps data rate?
-
Are they compatible over the air with the Nordic chips (at 1Mbps/2Mbps)? In general, and in terms of using ESB mode. At least one clone/derivative chip got the NoAck bit (as sent over the air) reversed from Nordic, due to an error in the Nordic datasheet. (We don't see that in the registers, it only shows up in the OTA packet).
It would be good to be compatible with Nordic (and good clones), so that (1) we can swap in/out with other nRF chips we already have or purchase in the future and (2) in particular we can use the higher powered LNA+PA+antenna versions for a gateway or hub, which are not available in blob form AFAIK.
Do you have any answers to any of these yet? Anybody else? If they have ESB and are compatible OTA with Nordic, I think they are very attractive; the power usage is a secondary concern, and only for some nodes.
-
-
I don't at present know any of those answers. However, I am interested in power consumed. Also, at present I'm less concerned about interoperability than I am about range and not having to aim the antenna so precisely.
-
So, for the NRF24L01+, if you can call it that, this "blob module" is my final choice.
They are sounding potentially attractive. Here is some of what I am wondering.
-
Do they take more power when transmitting? When receiving? (Should be fairly easy to test) When sleeping? (Harder, needs micropower sensor)
-
Do they test (via registers) as nRF24L01 or nRF24L01+? And in particular, do they implement all the plus features (like ESB mode) other than the missing 250 Kbps data rate?
-
Are they compatible over the air with the Nordic chips (at 1Mbps/2Mbps)? In general, and in terms of using ESB mode. At least one clone/derivative chip got the NoAck bit (as sent over the air) reversed from Nordic, due to an error in the Nordic datasheet. (We don't see that in the registers, it only shows up in the OTA packet).
It would be good to be compatible with Nordic (and good clones), so that (1) we can swap in/out with other nRF chips we already have or purchase in the future and (2) in particular we can use the higher powered LNA+PA+antenna versions for a gateway or hub, which are not available in blob form AFAIK.
Do you have any answers to any of these yet? Anybody else? If they have ESB and are compatible OTA with Nordic, I think they are very attractive; the power usage is a secondary concern, and only for some nodes.
@Zeph said:
So, for the NRF24L01+, if you can call it that, this "blob module" is my final choice.
They are sounding potentially attractive. Here is some of what I am wondering.
-
Do they take more power when transmitting? When receiving? (Should be fairly easy to test) When sleeping? (Harder, needs micropower sensor)
-
Do they test (via registers) as nRF24L01 or nRF24L01+? And in particular, do they implement all the plus features (like ESB mode) other than the missing 250 Kbps data rate?
-
Are they compatible over the air with the Nordic chips (at 1Mbps/2Mbps)? In general, and in terms of using ESB mode. At least one clone/derivative chip got the NoAck bit (as sent over the air) reversed from Nordic, due to an error in the Nordic datasheet. (We don't see that in the registers, it only shows up in the OTA packet).
It would be good to be compatible with Nordic (and good clones), so that (1) we can swap in/out with other nRF chips we already have or purchase in the future and (2) in particular we can use the higher powered LNA+PA+antenna versions for a gateway or hub, which are not available in blob form AFAIK.
Do you have any answers to any of these yet? Anybody else? If they have ESB and are compatible OTA with Nordic, I think they are very attractive; the power usage is a secondary concern, and only for some nodes.
@Zeph: Regarding #2: What is ESB mode? To what degree does the mysensors code rely on those things being true? i.e. do certain clone/fake chips "break" the mysensors code, or do they just run less efficiently?
So far I haven't noticed incompatibility between the blob modules and other modules. I haven't extensively tested, though, so it's more of a casual observation. The data seems to get through. That said, I'm going to use only blob modules, so it's a moot issue to me. If it were a concern for you, they're cheap enough you could probably just replace whatever modules you have with blob modules, and then those potential issues disappear. Ironically, the only way to be certain all your modules are of the same type may be to use blob modules! Otherwise, as you outlined earlier, it's really hard to know what chip you actually have on any given module. I have less confidence in how randomly different chips might interoperate than when chps are all of one type, whatever that may be.
I'm going to switchover from using Mirf (which got me started) to the same library mySensors uses :tmrh20. Then I'll be better able to run more detailed tests that are directly relevant. Either before or after that I'll try to measure power consumption, especially transmit power.
-
-
Hi everyone!
I bought some NRF24L01+ that have the Range Extension chip RFaxis RFX2401C
I'm curious to see how they perform :)
And for that I'm thinking in rewriting the RFToy Sender/Receiver examples with the MySensor libraries.
This will allow me to learn about the MySensor libraries and also to test the "performance" of the RF modules with different configurations.What do you think? Let me know if you're interested in such code.
Regards
MySensors rules my home :)
-
Hi everyone!
I bought some NRF24L01+ that have the Range Extension chip RFaxis RFX2401C
I'm curious to see how they perform :)
And for that I'm thinking in rewriting the RFToy Sender/Receiver examples with the MySensor libraries.
This will allow me to learn about the MySensor libraries and also to test the "performance" of the RF modules with different configurations.What do you think? Let me know if you're interested in such code.
Regards
@Daniel-Oliveira said:
Hi everyone!
I bought some NRF24L01+ that have the Range Extension chip RFaxis RFX2401C
I'm curious to see how they perform :)
And for that I'm thinking in rewriting the RFToy Sender/Receiver examples with the MySensor libraries.
This will allow me to learn about the MySensor libraries and also to test the "performance" of the RF modules with different configurations.What do you think? Let me know if you're interested in such code.
Regards
Yes, definitely! I'll also be very interested to hear about the performance of your range extended modules.
-
I took a quick stab just now at using a Dave Jones uCurrent and an oscilliscope to measure the current on an NRF24L01+, but there was too much noise. I suspect long wires are contributing to the problem. I'm inclined to think some kind of onboard measurement by the arduino itself is the way to go, as then the wire lengths are short. Not sure how other people are rigging to do it, but so far measuring NRF power consumption seems a lot easier said than done.
-
I took a quick stab just now at using a Dave Jones uCurrent and an oscilliscope to measure the current on an NRF24L01+, but there was too much noise. I suspect long wires are contributing to the problem. I'm inclined to think some kind of onboard measurement by the arduino itself is the way to go, as then the wire lengths are short. Not sure how other people are rigging to do it, but so far measuring NRF power consumption seems a lot easier said than done.
@NeverDie just some tips when measuring small currents:
- use a stable power supply (e.g lab supply). Don't power from you pc or cheap switching powersupply.
- twist the leads to the current.
- use your scope to filter noise or add a lowpass filter using a capicitor+resistor on the signal going from the ucurrent to your scope
http://yveaux.blogspot.nl
-
@NeverDie just some tips when measuring small currents:
- use a stable power supply (e.g lab supply). Don't power from you pc or cheap switching powersupply.
- twist the leads to the current.
- use your scope to filter noise or add a lowpass filter using a capicitor+resistor on the signal going from the ucurrent to your scope
@Yveaux said:
@NeverDie just some tips when measuring small currents:
- use a stable power supply (e.g lab supply). Don't power from you pc or cheap switching powersupply.
- twist the leads to the current.
- use your scope to filter noise or add a lowpass filter using a capicitor+resistor on the signal going from the ucurrent to your scope
Thanks! Those are useful suggestions on how to proceed.
On my first attempt last night I used an Arduino Uno to drive the NRF24L01+. I eventually noticed that even without plugging the USB cable into my computer that the USB cable was a big source of noise when plugged into the Uno. When I did plug the USB cable into my computer, the noise got much worse. So, the USB cable has got to go.
New plan for the second attempt::
-
Use an RFToy, instead of Uno, because it's a more compact way to plug-in the NRF24L01+ without having wires dangling all over, and because it can run off a coin cell battery, again without wires.
-
Plug the NRF24L01+ into "tall" female header pins, and then plug those into the usual 2x4 header on the RFToy. Why? Because the leg of the tall VCC header pin I'm going to snip and (hopefully) replace with a 1 ohm sense resister. With luck there will be enough room on either side of the inline sense resister to connect up the oscilloscope and thereby do measurements without introducing long wires that might pick up noise.
-
BTW, I notice ManiacBug measures transmitter current with just a $50 multimeter and setting "endless trasmitter" mode. https://maniacbug.wordpress.com/2011/10/19/sensor-node/
Not sure how accurate that is though.
-
Lastly, I notice these "Noise Cancelling Techniques" from an Attiny datasheet, regtarding ADC measurements:
"Digital circuitry inside and outside the device generates EMI which might affect the accuracy of
analog measurements. When conversion accuracy is critical, the noise level can be reduced by
applying the following techniques:
• Keep analog signal paths as short as possible.
• Make sure analog tracks run over the analog ground plane.
• Keep analog tracks well away from high-speed switching digital tracks.
• If any port pin is used as a digital output, it mustn’t switch while a conversion is in progress.
• Place bypass capacitors as close to VCC and GND pins as possible." -
@Zeph said:
So, for the NRF24L01+, if you can call it that, this "blob module" is my final choice.
They are sounding potentially attractive. Here is some of what I am wondering.
-
Do they take more power when transmitting? When receiving? (Should be fairly easy to test) When sleeping? (Harder, needs micropower sensor)
-
Do they test (via registers) as nRF24L01 or nRF24L01+? And in particular, do they implement all the plus features (like ESB mode) other than the missing 250 Kbps data rate?
-
Are they compatible over the air with the Nordic chips (at 1Mbps/2Mbps)? In general, and in terms of using ESB mode. At least one clone/derivative chip got the NoAck bit (as sent over the air) reversed from Nordic, due to an error in the Nordic datasheet. (We don't see that in the registers, it only shows up in the OTA packet).
It would be good to be compatible with Nordic (and good clones), so that (1) we can swap in/out with other nRF chips we already have or purchase in the future and (2) in particular we can use the higher powered LNA+PA+antenna versions for a gateway or hub, which are not available in blob form AFAIK.
Do you have any answers to any of these yet? Anybody else? If they have ESB and are compatible OTA with Nordic, I think they are very attractive; the power usage is a secondary concern, and only for some nodes.
@Zeph: Regarding #2: What is ESB mode? To what degree does the mysensors code rely on those things being true? i.e. do certain clone/fake chips "break" the mysensors code, or do they just run less efficiently?
So far I haven't noticed incompatibility between the blob modules and other modules. I haven't extensively tested, though, so it's more of a casual observation. The data seems to get through. That said, I'm going to use only blob modules, so it's a moot issue to me. If it were a concern for you, they're cheap enough you could probably just replace whatever modules you have with blob modules, and then those potential issues disappear. Ironically, the only way to be certain all your modules are of the same type may be to use blob modules! Otherwise, as you outlined earlier, it's really hard to know what chip you actually have on any given module. I have less confidence in how randomly different chips might interoperate than when chps are all of one type, whatever that may be.
I'm going to switchover from using Mirf (which got me started) to the same library mySensors uses :tmrh20. Then I'll be better able to run more detailed tests that are directly relevant. Either before or after that I'll try to measure power consumption, especially transmit power.
@NeverDie said:
@Zeph said:
So, for the NRF24L01+, if you can call it that, this "blob module" is my final choice.
They are sounding potentially attractive. Here is some of what I am wondering.
-
Do they take more power when transmitting? When receiving? (Should be fairly easy to test) When sleeping? (Harder, needs micropower sensor)
-
Do they test (via registers) as nRF24L01 or nRF24L01+? And in particular, do they implement all the plus features (like ESB mode) other than the missing 250 Kbps data rate?
-
Are they compatible over the air with the Nordic chips (at 1Mbps/2Mbps)? In general, and in terms of using ESB mode. At least one clone/derivative chip got the NoAck bit (as sent over the air) reversed from Nordic, due to an error in the Nordic datasheet. (We don't see that in the registers, it only shows up in the OTA packet).
It would be good to be compatible with Nordic (and good clones), so that (1) we can swap in/out with other nRF chips we already have or purchase in the future and (2) in particular we can use the higher powered LNA+PA+antenna versions for a gateway or hub, which are not available in blob form AFAIK.
Do you have any answers to any of these yet? Anybody else? If they have ESB and are compatible OTA with Nordic, I think they are very attractive; the power usage is a secondary concern, and only for some nodes.
@Zeph: Regarding #2: What is ESB mode?
Enhanced ShockBurst, which is a mode added to the plus version by Nordic (nRF24L01+). Many of the clones and derivatives have it, some may not. It adds automatic ack and retry, and perhaps other features.
@hek is ESB mode still used in MySensors?
So far I haven't noticed incompatibility between the blob modules and other modules. I haven't extensively tested, though, so it's more of a casual observation. The data seems to get through. That said, I'm going to use only blob modules, so it's a moot issue to me. If it were a concern for you, they're cheap enough you could probably just replace whatever modules you have with blob modules, and then those potential issues disappear.
Have you found compatible blob modules with external antennas and/or LNA+PA (Low Noise Amplifier + Power Amplifier)?
Ironically, the only way to be certain all your modules are of the same type may be to use blob modules!
Until a new blob module type shows up.
Otherwise, as you outlined earlier, it's really hard to know what chip you actually have on any given module. I have less confidence in how randomly different chips might interoperate than when chps are all of one type, whatever that may be.
People here and elsewhere have had a lot of success in interoperation. However, that could be becoming more difficult, if too many fake chips get on the market.
BTW - I consider an openly described "nRF24L01+ compatible" chip to be a "derivative" if it openly modifies or extends the Nordic functions, a "clone" if it attempts to exactly mimic the Nordic chips. A "fake" is mislabeled and deceptive rather than being openly described as not Nordic.
I'm going to switchover from using Mirf (which got me started) to the same library mySensors uses :tmrh20. Then I'll be better able to run more detailed tests that are directly relevant. Either before or after that I'll try to measure power consumption, especially transmit power.
Good idea. I think TMRH20 has the best RF24 fork, and I've contributed slightly to it in its early days.
I look forward to your measurements. For battery operation with long sleep periods, the sleep current is also important.
If your module has higher RF transmit power (as I suspect), it might also be interesting to see what the current drain is when you drop the power a notch (ie: bring it closer to the Nordic part's RF output). The ideal might be if it can be run at about the same RF power as Nordic with similar PS current, OR could be boosted for more RF power at the cost of more PS current.
Bu the way, you might have a version which can boost its power still further. For example, the Si24R01 has a default boost of about 2-3 dBm over the Nordic, but can be set for 7 dBm! See https://github.com/solarkennedy/equail/tree/master/Libraries/RF24
Since transmit power is likely over 10mA you may be able to measure that without a MicroPower device. But you'll need such a device to measure sleep currents.
-
-
@NeverDie said:
@Zeph said:
So, for the NRF24L01+, if you can call it that, this "blob module" is my final choice.
They are sounding potentially attractive. Here is some of what I am wondering.
-
Do they take more power when transmitting? When receiving? (Should be fairly easy to test) When sleeping? (Harder, needs micropower sensor)
-
Do they test (via registers) as nRF24L01 or nRF24L01+? And in particular, do they implement all the plus features (like ESB mode) other than the missing 250 Kbps data rate?
-
Are they compatible over the air with the Nordic chips (at 1Mbps/2Mbps)? In general, and in terms of using ESB mode. At least one clone/derivative chip got the NoAck bit (as sent over the air) reversed from Nordic, due to an error in the Nordic datasheet. (We don't see that in the registers, it only shows up in the OTA packet).
It would be good to be compatible with Nordic (and good clones), so that (1) we can swap in/out with other nRF chips we already have or purchase in the future and (2) in particular we can use the higher powered LNA+PA+antenna versions for a gateway or hub, which are not available in blob form AFAIK.
Do you have any answers to any of these yet? Anybody else? If they have ESB and are compatible OTA with Nordic, I think they are very attractive; the power usage is a secondary concern, and only for some nodes.
@Zeph: Regarding #2: What is ESB mode?
Enhanced ShockBurst, which is a mode added to the plus version by Nordic (nRF24L01+). Many of the clones and derivatives have it, some may not. It adds automatic ack and retry, and perhaps other features.
@hek is ESB mode still used in MySensors?
So far I haven't noticed incompatibility between the blob modules and other modules. I haven't extensively tested, though, so it's more of a casual observation. The data seems to get through. That said, I'm going to use only blob modules, so it's a moot issue to me. If it were a concern for you, they're cheap enough you could probably just replace whatever modules you have with blob modules, and then those potential issues disappear.
Have you found compatible blob modules with external antennas and/or LNA+PA (Low Noise Amplifier + Power Amplifier)?
Ironically, the only way to be certain all your modules are of the same type may be to use blob modules!
Until a new blob module type shows up.
Otherwise, as you outlined earlier, it's really hard to know what chip you actually have on any given module. I have less confidence in how randomly different chips might interoperate than when chps are all of one type, whatever that may be.
People here and elsewhere have had a lot of success in interoperation. However, that could be becoming more difficult, if too many fake chips get on the market.
BTW - I consider an openly described "nRF24L01+ compatible" chip to be a "derivative" if it openly modifies or extends the Nordic functions, a "clone" if it attempts to exactly mimic the Nordic chips. A "fake" is mislabeled and deceptive rather than being openly described as not Nordic.
I'm going to switchover from using Mirf (which got me started) to the same library mySensors uses :tmrh20. Then I'll be better able to run more detailed tests that are directly relevant. Either before or after that I'll try to measure power consumption, especially transmit power.
Good idea. I think TMRH20 has the best RF24 fork, and I've contributed slightly to it in its early days.
I look forward to your measurements. For battery operation with long sleep periods, the sleep current is also important.
If your module has higher RF transmit power (as I suspect), it might also be interesting to see what the current drain is when you drop the power a notch (ie: bring it closer to the Nordic part's RF output). The ideal might be if it can be run at about the same RF power as Nordic with similar PS current, OR could be boosted for more RF power at the cost of more PS current.
Bu the way, you might have a version which can boost its power still further. For example, the Si24R01 has a default boost of about 2-3 dBm over the Nordic, but can be set for 7 dBm! See https://github.com/solarkennedy/equail/tree/master/Libraries/RF24
Since transmit power is likely over 10mA you may be able to measure that without a MicroPower device. But you'll need such a device to measure sleep currents.
@Zeph said:
Have you found compatible blob modules with external antennas and/or LNA+PA (Low Noise Amplifier + Power Amplifier)?
Interesting idea. I don't recollect seeing any LNA+PA modules with blobs on them, but then again I haven't tried looking for such a thing. At least so far the simple blob module appears to have all the range I need.
-
-
@NeverDie said:
@Zeph said:
So, for the NRF24L01+, if you can call it that, this "blob module" is my final choice.
They are sounding potentially attractive. Here is some of what I am wondering.
-
Do they take more power when transmitting? When receiving? (Should be fairly easy to test) When sleeping? (Harder, needs micropower sensor)
-
Do they test (via registers) as nRF24L01 or nRF24L01+? And in particular, do they implement all the plus features (like ESB mode) other than the missing 250 Kbps data rate?
-
Are they compatible over the air with the Nordic chips (at 1Mbps/2Mbps)? In general, and in terms of using ESB mode. At least one clone/derivative chip got the NoAck bit (as sent over the air) reversed from Nordic, due to an error in the Nordic datasheet. (We don't see that in the registers, it only shows up in the OTA packet).
It would be good to be compatible with Nordic (and good clones), so that (1) we can swap in/out with other nRF chips we already have or purchase in the future and (2) in particular we can use the higher powered LNA+PA+antenna versions for a gateway or hub, which are not available in blob form AFAIK.
Do you have any answers to any of these yet? Anybody else? If they have ESB and are compatible OTA with Nordic, I think they are very attractive; the power usage is a secondary concern, and only for some nodes.
@Zeph: Regarding #2: What is ESB mode?
Enhanced ShockBurst, which is a mode added to the plus version by Nordic (nRF24L01+). Many of the clones and derivatives have it, some may not. It adds automatic ack and retry, and perhaps other features.
@hek is ESB mode still used in MySensors?
So far I haven't noticed incompatibility between the blob modules and other modules. I haven't extensively tested, though, so it's more of a casual observation. The data seems to get through. That said, I'm going to use only blob modules, so it's a moot issue to me. If it were a concern for you, they're cheap enough you could probably just replace whatever modules you have with blob modules, and then those potential issues disappear.
Have you found compatible blob modules with external antennas and/or LNA+PA (Low Noise Amplifier + Power Amplifier)?
Ironically, the only way to be certain all your modules are of the same type may be to use blob modules!
Until a new blob module type shows up.
Otherwise, as you outlined earlier, it's really hard to know what chip you actually have on any given module. I have less confidence in how randomly different chips might interoperate than when chps are all of one type, whatever that may be.
People here and elsewhere have had a lot of success in interoperation. However, that could be becoming more difficult, if too many fake chips get on the market.
BTW - I consider an openly described "nRF24L01+ compatible" chip to be a "derivative" if it openly modifies or extends the Nordic functions, a "clone" if it attempts to exactly mimic the Nordic chips. A "fake" is mislabeled and deceptive rather than being openly described as not Nordic.
I'm going to switchover from using Mirf (which got me started) to the same library mySensors uses :tmrh20. Then I'll be better able to run more detailed tests that are directly relevant. Either before or after that I'll try to measure power consumption, especially transmit power.
Good idea. I think TMRH20 has the best RF24 fork, and I've contributed slightly to it in its early days.
I look forward to your measurements. For battery operation with long sleep periods, the sleep current is also important.
If your module has higher RF transmit power (as I suspect), it might also be interesting to see what the current drain is when you drop the power a notch (ie: bring it closer to the Nordic part's RF output). The ideal might be if it can be run at about the same RF power as Nordic with similar PS current, OR could be boosted for more RF power at the cost of more PS current.
Bu the way, you might have a version which can boost its power still further. For example, the Si24R01 has a default boost of about 2-3 dBm over the Nordic, but can be set for 7 dBm! See https://github.com/solarkennedy/equail/tree/master/Libraries/RF24
Since transmit power is likely over 10mA you may be able to measure that without a MicroPower device. But you'll need such a device to measure sleep currents.
@Zeph said:
For battery operation with long sleep periods, the sleep current is also important.
Good point. Noise might present a problem with measuring it, but I'll make an attempt. Perhaps a regular multimeter would be good enough for that, since (presumably) it would average any spikes? The result might be higher than the true number, and so be a worst case number. That's possibly OK though: if it turns out the worst case number is acceptable, then all is good.
-
-
@NeverDie said:
@Zeph said:
So, for the NRF24L01+, if you can call it that, this "blob module" is my final choice.
They are sounding potentially attractive. Here is some of what I am wondering.
-
Do they take more power when transmitting? When receiving? (Should be fairly easy to test) When sleeping? (Harder, needs micropower sensor)
-
Do they test (via registers) as nRF24L01 or nRF24L01+? And in particular, do they implement all the plus features (like ESB mode) other than the missing 250 Kbps data rate?
-
Are they compatible over the air with the Nordic chips (at 1Mbps/2Mbps)? In general, and in terms of using ESB mode. At least one clone/derivative chip got the NoAck bit (as sent over the air) reversed from Nordic, due to an error in the Nordic datasheet. (We don't see that in the registers, it only shows up in the OTA packet).
It would be good to be compatible with Nordic (and good clones), so that (1) we can swap in/out with other nRF chips we already have or purchase in the future and (2) in particular we can use the higher powered LNA+PA+antenna versions for a gateway or hub, which are not available in blob form AFAIK.
Do you have any answers to any of these yet? Anybody else? If they have ESB and are compatible OTA with Nordic, I think they are very attractive; the power usage is a secondary concern, and only for some nodes.
@Zeph: Regarding #2: What is ESB mode?
Enhanced ShockBurst, which is a mode added to the plus version by Nordic (nRF24L01+). Many of the clones and derivatives have it, some may not. It adds automatic ack and retry, and perhaps other features.
@hek is ESB mode still used in MySensors?
So far I haven't noticed incompatibility between the blob modules and other modules. I haven't extensively tested, though, so it's more of a casual observation. The data seems to get through. That said, I'm going to use only blob modules, so it's a moot issue to me. If it were a concern for you, they're cheap enough you could probably just replace whatever modules you have with blob modules, and then those potential issues disappear.
Have you found compatible blob modules with external antennas and/or LNA+PA (Low Noise Amplifier + Power Amplifier)?
Ironically, the only way to be certain all your modules are of the same type may be to use blob modules!
Until a new blob module type shows up.
Otherwise, as you outlined earlier, it's really hard to know what chip you actually have on any given module. I have less confidence in how randomly different chips might interoperate than when chps are all of one type, whatever that may be.
People here and elsewhere have had a lot of success in interoperation. However, that could be becoming more difficult, if too many fake chips get on the market.
BTW - I consider an openly described "nRF24L01+ compatible" chip to be a "derivative" if it openly modifies or extends the Nordic functions, a "clone" if it attempts to exactly mimic the Nordic chips. A "fake" is mislabeled and deceptive rather than being openly described as not Nordic.
I'm going to switchover from using Mirf (which got me started) to the same library mySensors uses :tmrh20. Then I'll be better able to run more detailed tests that are directly relevant. Either before or after that I'll try to measure power consumption, especially transmit power.
Good idea. I think TMRH20 has the best RF24 fork, and I've contributed slightly to it in its early days.
I look forward to your measurements. For battery operation with long sleep periods, the sleep current is also important.
If your module has higher RF transmit power (as I suspect), it might also be interesting to see what the current drain is when you drop the power a notch (ie: bring it closer to the Nordic part's RF output). The ideal might be if it can be run at about the same RF power as Nordic with similar PS current, OR could be boosted for more RF power at the cost of more PS current.
Bu the way, you might have a version which can boost its power still further. For example, the Si24R01 has a default boost of about 2-3 dBm over the Nordic, but can be set for 7 dBm! See https://github.com/solarkennedy/equail/tree/master/Libraries/RF24
Since transmit power is likely over 10mA you may be able to measure that without a MicroPower device. But you'll need such a device to measure sleep currents.
@Zeph said:
I think TMRH20 has the best RF24 fork, and I've contributed slightly to it in its early days.
Excellent! In that case, do you happen to know off the top of your head: what's the simplest method or function call in TMRH20 for putting the NRF24L01+ to sleep? If I don't have to research that, I can jump ahead to taking a measurement of it sleeping, as per the above.
-
-
@Zeph said:
I think TMRH20 has the best RF24 fork, and I've contributed slightly to it in its early days.
Excellent! In that case, do you happen to know off the top of your head: what's the simplest method or function call in TMRH20 for putting the NRF24L01+ to sleep? If I don't have to research that, I can jump ahead to taking a measurement of it sleeping, as per the above.
@NeverDie
http://tmrh20.github.io/RF24/classRF24.html#aa0a51923a09ba4f3478aba9be0f8a6a1You are going to need your Davy Jones uCurrent to measure sleeping current!
-
So, here are the current measurements on the blob module. I used a 1 ohm sense resister, so 1mv=1ma.
I wrote a short script to transmit a packet once every 10 milliseconds:
Now I'll zoom in progressively so you can see for yourself what the current is:
Doing this measurement is the first time I've ever used an oscilliscope (a Rigole 1054Z). Because the lines are kinda thick (noise, I guess), what would you say the current draw is during a transmission?
In this case, there is no echo receiver, and so whatever gets sent isn't received by anything.
