Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?
-
Reporting back: Today I received proper IPEX to RP-SMA connector cable. I hooked up both the transmitter and receiver using them to the factory recommended 2.4ghz antennas. The transmitter and receiver are two rooms apart, and the signal has to pass through two closed doors. What I'm getting doesn't look great:
4s PacketError,RSSI,-74dBm,SNR,-4dB,Length,23,Packets,0,Errors,1,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 7s PacketError,RSSI,-79dBm,SNR,-15dB,Length,23,Packets,0,Errors,2,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 9s PacketError,RSSI,-77dBm,SNR,-11dB,Length,23,Packets,0,Errors,3,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 12s PacketError,RSSI,-73dBm,SNR,-1dB,Length,23,Packets,0,Errors,4,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 13s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,-6dB,Length,23,Packets,1,Errors,4,IRQreg,8012 14s PacketError,RSSI,-79dBm,SNR,-8dB,Length,23,Packets,1,Errors,5,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 16s PacketError,RSSI,-78dBm,SNR,-4dB,Length,23,Packets,1,Errors,6,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 18s PacketError,RSSI,-82dBm,SNR,-17dB,Length,23,Packets,1,Errors,7,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 26s PacketError,RSSI,-80dBm,SNR,-22dB,Length,23,Packets,1,Errors,8,IRQreg,8020,IRQ_HEADER_ERROR,IRQ_PREAMBLE_DETECTED 28s PacketError,RSSI,-79dBm,SNR,-9dB,Length,23,Packets,1,Errors,9,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 31s PacketError,RSSI,-85dBm,SNR,-19dB,Length,23,Packets,1,Errors,10,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 32s PacketError,RSSI,-83dBm,SNR,-7dB,Length,23,Packets,1,Errors,11,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 35s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,-8dB,Length,23,Packets,2,Errors,11,IRQreg,8012 37s PacketError,RSSI,-82dBm,SNR,-15dB,Length,23,Packets,2,Errors,12,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 50s Hello World 1234567890*,CRC,DAAB,RSSI,-81dBm,SNR,-17dB,Length,23,Packets,3,Errors,12,IRQreg,8012 51s Hello World 1234567890*,CRC,DAAB,RSSI,-81dBm,SNR,-12dB,Length,23,Packets,4,Errors,12,IRQreg,8012 54s PacketError,RSSI,-79dBm,SNR,-4dB,Length,23,Packets,4,Errors,13,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 57s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,-6dB,Length,23,Packets,5,Errors,13,IRQreg,8012 60s PacketError,RSSI,-78dBm,SNR,-14dB,Length,23,Packets,5,Errors,14,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 62s Hello World 1234567890*,CRC,DAAB,RSSI,-75dBm,SNR,-6dB,Length,23,Packets,6,Errors,14,IRQreg,8012 67s PacketError,RSSI,-84dBm,SNR,-20dB,Length,23,Packets,6,Errors,15,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 69s PacketError,RSSI,-78dBm,SNR,-12dB,Length,23,Packets,6,Errors,16,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 72s Hello World 1234567890*,CRC,DAAB,RSSI,-77dBm,SNR,-11dB,Length,23,Packets,7,Errors,16,IRQreg,8012 76s PacketError,RSSI,-79dBm,SNR,-13dB,Length,23,Packets,7,Errors,17,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 78s Hello World 1234567890*,CRC,DAAB,RSSI,-79dBm,SNR,-12dB,Length,23,Packets,8,Errors,17,IRQreg,8012 80s Hello World 1234567890*,CRC,DAAB,RSSI,-76dBm,SNR,-7dB,Length,23,Packets,9,Errors,17,IRQreg,8012 83s PacketError,RSSI,-75dBm,SNR,-7dB,Length,23,Packets,9,Errors,18,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 86s PacketError,RSSI,-78dBm,SNR,-6dB,Length,23,Packets,9,Errors,19,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 103s PacketError,RSSI,-76dBm,SNR,-18dB,Length,23,Packets,9,Errors,20,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 105s PacketError,RSSI,-81dBm,SNR,-18dB,Length,23,Packets,9,Errors,21,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 108s PacketError,RSSI,-79dBm,SNR,-3dB,Length,23,Packets,9,Errors,22,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTED 109s Hello World 1234567890*,CRC,DAAB,RSSI,-78dBm,SNR,-3dB,Length,23,Packets,10,Errors,22,IRQreg,8012 110s Hello World 1234567890*,CRC,DAAB,RSSI,-79dBm,SNR,-6dB,Length,23,Packets,11,Errors,22,IRQreg,8012 112s PacketError,RSSI,-78dBm,SNR,-3dB,Length,23,Packets,11,Errors,23,IRQreg,8052,IRQ_RX_DONE,IRQ_HEADER_VALID,IRQ_CRC_ERROR,IRQ_PREAMBLE_DETECTEDI think maybe the breadboard construction and long wires are introducing too much unwanted signals, resulting in lowered performance. The only way I can think of to get rid of that would be to make a specialty PCB that puts an atmega328p in close proximity with the module, so that there aren't long wires or long traces to pick up noise along the way.Or, maybe it's something else. In any case, I'm going to pause this and switch-over to a 915Mhz AI-Thinker module to see whether I get more traction there. -
Re-thinking this, probably the easiest way to exclude whether or not the breadboarding and related wiring is a crippling source of noise would be to create a PCB that an Arduino Pro Mini can dock with and which makes all the needed connections directly to the E28-2G4M27S. It's so easy that I should have thought of it in the first place! I have started work on it, and I'll post a rendering when its ready. I may post it in openhardware.io, and I think I may take a similar approach to future breakout boards as well. Pro-mini's are so cheap that it will make for a good way to test different radio modules.
-
What happened to prices? I checked just now and pro mini's are selling for $5+. Pre-pandemic they could be had for closer to $1.
-
What happened to prices? I checked just now and pro mini's are selling for $5+. Pre-pandemic they could be had for closer to $1.
@NeverDie Haven't you heard of the chip shortage? It's changed everything, and prices for those things that are even available have generally gone up. (Though somehow magically, the ESP32 seems to be pretty much untouched. You can still buy them, and prices have been relatively stable. I don't know how they've done it.) AVR, PIC, STM chips have all been hard to get specific models, and at times any model that has the features. I expect other brands were similar, but those are the ones that I've looked for.
I hope they someday go back, but for the foreseeable future, expect it to be like this.
Pro minis for close to $1 was always a shock, since even at 1k qty, just the chip itself costs more than that. So to get to that price for the whole assembled board, there must be some kind of gray-market thing going on. If I were to try to make a profit on 1k at a time, assembled and everything, I'm pretty sure the final price would have to be in the ballpark of $10 each.
-
@NeverDie Haven't you heard of the chip shortage? It's changed everything, and prices for those things that are even available have generally gone up. (Though somehow magically, the ESP32 seems to be pretty much untouched. You can still buy them, and prices have been relatively stable. I don't know how they've done it.) AVR, PIC, STM chips have all been hard to get specific models, and at times any model that has the features. I expect other brands were similar, but those are the ones that I've looked for.
I hope they someday go back, but for the foreseeable future, expect it to be like this.
Pro minis for close to $1 was always a shock, since even at 1k qty, just the chip itself costs more than that. So to get to that price for the whole assembled board, there must be some kind of gray-market thing going on. If I were to try to make a profit on 1k at a time, assembled and everything, I'm pretty sure the final price would have to be in the ballpark of $10 each.
@ejlane & @NeverDie: Amazing technology that was available for $1 was … too hard to believe. Even $5 for a ProMini is pretty mind-blowing. Not that I buy commodities, I do buy these components a dozen at a time to save on shipping even when it is ‘free’. I laugh at myself when I spend a week of my time on a $2 chip and then wonder how I can rework it from a PCB (never worth the attempt). Compared to any other hobby or habit this radio-electronic stuff is cheaper than cooking top-ramen at home.
BTW, thanks for the radio discussion posted last week. I will read and learn later. -
Here's the schematic for what I have in mind:

Thinking about it more, I don't think it makes sense to post it to openhardware.io until I've proven that it provides a big improvement over the breadboard, because if it turns out that it isn't an improvement, it might be drawing attention away from more worthy projects.
Anyhow, I'll most likely use a similar method for building a test setup for the 915Mhz Thinker-AI radio, as it's ultimately more robust and less clumsy than breadboarding. In the meantime though I'll be breadboarding some old school 915Mhz LoRa modules to see whether going down that path is likely to bear fruit or not.
-
So as to have a point of comparison, I today hooked up some old school SX1276 915Mhz LoRa modules (based on an Adafruit breakout board: https://www.adafruit.com/product/3072?gclid=EAIaIQobChMIxJm5r6-w9wIV_WxvBB0GjwCCEAQYASABEgLRofD_BwE ), and the difference is like night and day in performance:

At the same distance as with previous tests, it works 100% flawlessly:377s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,10dB,Length,23,Packets,108,Errors,0,IRQreg,50 378s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,9dB,Length,23,Packets,109,Errors,0,IRQreg,50 379s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,10dB,Length,23,Packets,110,Errors,0,IRQreg,50 381s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,10dB,Length,23,Packets,111,Errors,0,IRQreg,50 382s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,10dB,Length,23,Packets,112,Errors,0,IRQreg,50 383s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,9dB,Length,23,Packets,113,Errors,0,IRQreg,50 384s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,9dB,Length,23,Packets,114,Errors,0,IRQreg,50 385s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,9dB,Length,23,Packets,115,Errors,0,IRQreg,50 386s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,9dB,Length,23,Packets,116,Errors,0,IRQreg,50 387s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,9dB,Length,23,Packets,117,Errors,0,IRQreg,50 388s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,9dB,Length,23,Packets,118,Errors,0,IRQreg,50 389s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,9dB,Length,23,Packets,119,Errors,0,IRQreg,50 390s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,9dB,Length,23,Packets,120,Errors,0,IRQreg,50 391s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,9dB,Length,23,Packets,121,Errors,0,IRQreg,50 392s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,9dB,Length,23,Packets,122,Errors,0,IRQreg,50 394s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,10dB,Length,23,Packets,123,Errors,0,IRQreg,50 395s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,9dB,Length,23,Packets,124,Errors,0,IRQreg,50 396s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,9dB,Length,23,Packets,125,Errors,0,IRQreg,50 397s Hello World 1234567890*,CRC,DAAB,RSSI,-75dBm,SNR,10dB,Length,23,Packets,126,Errors,0,IRQreg,50 398s Hello World 1234567890*,CRC,DAAB,RSSI,-71dBm,SNR,10dB,Length,23,Packets,127,Errors,0,IRQreg,50 399s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,10dB,Length,23,Packets,128,Errors,0,IRQreg,50 400s Hello World 1234567890*,CRC,DAAB,RSSI,-73dBm,SNR,9dB,Length,23,Packets,129,Errors,0,IRQreg,50 401s Hello World 1234567890*,CRC,DAAB,RSSI,-75dBm,SNR,9dB,Length,23,Packets,130,Errors,0,IRQreg,50 402s Hello World 1234567890*,CRC,DAAB,RSSI,-74dBm,SNR,10dB,Length,23,Packets,131,Errors,0,IRQreg,50which, quite frankly, is what I had been expecting from the 2.4GHz modules. Notice that these are also on breadboards, yet the SNR is vastly superior to what the Ebyte modules were reporting. So, although I can't yet say so definitively, I'm starting to suspect that there's something wrong with the Ebyte 2.4Ghz LoRa modules that I received. If I had a couple 2.4Ghz LoRa modules from a different manufacturer, it might tell the tale. As it stands, it doesn't much matter the reason, since performance at 915Mhz is so much better.
I'll next try running the Ebyte modules direct from two AA batteries. If there's noise in the present power supplies, that should remove it. I've already put decoupling caps on the radio module, but I could also do the same with the Arduino Pro Mini. Sooner or later we'll find the culprit. If worse comes to worst, I'll fabricate this low noise test board and try it with that:

-
Semtech did write a paper analyzing possible interference between the SX1280 LoRa and WiFi. Here is the conclusion:

Not exactly sure what it means. Looks as though it doesn't have as much immunity to 802.11n as to 802.11g, which is maybe(?) a problem given how common 802.11n is these days. Reducing bandwidth and increasing spreading factor are the recommended workarounds. Unfortunately, all my neighbors have wi-fi, so finding unused spectrum, or with low enough signal, may not be feasible at 2.4Ghz.
Come to think of it, I do have a dual-band meshed wi-fi network at home. I hadn't thought I needed tri-band, but this might be a case where backhauling over that third band, or possibly ethernet, might knock down some of the wi-fi generated "noise" in the 2.4Ghz spectrum. If this turns out to be part of the issue, then, indeed, going to 915Mhz instead would be a lot easier solution.
-
One more reason for preferring 915Mhz over 2.4Ghz: The SX1262 (915Mhz) has a receive sensitivity of -148dBm, whereas the SX1280 (2.4Ghz) is only -132dBm. I hadn't realized the gap was so large. All by itself that's an appreciable difference. I suspect that to cash-in on all the potential receive sensitivity, it may require a TCXO, but I'd have to look that up to be sure. Now granted, external PA's and LNA's might be employed, but as far as the chips themselves, the max transmit power on the SX1280 is 12.5dBm, whereas on the SX1262, it's 22dBm, so at the chip level the SX1262 is more capable on the transmit side by a considerable degree.
Comparing the SX1262 to the SX1276 (Adafruit that I tested today), the receive sensitivities are the same. The SX1276 has a max Tx power of 20dBm, so the SX1262's 22dBm transmit power is only just a little better. The SX1262 may be more energy efficient, but in terms of raw link budget, it's almost the same as the SX1276. So, for some applications, such as gateways, using SX1276 chips/modules might make sense if they're cheaper. However, looking at current market pricing, they don't appear to be. Strange.
-
Reporting back: I tried running both transceivers off of two AA's with decoupling capacitors and... no change. I also tried varying the location, in case there was a strong local interference source. No change. Again, to recap: RSSI seems good, but SNR seems bad. So, the next thing left to try is the low noise PCB I pictured above. I'll do that, but fabrication will have to wait until I have other PCB's ready to be fabbed as well so as to save on shipping by combining the orders, because at this point getting these Ebyte SX1280 modules to work satisfactorily is looking more and more like a long shot. :disappointed: Given that Andreas Spiess was also not particularly sanguine about his Ebyte SX1280 LoRa modules, I suspect the blame may lay with the modules. Anyhow, it's becoming academic, because I'm moving on to 915Mhz LoRa, since from what I've seen firsthand so far that seems much more robust, and on paper an SX1262 or SX1276 handily outperforms an SX1280.
-
@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 Hi, I've just started playing with a pair of these modules that I've had kicking around for a while. Fascinating thread and I haven't finished reading through yet, thanks for being so thorough!
I'm using the same library. When it comes to enabling the TX_EN and RX_EN pins, can you clarify how? Is it done through the microcontroller script, or by setting the pin inputs to high (+3.3v)?
-
@NeverDie Hi, I've just started playing with a pair of these modules that I've had kicking around for a while. Fascinating thread and I haven't finished reading through yet, thanks for being so thorough!
I'm using the same library. When it comes to enabling the TX_EN and RX_EN pins, can you clarify how? Is it done through the microcontroller script, or by setting the pin inputs to high (+3.3v)?
@samh For the receiver node, I simply wired RX_EN to 3.3V and TX_EN to GND. For the transmitter module, I found that wiring TX_EN direcctly to 3.3V doesn't work so well (probably too high a duty cycle for the PA to be operating continuously like that), so I instead wired TX_EN to a spare pin and I modified the code so as to drive that pin HIGH just prior to transmitting and drive it to LOW when done transmitting. Also, on the transmitter node I wired RX_EN to ground. This seemed to work. However, it reminds me now that this was really just improvisation on my part for expediency in getting something setup fast.. Perhaps I should be using pull-up and/or pull-down resistors instead. Thanks for bringing up this topic! I'll investigate further. Please do post what you end up using youself, as well as whether you are getting similar or different results regarding noise (SNR) and/or range.
-
Reporting back: It turns out that in the settings.h file, you can assign pins for TX_EN and RX_EN. I assigned Arduino pin 4 for TX_EN and pin 5 for RX_EN, and it works fine.
I also inserted 10K resistors as a "just in case". I also increased TX_POWER to 10.
I'm not sure which of the 3 changes made the most difference, but the result is noticeable improvement. SNR is still reported as low., but I am now getting reliable longer range than previously. Maybe SNR is just not measured accurately by the module?
IIRC, the module has two forms of integrated step-down within the chip: an LDO and a buck converter. Not sure which one the library defaults to (I'll have to look it up) but if it's the buck, then switching over to the LDO might help with the SNR.
[Edit: I just now checked, and the library defaults to using the LDO rather than the buck converter]
-
Last update: I changed frequencies to 2.42Ghz, and SNR became a bit better, so maybe interference in the 2.4Ghz band really does play a role. It still performs much worse than the 915Mhz LoRa nodes I i discussed above however. At this point the next noticeable improvement, if anything, probably won't happen until I fab the custom low noise PCB which I showed above.
-
Thanks for letting me know, I'm going to play around with these over the weekend and I'll try to report back. Not too bothered about getting optimal performance since it's my first time messing with RF specifically in an arduino project, just want to do some basic testing. Some 868 modules are for sure on my list to check out next
-
Thanks for letting me know, I'm going to play around with these over the weekend and I'll try to report back. Not too bothered about getting optimal performance since it's my first time messing with RF specifically in an arduino project, just want to do some basic testing. Some 868 modules are for sure on my list to check out next
-
Regarding the 915Mhz SX1262, the Dorji brand seems interesting. They sell two different module types: one, the DRF1262T, with a TCXO at 1ppm, and one, the DRF1262G, with a non-TCXO crystal (uses less power) which they say is 10ppm. They also have a breakout board for Arduino Uno to facilitate testing:
https://www.ebay.com/itm/192665058568
https://www.ebay.com/itm/202574135410
https://www.ebay.com/itm/202436579399So, in addition to the AI-Thinker Ra-01SH modules, I've ordered some of these DRF1262T/G to compare performance. Hopefully at least one of the three different models will be a winner.
-
Last update: I changed frequencies to 2.42Ghz, and SNR became a bit better, so maybe interference in the 2.4Ghz band really does play a role. It still performs much worse than the 915Mhz LoRa nodes I i discussed above however. At this point the next noticeable improvement, if anything, probably won't happen until I fab the custom low noise PCB which I showed above.
@NeverDie, Thanks again for all the blogging on this subject. If you have not yet ordered your custom low-noise PCB, I had one design idea. If you flip the ProMini orientation end over end most of the traces will be shorter, especially the RX/TX lines. I’ve not examined the code, but I’d think that the RX/TX connections have the most signal activity on the board, thus EMI potential. I like how you keep all the traces on one side. That should solve the interrupted ground-plane problem we learned from Rick Hartley above.
It is far more fun to roll-your-own. Alternatively, I was thinking … I just checked the Moteino breakout boards from Felix at LowerPowerLabs to see if those would work with your Ebyte radios: too bad, different pinout. I just bought a few Moteinos (915 mhz) boards to save myself from my low-quality solder jobs and shaky hands – only $13 but I have to add my own radio or spend another $7. Everything I've seen from LowPowerLabs has been high quality.
-
I've finally made a little progress over the last two days. Lots of background reading on the excellent SX12XX library and some tinkering to make a portable radio modem for future testing
Here's the transmit end soldered up to a little bit of prototyping board I had lying around, which it turned out was the perfect size to fit the E28+breakout, Arduino Pro Mini, and voltage reg! All powered off a tiny 2S LiPo at the moment. The antennas are external Happymodel ELRS-intended and are supposedly 5dB...


The voltage divider is included for battery monitoring. I modified the 'varying power' library examples (numbers 10/20) to include sending one battery voltage packet per test and print serial bytes in a slightly more interpretable format for a python script to read and save to csv.
Just as a proof of concept, I looked at how RSSI/SNR vary with Tx power and RF attenuation, see below:
- TC1 = line of sight, 3-4m separation
- TC2 = as TC1 but cross-polarised antennas
- TC3 = several brick walls of attenuation
- TC4 = as TC3 but cross-polarised antennas
(and yes, the axes are intentionally the wrong way around since it's easier to fit the plots on a horizontal screen this way!)

Clearly something is working right as RSSI drops off linearly with Tx power! SNR performance leaves a bit to be desired but seems that @NeverDie had similar results. Not very exciting but showing the setup is correct for now and I can move on to some more interesting things.
Next up is to have a look at implementing the PA/LNA on the E28 modules and seeing what kind of difference I get in performance. Spotted the RX/TX_EN pins in the library documentation so I'll give those a go
-
@NeverDie, Thanks again for all the blogging on this subject. If you have not yet ordered your custom low-noise PCB, I had one design idea. If you flip the ProMini orientation end over end most of the traces will be shorter, especially the RX/TX lines. I’ve not examined the code, but I’d think that the RX/TX connections have the most signal activity on the board, thus EMI potential. I like how you keep all the traces on one side. That should solve the interrupted ground-plane problem we learned from Rick Hartley above.
It is far more fun to roll-your-own. Alternatively, I was thinking … I just checked the Moteino breakout boards from Felix at LowerPowerLabs to see if those would work with your Ebyte radios: too bad, different pinout. I just bought a few Moteinos (915 mhz) boards to save myself from my low-quality solder jobs and shaky hands – only $13 but I have to add my own radio or spend another $7. Everything I've seen from LowPowerLabs has been high quality.
@samh Great stuff! I look forward to hearing more. As you probably know, the buck/boost converter (whichever it is) that's in your photo is a possible source of noise. I can't say whether, in reality, it would be or not. That's one of the reasons why (below), I'm planning to run directly from batteries only.
@Larson Good suggestions. I decided to dump the pro mini idea and just make my own barebones pro mini, because pro mini's come with three things that aren't useful and actually get in the way: 1. the LDO, 2. the oscillator, and 3. the LED on pin 13. I'm hoping (but haven't confirmed) that by eliminating the oscillator on pins D20 and D21, I can use those pins to drive two LED's kinda "for free" since nobody uses those pins for anything. So, the first draft looked like this:

to get the shortest possible lines, like you said. It also includes a TPL5010 as an ultra low current wakeup timer. The main thing, though, is that it runs from two AA batteries, which are directly attached to the PCB itself. Well, this design was working out fine, but it seemed a bit tedious to redo it for each possible radio I wanted to test, so I think I'm settling on this instead as a test platform:

which amounts to a stripped down pro mini (plus two I2C pinsout at the bottom for plugging in a TH sensor, or whatnot). In this case, the idea is to do a simple breakout board for each radio and connect it as a shield to the unused pins on the atmega328p. I figure it should be easier than doing a complete, fully integrated board for each radio. And I like that it's of minimal size (the footprint of two AA batteries), yet packs enough power that I expect it should have no trouble supplying even 200ma if needed just from the batteries themselves.I'm lucky in that I have a Dragon programmer, so I can both burn the bootloader and set the fuses on the atmega328p prior to soldering it into place on the PCB. From past experience, the sleep current on the atmega328p itself can be as low as 100na. In the past when Pro Mini's sold for only a buck, I leaned toward using Pro Mini's for everything. These days I guess I'll roll my own.
I think eventually I want to replace the canonical 6 pin FTDI connection with a 5 pin picoblade. I've only just started looking into that. I was favoring the idea of using 1.0mm pitch JST-SH conectors for the task, but sourcing them didn't look easy. So, I'm reluctantly settling on the 1.25mm pitch picoblade instead. If there exists something even more compact (maybe some kind of 2x3 row of pins on a connector), then I'd be keen to hear what it is.
The AA battery connectors are the Keystone 92, which look like this:

In the end, it might look like an improved variation of one of these:
https://www.openhardware.io/view/395/LoRa-Ra-01-ATmega328P-Node
https://www.openhardware.io/view/268/Arduino-Pro-Mini-Shield-for-RFM69HW
https://www.openhardware.io/view/480/Compact-nRF24L01-Pro-Mini-Bottom-Shield
but this time a bit more of a general purpose razor and blades system, if you catch my meaning. This time it will be a little wider than a pro mini, so it will be possible to fit any radio onto the shield. That said, I always liked the simplicity and ease of assembly of the "LoRa Ra-01 ATmega328P node". Perhaps the biggest improvement is the tight integration of the batteries, which in most designs are left "flapping in the breeze" as an afterthought for the builder to sort out.Anyhow, I have a bit more work to do, but that's the current evolution. As always, any thoughts, reactions, suggestions, or feedback appreciated.