Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?
-
@Larson Glad you liked it. If you're interested in the theory of it, then you may find this a worthwhile survey of some of the big ideas:
https://www.youtube.com/watch?v=bHIhgxav9LYPlainly it's a deep topic, so I'm relieved whenever I find simple design rules of thumb which make it possible to do successful projects without having to peel back everything to first principles. ;-)
@NeverDie Yes, I strive to not reinvent also. But it is nice to know why wheels are round. So I dug a little further on this ground plane subject and I’m conflicted. At 40:42 on this video, ground planes are discussed. In short, he discourages the use of ground planes. So I ask myself, what design is used on an ESP8266 itself. Certainly, they use the best design standards to minimize EMI since they manufacture these radios by the millions. To find out I get out my zacto knife and scrape off some of the masking of the ESP and check for ground. Sure enough they use ground planes everywhere except for under the antennae. Go figure.
[Edit 5/30/22. After listening to the link in my post again, I’m realizing that I was wrong to say Eric Bogatin discourages ground planes. I think I’ve learned that he discourages the use of copper fills on signal layers. Big difference. It was unclear in the referenced video segment that the three experimental boards with different trace distributions had a ground plane below, but I believe that was the case.]
-
@NeverDie Yes, I strive to not reinvent also. But it is nice to know why wheels are round. So I dug a little further on this ground plane subject and I’m conflicted. At 40:42 on this video, ground planes are discussed. In short, he discourages the use of ground planes. So I ask myself, what design is used on an ESP8266 itself. Certainly, they use the best design standards to minimize EMI since they manufacture these radios by the millions. To find out I get out my zacto knife and scrape off some of the masking of the ESP and check for ground. Sure enough they use ground planes everywhere except for under the antennae. Go figure.
[Edit 5/30/22. After listening to the link in my post again, I’m realizing that I was wrong to say Eric Bogatin discourages ground planes. I think I’ve learned that he discourages the use of copper fills on signal layers. Big difference. It was unclear in the referenced video segment that the three experimental boards with different trace distributions had a ground plane below, but I believe that was the case.]
@Larson AFAIK, the biggest reason to have a ground plane in a radio system is to improve the performance of a whip antenna. I'm not sure what's ideal, but, for example, https://www.digi.com/support/knowledge-base/does-a-1-4-wave-antenna-need-a-ground-plane recommends a 3 inch radius groundplane for a 2.4Ghz radio if the antenna were put in the very middle of it. Well,that would be a 6 inch diameter ground plane! Not a great option for tiny IOT devices.
Fortunately, it does concede that "The antenna can still work on a smaller ground plane but the efficiency will be reduced." On the other hand, if you're using a dipole antenna, then maybe (?) the ground plane isn't so important. Not entirely sure.Anyhow, if you find out anything more, I'd be interested.
-
I'm an engineer, though not RF. My understanding, from short discussions years ago with RF engineers, was that the ground planes have strong effects on antenna performance.
Depending on the design of the antenna, sometimes you want the ground plane and sometimes you don't.
But that's the extent of what I remember. (And it could be that I've even got errors in that little bit.) But basically to go with whatever the antenna designer recommended, because there are reasons for it. Just because one design calls for it and the other doesn't, it doesn't make either of them wrong.
Without the deep understanding myself, and not having however much testing equipment necessary to check the results, I try to stick as close to what the manufacturer/designer calls for as possible.
-
I'm an engineer, though not RF. My understanding, from short discussions years ago with RF engineers, was that the ground planes have strong effects on antenna performance.
Depending on the design of the antenna, sometimes you want the ground plane and sometimes you don't.
But that's the extent of what I remember. (And it could be that I've even got errors in that little bit.) But basically to go with whatever the antenna designer recommended, because there are reasons for it. Just because one design calls for it and the other doesn't, it doesn't make either of them wrong.
Without the deep understanding myself, and not having however much testing equipment necessary to check the results, I try to stick as close to what the manufacturer/designer calls for as possible.
@NeverDie and @ejlane: Thanks for the inputs. Wise counsel has been my easy path, too, especially in engineering (Civil by profession, but wannabe Electronic in my retirement). @ejlane: I ran across NeverDie and MySensors in my earlier radio research (RFM69’s I think) and fast embraced his advice & learnings. And I admire his clear writings/descriptions.
After digesting the content of this thread and having time to sleep on it I’m starting to think that signal integrity (EMI) and antennae performance are maybe the same thing on different ends of a design spectrum. So perhaps both ground planes and non-ground planes are just different design criteria for different purposes (transmission vs. noise immunity).@NeverDie - yep, 6-inch GP will sink my little boards. Funny that the RFM69's do so well with such a tiny board and whip antennae. I haven't scraped the masking on those radios looking for GP's, however.
Someday I'll grow-up and buy a scope. Discussions like this really help – thanks.
-
I'd say that EMI is just transmitting accidentally. Parts of the circuit are radiating when you didn't mean them to. When that accidental radiation - which is unavoidable at some level - rises above the regulation limit for any frequency band then you have FCC (or other country alternative agency) problems. Of course the accidental emissions can also be just about any frequency, depending on trace length and shape, clock speeds, etc. That again might require antenna knowledge to know what to expect.
-
@Larson AFAIK, the biggest reason to have a ground plane in a radio system is to improve the performance of a whip antenna. I'm not sure what's ideal, but, for example, https://www.digi.com/support/knowledge-base/does-a-1-4-wave-antenna-need-a-ground-plane recommends a 3 inch radius groundplane for a 2.4Ghz radio if the antenna were put in the very middle of it. Well,that would be a 6 inch diameter ground plane! Not a great option for tiny IOT devices.
Fortunately, it does concede that "The antenna can still work on a smaller ground plane but the efficiency will be reduced." On the other hand, if you're using a dipole antenna, then maybe (?) the ground plane isn't so important. Not entirely sure.Anyhow, if you find out anything more, I'd be interested.
@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:
Anyhow, if you find out anything more, I'd be interested.
Eric Bogatin, master and professor of signal integrity, gave this presentation at an Altuim conference. At about 42:00 he talks about 7 Habits of Good Design. This, again, has more to do with PCB design and not radio performance. I have a suspicion that several radio boards I designed failed not because of the transmitter, but because of bad PCB design. I can make a failed transmitter (whip antennae) board work by putting the 433 MHz transmitter on a 7" leash away from the board. Now that is a sign.
@ejlane - Thanks. I'm just now learning of the EMI/EMC testing required for commercial products and FCC requirements. While that exceeds the requirements and budget for my home projects, I do think that I might employ the pre EMI testing that one can do with a scope and probes. That may drive me back to school to learn scopes!
-
@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:
Anyhow, if you find out anything more, I'd be interested.
Eric Bogatin, master and professor of signal integrity, gave this presentation at an Altuim conference. At about 42:00 he talks about 7 Habits of Good Design. This, again, has more to do with PCB design and not radio performance. I have a suspicion that several radio boards I designed failed not because of the transmitter, but because of bad PCB design. I can make a failed transmitter (whip antennae) board work by putting the 433 MHz transmitter on a 7" leash away from the board. Now that is a sign.
@ejlane - Thanks. I'm just now learning of the EMI/EMC testing required for commercial products and FCC requirements. While that exceeds the requirements and budget for my home projects, I do think that I might employ the pre EMI testing that one can do with a scope and probes. That may drive me back to school to learn scopes!
@Larson As far as I know, it takes special probes for magnetic fields to check for EMI. Never done it myself, but I keep meaning to. :)
But scopes are well worth it to see what's going on. You can make it a fair ways with just fiddling with the dials and some light watching of YouTube. I used scopes a bit here and there before I ever went to school for engineering. (Though there was no YouTube to learn from at the time. The basics are pretty self-explanatory, and the advanced features are still beyond what I really do sometimes.)
-
Good news. Regarding the SHT45 TH sensor I mentioned in the first post, mouser expects to have it in stock by July 29, 2022: https://www.mouser.com/c/?q=sht45 Quantity 1 price is $4.60. AFAIK, in terms of accuracy and precision and measurable range, it's pretty much state of the art. If anyone knows of anything better, please do post what it would be.
A bit like the DeLorean in Back to the Future, I figure if you're going to build a TH sensor, might as well do it in style!
-
I've had the board fabricated, and I've verified that the through-holes will correctly line-up with the holes on a 2.54 pitch prototypig board. Also, the landing pads appear to line-up perfectly as well. Therefore, I have removed the "work in progress" tag. The breakout board is done!
https://www.openhardware.io/view/8304/EBYTE-E28-2G4M27S-SX-1280-chip-24GHz-LoRa-Breakout-Board
-
I just now noticed that Andreas Spiess did a youtube about the same chip, though different model Ebyte modue:
https://www.youtube.com/watch?v=JYThKZCflJcSmall world: it turns out he also made a breakout board for himself in order to test the module. It doesn't look pin compatible with my module, however, as it has only 14 pins on its pinout, whereas mine has 16. Also, not sure whether Andreas posted his breakout board anywhere. I would expect so. He has a github, but it has almost no descriptive material in it other than the titles, so it's hard to know what is truly what.
Worthy of note: the module he chose is less capable than the one I picked: substantially less potential transmit power, and also, according to Ebyte specs, somewhat inferior receive sensitivity.
Fortunately, he does post links to the libraries that he used to operate the SX1280 chip, so that's probably a good starting point, or at least a point of comparison.
To avoid interference he does report having to turn off the wifi on his esp32 that's driving the module, so having an ethernet connection for the gateway probably makes the most sense. The good news is that with LoRa, you should need only one such gateway, and you can probably put it just about anywhere and still have a good, solid RF connection to your nodes. Probably a raspberry pi could serve that purpose for a low effort solution, though I may go for an arduino-ethernet solution because that may turn out to be even easier, and probably without the need for ongoing updates and security maintenance. i.e. it should "just work". Perhaps setting the target IP address with a dipswitch would avoid any future need to revisit the firmware. Also, a raspberry pi's attack surface seems orders of magnitude larger than a more basic, hardware oriented solution.
Regardless, the next step for me is to wire it up and get it to play ping pong with another node. Then I'll be able to quickly determine whether ambient wi-fi signals in the environment will be a cause for concern or not. I suspect not, but sending thousands/millions of test packets while measuring for packet loss will tell the tale definitively.
I have one node with a 100uF capacitor (pictured in my preceding post), and another node without, so I'll try to determine whether it makes any practical difference or not. I'm guessing that it were powered by a coincell, it's essential, but if by two AA's in close proximity, probably not (though if the batteries are weak, maybe it would, at the margin, still help).
-
Here's what the breadboarded LoRa transmitter node looks like:
It turns out you need an external LED for status purposes, because the typical Pin 13 LED isn't available because it's in use by the SPI interface as a clock pin. The LED blinks every time a packet is transmitted (about once a second). In the picture here, I managed to photograph it at the very moment of blinking after a transmission.
The wiring pinout is given in the header file of the library example application, so no thinking required. I'm using a generic pro mini with the 5v LDO removed, and I then programmed it using the Arduino IDE as a 3.3v 8Mhz pro mini using the library's example transmitter setup sketch downloaded from: https://github.com/StuartsProjects/SX12XX-LoRa
-
Here's what the breadboarded receiver looks like:
Every time it receives a packet from the transmitter (pictured in the immediately preceding post), it blinks the red LED.
Simple to assemble. Both transmitter and receiver worked flawlessly the very first time I put it all together. :-)
Next up: do range testing around the house and run enough packets to determine whether any ever get lost, and, if so, what the rate of loss is. I'll also dial down the transmit power to see how low is still sufficient.
-
@NeverDie - thanks for the prolific work. There is alot to consider here. I reviewd the Andreas Spiess video...wonderful as usual. I'll have lots of questions after I set-up my own station to poke around.
On your range tests: The tests that I have seen that are most effective are those where the transmitters are always sending. The recievers have packet counting stats to give evidence. And for a topper, the reciever sends an ack that can also meausre packett success. Fun stuff.
-
@NeverDie - thanks for the prolific work. There is alot to consider here. I reviewd the Andreas Spiess video...wonderful as usual. I'll have lots of questions after I set-up my own station to poke around.
On your range tests: The tests that I have seen that are most effective are those where the transmitters are always sending. The recievers have packet counting stats to give evidence. And for a topper, the reciever sends an ack that can also meausre packett success. Fun stuff.
@Larson Yup. It will be fun to see how LoRa performs at 2.4Ghz.:grin:
Since LoRa potentially has such long transmission windows (at the extreme, as much as one second), it will be important to keep the transmissions of different nodes from overlapping and for recovering (and avoiding future overlaps) if they do.
-
In case anyone is wondering, the default receiver output using the library's receiver setup example looks like this:
17:05:02 Apr 17 2022 V1.0 104_LoRa_Receiver_Detailed_Setup Starting LoRa Device found SX1280,PACKET_TYPE_LORA,2444999936hz,SF7,BW406250,CR4:5 SX1280,PACKET_TYPE_LORA,Preamble_12,Explicit,PayloadL_255,CRC_ON,IQ_NORMAL,LNAgain_HighSensitivity Reg 0 1 2 3 4 5 6 7 8 9 A B C D E F 0x900 80 FF 77 41 20 FA BC 13 C1 80 00 00 00 00 00 61 0x910 9C 44 00 00 00 19 00 00 00 19 87 65 43 21 7F FF 0x920 FF FF FF 00 70 37 12 50 D0 80 00 C0 5F D2 8F 0A 0x930 00 C0 00 00 00 24 00 21 28 B0 30 0D 01 51 63 0C 0x940 58 0B 32 0A 16 24 6B 96 00 18 00 00 00 00 00 00 0x950 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x960 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF FF 0x970 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 04 0x980 00 0B 18 70 00 00 00 4C 00 F0 64 00 00 00 00 00 0x990 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x9A0 00 08 EC B8 9D 8A E6 66 04 00 00 00 00 00 00 00 0x9B0 00 08 EC B8 9D 8A E6 66 04 00 00 00 00 00 00 00 0x9C0 00 16 00 3F E8 01 FF FF FF FF 5E 4D 25 10 55 55 0x9D0 55 55 55 55 55 55 55 55 55 55 55 55 55 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 4s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,1,Errors,0,IRQreg,8012 5s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,2,Errors,0,IRQreg,8012 6s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,8dB,Length,23,Packets,3,Errors,0,IRQreg,8012 7s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,4,Errors,0,IRQreg,8012 8s Hello World 1234567890*,CRC,DAAB,RSSI,-52dBm,SNR,12dB,Length,23,Packets,5,Errors,0,IRQreg,8012 9s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,14dB,Length,23,Packets,6,Errors,0,IRQreg,8012 10s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,7,Errors,0,IRQreg,8012 11s Hello World 1234567890*,CRC,DAAB,RSSI,-52dBm,SNR,14dB,Length,23,Packets,8,Errors,0,IRQreg,8012 12s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,9,Errors,0,IRQreg,8012 13s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,10,Errors,0,IRQreg,8012 14s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,11,Errors,0,IRQreg,8012 15s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,12,Errors,0,IRQreg,8012 16s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,13,Errors,0,IRQreg,8012 17s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,12dB,Length,23,Packets,14,Errors,0,IRQreg,8012 18s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,15,Errors,0,IRQreg,8012 19s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,12dB,Length,23,Packets,16,Errors,0,IRQreg,8012 20s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,17,Errors,0,IRQreg,8012 21s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,18,Errors,0,IRQreg,8012 22s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,19,Errors,0,IRQreg,8012 24s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,20,Errors,0,IRQreg,8012 25s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,21,Errors,0,IRQreg,8012 26s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,22,Errors,0,IRQreg,8012 27s Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,23,Errors,0,IRQreg,8012 28s Hello World 1234567890*,CRC,DAAB,RSSI,-52dBm,SNR,11dB,Length,23,Packets,24,Errors,0,IRQreg,8012 29s Hello World 1234567890*,CRC,DAAB,RSSI,-53dBm,SNR,13dB,Length,23,Packets,25,Errors,0,IRQreg,8012 30s Hello World 1234567890*,CRC,DAAB,RSSI,-53dBm,SNR,13dB,Length,23,Packets,26,Errors,0,IRQreg,8012 31s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,12dB,Length,23,Packets,27,Errors,0,IRQreg,8012 32s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,28,Errors,0,IRQreg,8012 33s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,12dB,Length,23,Packets,29,Errors,0,IRQreg,8012 34s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,30,Errors,0,IRQreg,8012 35s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,12dB,Length,23,Packets,31,Errors,0,IRQreg,8012 36s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,32,Errors,0,IRQreg,8012 37s Hello World 1234567890*,CRC,DAAB,RSSI,-53dBm,SNR,3dB,Length,23,Packets,33,Errors,0,IRQreg,8012 38s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,14dB,Length,23,Packets,34,Errors,0,IRQreg,8012 39s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,35,Errors,0,IRQreg,8012 40s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,36,Errors,0,IRQreg,8012 41s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,37,Errors,0,IRQreg,8012 42s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,38,Errors,0,IRQreg,8012 43s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,39,Errors,0,IRQreg,8012 44s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,40,Errors,0,IRQreg,8012 45s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,41,Errors,0,IRQreg,8012 46s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,42,Errors,0,IRQreg,8012 47s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,43,Errors,0,IRQreg,8012 48s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,11dB,Length,23,Packets,44,Errors,0,IRQreg,8012 49s Hello World 1234567890*,CRC,DAAB,RSSI,-55dBm,SNR,13dB,Length,23,Packets,45,Errors,0,IRQreg,8012 50s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,12dB,Length,23,Packets,46,Errors,0,IRQreg,8012 52s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,47,Errors,0,IRQreg,8012 53s Hello World 1234567890*,CRC,DAAB,RSSI,-52dBm,SNR,2dB,Length,23,Packets,48,Errors,0,IRQreg,8012 54s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,49,Errors,0,IRQreg,8012 55s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,50,Errors,0,IRQreg,8012 56s Hello World 1234567890*,CRC,DAAB,RSSI,-55dBm,SNR,14dB,Length,23,Packets,51,Errors,0,IRQreg,8012 57s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,52,Errors,0,IRQreg,8012 58s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,53,Errors,0,IRQreg,8012 59s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,54,Errors,0,IRQreg,8012 60s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,55,Errors,0,IRQreg,8012 61s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,12dB,Length,23,Packets,56,Errors,0,IRQreg,8012 62s Hello World 1234567890*,CRC,DAAB,RSSI,-55dBm,SNR,14dB,Length,23,Packets,57,Errors,0,IRQreg,8012 63s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,58,Errors,0,IRQreg,8012 64s Hello World 1234567890*,CRC,DAAB,RSSI,-53dBm,SNR,4dB,Length,23,Packets,59,Errors,0,IRQreg,8012 65s Hello World 1234567890*,CRC,DAAB,RSSI,-53dBm,SNR,13dB,Length,23,Packets,60,Errors,0,IRQreg,8012 66s Hello World 1234567890*,CRC,DAAB,RSSI,-53dBm,SNR,12dB,Length,23,Packets,61,Errors,0,IRQreg,8012 67s Hello World 1234567890*,CRC,DAAB,RSSI,-53dBm,SNR,13dB,Length,23,Packets,62,Errors,0,IRQreg,8012 68s Hello World 1234567890*,CRC,DAAB,RSSI,-53dBm,SNR,13dB,Length,23,Packets,63,Errors,0,IRQreg,8012 69s Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,64,Errors,0,IRQreg,8012 70s Hello World 1234567890*,CRC,DAAB,RSSI,-53dBm,SNR,13dB,Length,23,Packets,65,Errors,0,IRQreg,8012 71s Hello World 1234567890*,CRC,DAAB,RSSI,-52dBm,SNR,13dB,Length,23,Packets,66,Errors,0,IRQreg,8012 72s Hello World 1234567890*,CRC,DAAB,RSSI,-49dBm,SNR,13dB,Length,23,Packets,67,Errors,0,IRQreg,8012So, an obvious thing to do would be to send an incrementing count in each transmitted package as a way to detect lost packets.
Interesting that it displays the SNR. AFAIK, this is the first chip I've wrong across which offers that up. It might be handy for identifying a clear channel. Or, less elegantly, one could just check to see if, based on time, an expected packet doesn't arrive. The one virtue in that is that it would require no code change at all.
-
If I put it further away, you can see that it does encounter either missing packets with the generic configuration and/or packets that are received but which fail CRC:
2374s Hello World 1234567890*,CRC,DAAB,RSSI,-85dBm,SNR,-2dB,Length,23,Packets,79,Errors,0,IRQreg,8012 2375s Hello World 1234567890*,CRC,DAAB,RSSI,-79dBm,SNR,14dB,Length,23,Packets,80,Errors,0,IRQreg,8012 2376s PacketError,RSSI,-77dBm,SNR,5dB,Length,23,Packets,80,Errors,1,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 2377s Hello World 1234567890*,CRC,DAAB,RSSI,-79dBm,SNR,12dB,Length,23,Packets,81,Errors,1,IRQreg,8012 2378s PacketError,RSSI,-79dBm,SNR,-9dB,Length,23,Packets,81,Errors,2,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 2381s PacketError,RSSI,-79dBm,SNR,12dB,Length,23,Packets,81,Errors,3,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 2382s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,-1dB,Length,23,Packets,82,Errors,3,IRQreg,8012 2383s PacketError,RSSI,-83dBm,SNR,12dB,Length,23,Packets,82,Errors,4,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 2384s Hello World 1234567890*,CRC,DAAB,RSSI,-80dBm,SNR,5dB,Length,23,Packets,83,Errors,4,IRQreg,8012 2385s PacketError,RSSI,-81dBm,SNR,-10dB,Length,23,Packets,83,Errors,5,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 2388s Hello World 1234567890*,CRC,DAAB,RSSI,-87dBm,SNR,-5dB,Length,23,Packets,84,Errors,5,IRQreg,8012 2390s Hello World 1234567890*,CRC,DAAB,RSSI,-75dBm,SNR,-1dB,Length,23,Packets,85,Errors,5,IRQreg,8012 2391s PacketError,RSSI,-78dBm,SNR,2dB,Length,23,Packets,85,Errors,6,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 2392s PacketError,RSSI,-73dBm,SNR,1dB,Length,23,Packets,85,Errors,7,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 2394s PacketError,RSSI,-76dBm,SNR,9dB,Length,23,Packets,85,Errors,8,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 2395s Hello World 1234567890*,CRC,DAAB,RSSI,-80dBm,SNR,8dB,Length,23,Packets,86,Errors,8,IRQreg,8012 2396s PacketError,RSSI,-77dBm,SNR,9dB,Length,23,Packets,86,Errors,9,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 2397s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,10dB,Length,23,Packets,87,Errors,9,IRQreg,8012 2398s PacketError,RSSI,-72dBm,SNR,1dB,Length,23,Packets,87,Errors,10,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 2399s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,10dB,Length,23,Packets,88,Errors,10,IRQreg,8012 2400s PacketError,RSSI,-79dBm,SNR,0dB,Length,23,Packets,88,Errors,11,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 2401s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,8dB,Length,23,Packets,89,Errors,11,IRQreg,8012 2402s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,13dB,Length,23,Packets,90,Errors,11,IRQreg,8012 2404s Hello World 1234567890*,CRC,DAAB,RSSI,-84dBm,SNR,-9dB,Length,23,Packets,91,Errors,11,IRQreg,8012 2405s Hello World 1234567890*,CRC,DAAB,RSSI,-73dBm,SNR,2dB,Length,23,Packets,92,Errors,11,IRQreg,8012 2408s Hello World 1234567890*,CRC,DAAB,RSSI,-81dBm,SNR,-7dB,Length,23,Packets,93,Errors,11,IRQreg,8012 2409s PacketError,RSSI,-71dBm,SNR,-3dB,Length,23,Packets,93,Errors,12,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 2410s Hello World 1234567890*,CRC,DAAB,RSSI,-73dBm,SNR,-1dB,Length,23,Packets,94,Errors,12,IRQreg,8012 2411s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,10dB,Length,23,Packets,95,Errors,12,IRQreg,8012 2412s Hello World 1234567890*,CRC,DAAB,RSSI,-75dBm,SNR,8dB,Length,23,Packets,96,Errors,12,IRQreg,8012 2413s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,11dB,Length,23,Packets,97,Errors,12,IRQreg,8012 2414s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,9dB,Length,23,Packets,98,Errors,12,IRQreg,8012 2415s PacketError,RSSI,-76dBm,SNR,12dB,Length,23,Packets,98,Errors,13,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 2416s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,12dB,Length,23,Packets,99,Errors,13,IRQreg,8012 2417s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,13dB,Length,23,Packets,100,Errors,13,IRQreg,8012 2418s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,13dB,Length,23,Packets,101,Errors,13,IRQreg,8012I'll have to take a closer look at the transmitter settings to see how they might be improved. My guess is that out-of-the-box, all the settings are turned way down for when people are setting up their first nodes. As pictured in the Andreas Spiess video, there is a LoRa calculator which helps with configuration and which can compute the corresponding link budget.
Also, I'm guessing that the trace antenna is directional, so maybe that's partly why Andreas switched to an external antenna. I think Adreas is a good youtuber with interesting content, but there's no denying that he glosses over quite a lot, perhaps to keep his audience's interest by just hitting the highlights.
Also, the SNR is all over the map,, so maybe interference really is a factor that needs to be considered, even with LoRa. We shall see. Anyway, that's why I'm testing using cheap breadboard prototypes before going all-in. If there's bad news, I'd rather find it early than late!
There could be all manner of reasons for packet failures with the generic settings, including some which are not deal-killers in themselves: use of the breadboard itself, the long wires on the breadboard, possible noise from the power supply I'm currently using, noise from the computer that's connected to it for reading the text output, etc. Perhaps the Ebyte modules themselves are defective? That would explain the deep discount at which I acquired them. Who knows. So, I'll do as Andreas did, which is go for the highest possible link budget. If I'm still getting errors after that, then surely it's some other factor than the SX1280 chip itself that's causing the problem.
-
Reporting back: it turns out that the trace antennas are highly directional, and changing the orientation on just one of them can remove 20 to 30dBa from the link budget, which is significant. I'm not sure why that is, as ESP8266's have a similar design and yet don't seem to be as sensitive to orientation. Therefore, putting an omni directiona antenna on at least the receiving node would seem to make a lot of sense.
Furthermore, the default settings used by the library appear to yield a link budget of just 123dB:
which is good for a meh transceiver, but not especially awesome for a LoRa transceiver. With such a meh link budget, it's easy to see how a poorly orientated trace antenna could severely impair the packet error rate.However, by increasing the spreading factor to 12 and narrowing the bandwidth to 200khz, it's possible to add roughly another 20dB to the link budget:
However, a big downside to this approach is that the transmission time incrases to nearly 1 second, which is a considerable energy drain. Also, the calculator only allows a max transmission power of 12.5dBm, which is well become the module;s advertised maximum transmit power. So,it has me wondering now whether some other register or pin needs to be touched in order to arrive at maximum transmission power. Presumably the SX1280 chip itself has a maximum transmit power of 12.5dBm, and further power would come from activating a power-amplifier on the module, similar to the way the RFM69 module works. However, looking at the manual, this is not the case. Rather, it appears that both the PA and the LNA are permanently activated, and it recommends setting the output power of the SX1280 to 0dBm, at which time the effective output power is 27dBm.So, I do that, and increase the spreading factor to 12, and decrease the bandwidth to 203kHz, but the overall performance is still lackluster. That the power output doesn't seem to be obviously easy to adjust is a disappointment. Overall performance falls far below what the 400Mhz AI-Thinker module can achieve, and those modules are very inexpensive (around $1-2 each).
So.... I'm disappointed. They perform far worse than even the el cheapo NRF24L01 modules that are outfitted with PA + LNA, which operate in the same 2.4Ghz band. This should not be! I'll try them next with some 2.4Ghz pigtail dipole antennas and see whether or not that yields significant improvement, even though it undermines the economics of choosing these modules in the first place. If that also fails, then I'm not sure it's worth the time, money, and effort to troubleshoot it further, especially since Andreas Spiess also wasn't sanguine about his different model 2.4Ghz Ebyte LoRa module either.
The nice thing about the Ai-Thinker LoRa modules is that they very easily accomodate a wire whip antenna (which are super cheap), whereas these Ebyte modules rely on either the trace antenna (which I now know to be problematic because of its apparent directional sensitivity) or on an IPEX connector, which increases the BOM's antenna price.
[Edit: I've changed out the power supplies for battery power. No change. I've removed the receiver from the PC, and no change either. Therefore, it either is the antenna, the breadboard wiring, the Ebyte module itself which is at fault, or else interference in the 2.4Ghz band is too much for these LoRa modules to handle (which would be weird, because 2.4Ghz Wi-Fi seems to work well enough, so go figure). I should receive some IPEX antennas this Thursday to try out, and if that doesn't solve it, then I'm going to build something equivalent with RA-01SH 915Mhz LoRa modules by AI-Thinker and see if that breadboard setup is dramatically better or not. Those modules cost around $3 each on Aliexpress ].
-
Reporting back: it turns out that the trace antennas are highly directional, and changing the orientation on just one of them can remove 20 to 30dBa from the link budget, which is significant. I'm not sure why that is, as ESP8266's have a similar design and yet don't seem to be as sensitive to orientation. Therefore, putting an omni directiona antenna on at least the receiving node would seem to make a lot of sense.
Furthermore, the default settings used by the library appear to yield a link budget of just 123dB:
which is good for a meh transceiver, but not especially awesome for a LoRa transceiver. With such a meh link budget, it's easy to see how a poorly orientated trace antenna could severely impair the packet error rate.However, by increasing the spreading factor to 12 and narrowing the bandwidth to 200khz, it's possible to add roughly another 20dB to the link budget:
However, a big downside to this approach is that the transmission time incrases to nearly 1 second, which is a considerable energy drain. Also, the calculator only allows a max transmission power of 12.5dBm, which is well become the module;s advertised maximum transmit power. So,it has me wondering now whether some other register or pin needs to be touched in order to arrive at maximum transmission power. Presumably the SX1280 chip itself has a maximum transmit power of 12.5dBm, and further power would come from activating a power-amplifier on the module, similar to the way the RFM69 module works. However, looking at the manual, this is not the case. Rather, it appears that both the PA and the LNA are permanently activated, and it recommends setting the output power of the SX1280 to 0dBm, at which time the effective output power is 27dBm.So, I do that, and increase the spreading factor to 12, and decrease the bandwidth to 203kHz, but the overall performance is still lackluster. That the power output doesn't seem to be obviously easy to adjust is a disappointment. Overall performance falls far below what the 400Mhz AI-Thinker module can achieve, and those modules are very inexpensive (around $1-2 each).
So.... I'm disappointed. They perform far worse than even the el cheapo NRF24L01 modules that are outfitted with PA + LNA, which operate in the same 2.4Ghz band. This should not be! I'll try them next with some 2.4Ghz pigtail dipole antennas and see whether or not that yields significant improvement, even though it undermines the economics of choosing these modules in the first place. If that also fails, then I'm not sure it's worth the time, money, and effort to troubleshoot it further, especially since Andreas Spiess also wasn't sanguine about his different model 2.4Ghz Ebyte LoRa module either.
The nice thing about the Ai-Thinker LoRa modules is that they very easily accomodate a wire whip antenna (which are super cheap), whereas these Ebyte modules rely on either the trace antenna (which I now know to be problematic because of its apparent directional sensitivity) or on an IPEX connector, which increases the BOM's antenna price.
[Edit: I've changed out the power supplies for battery power. No change. I've removed the receiver from the PC, and no change either. Therefore, it either is the antenna, the breadboard wiring, the Ebyte module itself which is at fault, or else interference in the 2.4Ghz band is too much for these LoRa modules to handle (which would be weird, because 2.4Ghz Wi-Fi seems to work well enough, so go figure). I should receive some IPEX antennas this Thursday to try out, and if that doesn't solve it, then I'm going to build something equivalent with RA-01SH 915Mhz LoRa modules by AI-Thinker and see if that breadboard setup is dramatically better or not. Those modules cost around $3 each on Aliexpress ].
-
@NeverDie in addition to the energy drain, the module would be transmitting for longer than the 400ms FCC dwell time limit.
@mfalkvidd Good catch! I'll take your word for it. Thank you!
Reporting back: I found a critical error. The library defaults to leaving the TX_EN and RX_EN pins disconnected. However, this module has a PA and LNA, so it is relevant to it. Since my first attempt merely followed the wiring instructions in the library, I had failed to enable these pins. Now that I have, it's a big improvement.
-
Thanks to feedback from @mfalkvidd, I've constructed this as the new target:
The directional sensitivity of the trace antenna is still a problem, so it'll have to wait until this Thursday, when the dipole antenna drives, to see whether the latest revision will be good enough or not.
