Most reliable "best" radio
-
From time to time I'll try comparing different radios, and when I do I'll try to update this thread.
As a baseline, the first radio I'm trying that passes the test of reliably transmitting packets across the worst possible path in my house (namely, 5 feet below grade behind a concrete footer to the receiver, located on the diagonal of the house on the second story) is the DORJI DRF1262T LoRa radio, which includes a TCXO and operates at 915Mhz. It uses Semtech's SX1262 chip. First pass results over the "worst case" transmission path just described using mostly default library settings are quite encouraging:
12:34:34 May 20 2022 V1.1 104_LoRa_Receiver_Detailed_Setup Starting LoRa Device found SX1262,915000000hz,SF7,BW125000,CR4:5,LDRO_Off,SyncWord_0x1424,IQNormal,Preamble_8 SX1262,PacketMode_LoRa,Explicit,LNAgain_Boosted Reg 0 1 2 3 4 5 6 7 8 9 A B C D E F 0x800 00 00 00 00 29 07 20 09 00 10 19 D4 10 52 10 16 0x810 10 4F 10 19 10 4F 10 19 00 58 17 6B 89 00 00 00 0x820 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x830 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x840 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x850 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x860 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x870 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x880 03 00 00 5F 10 08 00 00 08 04 00 39 30 00 00 0C 0x890 00 00 00 10 BD 0F 0A 07 10 00 26 01 01 53 06 07 0x8A0 10 00 AD 20 5A 04 F0 02 56 56 54 43 96 20 40 00 0x8B0 00 83 11 00 01 04 0A 4C 14 0A 2F 01 6B FF FF 00 0x8C0 00 A0 20 00 00 00 AC 00 1C 00 00 AB 05 30 12 13 0x8D0 0C 15 16 40 06 00 00 10 E8 00 00 00 00 00 39 39 0x8E0 90 39 0C 04 40 20 16 38 06 00 05 04 03 02 01 01 0x8F0 03 00 00 00 30 00 00 00 00 00 00 00 00 00 00 00 0x900 30 00 00 00 00 64 00 00 00 00 00 00 24 04 47 04 0x910 00 2F 00 00 00 03 0A 00 15 35 09 00 02 2A 67 08 0x920 07 04 05 00 00 00 00 00 00 00 00 00 00 00 00 00 0x930 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x940 00 07 00 03 02 00 10 00 0A 00 03 04 00 14 0C 00 0x950 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00 0x960 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x970 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x980 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x990 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x9A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x9B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x9C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x9D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x9E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x9F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Receiver ready - RXBUFFER_SIZE 32 5s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,1,Errors,0,IRQreg,16 6s Hello World 1234567890*,CRC,DAAB,RSSI,-79dBm,SNR,11dB,Length,23,Packets,2,Errors,0,IRQreg,16 7s Hello World 1234567890*,CRC,DAAB,RSSI,-79dBm,SNR,12dB,Length,23,Packets,3,Errors,0,IRQreg,16 8s Hello World 1234567890*,CRC,DAAB,RSSI,-80dBm,SNR,11dB,Length,23,Packets,4,Errors,0,IRQreg,16 9s Hello World 1234567890*,CRC,DAAB,RSSI,-80dBm,SNR,11dB,Length,23,Packets,5,Errors,0,IRQreg,16 10s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,6,Errors,0,IRQreg,16 11s Hello World 1234567890*,CRC,DAAB,RSSI,-80dBm,SNR,12dB,Length,23,Packets,7,Errors,0,IRQreg,16 12s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,4dB,Length,23,Packets,8,Errors,0,IRQreg,16 14s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,9,Errors,0,IRQreg,16 15s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,10,Errors,0,IRQreg,16 16s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,11,Errors,0,IRQreg,16 17s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,12,Errors,0,IRQreg,16 18s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,11dB,Length,23,Packets,13,Errors,0,IRQreg,16 19s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,14,Errors,0,IRQreg,16 20s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,15,Errors,0,IRQreg,16 21s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,16,Errors,0,IRQreg,16 22s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,9dB,Length,23,Packets,17,Errors,0,IRQreg,16 23s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,18,Errors,0,IRQreg,16 25s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,19,Errors,0,IRQreg,16 26s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,20,Errors,0,IRQreg,16 27s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,12dB,Length,23,Packets,21,Errors,0,IRQreg,16 28s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,12dB,Length,23,Packets,22,Errors,0,IRQreg,16 29s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,23,Errors,0,IRQreg,16 30s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,24,Errors,0,IRQreg,16 31s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,25,Errors,0,IRQreg,16 32s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,7dB,Length,23,Packets,26,Errors,0,IRQreg,16 33s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,27,Errors,0,IRQreg,16 34s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,28,Errors,0,IRQreg,16 36s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,29,Errors,0,IRQreg,16 37s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,30,Errors,0,IRQreg,16 38s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,12dB,Length,23,Packets,31,Errors,0,IRQreg,16 39s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,32,Errors,0,IRQreg,16 40s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,33,Errors,0,IRQreg,16 41s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,11dB,Length,23,Packets,34,Errors,0,IRQreg,16 42s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,9dB,Length,23,Packets,35,Errors,0,IRQreg,16 43s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,36,Errors,0,IRQreg,16 44s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,37,Errors,0,IRQreg,16 45s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,38,Errors,0,IRQreg,16 47s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,39,Errors,0,IRQreg,16 48s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,40,Errors,0,IRQreg,16 49s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,41,Errors,0,IRQreg,16 50s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,11dB,Length,23,Packets,42,Errors,0,IRQreg,16 51s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,11dB,Length,23,Packets,43,Errors,0,IRQreg,16 52s Hello World 1234567890*,CRC,DAAB,RSSI,-75dBm,SNR,5dB,Length,23,Packets,44,Errors,0,IRQreg,16 53s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,11dB,Length,23,Packets,45,Errors,0,IRQreg,16 54s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,11dB,Length,23,Packets,46,Errors,0,IRQreg,16 55s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,47,Errors,0,IRQreg,16 56s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,48,Errors,0,IRQreg,16 58s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,49,Errors,0,IRQreg,16 59s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,50,Errors,0,IRQreg,16 60s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,51,Errors,0,IRQreg,16 61s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,52,Errors,0,IRQreg,16 62s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,6dB,Length,23,Packets,53,Errors,0,IRQreg,16 63s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,54,Errors,0,IRQreg,16 64s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,55,Errors,0,IRQreg,16 65s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,56,Errors,0,IRQreg,16 66s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,57,Errors,0,IRQreg,16 68s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,58,Errors,0,IRQreg,16 69s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,59,Errors,0,IRQreg,16 70s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,60,Errors,0,IRQreg,16 71s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,61,Errors,0,IRQreg,16 72s Hello World 1234567890*,CRC,DAAB,RSSI,-75dBm,SNR,6dB,Length,23,Packets,62,Errors,0,IRQreg,16 73s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,63,Errors,0,IRQreg,16 74s Hello World 1234567890*,CRC,DAAB,RSSI,-75dBm,SNR,11dB,Length,23,Packets,64,Errors,0,IRQreg,16 75s Hello World 1234567890*,CRC,DAAB,RSSI,-75dBm,SNR,11dB,Length,23,Packets,65,Errors,0,IRQreg,16 76s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,11dB,Length,23,Packets,66,Errors,0,IRQreg,16 77s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,67,Errors,0,IRQreg,16 79s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,68,Errors,0,IRQreg,16 80s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,11dB,Length,23,Packets,69,Errors,0,IRQreg,16 81s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,11dB,Length,23,Packets,70,Errors,0,IRQreg,16 82s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,8dB,Length,23,Packets,71,Errors,0,IRQreg,16 83s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,11dB,Length,23,Packets,72,Errors,0,IRQreg,16 84s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,11dB,Length,23,Packets,73,Errors,0,IRQreg,16 85s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,74,Errors,0,IRQreg,16 86s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,75,Errors,0,IRQreg,16 87s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,12dB,Length,23,Packets,76,Errors,0,IRQreg,16 88s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,12dB,Length,23,Packets,77,Errors,0,IRQreg,16 90s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,11dB,Length,23,Packets,78,Errors,0,IRQreg,16 91s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,79,Errors,0,IRQreg,16 92s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,9dB,Length,23,Packets,80,Errors,0,IRQreg,16 93s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,81,Errors,0,IRQreg,16 94s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,82,Errors,0,IRQreg,16 95s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,83,Errors,0,IRQreg,16 96s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,84,Errors,0,IRQreg,16 97s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,85,Errors,0,IRQreg,16 98s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,86,Errors,0,IRQreg,16 99s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,87,Errors,0,IRQreg,16 101s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,88,Errors,0,IRQreg,16 102s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,9dB,Length,23,Packets,89,Errors,0,IRQreg,16 103s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,12dB,Length,23,Packets,90,Errors,0,IRQreg,16 104s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,11dB,Length,23,Packets,91,Errors,0,IRQreg,16 105s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,92,Errors,0,IRQreg,16 106s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,12dB,Length,23,Packets,93,Errors,0,IRQreg,16 107s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,94,Errors,0,IRQreg,16 108s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,11dB,Length,23,Packets,95,Errors,0,IRQreg,16These results are with the transmitter mote set to transmit at 22dBa. I haven't yet tried to optimize that to a lower number. Rather, at the moment, this is more of a quick existence proof that a radio module exists that, under worst case positioning, appears to be solidly reliable.
As time allows I'll do some energy measurements. According to Semtech's "Recommendations for Best Performance" ( https://semtech.my.salesforce.com/sfc/p/#E0000000JelG/a/2R000000HSRX/x.ZO11VNOR4sHFmdUe6NcnHdMHfAiTpsbEcINLKwDvE ) one way to save energy is to power the radio at minimal voltage. It turns out the SX1262 has only an LDO for transmission purposes, whereas the SX1261 also has a more efficient DCDC converter. However, I haven't yet found an SX1261 module in the marketplace that's anywhere near as low priced as the available SX1262 modules. Nonetheless, I reckon one could do one's own DCDC conversion for the SX1262 external to the module, if so desired. I won't know until I do some energy measurements whether it's worth the bother of doing that or whether it's good enough as is.
If I can find an nRF24L01 radio with PA and LNA that can pass the same worst-case transmission path challenge, I'd be interested in measuring how its energy efficiency compares. Because its over-the-air bitrate can be so much faster than what LoRa can deliver, maybe it would prove to be the winner. However, that's only a hypothesis. It will take collecting real measurements to know for sure.
Lastly, I'm aware that a different network topology might be both the lowest cost and most energy efficient of all. For example, using cheap nRF24L01/Si24R1 modules (or nRF52x modules for that matter) in conjunction with nearby powered hubs is probably the lowest cost and most energy efficient of all. So, I'll consider the tradeoffs of that approach also. Maybe the use case for LoRa will turn out to be solely those situations where having a powered hub nearby to backhaul the data is not a practical option.
-
Reporting back: to a first approximation, I may not even need to look at any other radios. Using the Nordic Power Profiler on the entire mote, not just the radio, shows that the library's default transmission at 22dBm--a transmission which delivers packets without problem over even the worst transmission path in my house--consumes just 94.81ma over a period of 67.33ms:
at 3.3v. i.e. without even any attempt at power optimization of any kind. Well, looking at just that transmit interval, and assuming it repeats once every 5 minutes (e.g. for a TH sensor), then, assuming it was powered by 2xAA lithium primary batteries with a capacity of 3500mah, then I calculate those batteries would last more than 18 years, ignoring self-discharge by the batteries. I deem that good enough for me!I'll do a more careful calculation with a sharper pencil and more refined measurements, but on first blush it does not appear I need to look for a better radio after all--at least not if the mote is powered by 2xAA lithium batteries and transmitting no more frequently than once every 5 minutes. Of course, being powered by just a droopy coincell battery or the barest whisp of harvested energy would maybe point to a different solution.
-
Reporting back again: To greatly reduce the transmission time, I changed the bandwidth to 500 and the spreading factor to 5. The end result is that I still get flawless reception across the worst transmission path in the house. Under these assumptions energy consumption becomes even more manageable:
Using these new measurements and the same type of assumptions as before, I calculate the batteries would last more than 188 years! In reaity, of course, the batteries would fully self-discharge long before then.Next up: In addition to the above, for further improvement reduce the transmit power itself.
-
Well, with a projected lifespan as long as that, I might as well have it listen for an ACK to confirm that its transmission was successful. Who cares if it shaves 100 years off its lifespan if it still has 88 years left afterward anyway? LOL. I'm guessing that the long tail pictured above is sx1262 simply idling after transmission before the default library code puts it to sleep.
I did try some lower transmission power levels, but apparently my worst-case path needs more or less the full 22dBm. 15dBm, which is the max power of an SX1261, was nowhere good enough. For that reason, I won't bother looking any more for an SX1261 module, since the chip can't natively go higher than 15dBm on transmit power. 18dBm tested better but also was not fully reliable the way 22dBm is. Of course, better antennas could improve upon this, but those are the results with a simple 3.25" quarter wavelength wire whip antenna on both transmitter and receiver.
The "next thing" on the horizon may be LR-FHSS, which stands for Long Range Frequency Hopping Spread Spectrum. According to Semtech, it has even better energy specs than LoRa and better range and better interference/coexistence. Not surprising that everything needs to be better, better, better, or else it won't get adopted. However, it's still early days, and so far there's nothing yet on Aliexpress. I'm guessing maybe in 5 years the LR1110 chip and related modules may start to show up in the marketplace at low prices, but right now development boards are pricey.
-
I was able to separate out the current going to just the SX1262 radio during a 22dBm transmission event:
As you can see, there is no appreciable tail after the transmission event, so in the earlier snapshot that must have been the atmega328p that was drawing that tail current.So, ignoring the atmega328p, and using just the figures from a transmission interval, then it turns out the lifespan of the batteries (ignoring self-discharge) would be 258
years if assumes such a transmission event once every 5 minutes. I realize that sounds ludicrous, so if your math says differently, please post; perhaps I made a calculation error. Anyway, if the past is any guide, it's the sleep currents that dominate the energy consumption, and I haven't yet accounted for those. So, to tighten up the numbers further, I'll need to measure 1. the sleep current of the radio when it's powered down (though for now I could use the number in the datasheet as a proxy for that), and 2. the amount of energy consumed when waking up from a deep sleep prior to transmission. For #2, I'll definitely want a real measurement, just to be sure. Before that, I'll need to take a deeper look into the library to see how it is currently handling the SX1262 after a transmission event, so I can be sure it's being put into deep sleep. For #1, the equipment I need for accurately measuring nano-amp radio deep sleep current should be arriving on Monday.It turns out that the purely ammeter function of the Nordic Power Profiler PPK2 seems to be hampered by burden voltage, so I had to use the PPK2 as a power source instead in order to get the SX1262 radio's current measurement. For that purpose I set the power source voltage to 3.0, which is a little closer to the voltage of the 2xAA batteries powering the atmega328p. If the voltages are different, one may backfeed the other.
-
For anyone interested, this is how I calculated the number of years of battery capacity from 2xAA lithium batteries (assuming 3500mah capacity for the pair):
Limitations of this calculation are 1. it considers only the currents involved in the actual radio transmission themselves, not any of the other currents also involved, including sleep currents that surround them, nor any of the currents that would be consumed by the atmega328p, 2. to keep the calculation simple, the batteries are assumed to have no self-discharge. Regarding #2, in reality the batteries would self-discharge long before the 258 years were up. Regarding #1, we'll get to a more complete picture that accounts for the missing drains once I have measurements on the sleep currents, startup currents, etc.By the way, the above assumes a 23 byte payload per packet, because that is the hello world packet defined by the library that I measured.
Anyhow, the practical upshot is that I could trade-off some transmission power for greater spreading-factor to get the same range and reliability, even if it means giving up some number of years of battery capacity, because, well, with 258 years of capacity as a starting point, I can probably afford to give up a couple centuries.
-
The radio can be powered on as little as 1.8v. If I use the PPK2 to supply the radio with 1.8v, then the current consumed appears to go down, even if transmission power is still set to 22dBm:
Supposedly it has a built-in LDO to down regulate to 1.8v, but I'm not entirely sure what's going on with that. If I power it at 2v, current consumed goes up, but is still less than when it was powered at 3v (see screen capture in earlier post above). Here's the 2.0 volt picture:
Anyhow, if all else turns out to be equal (?), it looks as though powering the radio at 1.8v would be the most energy efficient, and it will keep the module cooler as well because the built-in LDO won't need to burn off as much extra voltage as heat.
-
If both the atmega328p is held in deepest sleep (100na) and the SX1262 is held in deepest sleep (160na), then at the combined 260na for them both sleeping, then 2xAA batteries with 3500mah of capacity would last... ready for it?.... 1,537 years! If you can prove me wrong, then please do. Mind you, that is how long it would be with both simply sleeping and never waking up.
So, the only place left to look for meaningful energy consumption is during the wake-up-and-prepare-to-transmit phases for the atmega328p and the SX1262. The atmega328p can wake up in less than 4 microseconds, so that leaves the cold-start current draw of the SX1262 being the only place left to focus on. In simplest terms, it just needs to power up its TCXO and get it phase-locked-loop tuned to the proper frequency before it can transmit. So, however long that takes plus the (possibly overlapping) time to reprogram the SX1262 registers (because at 160na it will have forgotten everything), times the average current consumed while all of this happens will be the start-up energy draw. I'll see if I can find plug-numbers from the datasheet; otherwise, I'll just program it all and then measure it with the PPK2, which is perhaps the best way know for sure anyway.
-
Well, upon closer examination using some better software, I found that with a spreading factor of only 5 that I am, in fact, losing some packets along my worst-case transmission path. However, although increasing the spreading factor to 12 seems to guarantee that every packet arrives the first time, it's not the most energy efficient approach because the airtime is so much longer. Increasing spreading factor from 5 to 6 doubles the airtime, and from 6 to 7 doubles it again, and so on. So, from an energy perspective, it's better to accept even a 10% packet loss and retransmit than it is to increase the spreading factor. Keeping the airtime short also reduces the chances of collisions. This realization is a big change in my perspective on LoRa and what I should expect to get out of it. It puts LoRa more on par with other approaches to radio than I had originally thought.
Fortunately, the worst-case transmission path is exactly that, and for most things a spreading factor of 5 seems flawless, so I think that overall I'll stick with a SF of 5 and enjoy benefits of the very short transmission times. I can always do what LoRaWAN does and just insert one or more dumb hubs wherever needed, assuming it ever becomes necessary.
-
@NeverDie said in Most reliable "best" radio:
would last... ready for it?.... 1,537 years!
Have you considered comedy as a profession? I love your postings. The self-discharge of the human is another limitation. Unless, of course, you have a couple of Methuselahs in your progeny and a good set of instructions. And I know you can write good ones.
Thanks for the post.
-
A closer look at the datasheet explains why the transmission currents are dropping as I lowered the voltage: it's no longer able to to transmit at the full 22dBm!
If you all you care about is transmitting at 16dBm or less, then, yes, you can power the SX1262 all the way down to 2v. But if you want the full 22dBm transmit power, then the SX1262 needs no less than 3.3v (because the built-in LDO drops 200mv). Well, that's quite obviously a real bummer to find out this late in the game, because there is just no way 2xAA are going to source 3.3v on their own without help from a charge pump or a boost converter. Will running a boost converter during a transmission introduce unacceptable noise? How would I even measure for that effect or know how much noise is too much? Alternatively, how big a capacitor would one need if, instead, the idea is to charge up the capacitor and run from that, with the boost converter turned off, during a transmission? After all, in principle LoRa transmissions can be quite lengthy. Or does one need 3xAA or 4xAA batteries with a low noise LDO for a more viable option? Dang, this may turn out to be quite a nasty gotcha!
Of course, one alternative is to accept the 16dBm max transmission power but rely on more LoRa spreading factor or narrower bandwidth to arrive at an equal or better link budget. I already know that SF12 is more than adequate, because I've already tested it. I just need to test a bit more to find out what the right Goldilocks spreading factor would be to ace my worst-case transmission path and then compute what effect the longer transmit time will have on battery life. Perhaps this story may yet have a happy ending.
-
In principle, using the LoRa calculator, the trade-off isn't so bad. With just under a tripling of airtime, a SF of 7 would yield the same link budget at a transmission power of 16dBm as a SF of 5 would at a transmission power of 22dBm:
[Edit: Reporting back. Indeed, testing the worst case transmission path with a transmission power of 16dBm and an SF of 8 yields:
983 packets received. 17 missing packets.
,CRC,35BC,RSSI,-79dBm,SNR,10dB,Length,23,Packets,983,Errors,0,i.e. 1.7% missing packets. I know this because I wrote some code to put an index number into each packet, such that the index increments on each transmission. The receiver thus knows what numbers to expect and tallies up the number of packets that are missing in the received sequence.
The airtime with SF8 is about 34ms, so the battery's transmission lifespan is still likely to exceed the battery's useful shelf life. I'll want to take some transmission current measurements with transmit power set to 16dBm and then re-run the numbers, but as a lower bound on battery capacity I could take 258 years and multiply 6.838 (the previously measured onair time with SF5) and divide by 33.408 (the calculated onair time with SF8), to get 52.8 years as a low-bound. It's lower bound because I had set a transmission power of 22dBm for the earlier measurement. Who knows what transmission power I actually got, but definitely lower than 22dBm based on the new information regarding supply voltage and transmit power. So, lower than 22dBm, but presumably higher than 16dBm. If that's right, then remeasuring the actual utilized current when the requested transmission power has been lowered to 16dBm should yield a longer expected transmission life than the 52.8 years arrived at here with these back-of-the-envelope conservative assumptions.
I'll try increasing the number of pre-amble symbols and see if that reduces the number of missed packets at all. According to Semtech's SX1262 LoRa calculator, increasing pre-amble symbols is relatively cheap in terms of airtime. ]
-
Hmmm.... Not sure why, but the calculations from the new SX1262 transmission current measurements(see picture below) indicate the 2xAA batteriess would last 38 years using SF8 and transmission power set to 16dBm, which is obviously less than what I was predicting. I haven't yet increased the number of pre-amble symbols, so the reason isn't that. This time I did power the radio module with 2.8v instead of the 3.0v I used in the earlier measurement, so maybe that had something to do with it. Not sure at this point. Go figure:
Anyhow, regardless of the reason, that's enough battery capacity headroom that I'm not worried.
[Edit: I found the reason: I had lately increased the coding rate from 4/5 to 4/8, which increased the airtime over what it had been previously at 4/5, but I had forgotten to include that change in the Semtech LoRa calculator calculation.
If I use the 47.232ms Time on Air number shown in the LoRa calculator results here and redo the previous lower bound calculation, the answer is a lower bound of 37.35 years, which is indeed less than the 38 years calculated based on the new measurements above. ][As an experiment, I tried powering the same SF8 mote with a solid 3.3v and a transmit power of 22dBm provided by 4xAA batteries and an LDO. The result was about 1% missing packets. Then, reverting to just 16dBm, it was a roughly 2% missing packet rate. Therefore, it's probably not worth the bother of powering the mote with 4xAA batteries and an LDO. Granted, it would be some improvement, but, IMHO, not really enough of an improvement to justify upgrading to a 3.3v supply source. ]
-
The library's default sleep mode for the SX1262 radio should consume 600na with the configuration retained. Measuring it when powered by 2xAA batteries, I can confirm that it does:
On the other hand, if it were put in deepest sleep, where it forgets everything, the datasheet says it would instead consumed 160na (see 3.5.1. Power Consumption table in the datasheet). Well, when I put it into deepest sleep, I measured a number reasonably close to 160na:
Lastly, we know from the atmega328p datasheet that in the atmega328p's deepest sleep, it will consume only 100na. Well, doing that and measuring, I get a number reasonably close to that:
I only just yesterday received this particular nanocurrent meter, and these were my very first mesurements with it.
The last thing to measure will be the amount of energy consumed by the SX1262 during a wake up. We should then have all the data we need to calculate the mote's estimated battery life.
-
Reporting back: I measured the wake-up current that occurs in one of the library sleep examples, and, as you can see, it simply isn't significant relative to the transmission itself:
So, without getting into the numbers this time, I think it's safe to say that as a generic mote platform, this LoRa mote will function until its batteries completely die of old age, more than twenty years from now, provided that it has a suitable ultra low current way to wake up periodically.
Of course, YMMV, depending on what else you want the mote to do.
-
@NeverDie Interesting work and thanks for sharing it - I am sure it will interest many people trying to get the best out of their batteries.
The one thing I suggest is to also take measurements across the expected working temperature range. I don't pretend to know how much affect, but battery life is extended by storing them cool whilst in use a warmer temperature will allow more energy to be 'mined' from the battery (due to the chemical reaction).....
-
@skywatch said in Most reliable "best" radio:
The one thing I suggest is to also take measurements across the expected working temperature range. I don't pretend to know how much affect, but battery life is extended by storing them cool whilst in use a warmer temperature will allow more energy to be 'mined' from the battery (due to the chemical reaction).....
It's a fair point. Ideally the battery datasheet would cover the temperature range of interest.
Is there a battery chemistry other than Energizer lithium primary cells that you think might be the best overall choice? They claim to have a 20 year shelf life, and the price seems pretty reasonable. To your point, they also seem to have a pretty wide rating temperature range, certainly better than Alkaline. Also, much less likely to leak than Alkaline, which certainly matters if the goal is "as long as possible" between battery changes.
Anyhow, I'm glad I finally did the measurements and crunched the numbers. Prior to now I was under the impression that LoRa transmissions times were inevitably so long that battery life would be greatly diminished. This thread seems to prove that, on the contrary, for simple sensor measurements taken at 5 minute intervals, LoRa can be awesome.
Also, in the US, the FCC allows for the legal use of higher transmit power if using spread spectrum or frequency hopping (though there do still exist restrictions relating to dwell time and duty cycle). I'm no lawyer, but I get the impression LoRa counts as spread spectrum as far as the FCC is concerned. Without either spread spectrum or frequency hopping, the allowed transmit power is pretty low--more or less reliable only if the receiver is both nearby and line-of-sight with the transmitter. In my book that's not very practical. An example of that would be a plain vanilla Nordic nRF24L01, or the first generation z-wave, both of which had a max transmit power of just 0dBm.
-
@NeverDie said in Most reliable "best" radio:
Is there a battery chemistry other than Energizer lithium primary cells that you think might be the best overall choice?
I don't know enough about battery chemistry to make an informed contribution.
I have some lithium cells with 2040 date on, but not using them yet (probably in the next few weeks)....
Also, in the US, the FCC allows for the legal use of higher transmit power if using spread spectrum or frequency hopping (though there do still exist restrictions relating to dwell time and duty cycle). I'm no lawyer, but I get the impression LoRa counts as spread spectrum as far as the FCC is concerned. Without either spread spectrum or frequency hopping, the allowed transmit power is pretty low--more or less reliable only if the receiver is both nearby and line-of-sight with the transmitter. In my book that's not very practical. An example of that would be a plain vanilla Nordic nRF24L01, or the first generation z-wave, both of which had a max transmit power of just 0dBm.
The NRF24L01+ has frequency hopping capability - I tried it by modifying the tmrh library before I came to mysensors. I only made a slow hop rate (4 hops/sec) but it seemed to work nicely. It would be cool if my sensors supported this, but there is probably a good reason why it doesn't.
-
@skywatch said in Most reliable "best" radio:
The NRF24L01+ has frequency hopping capability - I tried it by modifying the tmrh library before I came to mysensors. I only made a slow hop rate (4 hops/sec) but it seemed to work nicely. It would be cool if my sensors supported this, but there is probably a good reason why it doesn't.
There is some posted code on github that looks like it might do the business: https://github.com/search?q=hopping+nrf24l01 Not sure how energy efficient frequency hopping would be, but it would be fun to give it a try and reap the rewards of a 2mbps datarate. I wonder whether any of those AT-command type of modules might already implement it? That would sure make it easy.
On AliExpress I notice that the RF4463PRO radio modules claim to be able to do frequency hopping. Their on-air bitrate is theoretically as high as 1mbps.
-
Closing off a loose end: Regarding the Adafruit TPL5110 delay module for powering projects, I just now did an experiment where I used it to power a generic atmega328p platform (not that I would actually use it that way, but for convenience of testing) and then did a measurement of the current draw when it was in power-off mode, because, as pointed out in the other thread, Adafruit rather bizarrely reports that it consumes 20ua in that mode (https://www.adafruit.com/product/3435) according to Adafruit's "monsoon" measuring system. However, my measurement with a Current Ranger shows it settles at around 42na when feeding it 3.3v, which is close to the 35na at 2.5v reported by the tpl5110 datasheet(https://www.ti.com/lit/ds/symlink/tpl5110.pdf?ts=1653609291212&ref_url=https%3A%2F%2Fwww.google.com%2F).
So, if you wanted to use it as a kind of "triggerboard" for an esp8266 or esp32, I expect it would work quite well.Worthy of note: I did have to connect a 10k resistor between the Done pin and ground. Adafruit uses just a 1M pulldown resistor, which is too weak. If left with only a 1M pulldown resistor, the mote effectively hits "Done" when it's in the process of powering up, which turns it back off before it finishes powering up. Not good. The 10k resistor fixes that, and my measurement shows that the quiescent current doesn't suffer because of it. Perhaps it is the weak pulldown resistor that Adafruit uses in its design which explains why some people report a fail in getting the Adafruit TPL5110 to control power to an ESP8266 or ESP32. With the 10K pulldown resistor added, I had no problem having the TPL5110 supply power cycles to my generic atmega328p platform, as per the intended design.
Given that this appears to work, it opens the door to testing current consumption of an ESP8266 that's programmed to operate in ESP-NOW mode. i.e. current consumed from the moment of power-on, through packet transmission, up to the point where the DONE pin on the TPL5110 is pulled high by the ESP8266, which kills power to the ESP8266 until the next cycle starts all over again. That's the kind of information that seems very hard to find and yet which is critical for anyone wanting to assess the battery life of such a setup.
On its face, though, one youtuber claims it takes 280ms for an ESP8266 to wake-up and transmit using ESP-NOW:
but that in itself doesn't really answer the question with any degree of accuracy. And would an ESP32 be any faster? As per usual, the important details gets glossed over, leaving one wondering.
-
As a first step I looked purely at the transmission interval of an ESP8266 running the demo "controller" sketch from the above youtube video. Quite impressive:
That's just a simple wemos D1 mini ESP8266, powered at 3.3v over its 3.3v pin, blasting out an 8 byte packet to the universe using ESP-NOW. No listening for an acknowledgement of any kind. So, using the same assumptions as before of a transmission of once every 5 minutes, and crunching the numbers are before, then if that were the only current drain (which we know is false, but for an initial calculation assume it were true) then the expected lifespan of the batteries would be an impressive 1,031 years. That does get my attention, and to me that warrants the effort of making a measurement over an entire power-on to power-off transmission cycle using an adafruit TPL5110, because we already know (from directly above) that the power-off current will be a trivial 43na. I haven't yet measured to see whether it can traverse my worst-case transmission path, or what the packet loss rate would be, but on the can it says it has a transmission power of 25dBm. On the other hand, it is 2.4Ghz, but maybe the shortness of the transmission will reduce its odds of collision with sporadic interference. The weakness is that the powerdraw on either side of the transmission is about 80ma, so that may turn out to be its fatal flaw, because if you simply assume an 80ma draw for a period of 280ms at 5 minute intervals (i.e. not even counting the transmission current itself), then the projected battery lifespan is 5.3 years.Would an ESP32 do better than an ESP8266? I don't own any. Which of the many ESP32 flavors in particular would likely do the best in testing?
-
Well, the rumors were right: the ESP8266 doesn't seem to work with the TPL5110. I tried different pulldown resistors but no joy. Not sure why. Go figure.[Edit: after some FAFing, I find that it does work after all if a 10k pulldown resistor is (as before) added to the DONE pin on the TPL5110, and a 470uF capacitor added between GND and 3.3v on the input power. Maybe other capacitor values would also work, that's just the first one I reached for. Without those two mods, though, a Wemos D1 Mini won't dance properly with an Adafruit TPL5110 breakout board. ]
I found that ESP8266 GPIO14 worked for pulling DONE to high without much drama. Apparently, some other ESP8266 pins (GPIO16, GPIO3, GPIO1, GPIO10, and GPIO9, as detailed here: https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/) start out HIGH when the ESP8266 boots up, which is no bueno.
-
Bingo! Scored it. Captured below is a single transmission using the Adafruit TPL5110 to power up a Wemos D1 Mini ESP8266 from essentially nothing (43na) and then return to essentially nothing (43na) afterward. So, this screenshot captures the entire process for an ESP8266 that's in ESP-NOW mode.
Here is the sketch that I used:/**************************************************************************************************************************************************** * TITLE: ESP-NOW Getting Started Examples * * By Frenoy Osburn * YouTube Video: https://youtu.be/_cNAsTB5JpM ****************************************************************************************************************************************************/ /******************************************************************************************************************** * Please make sure that you install the board support package for the ESP8266 boards. * You will need to add the following URL to your Arduino preferences. * Boards Manager URL: http://arduino.esp8266.com/stable/package_esp8266com_index.json ********************************************************************************************************************/ /******************************************************************************************************************** * Board Settings: * Board: "WeMos D1 R1 or Mini" * Upload Speed: "921600" * CPU Frequency: "80MHz" * Flash Size: "4MB (FS:@MB OTA:~1019KB)" * Debug Port: "Disabled" * Debug Level: "None" * VTables: "Flash" * IwIP Variant: "v2 Lower Memory" * Exception: "Legacy (new can return nullptr)" * Erase Flash: "Only Sketch" * SSL Support: "All SSL ciphers (most compatible)" * COM Port: Depends *On Your System* *********************************************************************************************************************/ #include<ESP8266WiFi.h> #include<espnow.h> #define MY_NAME "CONTROLLER_NODE" #define MY_ROLE ESP_NOW_ROLE_CONTROLLER // set the role of this device: CONTROLLER, SLAVE, COMBO #define RECEIVER_ROLE ESP_NOW_ROLE_SLAVE // set the role of the receiver #define WIFI_CHANNEL 1 uint8_t receiverAddress[] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF}; // please update this with the MAC address of the receiver struct __attribute__((packed)) dataPacket { int sensor1; int sensor2; float sensor3; }; void transmissionComplete(uint8_t *receiver_mac, uint8_t transmissionStatus) { if(transmissionStatus == 0) { //Serial.println("Data sent successfully"); digitalWrite(14,HIGH); } else { //Serial.print("Error code: "); //Serial.println(transmissionStatus); } } dataPacket packet; void setup() { pinMode(14,OUTPUT); digitalWrite(14,LOW); //Serial.begin(115200); // initialize serial port //Serial.println(); //Serial.println(); //Serial.println(); //Serial.print("Initializing..."); //Serial.println(MY_NAME); //Serial.print("My MAC address is: "); //Serial.println(WiFi.macAddress()); WiFi.mode(WIFI_STA); WiFi.disconnect(); // we do not want to connect to a WiFi network if(esp_now_init() != 0) { //Serial.println("ESP-NOW initialization failed"); return; } esp_now_set_self_role(MY_ROLE); esp_now_register_send_cb(transmissionComplete); // this function will get called once all data is sent esp_now_add_peer(receiverAddress, RECEIVER_ROLE, WIFI_CHANNEL, NULL, 0); packet.sensor1 = 123; //Serial.println("Initialized."); } void loop() { packet.sensor1++; packet.sensor2 = 456; packet.sensor3 = 3.14; esp_now_send(receiverAddress, (uint8_t *) &packet, sizeof(packet)); delay(1000); }It is only slightly modified from the original. Essentially I commented-out all of the code relating to print statements, because that would drag out the time and is superfluous for present purposes, and I set GPIO14 to high as the "DONE" signal after the packet was finished sending and the related callback function was called, which instructed the TPL5110 to cut the power.
So, I finally have the data now to do the necessary battery calculation. Crunching the numbers, assuming a single transmission like this every 5 minutes, the batteries would last almost 19 years. That is just a pure packet transmission with no acknowledgement. Still, it is much better than what I had been expecting based on what others have reported.
It might be that this could be improved upon by removing the ESP8266 from its Wemos D1 Mini PCB, as the PCB contains components which may be soaking up power and simply aren't needed. Also, looking at the current graph, it looks as though maybe it's listening after the main transmission? Maybe someone knowledgeable about ESP-NOW can comment. Lastly, I'm not sure what datarate ESP-NOW defaults to. Maybe it would be possible to have it transmit faster and thereby use less current. So, lots to look into if anyone here has the interest.
Anyhow, I think that this proves the concept. Who knew? All this time the ESP8266 had been type-cast as impossibly power hungry. I guess the main downside is that anything in addition that one might do, such as measuring the battery voltage or doing an TH measurement, as examples, will be done at a fairly high current burnrate. Offsetting that might (?) be the prospect of getting it done sooner.
The real question, though, is whether it makes sense to do a similar measurement on an ESP32, and, if so, which one? Any chance it would be better? Or would it likely be worse?
-
For comparison, an nRF24L01 can, according to its datashet, cold-start from completely powered off to an idle state in 11.8ms. From there the remaining delay would mainly be the amount of time needed for the MCU to configure registers and load the transmit FIFO buffer. Not sure how long that takes. Anybody know? After that it would, in theory anyway, take just 130us to initiate the start of transmission.
For that reason I'm guessing an nRF24L01 could, if it were an apples-to-apples comparison, have a much shorter transmission cycle than the 181.6ms transmission cycle of the Wemos D1 Mini ESP8266 that I measured above.Fun fact: the nrf5x modules have the advantage that they don't need to use SPI to load bytes into a transmission queue. Instead, when transmitting, an nRF5x can read the transmission bytes directly from memory via DMA.
In any case, comparing the SX1262 switching times, the SX1262 (LoRa) looks to be pretty fast:
Cold start to standby in 3.5ms, and then from standby to transmitting in 126us. As with the nrf24l01, the MCU will need to define registers and load the FIFO transmission queue before it can initiate the transmission, and that will take some amount of time because it happens over SPI.
-
CORRECTION: Earlier I said that Adafruit's TPL5110 breakout board appeared to use a 1M pulldown resistor on DONE. I remeasured today and that's wrong. It's actually a 10K resistor. So, since my adding a 10K resistor to that in parallel solved the issue of it not working, I today replaced Adafruit's 10K SMD resistor with a 5.1K SMD resistor. Afterward I retested, and I've confirmed that (not surprisingly) that works. So, with that modification to the Adafruit TPL5110 board, an external pulldown resistor is no longer needed. Not a big deal, but it keeps things a little tidier. As to what the optimal value should be, I don't know. I'm simply reporting that 5.1K seems to work and that Adafruit's choice of 10K didn't work in the two different test scenarios that I tried.
-
I'd like to try one of these recently announced RFicient ultra low power receiver wake-up chips:
Always ready to receive β RFicient chips for a sustaina-ble Internet of Things β 03:09
β FraunhoferIt claims a receive current of just 3 microamps and allegedly works in any of the 3 ISM bands.
Unfortunately, nothing yet on mouser or digikey. Who knows whether they'll actually deliver or whether they're just testing the market demand.
-
Well, some good news regarding the LoRa SX1262: in looking at the datasheet, I see that it says that " SX1261/2 supports the modulation underlying LR-FHSS (at present, GMSK
modulation)" that equates to LoRa SF12 sensitivity, but is presumably (?) faster given that it is GMSK and not LoRa. The chip handles the hopping, but it relies on the MCU to set everything up. The better news is that just 3 months ago Semtech posted a github library (https://github.com/Lora-net/SWDM001) that allegedly demos it.Another nice thing I noticed in the datasheet is that unlike prior LoRa chips, the SX1262 has a Channel Activity Detector that can detect not just LoRa preamble bits (as earlier chips could) but data bits as well. That's good because it reduces the odds that a new transmission will start prematurely and result in a collision with a LoRa transmission that's already in progress. The bad news though is that, if using it for deciding whether to wake-up or not, it looks to takelonger than getting an RSSI measurement would.
-
For comparison, I just now measured the energy consumption of a generic key finder, such as what you can find for cheap on amazon.com or aliexpress:
So, the high level overview is this:
I feed it 3v from the PPK2, and this picture shows what happens before and after powering it on. When first powered on, it blinks the LED a couple of times, which explains the first two current pulses.Zooming in a bit we can determine the length of the duty cycle:
This is perhaps the most revealing of the screenshots. As you can see, it wakes up roughly once a second to see if it can receive anything. According to PPK2, the average current draw is 34.71ua.
And out of that one second, it is active only about 8.764ms.It was advertised as having a battery life of two years, but I can tell you from experience that it hasn't lasted even 6 months. Probably even less than that--I just haven't paid close enough attention as to when it actually fails because I almost never use it. Of the couple of times I did have a reason to use it, the batteries were already dead, and it didn't work at all.
If nothing else, a meaningful improvement would be if it could at least occasionally call home and report what its remaining battery capacity is.
-
@NeverDie They claim that it is already available in a QFN16 package. https://www.iis.fraunhofer.de/en/ff/sse/ic-design/rf-ic/wakeup.html
But they say you have to go through "EBV Chips" to get it, and everything I've seen makes it look like that's for large companies only. I can get to this page at Avnet, https://www.avnet.com/wps/portal/ebv/solutions/ebvchips/ebvchips-overview/ but I can't seem to get past it to any chance to order or see a detailed datasheet or anything like that. A search just on regular Avnet for the part turns up empty with the things I can think of.
This is the best page I can come up with: https://www.avnet.com/wps/portal/ebv/solutions/ebvchips/rficient/ which is cool and all, but still nothing orderable for normal people.
-
Curiously, this keyfinder does appear to function fairly decently all the way down to 1.9v:
and its current draw actually drops to 29ua:
I'm including this screenshot of the Rx interval for completeness:
By the time it reaches 1.8v, it dies rapidly because it spends most of the 1 second duty cycle listening:
What the PPK2 doesn't do is simulate the voltage droop that a CR2032 can experience. Not at all sure what happens under those conditions, but maybe (probably?) it contributes to the seemingly short battery life. If that's the case, maybe these keyfinder receivers could be rehabilitated to last longer before needing a battery replacement.
By the way, when I checked the voltage remaining on the coincell taken from this keyfinder receive, it measures about 3mv. So, it got drained practically all the way to zero.
Anyhow, according to energizer, their CR2032 has 235mah of capacity when measured from fresh down to 2.0v (https://data.energizer.com/pdfs/cr2032.pdf). So, doing the math on that, assuming a 35ua burn rate, it should theoretically last 279 days, or about 9 months. That would be the lower bound. If one assumes 29ua as the burn rate, then it could last 11 months. That would be the upper bound. i.e. theoretically, it might last somewhere from 9-11 months. Definitely not two years. Also, I'm definitely got getting anything in that range on my keyfinder receiver tags--they die much sooner than that. I'm guessing it's CR2032 voltage droop that gets worse as the battery gets depleted which leads to premature failure. I wondering whether simply soldering in a suitably large value ceramic capacitor between VCC and GND might help it power through the droop and live up to its design potential? Better yet, I'd be willing to trade off responsiveness for much better battery life. Rather than checking once per second, maybe it could be modified to listen much less often than that.
-
Looking at the chips involved:
only one has markings on it:
and that seems to return a null google result. So, it's a deadend in terms of modifying the receiver duty cycle.Maybe there are chips with actual datasheets for doing this kind of thing? The application is certainly nothing new.
-
This reminds me of an earlier tip that @mfalkvidd offered up here: https://forum.mysensors.org/topic/10806/how-is-this-receiver-able-to-continuously-rx-but-consume-only-90ua?_=1653861040283 for a chip that consumes only 1.37ua in listen mode.
That chip is now available (and in stock) via digikey: https://www.digikey.com/en/product-highlight/a/ams/as3930-low-frequency-wakeup-receiver?utm_adgroup=General&utm_source=google&utm_medium=cpc&utm_campaign=Dynamic Search_EN_RLSA&utm_term=&utm_content=General&gclid=EAIaIQobChMIg5OvvNmF-AIVzhXUAR2AXwVNEAAYASAAEgJG3vD_BwE
One possible catch is that it operates in a low frequency band that I know nothing about. If lucky, maybe that's a clean band set aside for this type of thing? On the face of it, it might make for a very long battery life keyfinder tag receiver, and compared to a Bluetooth TILE, the chip price isn't bad.
Maybe now is a good time to revisit this? Still in a bit of a quandary as to an easy way to test drive it. The eval kit actually went up in price to $333. There is a github library though for connecting an arduino to a related chip: https://github.com/LieBtrau/arduino-as3933
Also, another guy here: https://forum.digikey.com/t/as3933/2604/8 offers up a schematic and pcb layouts for connecting an as3933 to an atmega32u4. So, maybe taken together that does the business....provided you can find/make a suitable transmitter to activate it. In any case, from that same thread, what it appears to be is some kind of RF power envelope detector, which maybe explains the weird 100uvrms for expressing its sensitivity:
In other words, it's a more maybe a more sensitive version of a $2 RF Power detector:
2 Dollar Radiation Detector You Can Build. Beware of imitation diodes that don't have an H on them. β 08:53
β Grants Pass TV Repairwhich is close range but is completely passive and so doesn't consume any power at all to "listen".
-
The listen mode I previously worked out on the nRF52832 pretty much blows away the performance of the cheap keyfinder receiver:
https://forum.mysensors.org/topic/6961/nrf5-action/1052?_=1653867854046
It had an Rx interval of just 30us and, aside from the startup time, the rest of the time, while sleeping, the current draw was <3ua. And it checked for packets once every 100ms, not once a second, so it was plenty responsive. If only the sleep current had been less. Perhaps in combination with a TPL5110 it would completely trump the battery life of the keyfinder tag. But, it's relatively expensive.That leaves the nRF24L01P. It draws 900na in powerdown mode, from which it takes 1.5ms to startup into standby mode, and from there only 130us to enter Rx mode. I'd say it has a chance for beating the keyfinder tag, because it could have a much shorter receive window than the ~8ms Rx window that the keyfinder tag has, even though the keyfinder tag appears to have a sleep current of nearly zero. What's the shortest valid packet that an nRF24L01 can receive? It turns out sparkfun had a (now retired) nRF24L01P keyfob, though they used it as a transmitter rather than as a keyfinder: https://www.sparkfun.com/products/retired/8602
-
The SX1280 appears to have much faster transitions from sleep to idle than the SX1262, and practically an order of magnitude faster than the nRF24L01:
i.e. it can go from sleeping at a current of 1.2ua (maybe even 0.4ua?) with full data retention to Rx listening mode in 130+85 = 215us. That's pretty snappy.
-
One big difference I hadn't realized until just now between the 2.4Ghz SX1280 and the sub-gigahertz SX1262 is that the SX1280 can utilize a bandwidth as wide as 1625KHz, whereas the SX1262 is limited to at most 500KHz. Why does that matter? Speed. The SX1280 can have a symbol time as low as 0.0197ms, whereas the fastest symbol time on the SX1262 is 0.064ms. That means the SX1280 can transmit 3.25x faster than the SX1262.
I confirmed this with a measurement on the SX1280 transmitting one byte (along with CRC-32 and all the other overhead that the library defaults to):
Add to that the faster transition times of the SX1280, and I conclude that at normal distances and transmission paths, the SX1280 is better suited for a battery powered mote that needs to duty-cycle listen for a wake-up packet than the SX1262 is.
By the way, observe the relatively high current draw on this particular SX1280. That is because of the 27dBm transmit power afforded by the PA of the Ebyte E28-2G4M27S module that it's a part of. That's why I made my own overkill usb-to-serial converter with a low-noise LDO that's rated to deliver as much as 1.1a at 3.3v, in case I'm powering the module that way.
The current draw that's in evidence in this snapshot would completely swamp the 50ma limit on most 3.3v USB-to-serial adapters on the market. Even Sparkfun's Beefy 3 is limited to 200ma, which is less than 1/3 the amount being drawn by the Ebyte module.So, worst case, if I were to power the Ebyte module in Rx mode for 2ms per 1 second period, waiting for a 1 byte packet and all the overhead, that would translate into about 17ua average current draw, or a little over half of what my keyfinder fob draws.
However, by using the Channel Activity Detector (CAD), I should be able to reduce the wake-up detection window to about 4 symbol periods to reliably detect a LoRa transmission that overlaps its Rx window, which on an SX1280 would be 4*(0.0197ms)=0.0788ms. Let's round up and call that 0.1ms. Napkin math: that would maybe (?) translate into an average current draw that's under 4ua if one were to assume that, like the keyfinder fob, it listens only once per second and draws the worst-case 8.2ma while actively receiving in high-sensitivity mode and draws the worst-case 1.2ua while sleeping the rest of the time. Not bad! I say "maybe" because I'm not exactly sure how much it might draw while powering up and getting ready to receive. 0.1ms = 100us, so the current drawn during the 210us it takes for the SX1280 (and maybe longer for the Ebyte LNA?) to transition from sleep into Rx is going to affect the average current draw. With worst-case assumptions, the total shouldn't be more than an average current draw of 12ua, and I'd expect it to be much less than that. We know from the the SX1280 datasheet that Standby-RX mode draws 700ua, but clearly there must be some kind of ramping from the 1.2ua sleep current up to that amount, and between that amount and the 8.2ma when in receive mode. Therefore, I don't see a way to precisely calculate from just the datasheet alone. I could compute lower-bounds and upper-bounds or make some assumptions about the ramp rate, but to really remove the fog around this I think I'll write the duty-cycled listen code and then measure it with the PPK2.
Anyhow, this makes for yet another interesting point of comparison with the nRF24L01, or even the RFM69. The nRF24L01/RFM69 could maybe use RSSI threshold as a quick, short-hand way to judge whether a transmission might be occuring without having to go through a full packet receive cycle, but relying on RSSI alone for that purpose would tend to be sensitive to noise and interference, resulting in false positives. The CAD of the SX1280, in contrast, is designed to detect LoRa transmissions specifically, so hopefully it will filter out that kind of noise, or, at minimum, at least not false positive trigger on it. That's especially important for the SX1280, which operates in the crowded 2.4GHz band.
Another advantage of the SX1280, as compared to the SX1262, is that the SX1280 can run its DCDC converter in RX and TX modes, whereas the SX1262 is limited to LDO only, so that's another way the SX1280 can get longer battery life.
-
Using RadioLib on the SX1280 Ebyte module, I was able to get the CAD working at 1 second intervals:
I picked 1 second to make for an apples-to-apples comparison against the Keyfinder fob above.
Zooming in to the area of interest:
This screenshot shows the average current consumed while waking up, re-establishing the radio configuration, and then doing the CAD. I reduced the spreading factor to SF5, and I increased the bandwidth to 1625Mhz. Also, in the RadioLib library, DC-DC conversion on the SX1280 is turned on by default. I expect the results shown could be improved upon with more careful programming, but as a first-pass the results are: it could last 2.8 years on a CR2032 coincell. That is using RadioLib's default 8 symbols for judging a CAD. So, as a first-pass, not bad! It definitely beats the projected 9-11 month battery lifespan on the keyfinder fob from above. I'm reasonably sure that lifespan could be improved using more careful programming to reduce the SX1280 radio configuration time after waking up. In theory, the SX1280 is supposed to remember its configuration in one of the two sleep modes, but, in practice, it seems to be forgetting at least some of it, so for a quick first-pass workaround I do a full re-configuration each time it wakes up.
-
I'm getting no traction on this thread so I think I may move this topic to some other forum on some other website. Sorry. Maybe this is just the wrong place for it, or maybe the topic is of no interest to others here. Whatever the reason, monologging is no fun. There just isn't the feedback or comments or suggestions to make further posting on this topic worthwhile.
End of thread.
-
@NeverDie said in Most reliable "best" radio:
All this time the ESP8266 had been type-cast as impossibly power hungry. I guess the main downside is that anything in addition that one might do, such as measuring the battery voltage or doing an TH measurement, as examples, will be done at a fairly high current burnrate.
By turning off the 8266's radio and only using the CPU for TH, voltage, or any other measurement, considerable power savings result. I think I was getting down to the mid-teens of mA, instead of the 70 mA or so with the radio on. Another power savings came to me by saving up periodic readings, in like a table. Then every 50th reading, or so, turn radio back on and do a bulk-load to whatever database is desired, then turn off the radio and go to sleep. It was a kick to learn how to do this. Here is a posting I did at mathworks with more detail as it relates to loading to Thingspeak: https://www.mathworks.com/support/search.html/answers/890382-how-to-efficiently-transfer-bulk-upload-from-an-esp8266-to-thingspeak.html?fq[]=asset_type_name:answer&fq[]=category:thingspeak/write-data&page=1
I've seen several other uses of the ESP that exclude radio use and just implement the CPU.
-
@NeverDie said in Most reliable "best" radio:
I'm getting no traction here so I think I may move this to some other forum on some other website. Sorry. Maybe this is just the wrong place for it, or maybe the topic is of no interest to others here. Whatever the reason, monologging is no fun. There just isn't the feedback or comments or suggestions to make further posting on this topic worthwhile.
End of thread.Just saw this after my last post. Well, sorry to see this end and thank you for all the work. I've been so consumed on your SX1280 thread, and buying equipment that I haven't been back for a while. Regrets.
-
@NeverDie said in Most reliable "best" radio:
By the way, when I checked the voltage remaining on the coincell taken from this keyfinder receive, it measures about 3mv. So, it got drained practically all the way to zero.
I've seen this when playing with 328's and 8266's. When voltages drop to the min threshold, the devices fail into a funky state drawing big current. For that reason, my current designs give out a yelp at a moderately low voltage, if there is a radio attached. Then go into deep sleep hoping that a rescue arrives. Deep discharges are really problematic for rechargeable liOn batteries. The advice is to abandon the battery because of potential changes to chemistry and the risk of fire on recharge.
-
@Larson said in Most reliable "best" radio:
@NeverDie said in Most reliable "best" radio:
By the way, when I checked the voltage remaining on the coincell taken from this keyfinder receive, it measures about 3mv. So, it got drained practically all the way to zero.
I've seen this when playing with 328's and 8266's. When voltages drop to the min threshold, the devices fail into a funky state drawing big current. For that reason, my current designs give out a yelp at a moderately low voltage, if there is a radio attached. Then go into deep sleep hoping that a rescue arrives. Deep discharges are really problematic for rechargeable liOn batteries. The advice is to abandon the battery because of potential changes to chemistry and the risk of fire on recharge.
What kind of device/component do you use to make the yelp sound? I've looked for tiny piezo's that could maybe do this, but they all seem to be different degrees of large. I know it should be possible to be tiny, becaue, for example, a digital wristwatch is able to make audible beeps. On the other hand, after looking at some teardowns, I guess digital watches uses piezo disks that are at least 1/2" in diameter. Hmmmm.... Is that really as small as it gets? Anyone here know? What about hearing aids? Surely they have something smaller. The smallest thing I've found so far has been this: https://owolff.com/page140.aspx?recordid140=534&output=pdf&delay=3000&margin=1cm which is 5mm in diameter. So, I guess forget mounting anything directly to the PCB board: wired discs are the way it's done apparently and then just tuck it somewhere inside the project enclosure.
-
@NeverDie said in Most reliable "best" radio:
What kind of device/component do you use to make the yelp sound?
My present "Yelp" design comes from a Thingspeak script that sends an email. Yelp may have been the wrong word, but I was thinking of smoke detectors that beep to say, "I'm dying, replace my battery". Previously, I built a WiFi mouse trap that sent email/text/phonecall via SMTP2GO if the trap was tripped (mouse, or no mouse). That was fun! That code could easily be modified to trigger on a voltage threshold, or any other variable.
image url)
-
@Larson That's a nice, clean looking, elegant design. If you have any idea on how to kill skunks, let me know. They are destroying my lawn. Live capture doesn't seem practical for skunks, for obvious reasons. I've seen one youtube that demonstrates a deadfall device--and proves it works--but it's the only example I've managed to find. There do exist professional services, but they charge a couple hundred bucks per animal removed, but after removal they can't legally release them (because they are officially pests), so the pro's just end up killing them anyway.
-
@NeverDie For skunks, and racoons I use an electric fence. I string a wire around the lawns & ferns about 6" up from grade using non-conducting stakes. I think it works and is non-lethal. The e-fence was the smallest Coastal Farm offers. Our cat has 'figured' it out and knows to stay away.
In the spirit of radio electronics, I did build a system for mole elimination. It was complicated. I use a vibration detector/WiFi (ESPNOW) that sends notice to a piezo beeper inside the house. The detector is planted in the last active mole pile. If I hear the beeper I jump to action to hit a button (Transmit/Recieve pair) to ignite an electronic firecracker that would be burried in the last visited mole pile. I could have automated that button-pushing task, but the extra human control made it safer and more entertaining. The firecracker is be fitted with a nicrome wire fork, inplace of the normal fuse. The firecrackers I prepared were painted in some waterproof paint to keep them from degrading in the moist soil. An 18V Ryobi tool battery is used for the power source in the relay circuit because that gives enough juice to burn the nicrome wire. I tested it but have yet to deploy it. Here is the circuit for the igniter.
image url)
-
@Larson Will a firecracker actually kill a mole? This guy shows off his simple contraption that uses 500v to instantly kill rodents:
RID-O-RAT Homemade Electronic Pest Control Device β 12:16
β electronicsNmoreThe key seems to be charging high voltage capacitors, so that enough current is released at 500v when triggered. I know: dangerous as hell, but maybe this is where your wireless human-in-the-loop firing trigger could come into play so that it doesn't kill anything that it's not supposed to.
He says it's highly effective.
I don't know whether something like that would work for moles or not. I guess it depends on whether they ever leave their holes to look for food or whether they stay underground all the time.
I wouldn't feel comfortable walking up to something charged to 500v, but maybe that's where radio electronics could completely disarm it down to zero volts when commanded before you even think of touching it. His is more basic and doesn't have that added feature. I would want redundant everything on the safety features so that there's no chance of it going wrong.
As for charging it up, I think one of these would work for fairly cheap:
https://www.amazon.com/gp/product/B07JG4K6S6/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
as long as you terminate the charge when it gets to 500v and not let it continue on to 15,000 volts, which would destroy your charge capacitor. Since it comes in a pack of two, maybe the other one could be used to energize an electric fence? I know nothing about electric fences or what voltage they use, but I would hazard a guess that the circuitry is similar (flyback transformer design), and then all you would need is the right kind of wire and some insulated stakes.An electric fence is an interesting idea, provided it doesn't ignite dead leaves and create a fire. Not sure whether or not that's even a risk. I presume that professional electric fences wouldn't do that.
-
@Larson Do you have any links to this please? I found next doors 2 new cats killing 2 young birds they had paicked out of the tree and onto my lawn. The owners are un-cooperative on the issue and the cats have been using my garden as their own litter tray..... Garlic, chilli powder and vinegar have had no effect so I need to up the game!
-
@skywatch We had a neighbor with a cat like that once. Same liter box behavior as what you describe. I was sooooo glad when they finally moved to somewhere far away.
-
@NeverDie said in Most reliable "best" radio:
Will a firecracker actually kill a mole?
I'm not sure. But the MoleCat100 uses the blast from a 22 blank, and that has to be close to the concussive force of a firecracker. Being under the dirt by about 4" has to also help in rendering an effective shock wave since dirt is far less compressible than air.
@NeverDie said in Most reliable "best" radio:
The key seems to be charging high voltage capacitors, so that enough current is released at 500v when triggered.
Smoking Cool, and yea, probably dangerous. I was playing with flash bulb circuits from disposable cameras as a potential igniter. I accidently shorted a loaded circuit, and the thing burned a hole in my screw driver. Stunned and temporarily blinded, I put it away immediately and haven't gone back since. I don't think the 500 V device would work on moles; they do their foraging in their tunnels. Probably grubs and worms. Maybe they come out at night?
MouseTrapMonday has probably featured this 500 V device. He has quite a collection.
The Comidox 15KV looks like fun, and again dangerous. Glad to see that the thing comes disassembled. Assembly provides some knowledge requirement at least.
My electric fence is this one. It seems to have internal circuitry that limits grounding problems. The thing sends pulses at about 1Hz. Using a blade of grass, or green straw one can feel the pulses. I've had branches fall on the fence and pin it to the ground without resulting in problems so far. It would be fun to do a tear-down to learn how they work... but I've got these radios to play with.
-
@skywatch said in Most reliable "best" radio:
Do you have any links to this please?
Sure, Here it is on Amazon. I got mine at Coastal Farm and Ranch. While I'm now using it for skunks and racoons, I initially used it on the swim platform of my old wooden boat that was a party scene for sea otters. They can really stink up the boat after a winter.
-
@Larson Since it's fed by AC from the wall, I'm guessing it's a relatively straight forward transformer based design rather than a flyback circuit, but I'm no expert in such things. I presume there's some kind of circuit in addition which renders it safe and non-lethal. Probably best to go with something known to work safely like that for an electric fence and not go the flyback transformer route, especially since the price is so low to begin with.
-
@NeverDie I wouldn't know as I haven't studied power supplies outside of the engineering fundaments, yet. There is a version of these fences that use car batteries & solar charging. So they probably use different transformers.
I sure hope we didn't stink-up your thread with all this rodent-talk.
-
@Larson said in Most reliable "best" radio:
I sure hope we didn't stink-up your thread with all this rodent-talk
No worries. I'm not a stickler for staying on topic. I always say go where the interest is.
-
@Larson said in Most reliable "best" radio:
MouseTrapMonday has probably featured this 500 V device. He has quite a collection.
He's the one who demonstrated the dead fall skunk killer. He's also demoed some no-spray catch-and-release traps, but I don't see those as practical for anyone but the pro's. The way they work is interesting though: supposedly a skunk has to be able to raise its tail to spray, and the no-spray traps don't give them enough room to do that. The downside is that once you release a skunk from the no-kill trap, it can raise its tail and spray you, which is what happened to him in one of his videos.
-
@NeverDie Hilarious.
Release problem: Nothing that a remote, a servo, a relay, and a radio couldn't solve. All of which would get sprayed anyway. Hmmm...
-
@Larson said in Most reliable "best" radio:
Hilarious
Uh... after finding and watching the dead fall video, I downgrade my "Hilarious" comment to "Interesting". Back to the joy of radios!
-
@Larson said in Most reliable "best" radio:
@Larson said in Most reliable "best" radio:
Hilarious
Uh... after finding and watching the dead fall video, I downgrade my "Hilarious" comment to "Interesting". Back to the joy of radios!
I know what you mean. Not sure why, but even if the crush physics are equivalent, somehow his design does seem more disturbing than having a giant falling bolder do the dirty work. On the other hand, at some level it's no worse than road kill, which happens all the time, and most people seem relatively dismissive about that.
In any case, thanks for your post and info regarding the electric fence.
-
As a first pass I tried running the RadiolLlb on these two 20dBm nRF24L01's with the default settings:
and although they work fine at closer ranges, they delivered zero packets (i.e. total fail) along my worst-case transmission path. Make of that what you will. I'll see if I can possibly tweak some settings for a better result and then re-test, but those are the early results. I thought them worth testing because many people here like the nRF24L01 radios and because those radios do have good support for over-the-air updates on the atmega328p.To be fair, there do exist some nRF24L01 modules on Aliexpress with even higher transmission power, so maybe a pair of those would cut the mustard.
I purchased them on amazon, mainly because I could receive them a lot faster than ordering something from China: https://www.amazon.com/dp/B07QC1SXJ8?psc=1&ref=ppx_yo2ov_dt_b_product_details
[Edit: same results even if I reduce the datarate to 250kbps. ]
Well, too bad. They do work for short range. Although this isn't rigorous testing by any means, I'm concluding that long-range for the nRF24L01, or other impairments, is essentially out of consideration Its niche is short-range, and for non-amplified versions preferably line-of-sight short-range. Sorry if that seems harsh, but for a comparison of different radio modules, somebody has to call it--and that's how I'm calling it. If somebody has a better nRF24L01 module that they feel would test better, please make a post and let us know what it is.
-
Surprise! I'm getting it the nRF24L01 modules to send and receive, even along my worst-case transmission path, though for some reason ack's aren't being received along that worst-case path. Not sure why there would be an asymetry like that. Apparently the RadioLib library didn't default to full transmission power, because when I set transmit power to 0dB (which gets amplified by the PA), I'm now getting great radio communication. And this is the 2.4Ghz band, no less. Who would have thought? I'm flabbergasted. If anyone wants to replicate, I've posted my modified RadioLib sketches to source-code tab of the openhardware.io project for the nRF24L01 adapter.
Even if I increase the datarate to 1mbps, the majority of the packets are still getting through. This may turn out to be a closer horserace than I had originally thought: it may yet require some careful measruements to separate out the winner.
[Edit: As a result, I just now ordered some of these E01-2G4M27D: https://www.aliexpress.com/item/3256801616913450.html?spm=a2g0o.order_list.0.0.24f21802jP9dtI
presently on sale for $4.34 each with free shipping, which allegedly contain TCXO's and, hopefully, should be a further step-up in performance. In fact, these may be the top-end of what's currently available on the market in the nRF24L01 series.Now the long wait for them to arrive....]
-
@NeverDie said in Most reliable "best" radio:
If anyone wants to replicate, I've posted my modified RadioLib sketches to source-code tab of the openhardware.io project for the nRF24L01 adapter.
That is my aim (to replicate). I've got these radios on order, but from China.
@NeverDie said in Most reliable "best" radio:
Not sure why there would be an asymetry like that.
I'm thinking... maybe because of the compounded probability of the second (ack) transmission? Maybe having a secondary transmision counter for the ack would help? I'll play with it if I'm not too late. As said, you move fast.
-
@NeverDie One other late thought is to have some standard of antennae selection. I was thinking to make the different radios comparable some limit would be needed, I was thinking I'd stick to the bare 1/4 WL wire. But, reality of antenna science is probably far more complex. Thoughts?
-
@Larson said in Most reliable "best" radio:
That is my aim (to replicate).
Great! When you do, be aware that I found a bug in the RadioLib library wrt the nRF24L01, but it's easily patched: replace micros() with millis() in this section of their library code:
int16_t nRF24::receive(uint8_t* data, size_t len) { // start reception int16_t state = startReceive(); RADIOLIB_ASSERT(state); // wait for Rx_DataReady or timeout //uint32_t start = _mod->micros(); uint32_t start; start = millis(); while(_mod->digitalRead(_mod->getIrq())) { _mod->yield(); // check timeout: 15 retries * 4ms (max Tx time as per datasheet) //if(_mod->micros() - start >= 60000) { if((millis() - start) >= 60000) { standby(); clearIRQ(); return(RADIOLIB_ERR_RX_TIMEOUT); } }I commented out their erroneous code and put my corrected code beneath it. Doing this will allow the radio to listen in Rx mode for a minute before timing out. If you don't make the change, it will time out after 60ms, which I can't imagine is what they intended.
Of course, you may choose to use/try a different nRF24L01 library entirely. There are plenty to chose from.
-
@Larson said in Most reliable "best" radio:
I'll play with it if I'm not too late
I imagine you'll have plenty of time. I'll try again when the E01-2G4M27D's (see edited comment above) arrive, but unfortunately those may not arrive until the end of July according to aliexpress.
-
@Larson said in Most reliable "best" radio:
@NeverDie One other late thought is to have some standard of antennae selection. I was thinking to make the different radios comparable some limit would be needed, I was thinking I'd stick to the bare 1/4 WL wire. But, reality of antenna science is probably far more complex. Thoughts?
You raise a good point. Not really sure. I'll have to marinate on that one. For better or worse, some modules more or less force the use of different antennas than just a wire-whip or spring, because they come equipped with SMA connectors or u.fl connectors or they have trace antennas. As near as I can tell, dipole antennas are generally the best overall, unless you're deliberately trying to do something directional. So, one could maybe argue that we should test with dipole antennas, although that's easier said than done because it's easier with some modules than others.
I started this radio testing with the expectation that one radio, or at least one type of radio, would stand head-and-shoulders above the rest, regardless of antenna type. However, maybe that won't turn out to be the case, which will in itself be be an interesting result if that's how it plays out. For instance, by picking the E01-2G4M27D to test with, I'm certainly giving the nRF24L01 far more advantage than it ever would have if I were using just regular dirt cheap nRF24L01 modules without any PA or LNA. Those by themselves would have no chance of competing, except at very short range. However, for very short range applications, they may very well be winners because of their 2mbps data rate.
-
@NeverDie said in Most reliable "best" radio:
Of course, you may choose to use/try a different nRF24L01 library entirely. There are plenty to chose from.
As I say to my physician, dentist, and probably my mother: you lead, and I will follow. Your library is my library.
-
@NeverDie said in Most reliable "best" radio:
I started this radio testing with the expectation that one radio, or at least one type of radio, would stand head-and-shoulders above the rest, regardless of antenna type.
Yep. And that is why I was thrilled with your earlier conclusions about the SX1262. Andreas Spiess convinced me that maximizing design parameters depend on the needs. Bit rate, bandwidth, power demands, range, and other factors are all working against each other, or with each other. Wish I knew the fundamentals and that is my aim. It would be fun to stay with one radio and just change the parameters and antennae. That has probably been done in academic circles. Imagine what led to the progressive development of different radios. I'm sure it wasn't random. We are left to discover why.
Back to school for me.
-
It seems that I was able to get an improvemet from no ACKs to a majority of ACKs just by installing fresh batteries on the receiver. That was an improvement from 2.9v with the old batteries to 3.2v with the new fresh AA's. So... it makes me wonder whether there'd be even more improvement if it were running at the maximum allowed 3.6v. So, I tried powering it with an external power supply, but performance went down dramatically even at the 3.2v level. I guess probably from longer wires or maybe some other source of noise. Anyhow, just memorializing these findings here as a reminder in case it's worth exploring this topic further in the future.
-
@NeverDie Maybe just ripple on the DC? Did you scope it to see? Maybe try with 10n , 100n and 470uF caps across the DC power line? - Or if there is an onboard regulator on the RF module, then maybe that gets more noisey as the voltage drop across it increases?
-
@Larson Thanks- they are a LOT more expensive here, but cheaper versions are available - sorry for diverting the thread a little.
-
@skywatch said in Most reliable "best" radio:
@NeverDie Maybe just ripple on the DC? Did you scope it to see? Maybe try with 10n , 100n and 470uF caps across the DC power line? - Or if there is an onboard regulator on the RF module, then maybe that gets more noisey as the voltage drop across it increases?
It does already have 100n (=0.1uF) across the DC power line, extremely near the inputs to the nRF24L01. I didn't check those other things though. However, given how widespread the use of the nRF24L01 is on this forum, if anyone happens to know whether powering it with voltage at the higher end of its range improves performance, please post. I think for the LoRa chips it doesn't matter, because they all down-convert anyway. Maybe the nRF24L01 does as well? I really hadn't expected the nRF24L01, boosted as it was with PA and LNA, to do as well as it did. So, there's that added layer of PA + LNA complexity that may have something to do with it, not just the nRF24L01 chip itself. If I was focused on just one particular chip or module, I could do those tests. But multiply that workload by six or so other radio modules, all with different idiosyncrasies, and I quickly run out of time. I may have bitten off more than I can chew. So, I just have to draw the line and either come back to it in the future or not, depending on how the global picture develops. But if someone already happens to know the answer, then hopefully they might make a posting.
This guy just recently did a video on nRF24L01 problems:
NRF24 Frustration - Radio module doesn't work? β 12:46
β Electronoobsand the very first thing he talks about is long wires.
-
@Larson said in Most reliable "best" radio:
@NeverDie said in Most reliable "best" radio:
I started this radio testing with the expectation that one radio, or at least one type of radio, would stand head-and-shoulders above the rest, regardless of antenna type.
Yep. And that is why I was thrilled with your earlier conclusions about the SX1262. Andreas Spiess convinced me that maximizing design parameters depend on the needs. Bit rate, bandwidth, power demands, range, and other factors are all working against each other, or with each other. Wish I knew the fundamentals and that is my aim. It would be fun to stay with one radio and just change the parameters and antennae. That has probably been done in academic circles. Imagine what led to the progressive development of different radios. I'm sure it wasn't random. We are left to discover why.
Back to school for me.
I did that once with the RFM69, and the parameters on that radio are numerous and a real challenge to fully understand. The API of the newer LoRa radios is a lot simpler, which is fine by me.
If it weren't for the 2mbps, or even 1mbps, capability of the nRF24L01 (and related nrf5x modules, of course), I would drop the nRF24L01 like a hot brick. But those high datarates, and especially mysensors support for OTA updates using it, offer a compelling advantage.
So, now that there's a common test platform--one without long wires--we'll just see how it all develops.
It would be fun to test the si4468, which looks very capable, but I think I'm already at the limit of what I can consider all at one time.
-
@Larson Now that you have a PPK2, there's an easy way you can check for whether or not your plain, ordinary nRF24L01 chips are fake or not: looking at the Tx and Rx current draws and comparing them to the datasheet. For instance, on this particular nRF24L01 module:
Here is the Tx and Rx profile from running the RadioLib transmit script I posted in source code section:
The first plateau is the transmit current. The second plateau is the Rx current, where it's listening for an ACK. Well, as you can see, the Tx current is about 26-27ma and the Rx current is around 14-15ma. So, next, compare that to the specifications in the nRF24L01 datasheet:
and you can see that the values don't match. Not even close! 26-27ma is way beyond the spec of 11.3ma for maximum current draw,and 14-15ma is above the max of 12.3ma for Rx. So, the chip on this module, even though it says, as you can clearly see in the photo itself, that it is NRF 24L01+, it's a total fake. No question about it. Not only that, but if you want to, you can identify exactly which fake chip that it is, by looking at the datasheets of known fakes and looking for a match.
When in doubt you can also measure and compare sleep currents, which varies between the real and various fake chips. As you'd probably expect, Nordic has the lowest sleep current of any of them, at least as far as I'm aware.
-
@Larson In this case, it's almost certainly the si24R1 chip, because if you look at the datasheet here: https://datasheet.lcsc.com/lcsc/1811142211_Nanjing-Zhongke-Microelectronics-Si24R1_C14436.pdf and zoom in on the electrical specification, you see that the specified currents are:
which is a very close match.
I've written about this before (here: https://forum.mysensors.org/topic/1664/which-are-the-best-nrf24l01-modules/285 , where it took me a lot of effort to finally figure all this out), but it's so buried at this point that I doubt anyone new to the game is even aware of it. So, I include it here, as bonus perk for anyone who happens to be reading this thread. Nice, ya?
-
By the way, if I did end up using the nRF24L01 (or nRF5x series), I'd like to do what I outlined in the last post on that thread (https://forum.mysensors.org/topic/1664/which-are-the-best-nrf24l01-modules/309?_=1654977950928), which is to do channel hopping and time synchronization among motes. There are some interesting demos on distributed time synchronization which are pretty cool:
Proportional Integral Clock Synchronization in Wireless Sensor Networks β 01:00
β KasΔ±m Sinan YΔ±ldΔ±rΔ±mOne simple (but maybe not the best technique) is to have each node transmit its local time in some kind of sequence, while the other nodes listen and take note. Then by averaging these local times over a few iterations, the group converges onto a single time. Pretty neat, huh? I would imagine that, more efficient and less complex, would be to have a powered wireless time server, and then everything syncs to that.
-
And this youtube succinctly explains why it's worthwhile:
Wheel of Blinking LEDs β Wireless Time Synchronization β 02:50
β Analog Devices, Inc.TL;DR: much longer battery life, among other things.
-
@NeverDie You probably already considered this but using a co-ax cable for the power would offer some sheilding and also after watching the video you linked maybe some of those tiny ferrite beads on the data and power at the radio might be of help.
I had to chuckle when the guy in the video showed how he connected an external antenna without first removing the link to the PCB one!
If I can I will try one of the cdebyte modules on 3.6V and see if they are still good... Remind me in a week if I don't get it done!
-
@skywatch said in Most reliable "best" radio:
those tiny ferrite beads
Have you tried it before? Exactly which tiny ferrite beads do you recommend? Mouser lists over 4,200 different ones.
-
Well, the nRF24L01 datasheet says, "The nRF24L01 transmitter PLL operates in open loop when in TX
mode. It is important to never keep the nRF24L01 in TX mode for more than 4ms at a time."Disappointing, but I believe I can work around that limitation.
Why is there a limitation on Tx time but not Rx time? Is it a thermal issue of some kind?
-
@NeverDie said in Most reliable "best" radio:
I've written about this before (here: https://forum.mysensors.org/topic/1664/which-are-the-best-nrf24l01-modules/285 , where it took me a lot of effort to finally figure all this out), but it's so buried at this point that I doubt anyone new to the game is even aware of it. So, I include it here, as bonus perk for anyone who happens to be reading this thread. Nice, ya?
Yes, very nice. But how would you know where to look for the si24R1 chip amongst the others? I haven't read the other thread, just yet - it is the end of a very long sweaty fuse-setting day. Not only just a perk, your writing on these subjects is a library for others. Like today, I'm reading Nick Gammon's posts from 2012. They are there and very relevant still - I spend much of the day reading them. In 2032, should we get that far, folks will be upstudying your material.
-
@Larson Somewhere I found a list of known clones. I linked to it in the original thread that I referenced above. si24R1 is China's clone of the nRF24L01. Ebyte even explicitly advertises it as a clone on their website and in their aliexpress store. A lot of times if you see an advertisement for an "enhanced power" nRF24L01 that doesn't otherwise contain a PA, it's an si24R1, because it has a 7dBm Tx power, versus a max 0dBm Tx power for the nRF24L01.
-
@NeverDie I have not tried them for this particular application, but have used them for SMPSU and the larger clamp on styles for SDR and other RF devices.
They used to be quite cheap so trying a size that fits snuggly over the wires you are using should help.
I see that guy in the video you posted twisting the ground wire with the data wires. This could simply be adding capacitance to the circuit or acting as a common mode rejection against transient interference. I wonder why he didn't try different value pull-up resistors on the data lines to see if that would help.
-
@NeverDie I suspect that in 'open loop' (i.e. no feedback as I understand that to mean) then frequency stability over a longer period might be questionable. So to be safe they recommend a limit across which frequency drift won't be noticable. But as always, I could be completely wrong!
-
@skywatch said in Most reliable "best" radio:
@NeverDie I suspect that in 'open loop' (i.e. no feedback as I understand that to mean) then frequency stability over a longer period might be questionable. So to be safe they recommend a limit across which frequency drift won't be noticable. But as always, I could be completely wrong!
That's what I was thinking also, but if that were the case, why would the 4ms limit apply only to Tx and not to Rx? I guess the only way to find out is to run it longer than recommended and see what happens. In the worst case I burn out a module, but they're so cheap it would be worth the sacrifice.
What's a bit weird is that it doesn't say anything beyond not keeping it on for more than 4ms. It doesn't indicate that it needs a rest period or anything, so, yeah, I'm guessing you're right: it's some kind of frequency stability thing that mysteriously applies to Tx and not to Rx for some reason.
-
@NeverDie said in Most reliable "best" radio:
which is to do channel hopping and time synchronization among motes.
A guy by the name DeKay played with frequence hopping when trying to hack a Davis Pro Vantage Pro Weather station. He has several blogs about this. Here is one: [http://madscientistlabs.blogspot.com/2014/02/build-your-own-davis-weather-station_17.html] but there are others. Kobuki was one of the contributors of note.
-
@NeverDie said in Most reliable "best" radio:
...si24R1 is China's clone of the nRF24L01. Ebyte even explicitly advertises it as a clone on their website and in their aliexpress store.
On reading the comments in one of the refered Electronoobs links, I saw that the si24R1 was celebrated. If the higher TX power demand is effective ... then it it would be good to look at. I do marvel at the value that is delivered from China. It makes it possible for me to explore without worrying too much about smoking a few chips... which I have done.
-
@skywatch said in Most reliable "best" radio:
I see that guy in the video you posted twisting the ground wire with the data wires. This could simply be adding capacitance to the circuit or acting as a common mode rejection against transient interference. I wonder why he didn't try different value pull-up resistors on the data lines to see if that would help.
One of the comments I saw about this twisting technique referenced a radio tech from 50 years ago and it worked for them. I like your ideas. Is there a circuit for common mode rejection? It would be worth exploring. And using a test port for different pull-up resistors, better yet a variable resistor, would allow for testing. We have tools today to explore.
[edit: Now that I've learned from Hartley and Bogatin to think of the return path of signals, the twisting technique looks really appealing for prototype fly-wires. Is the common mode rejection an idea for more final PCB's? Or is it more of a breadboard idea?]
-
@Larson said in Most reliable "best" radio:
@NeverDie said in Most reliable "best" radio:
...si24R1 is China's clone of the nRF24L01. Ebyte even explicitly advertises it as a clone on their website and in their aliexpress store.
On reading the comments in one of the refered Electronoobs links, I saw that the si24R1 was celebrated. If the higher TX power demand is effective ... then it it would be good to look at. I do marvel at the value that is delivered from China. It makes it possible for me to explore without worrying too much about smoking a few chips... which I have done.
Yes, from the standpoint of having an inexpensive transmitter without a PA the si24R1 does very noticeably outperform the Nordic nRF24L01. 7dBm vs 0dBm. I like them. Just saying that it's good to know what you have. There are known to be some imcompatabilities, but I'm forgetting among which chips they arise. IIRC, it has to do with how ACK's are handled. It can be a source of frustration if you aren't aware of it, and it doesn't help that the chip labeling may lie about just exactly what they are. I'd have no complaints if the si24R1 chips were actually labeled si24R1 instead of trying to pass themselves off as nRF24L01's by labeling themselves as such (as in the photo that I posted). Sometimes they are, but more often than not they aren't.
-
Judging from the "power enhanced" title in this listing: https://www.amazon.com/dp/B082VLQK1M?psc=1&ref=ppx_yo2ov_dt_b_product_details
I'm guessing that they are probably si24R1's, even though the chip labeling in the photo says that they're nRF24L01's. I ordered some, and with the aid of the PPK2, I'll know soon just what they are.On Aliexpress they're even cheaper, but the wait is much, much longer: https://www.aliexpress.com/item/2251801699158809.html?spm=a2g0o.cart.0.0.202b38dax6gRtv&mp=1
They're so inexpensive that for short-range maybe they're good enough. I'm sure once the chip shortage is over that atmega328p's will be back to around $1 each. A $2 transceiver is pretty amazing. Like you say, the golden age.
-
@NeverDie said in Most reliable "best" radio:
On Aliexpress they're even cheaper, but the wait is much, much longer: https://www.aliexpress.com/item/2251801699158809.html?spm=a2g0o.cart.0.0.202b38dax6gRtv&mp=1
At 10 for $5.30, I can wait. I just ordered some!
-
@Larson What good luck: looks as though the pinout is an exact match for the pinout on my nRF24L01 adapter board for the test platform:
Makes me wonder what those two through-holes are for near the antenna?
Looks as though they are meant for something. Anybody know what those two through-holes are for?
-
Ignoring the warning about not transmitting for longer than 4ms at a time, I'm presently trying to blast out a continuous stream of packets from the nRF24L01 at 2mbps datarate without pausing between packets. According to the datasheet, one way to do it would be to start sending the first packet while ensuring that the Tx FIFO never empties. However, none of the libraries seem configured for doing that, so it involves working with the nRF24L01 at a lower level. In the worst case, I guess I could settle for a 4ms long packet train if that's the best it can do, but maybe an nRF24L01 equipped with a TCXO could perhaps go longer than 4ms? The 4ms is evidently a PLL limitation, and I'm not sure exactly how the PLL interacts with the crystal, or whether or not a better crystal will lengthen the continuous transmit time.
Anyone here tried this before? I mean, come on, a lot of people here use the nRF24L01 as their go-to transceiver. Anyone? Anyone? Bueller? Anyone?
-
@NeverDie It has an on-board frequency synthesiser so maybe during tx the temp rises on the substrate and this affects tx frequency stability? So it could be the FS rather than the PLL. Again just guessing here....
-
I went and did it. I got it to transmit continuously for many seconds before it peters out. And the packets it sends can be received, decoded, and understood. Exactly how long it goes seems to vary from one burst to the next, but a reset gets it going again. Anyhow, it works more than long enough for my purposes.
In case you're wondering why the current draw isn't higher (as it was in earlier pictures), it's because I turned the power all the way down to minimum, since I'm testing at close range.
-
Also, I'm happy to confirm that the amazon smd nRF24L01 modules that I ordered (see earlier post) have a pinout that matches my nRF24L01 adapters. I've tried it out, and it works:
That said, what I received is a little bit different than what was pictured in the amazon listing. If you look at the through-holes that are near the antenna, one of them is much smaller on the modules that I received. It's much more like a via than a through-hole.
-
Lastly, it sounds as though the shortage of legacy chips is going to continue for quite some time:
Where The Real Chip Shortage Is β 11:53
β AsianometryThe TL;DR is that there's little profit in those chips, and so there's no motivation for manufacturers to build expensive new plants to pump out yesterday's technology. I posted recently about the attiny3226, and now I wish I had bought some, because they're now all out of stock everywhere. I'm therefore debating whether to buy some attiny3224's, which lack as many pins, because they're presently in stock but soon will be sold out, jut like the attiny3226's. It might be years before things get back to normal.
-
@NeverDie said in Most reliable "best" radio:
Makes me wonder what those two through-holes are for near the antenna?
On ESP8266's, I wondered if the PCB antenna could be cut with a dremel tool and be fitted with an equivalent whip-wire. It would be cheap enough to try. It looks to be that the NRF24's are maybe making that easier? Again, cheap enough to try.
Thanks for all the updates to https://www.openhardware.io/user/310/projects/NeverDie#view=projects I've been busy updating all the files I've collected. You have been hard at work. All the added *.png and *jpg pictures really help. The *.rar files make it really easy to get into the guts of it all. I got KiCAD downloaded and am looking at the E28 project at the moment. Learning a new CAD tool will be a climb of its own for me.
For the benefit of others: To extract the *.rar in Windows 10, I downloaded a utility program (WinZip 21-day trial). Maybe everyone already knows that. What I have learned is that getting to the KiCAD files is a three step zip-sandwich procedure:
- download and unzip the openhardware *.zip file.
- find the *.rar file and use a utility like WinZip to unwrap it.
- unzip the resulting *.zip file.
The resulting four files (*.pcb, *.prl, *.pro, and *.sch) will deliver KiCAD access as a project via the *.pro file. It took me most of the day to learn that. There is probably an easier way.
-
@Larson said in Most reliable "best" radio:
unzip the resulting *.zip file.
Uh, oh. As Bug's Bunnny would say, you may have made a wrong turn at Albuquerque, or, in this case, on step 3.
There is, I think, a much simpler way. Instead of manually unzipping the .zip file and trying to make sense of the contents, do this instead: in Kicad 6, under the "File..." menu, go to "Unarchive project...." and give it the intact .zip file. It will instantly recreate the entire project on the spot, exactly where I left off with it. It really couldn't be simpler. Try it. You'll like it.
Regardless, thanks for the feedback. I just now changed the instructions on the openhardware.io projects to make it more clear what to do.
-
@Larson said in Most reliable "best" radio:
I wondered if the PCB antenna could be cut with a dremel tool and be fitted with an equivalent whip-wire. It would be cheap enough to try. It looks to be that the NRF24's are maybe making that easier? Again, cheap enough to try.
No need to guess. It's been done already. Here's one of the mods:
Cheap DIY NRF24L01 Antenna Modification β 02:48
β Pete BThis one looks even better: https://www.instructables.com/Enhanced-NRF24L01/
I haven't tried either one, but I do believe them when they say it helps improve range a lot.
-
@Larson said in Most reliable "best" radio:
You have been hard at work.
Yup, and although it's jumping the gun, I think I'm ready to reach conclusions. For battery powered nodes, I think for short-range the answer is si24R1, because it offers 2mbps and 7dBm and you can buy tiny, compact modules with in-built PCB antennas for around 50 cents each, as you have already done. Also, mysensors offers over-the-air updates with nRF24L01/si24R1, which is compelling. So, if you have a gateway within range, I see no problem with those radios. For longer range, I think the answer is SX1262 because FCC allegedly allows higher transmit power with spread spectrum, and it has a very large potential link budget. If powered by mains, I'd say ESP8266, which is what I will use to gateway the si24R1 and SX1262 motes. I could test and compare more radios, but I don't have infinite time, so I think that's as far as I'm going to take it for now. If anyone else wants to try more stuff and report back and/or make comparisons, I'd say by all means go for it. For instance, anything that does genuine frequency hopping would be worth looking into. Frequency Hopping would maybe get the best of both worlds, with a combination of high speed, a large link budget, and interference avoidance. This guy does a comparison of LoRa vs Frequency Hopping, and you can see why Frequency Hopping Spread Spectrum seems more compelling than LoRa:
LoRa Vs Spread Spectrum FHSS 2.4 GHz β 10:13
β 0033merWhat's interesting is that the FHSS module he demos actually uses the nRF24L01 chip inside it to accomplish the FHSS! See https://www.ebyte.com/en/new-view-info.html?id=450 So, I take that to mean that with the right software, one could program an MCU to get the nRF24L01 to do FHSS. I do wonder though just how it manages to do it. AFAIK, true FHSS requires psuedo-random changes in frequency while transmitting a single packet, not sending short packets in a pseudo-random sequence of different frequencies. Hmmm.... Maybe it just strips off all the header bytes, and does it that way? Maybe then there would be no difference. I'm guessing maybe that's how they do it. You could compute your own CRC and send the CRC bytes as part of the payload instead of in a separate part of the frame. In fact, that might even be better, because then you could do CRC32, whereas the nRF24L01 hardware encoding seems limited to CRC16. You send what would have been frame bytes as purely payload bytes, creating a kind of virtual Frame. Also, by chopping up the transmission--you could effectively send payloads that are longer than 32 bytes, which is the limit for any single packet on the nRF24L01--by loading and sending more than one pipe's worth of data. This is notionally similar to how I was able to get the nRF24L01 to transmit continuously (see earlier post) without dropping into standby/idle between packets.
-
@NeverDie said in Most reliable "best" radio:
No need to guess. It's been done already. Here's one of the mods:
Very interesting. Based on the measurements the author, Pete B, shows, the on-board antenna length is 33.3% the 1/4 Lambda WL. He adds 66.7% for a total 1/4 Lambda. I'll say the same thing is probably true for the ESP8266 antennae lengths. I'm looking forward to trying this with the ESP.
[Edit: My mistake. I looked at this further. The full 2.4GH WL is 4.92". So, the onboard measured 1.64" WL is a 1/3 WL. The additional 3.28" would bring the total WL to 1.0 * WL. Several simple RSSI tests would show the results. Frist test would be no change for a base case. Then test with the addition. Then one could cut the wire back to 3/4 WL, 1/2 WL, 1/4 WL, then finally remove the antenna to verify the original test, or to inspect for circuit damage.]
-
@NeverDie said in Most reliable "best" radio:
conclusions
Yes, I feared that I would be too late to the game to help. I hope to report back with some results after the boat from China arrives. I'd like to do the 2-D map of RSSI values with different radios.
