Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?

[NeverDie]

@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.

[ejlane]

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.

[Larson]

@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.

[ejlane]

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]

@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!

[ejlane]

@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.)

[NeverDie]

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!

[NeverDie]

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

[NeverDie]

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=JYThKZCflJc

Small 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).

[NeverDie]

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

[NeverDie]

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.

[Larson]

@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]

@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.

[NeverDie]

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,8012

So, 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.

[NeverDie]

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,8012

I'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.

[NeverDie]

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 ].

[mfalkvidd]

@NeverDie in addition to the energy drain, the module would be transmitting for longer than the 400ms FCC dwell time limit.

[NeverDie]

@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.

[NeverDie]

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.

[mfalkvidd]

@NeverDie I am unable to find a better FCC reference than https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/fcc-rules-for-frequency-hopping/msg16006/?PHPSESSID=6e7efa8daee6de15d09c2b954879be34#msg16006 but that reference says:

The maximum allowed 20 dB bandwidth of the hopping channel is 500 kHz.

Since the module is now using 1,625 kHz bandwidth, it is again outside FCC rules.