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

[Larson]

@NeverDie. You are way out there, man! Thanks to the references to the other boards made by you. What fantastic contributions to the maker market.
I suppose D20 and D21 are the same as PCINT6/XLTAL1 and PCINT7/XTAL2? I once reassigned RX and TX on an Attiny85 to RX and TX (edit: output functions) as I was pin limited. It took some doing, but that is the beauty of these multifunction pin assignments. The code, if I remember, had to be in the loop after a delay in the setup; that gave me a way to access the RX/TX pins again to reprogram if necessary. Maybe there are similar challenges with bypassing the crystal.
@samh. So you are setting power levels on the fly. Very clever.

[NeverDie]

@samh My first reaction is that your SNR is better than mine, especially for the measurements of going through several brick walls--though it's a bit hard to read the TC1-4 symbols when they're printed over one another, so I'm not completely sure. Since you also have some longish wires, I wouldn't be at all surprised if the cheap breadboards I used are, in one manner or another, impairing my SNR. This is where comparing notes can really be helpful. Thanks!

Despite China's lockdown, it looks as though my Ra-01SH modules may be here before long, so I want to get my test PCB orders in soon!

Looking forward to finally having a single test bed for comparing the performance of different radios modules! i.e. the only thing to change from one test to another will be the radio (and possibly software). For instance, it will be nice to know that when the bits "absolutely, positively, have to get there", which radio can do it reliably but also with the least amount of total energy? I mean, LoRa has the promise of great range, but the transmission time can be so long that may come at a pretty high energy price.... unless maybe the link budget allows the Tx power to be hugely reduced. That's what I'd very much like to know. i.e. which is ultimately better, if the figure of merit is energy spent per successfully delivered bit? FSK or LoRa? Or something else? Probably somebody out there in industry or the military or in academia has studied this question using the best equipment (or at least simulations) and published about it, but nothing beats real empirical results from whatever gear you have in your actual hands--because at the end of the day that's all you have to work with anyway. The cool thing is that the Semtech chips can do both FSK and LoRa, so you have the option to choose whatever best fits the situation, or switch back and forth depending on changing conditions. Ask near as I can tell, the FSK component of the Semtech LoRa radio chips is, essentially, an improved form of the RFM69's radio (which is also made by Semtech). My guess is that if you can get your packets delivered at 2mbps using an NRF24L01 (or equivalent NRF5x), then that's going to be the most energy efficient delivery method. But, if that doesn't work reliably enough, what's your next best option to get your bits delivered, and your next best option after that, etc.? And it's not just that: you need to compare sleep current consumption and wake-up times as well. Fun fact: when in the past I ran the numbers for mostly sleeping sensor devices, most often it's the sleep current consumption that dominates.

[NeverDie]

@ejlane said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

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

When is this chip shortage supposed to end? I thought the prices for atmega328pb's on mouser were reasonable enough, but then I just now noticed they weren't expected to be in stock until March 2023! LOL. Matter of fact, Mouser doesn't have any atmega328p's of any kind in stock at all. Unfortunately, as near as I can tell, the new attiny3226's, which are in stock, don't appear to be picopower, so the sleep currents aren't as good. Matter of fact, I can't deduce from its datasheet just what the poweroff current consumption of it is.

[ejlane]

@NeverDie As far as when the shortage ends, ??? I've seen estimates different times that it's "right around the corner" but nothing that was very convincing to me. Intel just this week or last came out and said that they think it's going to be better soon. NVidia chips/cards are getting to be more available. And random different chips have re-appeared, so maybe they're right this time? I wouldn't bet on it, though. There are still tons of parts that are hard or impossible to get in any quantity. I'm no insider, though. I shop at Digikey, Mouser, etc. same as you. Just maybe more often and a bit higher qty sometimes.

I actually have some of the Attiny3226 here to play with. When they came into stock, I bought a small bag of them. I haven't yet had a chance to do anything with them, though. I do see power consumption tables. pg 477-478 of the datasheet. https://www.mouser.com/datasheet/2/268/ATtiny3224_3226_3227_Data_Sheet_DS40002345B-2887812.pdf Numbers seem pretty reasonable, for a claimed 'low power' family of chips.

[NeverDie]

@ejlane Aha! Bingo! Thanks for the page reference! Looks as though attiny3226 is the same 100na in powerdown as the atmega328p:

Giving it a quick look, it seems both better and cheaper. What's not to like about this thing? I guess maybe just the total dearth of tutorials regarding it?

[ejlane]

@NeverDie Yeah, I think they are the next gen device. I believe that this batch that came out in the past ~6 months was the first production run of the '2' series devices. At least it was the first time that I had seen them available, though it wasn't something I had been actively searching for.

Should be about an identical AVR instruction set, but some of the low level stuff like registers might have changed, so it might take a bit of work to convert projects to it. I haven't done it yet to know.

[NeverDie]

Something to consider regarding the modules is that the maximum rated instantaneous current draw, according to the datasheet is 580ma:

That's worthy of note because the maximum current rated for a usb 2.0 port is just 500ma. So, if you're powering it from a USB 2.0 port off your computer via an LDO, that's potential problem #1. A USB 3.0 port, on the other hand, is rated for 900ma, so that would be fine. However, if you're powering it from most FTDI connectors (which typically max out at 50ma when operating at 3.3v mode), that's still going to be a problem. In this case, powering it from a Sparkfun Beefy 3 may be a solution, as "Built upon the same foundation as our 3.3V SparkFun FTDI Basic Breakout, the Beefy 3 is equipped with an AP2112K voltage regulator making this FTDI basic breakout board capable of handling a current load of up to 600 mA!" However, that's still cutting it very close though to the 580ma that the datasheet says is required. If you're powering it by some other means, you'll want to be sure you aren't backdriving your FTDI connection, as that wouldn't be good either.

My solution? I'm going to create my own custom 3.3v FTDI to UART board that can handle higher current (probably 1 amp or more) just to be sure I have enough headroom for a standalone solution. While I'm at it, I'll make sure to pick a low noise LDO....

[Edit: I think I'll go with the LT1965 LDO: https://www.mouser.com/datasheet/2/609/1965fb-1269903.pdf for it's overkill capability. Rated at 1.1a current, low noise, and big enough that it should be able to disappate heat better than some of the smaller, lower cost alternatives. That will also make it useful as a more general purpose tool. ]

[ejlane]

@NeverDie But that's only the instantaneous current needed for transmitting data over the radio. The receive current is more like what it will be doing the majority of the time. Put a beefy capacitor or two on the power line and they should handle those short little spikes.

I mean, you're not going to have a super-complicated web page on there or something. The packets being sent out will be what 1kB or something max, even serving a simple web page? According to this page: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/wifi.html#esp32-wi-fi-throughput you might get close to 80MBit/s speed. With some overhead, maybe the packet needs 10kBit, so it would only need to be on for 125uS. Even if the packets were far larger, the amount of time the radio needs to transmit is still a small fraction of the overall time. So just choose your capacitor(s) accordingly, and you'll be fine.

[ejlane]

@NeverDie Oh, whoops, looks like you're probably talking about a different module? I saw the transmit number, and had been recently talking about the ESP32, which has a similar TX power number, and looks like I misread your post.

The overall point remains, but it depends on the TX time vs. the rest of the time for the overall average power consumption and the size of capacitor needed.

[NeverDie]

@ejlane Yes, good point about using a capacitor to compensate.
27dB Tx power is, not considering inefficiencies, nominally equal to roughly 0.5amp, so the stated 580ma is probably about right and not mostly just in-rush current. LoRa transmissions can be rather lengthy, but I suppose a sufficiently large capacitor could compensate for that as well.

As it turns out I already went ahead and did a draft layout in KiCad for it:

Having already invested the time, I'm going to build it. The low noise aspect LT1965 LDO might (?) still make a difference. I also like that it has a USB-B connector on it for a nice solid connection that's mechanically anchored to the PCB (none of that surface mount micro usb rubbish). I've wanted one for quite a while, and now its moment has finally come. If anyone else has interest, I can post it to openhardware.io

[NeverDie]

Anyhow, back to the project at hand. I completed design of two different barebones mcu boards (one is just atmega328p and the other allows an Arduino pro mini to dock with it instead) that are 2xAA battery powered:

Given the wait time from a PCB fab, I went with two different designs just in case I made an error and one of them doesn't work. They both have identical test points where I can separately monitor current consumed by the mcu vs current consumed by the radio--all the better to tease apart what's really going on. Then I also have five different radio shields that fit either mcu board exactly the same:

As JLPCB doesn't work on weekends, I'm going to design a few more boards and then submit them all on Sunday night. When they finally do arrive in the mail, I'll not only be better able to evaluate the E28-2G4M27S (because the new design should practically eliminate any hardware noise), but also compare the following radios against one another for their relative performance on the exact same platform: 2.4Ghz E28-2G4M27S, three different kinds of 915Mhz SX1262 LoRa, a number of different kinds of 2.4GHz nRF24L01 (all with PA and LNA to put them on the same playing field as the other radios in the round-up), a 915Mhz RFM69HW, and a 400Mhz Ra-01 LoRa. Of interest to me are what makes for a reliable "worst case" range in my home environment at different transmission power levels and if anything stands out as a clear winner in terms of energy efficiency for bits that are reliably delivered. By worst case, I mean transmitting from behind a cement footer almost 6 feet beneath grade to a second story room across the house diagonally at the point furthest from it. If transmissions can work reliably along that transmission path, then they're probably good between any other two points in the house as well. There is, for instance, no way that a bog standard nRF24L01 could deliver any packets along that path, because its transmit power is just 0dB. However, with appropriate "boosting" via PA and LNA, I think it has a chance. In comparison, I previously tested the 400Mhz LoRa along this path, and it worked without a hitch. Matter of fact it could reach a quarter mile (or better) in all directions outside the house as well using just the default parameters in the old RadioHead libraries. I'll try that test again, but this time with the new library to see if it fares any differently this time around, as well as try LoRa at 915Mhz and 2.4Ghz.

Depending on how the testing goes, I may leverage the same platform to also try out some other inexpensive radio modules that I've seen on Aliexpress that, up to now, I've lacked an easy way to comparison test. For instance, some featuring radio chips made by Texas Instruments (CC1101, CC1310, CC1352, CC1120, CC2450, CC2640, CC2650, and a whole slew of others) and some featuring radio chips made by Silicon Labs (e.g. Si4463). If you know of chips that you're keen to try, let me know and maybe I can try them for you in a way that will be meaningful because of the comparisons. I'm not expecting that big differences will emerge that aren't already known, but testing will cut through the marketing propaganda and (hopefully) reveal the truth.

[ejlane]

@NeverDie I've never done a LoRa project, but I remember reading somewhere that some packets can take multiple seconds! So yeah, that would take a very large capacitor. I'm not sure what I would do in that scenario. I'd have to give it some thought, but I also might go with a dedicated power supply that could just handle the full current. Of course it would also depend on the specific trade-offs that were best for that project. Interesting problem.

Are you sure about JLCPCB not working on weekends? I 95% sure that I've submitted designs on Saturdays before and gotten a reply that they were accepted later that same day. I've also once or twice gotten things rejected when I made a silly mistake that they caught. I'm sure that it's a person reviewing things, and they have caught a couple errors. (Not in logic, obviously, but I had done a quick change one time, and a trace on another part of the board also got moved somehow, and it crossed over another. That's the only one I remember what the problem was.)

However, you can also always add boards to an order that is in process and they'll ship together for one price. Though if you're adding enough boards then there will be a bit of a shipping differential to pay for.

Those sound like some fun tests, and I look forward to hearing the results!

[NeverDie]

@ejlane said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

Are you sure about JLCPCB not working on weekends? I 95% sure that I've submitted designs on Saturdays before and gotten a reply that they were accepted later that same day.

On Thursday I asked "Eric", their sales rep, and he said they don't work or do production on weekends. He said that if I send the files Sunday night, it would most likely ship on Wednesday. And he said the same would be true if I sent them on Friday. All this assumes no errors in the gerber/drill files.

I'm impressed with JLBPCB in that they take the size of the board into consideration when quoting larger quantities. So, for instance, on one tiny board, I'll be getting 30 for just $4.40, even though getting 5 would cost me the $4 minimum. For some reason, though, if the order is larger than 30 boards of the same design, then it triggers a new minimum fee of around $9 or $10, IIRC. Not really sure why that is. It's a pity, because if I wanted a hundred or something for cheap, I'd have to panelize onto one PCB (Eric said no v-grooving or mouse bites allowed without paying a price penalty) and then saw/cut the boards apart after they're delivered. Fortunately, for most things, quantity 30 is a big enough number.

[ejlane]

@NeverDie Okay, sounds like you know more than I do about it, I guess. I was sure that I had gotten responses/work done on a weekend, but maybe my memory is just faulty.

But yes, their service is very impressive. And for a 2 layer board, I can get it delivered here on the west coast USA in usually 6 calendar days from ordering with the quickest shipping. That's shockingly quick, and faster than most local places can even just make the board. (Well faster than any that I know of. I've pretty much switched to only using JLCPCB. Hardly even bother quoting other places these days.)

I believe if you really needed a bunch, they would be a decent price even with the penalties. Every time I've had to pay an extra charge for something, it was a reasonable amount. Though I've never tried to order 100 of anything through them, so I could be wrong.

[NeverDie]

@ejlane said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@NeverDie Okay, sounds like you know more than I do about it, I guess. I was sure that I had gotten responses/work done on a weekend, but maybe my memory is just faulty.

But yes, their service is very impressive. And for a 2 layer board, I can get it delivered here on the west coast USA in usually 6 calendar days from ordering with the quickest shipping. That's shockingly quick, and faster than most local places can even just make the board. (Well faster than any that I know of. I've pretty much switched to only using JLCPCB. Hardly even bother quoting other places these days.)

In pre-pandemic times, I could order on a Monday from allpcb.com and get my order delivered by Friday here in the US. These days... not sure if that's true anymore, as I haven't ordered from them since before the pandemic.

I believe if you really needed a bunch, they would be a decent price even with the penalties. Every time I've had to pay an extra charge for something, it was a reasonable amount. Though I've never tried to order 100 of anything through them, so I could be wrong.

Eric basically said "Please don't panelize" and that it wouldn't save money. Now I think I understand why: if you do a lousy job of either the vgrooving or mouse bites, it's going to interfere with their manufacturing process. e.g. maybe that part of their much larger project board shatters to bits during fabrication because it's too weak structurally. It's much better for them (at least from their cost of business) to be in complete control of it. Otherwise, some engineer might have to remediate somebody's poor panelization, which takes extra time and throws a wrench into their work flow.

[NeverDie]

@ejlane said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

I've also once or twice gotten things rejected when I made a silly mistake that they caught. I'm sure that it's a person reviewing things, and they have caught a couple errors. (Not in logic, obviously, but I had done a quick change one time, and a trace on another part of the board also got moved somehow, and it crossed over another. That's the only one I remember what the problem was.)

I took JLCPCB's capabilities and, to the degree possible, imported them into KiCAD's design rule constraints:

This has surfaced violations that didn't get flagged by KiCAD's default design rule constraints--problems that I'm guessing JLCPCB would have kicked back at me if this method hadn't found them first.

[Parkeexant]

@NeverDie this video is very useful

[NeverDie]

@Parkeexant said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@NeverDie this video is very useful

Which video?

[ejlane]

@NeverDie I've only done my own panelization maybe 2 or 3 times ever. Usually just leave it to the board house, but 10 or so years ago, before the board houses were quite this cheap and I was on more of a budget because of saving for a down payment, I did try it out for some personal projects as an experiment.

But I didn't even try to do v-grooves. Not sure if whichever one I was using would even allow it. I just left extra room between the active parts of the board on the PCB and literally took tin snips and cut them apart with that. With 1 cm between boards it's easy to not hit anything.

Obviously doing it like that wouldn't weaken their board, but if you need precise board shape/size then this wouldn't do it. Ever since then the prices have gotten so low that I don't bother trying. I would be interested knowing what about JLCPCB's process makes them want to limit any order to the 30 pieces. That's always seemed a bit weird to me. I would think they would welcome the extra volume/money.

But weirdly enough, I don't even know where to go for larger orders. I mean, I can do a search like anyone else, but I don't have direct experience. By the time it gets to that qty, then the assembly house deals directly with whoever they work with to get the boards made. At that point it's not me dealing with them directly, except for passing requirements to the client, who then passes them to the assembly house, etc.

I've also entered some of their limitations into KiCad, but I'm not sure if I did a complete job of it. I try to be a bit more conservative than being right at the manufacturable edge. But yeah, get the rules to catch as much as possible. I think my problems came in when I did something that such a minor change I didn't even really think about running the rules again, and of course something like that is usually harmless, but every once in a while it does something unexpected, so obviously the rules need to be checked after every change, and every time before exporting gerbers for manufacturing. And I try to do that, but still these days I'm sure that are times that I forget.

[Larson]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

If you know of chips that you're keen to try, let me know

Since you asked, maybe look at the good-old cheap 433 MHz transmitter/receivers? Maybe you are sticking to transceivers so this wouldn’t fly. Or maybe you are staying away from ASK modulations. I’m sure these cheapo radios won’t pass your fundaments concrete/cross-house test, but it would be another data point. This season I’ve been slowly reworking my limited 433 MHz home network of motion detectors. Having failed to transmit through concrete/cross-house pathways, I built some 433 repeaters that successfully worked on a line-of-site pathways that allowed me to look around the corners. I have found these TX radios & SR501 motion detectors just sip energy and my 4-pack of AA batteries last for, in some cases, over 3 years.

As you are working with JLCPCB are you using them for assembly? I did so last year with different project and had really good results. I did have some difficulty finding compatible components, so I suspect that they won’t be able to resource all your radios… but that was some time ago and I have much to learn. I look forward to doing more assembly with JLCPCB. It was also really inexpensive and a great way to get around my poor home soldering quality.

[edit: forgot to say, @NeverDie and everyone else: What a great thread. Thanks for building and sharing. I have learned much here.]

[NeverDie]

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

As you are working with JLCPCB are you using them for assembly? I did so last year with different project and had really good results. I did have some difficulty finding compatible components, so I suspect that they won’t be able to resource all your radios… but that was some time ago and I have much to learn. I look forward to doing more assembly with JLCPCB. It was also really inexpensive and a great way to get around my poor home soldering quality.

Good idea. I haven't tried it, because I've been locked in a mindset of using radio modules, in which case soldering things is easy enough that I can do it myself manually without much effort. But for small, fine pitched chips (the kind I've been avoiding for just that reason), it sounds like a worthwhile thing to try. Maybe I could use better components than are typically found in aliexpress modules as well.

[NeverDie]

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

If you know of chips that you're keen to try, let me know

Since you asked, maybe look at the good-old cheap 433 MHz transmitter/receivers? Maybe you are sticking to transceivers so this wouldn’t fly. Or maybe you are staying away from ASK modulations. I’m sure these cheapo radios won’t pass your fundaments concrete/cross-house test, but it would be another data point. This season I’ve been slowly reworking my limited 433 MHz home network of motion detectors. Having failed to transmit through concrete/cross-house pathways, I built some 433 repeaters that successfully worked on a line-of-site pathways that allowed me to look around the corners. I have found these TX radios & SR501 motion detectors just sip energy and my 4-pack of AA batteries last for, in some cases, over 3 years.

Interesting idea. I'll have to give that one some thought. A lot of the cheap wireless temperature-humidity sensors seem to use ASK, and I've never been clear as to why. e.g. Oregon Scientific, and similar companies. There are a number of hacker-type projects aimed at receiving and decoding those signals precisely because the wireless sensors are so cheap. And those cheap wireless key-finder fobs I think may use it as well. Maybe the receiver current can be extremely low? Those fobs always have to be listening for a wireless signal. All I know is that low frequency implies less energy consumption by whatever oscillator is being used.

[Larson]

@NeverDie: Yes, as you describe elswere, and taught me, the design trade-off parameters are frequency, bandwith, dwell time, bit transfer rate, power demand, and most importantly, range. I'm looking forward to your findings.

Regarding the low reciever current: don't know about the FOB's but I have found the transmitter power to be key. My design has the "always on" reciever connected to mains. so I don't worry about that power. But the battery-limited transmitter devices are brought to life and triggered by the signal pin of the SR501 sensors that is high enough, long enough to complete a transmission, or several. The HT12E (encoder) chip is connected to the SR501 pin is fired and sends the settings of the dip-switch pin hi/low settings that is recieved by the always-on HT12d (decoder) that the Atmega 328PU can understand. I think the HT devices are MCUs in a different form, like what I imagine a FPLC to be like... don't know for sure. Why do I drone on? Because of the HT12D and HT12E pariings are very specific and very low on power demand due to their design. When I built my configuration (6 years ago) I knew more than I do now. But I'm relearning more. Andreas Spiess, Great Scott, Big Clive, and YOU, explore this stuff extensively, and I thank you all.

In summary, my repeaters and base RX station are mains powered so I don't worry about power & batteries. The primary focus for conservation of batteries is on the TX/Motion devices. Everything downstream of TX is mains powered or can be suitably backed up in the short term.

[NeverDie]

I think I'll pass on the ASK, and the reason is that it tends to be noise/interference sensitive. The usual workaround for noise/interference by ASK garage door openers, for instance, is to send the same packet multiple times, with the hope that at least one of them will get through. Well, I suppose that strategy works "good enough" in some sense for that application, but I'd say that all those extra packets being sent is a waste of energy for a battery powered sensor application that's transmitting, say, once every 5 minutes. On the other hand, if it doesn't really matter if you lose packets from time to time (e.g. a wireless TH sensor), maybe you don't need to send multiple redundant packets in the hopes that one gets through. That said, IIRC, Oregon Scientific TH sensors send their packets in triplicate. Well, that's my off-the-cuff take on it. Feel free to disagree if I'm missing something important.

Anyhow, I think that's why one tends to see ASK being used at 433Mhz: it's a relatively clean channel, so the noise/interference isn't as big a factor as it would be at 915Mhz or certainly 2.4Ghz.

At the end of the day, I think ASK was popular because, historically, it was easy and cheaper to make. Think 1940's, 1950's, and maybe 1960's, before integrated circuits. Now that FSK, its main competitor, is widespread and cheap anyway, I just don't see much benefit in reverting to old school ASK unless maybe you're manufacturing millions of something and want to save every penny possible. Because of the possible noise issue, you're also limited to slower bit rates with ASK than the alternatives, which, in turn, also lead to longer transmit times.

P.S. Build time at JLCPCB is now running 2-3 days. Out of the 10 boards I submitted on Sunday (China time), 9 are still awaiting "data preparation." Only 1 of the 10 is currently in production. I think they're manpower limited right now, maybe because of China's zero-tolerance covid policy.

[Larson]

@NeverDie Yes, you are correct: the HT12D datasheet indicates that multiple signals must be recieved before the enable pin is activated. I think the 'multiple' is a count of three and there is probably a preamble in advance of the main message of high/low settings. The transmitter, again I think, just keeps sending the message until the SR501 drops power (2 seconds on the minimum settings). I get alot of double hits because of this. Good to know about the noise and history. Thanks.

[NeverDie]

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@NeverDie Yes, you are correct: the HT12D datasheet indicates that multiple signals must be recieved before the enable pin is activated. I think the 'multiple' is a count of three and there is probably a preamble in advance of the main message of high/low settings. The transmitter, again I think, just keeps sending the message until the SR501 drops power (2 seconds on the minimum settings). I get alot of double hits because of this. Good to know about the noise and history. Thanks.

Worthy of note is, as you may already know, you can skip the HT12D and HT12E altogether if you're driving it from an Arduino. You can do all the encoding/decoding in software, and all you need on the transmit side is a mosfet to control the on/off of the transmit on the transmitter. I did this once by rolling my own software to do it, but I think it may also be handled in the wire library, IIRC. On the receiver side, I got better results by upgrading to an Arduino Due, because it has 12 bit instead of 10 bit Analog-to-digital converter, and a faster speed to do the processing. However, maybe I could have done it all digital and skipped that. I was just trying to eek the most reception I could out of possibly weak signals.

Fun fact: on a 900Mhz Raspberry Pi (Version 1), you can make a 900Mhz radio transmitter just by putting a wire of appropriate length in one of the GPIO pins and then toggling PWM to it at the 900Mhz clock cycle. Of course, you'll need something more sensitive on the receive side. This would be an ASK scheme, by the way.

Also, fun fact: the speed on the Due is fast enough that light (radio waves) doesn't move all that far per clock cycle, so you can detect when signals arrive directly between transmitter and receiver from an on-pulse, and you can also detect fainter echoes of that same pulse arriving later because they've bounced off a wall or something and took a longer path between the transmitter and receiver. I thought that was kinda cool, because I ordinarily think of the speed of light as being more or less instant in such close quarters. Anyhow, I forgot the name for this kind of temporal transmit "smearing", but it's a very real effect where the transmitter kinda interfers with itself, so to speak, because of the layout of reflecting surfaces in the environment. [Edit: just now looked it up. "Multipath interference" is the term. MIMO thrives on multipath signals, but it's a problem for regular radio to deal with it--though, as you'd expect, there are all kinda of ways to handle it; the easiest being just putting a long enough time interval after an ON pulse for the echoes to die out to background noise levels. ]

P.P.S. All 10 of my JLCPCB boards are now in production, though it is now technically early Tuesday morning in China. Looking at the time stamps, the production process itself appears to run around the clock, not just during daytime business hours, so that's good. Hopefully that means there's no complicating factor left standing in the way of completing the production and shipping it.

[Larson]

@NeverDie : Very interesting stuff. Even at the lowly 8MHz, the speed of processing pretty much blows away the human concept of time. Fun to hear of the Raspberry and Due. I’ll have to play with those.

HT12D/HT12E: Yes, I learned that the processing could be done on a MCU and I did that on the repeaters I built. I put a Pro-Mini in between a 433 Mhz RX and TX. This repeater sits and listens in the RX mode until it is pinged with a transmission from one of the 433-HT12E detectors. Once a message comes in, the MCU then switches to TX mode and passes the message along, then reverts to listening again. The repeaters and the base station are mains powered as I figured the always ON state would be a battery killer whereas the 433-HT12E’s are very low power and outfitted with batteries.

Rather than using the IIRC library I used RCSwitch – probably because I found that first. RadioHead was another option. The biggest challenge for me was learning which protocol to use for the 433 radios. The command mySwitch.setProtocol(11); did the trick.

[NeverDie]

@Larson The Due has an 84Mhz clock speed, making it easier to spot the effect. These days you could save some coin by using an ESP8266 (80Mhz) or even faster ESP-32, not to mention the crazy fast Teensy 4.1 (600Mhz). At 600Mhz, light moves only 20 inches per clock cycle. Pretty cool for cheap parts, isn't it?

[NeverDie]

I received the Dorji parts I had ordered. They arrived very fast and very well packed. I got them on ebay, but for comparison I'm still waiting on everything else that I had ordered from aliexpress.

It turns out it took 3 days for JLCPCB to build my simple 2 layer PCB's. Either they're overwhelmed with business or understaffed. With any luck they'll ship out tomorrow, so probably another week to get here.

Meanwhile I received a Nord PPK2 Power Profiler, as I found a seller who briefly had some in stock. So, I'll be putting that to use to accurately compare current consumption of the various test builds after the PCBs eventually arrive from JLPCB. Meanwhile, I may try it out on an ESP8266 to finally get some solid current consumption numbers on how much power it takes to wake-up into ESP-NOW mode from a cold start. If it's good, then maybe so-called trigger boards will bring the ESP8266 back to life as a low power competitor. Also, I'm really curious as to how sensitive (or not) the ESP8266 2.4Ghz ESP-NOW communications will be to interference in a home environment that, at least so far, seems to have shredded 2.4Ghz LoRa. According to the labeling on the tin, they come with 25dBa power amplifiers, so I expect they'll do far better than a bog standard nRF24L01, which has a maximum of only just 0dBa transmit power. Of course, when you add in the cost of a trigger board, then total cost may (?) turn out to be a wash compared to other mcu/radio combos that don't require a trigger board. We'll see!

[NeverDie]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

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.

Reporting back: I have the answer. It turns out that the standard arduino core for atmega328p that's baked into the standard Arduino IDE does not support Arduino pins 20 and 21 as digital GPIO pins for driving LEDs. However, the good news is that there's an even better Arduino core, called MCUDude MiniCore which does support exactly those pins for such purposes. Here's the TL;DR:

This core gives you two extra IO pins if you're using the internal oscillator! PB6 and PB7 is mapped to Arduino pin 20 and 21.

https://mcudude.github.io/MiniCore/package_MCUdude_MiniCore_index.json
It's very easy to use. You can install it into the regular Arduino IDE, pick from among the MiniCore "boards" in the board manager, select the 8Mhz option and a few other obvious options, and then you're done with instalation. From that point on your code will automagically compile using MiniCore. Just to be sure, I gave it a try myself, and I'm now blinking a blue LED off of Ardino Pin 20. It works!

[Larson]

@NeverDie More good information - thanks for posting. Good work on finding the alternate core. I have a couple of questions:

1. By “trigger board”, are you referring to the TPL5010 discussed above? (Adafruit carries the TPL5110, I think.) Is the idea here to power and de-power the radio, or mcu, to discover the rock-bottom minimum current requirement?
2. What are you sacrificing when not using the external crystal? And to do this, are you setting fuses to tell the 328 to use the internal crystal? I've found setting fuses to be a complicated affair.

[Larson]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

At 600Mhz, light moves only 20 inches per clock cycle. Pretty cool for cheap parts, isn't it?

Yes, mind-blowing. I got into this hobby via the Parallax Basic kits. The second MCU I bought from them was about $60 and I thought that was stunning. So when I found the ATTINY85 I was addicted, if only because the access to this technology costs less than a cup of coffee. The progression to Arduinos and ESP's was a natural extension for this cheap hobby.

[NeverDie]

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@NeverDie More good information - thanks for posting. Good work on finding the alternate core. I have a couple of questions:

1. By “trigger board”, are you referring to the TPL5010 discussed above?  (Adafruit carries the TPL5110, I think.)    Is the idea here to power and de-power the radio, or mcu, to discover the rock-bottom minimum current requirement?
   

2. What are you sacrificing when not using the external crystal? And to do this, are you setting fuses to tell the 328 to use the internal crystal? I've found setting fuses to be a complicated affair.

Good questions!

1. Yes, by "trigger board", the adafruit tpl5110, or something like it, is what I have in mind. The goal would be zero leakage current beyond the ~40 nanoamps of management overhead. I don't know if the p-channel mosfet design in adafruit's tpl5110 breakout board achieves zero leakage (or near enough),but it would be worth measuring. I think Kevin Darrah may be the one who coined the term "trigBoard". His design is a lot more elaborate and, I assume, costly: https://www.kevindarrah.com/wiki/index.php?title=TrigBoardV7

Is the idea here to power and de-power the radio, or mcu, to discover the rock-bottom minimum current requirement?

Yes. It's a little more complicated though, because generally the mcu/radio wake-up time is much longer from a cold start than from a deep sleep, so the real objective would be to find the breakeven point at which power-off is the better choice (i.e. how long does the duty cycle need to be).

What are you sacrificing when not using the external crystal?

Accuracy. If you were interfacing to something that had extremely tight timing requirements, the crystal would be more accurate. In practice, I haven't ever noticed a difference in anything that I've done.

And to do this, are you setting fuses to tell the 328 to use the internal crystal? I've found setting fuses to be a complicated affair.

Yes, I set the fuses. Currently I use the following fuse settings:

By running from the 8Mhz internal oscillator and sleeping, not only can you sleep the atmega328p at just 100na, but as a bonus the atmega328p can wake up in just 3 microseconds (I previously measured it with an oscilloscope, so that number is solid). For being such an old mcu, the atmega328p can be amazingly high performance when it comes to saving power. This becomes of greater relevance if you're getting your power by harvesting weak energy sources.

If you want to play around with setting fuse bits, the standard advice is to leave the Extended bits alone until you know what you're doing. Even then, there's probably no need to change them. It's the High and Low bits that are of relevance.

A great source of information is: https://www.gammon.com.au/power

[Larson]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

sleep the atmega328p at just 100na

Wow, that is pretty close to zero in my view. Consider battery self-discharge in comparison: I use 18650 LiOn batteries in most of my projects. Say a 2000 mAh battery loses 1%/month in self discharge s(ome say it is much higher). Well, the math, if I did it right, shows a self-discharge of about 25 uA. So sleeping at 100nA is really impressive.

Thanks for the fuse guidance. I will employ this next chance I get.

[NeverDie]

@Larson Yes. The RFM69 can also be slept at just 100na, so taken together they are an awesome duo. If you're running from 2xAA batteries, then the the combined 200na are essentially zero. If, in contrast, you're trying to harvest energy from a small solar cell in an indoor environment that's dimly lit by LED lighting only rarely, then it becomes more relevant.

Anyhow, I've noticed that a lot of people measure very small currents incorrectly, so just trying to find answers on the internet, which is full of wrong measurements, isn't easy. Datasheets can provide some insight.

[Larson]

@NeverDie Yes, the experience and knowledge found by doing (measuring) is always deeper,

Forgot to mention: Kevin Darah. I have bought several of his TrigBoards. I find the price to be a good value for the design, components, assembly, and all the content he has posted. The quality of his boards is great. I am a Patreon of his. I just need to play with the TrigBoards some more.

[NeverDie]

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@NeverDie Yes, the experience and knowledge found by doing (measuring) is always deeper,

Forgot to mention: Kevin Darah. I have bought several of his TrigBoards. I find the price to be a good value for the design, components, assembly, and all the content he has posted. The quality of his boards is great. I am a Patreon of his. I just need to play with the TrigBoards some more.

I'd be interested to hear your thoughts on Kevin's trigBoards after you've had a chance to get familiar with them. A compare/contrast of his board to the adafruit board would be even more awesome. The adafruit board is a very simple design and would cost less than $1 in parts if you were to source them yourself. I suppose its main limitation is 1. the maximum sleep time is two hours, and 2. not as accurate as a proper RTC. In its favor is that at 40na the sleep current consumption is next to nothing. On the other hand, some RTCs have a sleep current less than 1ua, so maybe that's good enough.

[Larson]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

In its favor is that at 40na the sleep current...

I'll order several. Then compare to the TrigBoards. Adafruit's TPL5011 advertises a run current of 20uA. Is that acceptable for you? If so I'll buy several. Couple of limitations for me: 1. Time - I'm about a month out, 2. My Ammeter is a standard DMM from Harbor Freight. The smallest range is 200uA and I've found it very useful. Certainly fine enough to show the 20uA, but inadequate for nanoAmps.

[NeverDie]

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

In its favor is that at 40na the sleep current...

I'll order several. Then compare to the TrigBoards. Adafruit's TPL5011 advertises a run current of 20uA. Is that acceptable for you? If so I'll buy several. Couple of limitations for me: 1. Time - I'm about a month out, 2. My Ammeter is a standard DMM from Harbor Freight. The smallest range is 200uA and I've found it very useful. Certainly fine enough to show the 20uA, but inadequate for nanoAmps.

Hmmmm... Something's wrong then with Adafruit's design if it's 20uA. The chip itself consumes only 35na according to its datasheet:
https://www.ti.com/lit/ds/symlink/tpl5110.pdf?ts=1652658923819&ref_url=https%3A%2F%2Fwww.google.com%2F
Maybe their p-channel mosfet has high leakage current with the circuit has they've designed it? I would pass if it really is 20uA. I'm sure I could do better than that.

You need something like either a Current Ranger or a MicroCurrent Gold to accurately measure microamps and nanoamps. Cost is around $100.

Also, I just now looked at one of Kevin Darrah's videos:
PART 3 Cellular -The Ultimate DIY Home Security System - ESP8266 (trigBoard) + 4G LTE Modem – 22:37
— Kevin Darrah

where he has embraced ESP-NOW. He said his esp8266 still takes around 1.5 seconds to wake up and transmit, even though running ESP-NOW, which is a very long time, as the module will be burning current through out that wake-up interval. In the example he showed, the delay was quite noticeable (though definitely an improvement compared to before when he was using plain wi-fi). Of course, the devil is in the details, but seeing that I'm more skeptical now than before.

[Larson]

@NeverDie I recognized the KD image as soon as I saw it. I'll watch... again... after dinner. Yes, the battery economics depend on time and power as you say. One of the tricks I have learned is aggregating data at the MCU level in RTC memory. I'm using both a 328 and an ESP; each dedicated to it's task. When 20 samples (minutes of data) are gathered the MCU wakes the ESP so it can bulk-load data to Thingspeak. This economizes the cost of the ESP wake-up by a factor of 20. This is all for my water-meter monitoring project. It has been fun stuff and I've learned a bunch. And I'm not using ESP-NOW because I'm going directly from the ESP transmitter to my home network - so I could do even better if I injected an ESP repeater that would transmit to the network. I think my wake-up/network-connection is about 8 seconds.

We have strayed far away from your initial "anyone-useing..." post. I hope that is okay?

[NeverDie]

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

We have strayed far away from your initial "anyone-useing..." post. I hope that is okay?

Yes, it's fine. I'll be testing the E28-2G4M27S once more after my JLCPCB's arrive.

[NeverDie]

The PCB's arived today, about 1 week after I placed the order. I already put together one mote:

It nicely fits the footprint of two AA batteries. I'll be running some tests soon and hopefully getting definitive answers.

By the way, the flashing green LED is being driven by Arduino Pin 20.

[NeverDie]

Mea Culpa. I found a mistake in my original setup which may explain at least some of the poor performance. I had thought that both my usb-to-serial converters were operating at 3.3v, but I noticed during disassembly that one was operating at 5v instead. Even though I was using pro mini's with 3.3v LDO's on them, it turns out that the 3.3v LDO only functions when the voltage is being fed to the pro mini over the RAW pin (which is never in my setup). Instead, the usb-to-serial converter fed its 5v directly to VCC over the header pin, and from there directly to the radio module. Although I did later do experiments where the entire setup was being run off of 3v of battery only, it may be that the radio module was already damaged by then.

I wouldn't be surprised if others besides just me have fallen into this same trap, as it might be natural to assume that a "3.3v pro mini" regulates all of its voltage sources to be 3.3v. However, such is not the case, as confirmed by checking the schematic.

So, to remove all doubt, I'll use brand new radio modules when testing with this new test setup, which won't be using pro mini's at all this time around. It turns out my barebones atmega328p design works just fine, and this way I have total control over the quality of all the components going into it, including X7R on all the capacitors (whereas who knows exactly what quality of components are used on pro mini's).

[NeverDie]

Here's an end-view of the test platform:

As you can see, I wouldn't want the batteries to be any closer together than they already are, or they would likely short out between them. As it stands, they're firmly in place, so no worries for now. These kinds of placement tolerance issues are hard to vet in advance prior to building a prototype. The keystone datasheet gave no guidance at all on side by side positioning. If I were to do it over, I think I'd give it another millimeter or two of safety factor separation.

Of bigger concern is the switch placement. A side mounted switch might be too tight a fit because of the battery connectors. On the other hand, the existing vertical switch can potentially can get in the way of things, so I may try mounting it upside down on the battery side. This would make it less accessible than it currently is, but, at the same time, it wouldn't get bumped by accident either. I reckon that with the aid of an insulated paperclip, or maybe a chop-stick, it should be possible to turn it on-off even in the more cramped position. Probably a more correct solution would be a surface mounted side-switch that's tiny but somehow good enough to carry 600ma+ currents. Finding such a thing may take some searching though, assuming it exists at all.

In a perfect world, the radio module, if it were to use its trace antenna, would be hanging over the end of the base PCB below. Part of the reason it wasn't was out of concern as to whether the breakout board might collide with the switch. Well, with the new switch position, that won't be a worry, so if I create a new version of the breakout board for the radio module, I'd make it so that the radio module has its trace antenna hang out over the end of not just the breakout adapter, but the end of the test platform as well.

I normally use regular headers, but out of an interest in making the whole thing more compact, and for snugger connections, I made a last minute decision to use machine pin headers instead. This was after the board had already been fab'd to use regular headers. If I were to do it over, I would have bigger diameter through-holes drilled into the PCB in order to seat the machine pin female headers properly. I'll do that in the next version I get fab'd, assuming there is a next version.

At the opposite end there's space to add a pico-blade for the FTDI attachment. If that works, then in a future design there will be space for extending a few more pins out from the MCU, making for a more complete universal test platform. For present testing purposes, though, things are good enough as they are.

If anyone reading this has any further thoughts or suggestions, please feel free to jump in and post them. I find it's less fun to do everything single handedly.

[NeverDie]

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

In its favor is that at 40na the sleep current...

I'll order several. Then compare to the TrigBoards. Adafruit's TPL5011 advertises a run current of 20uA. Is that acceptable for you? If so I'll buy several. Couple of limitations for me: 1. Time - I'm about a month out, 2. My Ammeter is a standard DMM from Harbor Freight. The smallest range is 200uA and I've found it very useful. Certainly fine enough to show the 20uA, but inadequate for nanoAmps.

I don't see any uCurrent Gold's for sale at the moment, but I did find a clone of it, which has what looks like a nice improvement over the original: you can plug it directly into an oscilloscope via its BNC connector.

https://www.n-fuse.co/devices/tinyCurrent-precision-low-Current-Measurement-Shunt-and-Amplifier-Device.html
or
https://github.com/nfhw/tinycurrent
as it is open source.

I temporarily misplaced my Dave Jones uCurrent Gold that I bought from him directly during his Kickstarter campaign. However, if I can't locate it soon, I may be either buying or making one of these tinyCurrent's to take advantage of the built-in BNC connector.

[NeverDie]

Reporting back: Problem solved!

Using two of the new test nodes, one in transmit and the other in receive, and each using a brand new E28-2G4M27S with just the trace antenna only, and with the default library settings for each, and with the transmit node in a different room with two closed doors in-between (exactly as before, with the initial testing at the start of this thread), I'm now getting the kind of flawless communication that I had expected all along from LoRa on the 2.4Ghz band:

12:23:12 May 18 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

5s  Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,10dB,Length,23,Packets,1,Errors,0,IRQreg,8012
9s  Hello World 1234567890*,CRC,DAAB,RSSI,-55dBm,SNR,14dB,Length,23,Packets,2,Errors,0,IRQreg,8012
13s  Hello World 1234567890*,CRC,DAAB,RSSI,-55dBm,SNR,10dB,Length,23,Packets,3,Errors,0,IRQreg,8012
18s  Hello World 1234567890*,CRC,DAAB,RSSI,-58dBm,SNR,13dB,Length,23,Packets,4,Errors,0,IRQreg,8012
22s  Hello World 1234567890*,CRC,DAAB,RSSI,-56dBm,SNR,14dB,Length,23,Packets,5,Errors,0,IRQreg,8012
26s  Hello World 1234567890*,CRC,DAAB,RSSI,-52dBm,SNR,13dB,Length,23,Packets,6,Errors,0,IRQreg,8012
30s  Hello World 1234567890*,CRC,DAAB,RSSI,-53dBm,SNR,9dB,Length,23,Packets,7,Errors,0,IRQreg,8012
34s  Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,8dB,Length,23,Packets,8,Errors,0,IRQreg,8012
38s  Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,9,Errors,0,IRQreg,8012
42s  Hello World 1234567890*,CRC,DAAB,RSSI,-52dBm,SNR,14dB,Length,23,Packets,10,Errors,0,IRQreg,8012
46s  Hello World 1234567890*,CRC,DAAB,RSSI,-55dBm,SNR,13dB,Length,23,Packets,11,Errors,0,IRQreg,8012
50s  Hello World 1234567890*,CRC,DAAB,RSSI,-55dBm,SNR,12dB,Length,23,Packets,12,Errors,0,IRQreg,8012
54s  Hello World 1234567890*,CRC,DAAB,RSSI,-56dBm,SNR,9dB,Length,23,Packets,13,Errors,0,IRQreg,8012
58s  Hello World 1234567890*,CRC,DAAB,RSSI,-59dBm,SNR,9dB,Length,23,Packets,14,Errors,0,IRQreg,8012
62s  Hello World 1234567890*,CRC,DAAB,RSSI,-59dBm,SNR,13dB,Length,23,Packets,15,Errors,0,IRQreg,8012
66s  Hello World 1234567890*,CRC,DAAB,RSSI,-61dBm,SNR,13dB,Length,23,Packets,16,Errors,0,IRQreg,8012
70s  Hello World 1234567890*,CRC,DAAB,RSSI,-57dBm,SNR,13dB,Length,23,Packets,17,Errors,0,IRQreg,8012
75s  Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,14dB,Length,23,Packets,18,Errors,0,IRQreg,8012
79s  Hello World 1234567890*,CRC,DAAB,RSSI,-55dBm,SNR,14dB,Length,23,Packets,19,Errors,0,IRQreg,8012
83s  Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,13dB,Length,23,Packets,20,Errors,0,IRQreg,8012

Notice that now both the RSSI is very good and the SNR is very high as compared to when I was having trouble with the earlier setup.

The E28-2G4M27S is vindicated. Case closed!

[NeverDie]

Epilog: I hooked up the old receiver, with its external antenna, to the new mote, and it's not obviously worse for the wear:

12:23:12 May 18 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,-57dBm,SNR,12dB,Length,23,Packets,1,Errors,0,IRQreg,8012
8s  Hello World 1234567890*,CRC,DAAB,RSSI,-55dBm,SNR,13dB,Length,23,Packets,2,Errors,0,IRQreg,8012
12s  Hello World 1234567890*,CRC,DAAB,RSSI,-57dBm,SNR,13dB,Length,23,Packets,3,Errors,0,IRQreg,8012
16s  Hello World 1234567890*,CRC,DAAB,RSSI,-57dBm,SNR,12dB,Length,23,Packets,4,Errors,0,IRQreg,8012
20s  Hello World 1234567890*,CRC,DAAB,RSSI,-54dBm,SNR,9dB,Length,23,Packets,5,Errors,0,IRQreg,8012
24s  Hello World 1234567890*,CRC,DAAB,RSSI,-52dBm,SNR,3dB,Length,23,Packets,6,Errors,0,IRQreg,8012
29s  Hello World 1234567890*,CRC,DAAB,RSSI,-55dBm,SNR,11dB,Length,23,Packets,7,Errors,0,IRQreg,8012
33s  Hello World 1234567890*,CRC,DAAB,RSSI,-55dBm,SNR,13dB,Length,23,Packets,8,Errors,0,IRQreg,8012
37s  Hello World 1234567890*,CRC,DAAB,RSSI,-50dBm,SNR,12dB,Length,23,Packets,9,Errors,0,IRQreg,8012
41s  Hello World 1234567890*,CRC,DAAB,RSSI,-53dBm,SNR,13dB,Length,23,Packets,10,Errors,0,IRQreg,8012
45s  Hello World 1234567890*,CRC,DAAB,RSSI,-56dBm,SNR,14dB,Length,23,Packets,11,Errors,0,IRQreg,8012
49s  Hello World 1234567890*,CRC,DAAB,RSSI,-53dBm,SNR,8dB,Length,23,Packets,12,Errors,0,IRQreg,8012
53s  Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,3dB,Length,23,Packets,13,Errors,0,IRQreg,8012
57s  Hello World 1234567890*,CRC,DAAB,RSSI,-52dBm,SNR,8dB,Length,23,Packets,14,Errors,0,IRQreg,8012
61s  Hello World 1234567890*,CRC,DAAB,RSSI,-52dBm,SNR,12dB,Length,23,Packets,15,Errors,0,IRQreg,8012
65s  Hello World 1234567890*,CRC,DAAB,RSSI,-52dBm,SNR,11dB,Length,23,Packets,16,Errors,0,IRQreg,8012
69s  Hello World 1234567890*,CRC,DAAB,RSSI,-52dBm,SNR,13dB,Length,23,Packets,17,Errors,0,IRQreg,8012
73s  Hello World 1234567890*,CRC,DAAB,RSSI,-50dBm,SNR,13dB,Length,23,Packets,18,Errors,0,IRQreg,8012
77s  Hello World 1234567890*,CRC,DAAB,RSSI,-51dBm,SNR,13dB,Length,23,Packets,19,Errors,0,IRQreg,8012
82s  Hello World 1234567890*,CRC,DAAB,RSSI,-55dBm,SNR,12dB,Length,23,Packets,20,Errors,0,IRQreg,8012
86s  Hello World 1234567890*,CRC,DAAB,RSSI,-56dBm,SNR,7dB,Length,23,Packets,21,Errors,0,IRQreg,8012
90s  Hello World 1234567890*,CRC,DAAB,RSSI,-57dBm,SNR,13dB,Length,23,Packets,22,Errors,0,IRQreg,8012
94s  Hello World 1234567890*,CRC,DAAB,RSSI,-56dBm,SNR,13dB,Length,23,Packets,23,Errors,0,IRQreg,8012
98s  Hello World 1234567890*,CRC,DAAB,RSSI,-48dBm,SNR,6dB,Length,23,Packets,24,Errors,0,IRQreg,8012

One thing I do notice,though, when reviewing the receive packet data, with both the new and old radios are considerable variances in SNR. The 915Mhz adafruit transceivers don't show much variance (see earlier post for the telemetry). I presume, therefore, the larger SNR variances are caused by environmental interference that varies over time in the 2.4Ghz band, or at least the default channel in that band chosen by the library.

The end!

[NeverDie]

Putting a Yagi antenna on this, one could perhaps gather data pointing to where the interference sources are located by backing out the "noise" value from the RSSI and SNR data collected.

[NeverDie]

One last thing to try: to eliminate the possibility that the USB-to-FTDI might be introducing noise into the receiver, I think I'll try a test setup with three motes. Two will be completely battery powered with no external connection, and one will be connected to the computer for datalogging over USB. The main change is that the receive node will receive packets, as before, from the battery powered transmitter mote, but instead of directly feeding those results over USB to the computer, it will transmit those results (including the RSSI and SNR on the packets it received) to the third mote. The third mote will be located in the same room as the receiver mote, and it is the third mote that will be connected to the computer over USB. The third mote being in the same room as the receive mote guarantees it won't lose any packets, and if any noise is introduced over USB to the third mote, it will be irrelevant, because the primary receiver mote will be stand-alone and entirely battery operated, with no possibility of USB injecting noise into it.

I suspect it won't make any difference to the final results, but the only way to know for sure is to test it. Going forward, to eliminate all doubt, I'll use the same type of three mote setup when testing other radios also. When testing different radios, all I'll need to do is swap in new radio shields and re-program the bases.

Anyhow, this thread has turned out to be more of a blog than anything, but, as always, it becomes more interesting if other people post too so that it's not just me recording a monolog. I'll start a new thread when I start testing other radios, with the goal being to compare the performance of different radio modules to see whether any one module stands out as obviously "best" in the general sense, or at least better understand under which use-cases which radio module would be better than the alternatives.

[NeverDie]

I haven't yet set up the 3 mote testing structure that I outlined above, but, for comparison, using the same two mote system for testing 915Mhz Dorji modules (each with a 3.25" wire whip antenna), with the same transmit and receive locations, the results there were rock solid SNR values with no variance over the sample:

12:16:09 May 20 2022
V1.1

104_LoRa_Receiver_Detailed_Setup Starting

LoRa Device found

SX1262,434000000hz,SF7,BW125000,CR4:5,LDRO_Off,SyncWord_0x1424,IQNormal,Preamble_8
SX1262,PacketMode_LoRa,Explicit,LNAgain_Boosted

Reg    0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
0x800  00 00 00 00 29 07 20 09 00 10 19 D4 10 C9 10 00 
0x810  10 C7 0F FE 10 C7 0F FE 00 76 8A A9 4A 00 00 00 
0x820  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x830  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x840  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x850  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x860  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x870  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x880  03 00 00 5F 10 08 00 00 08 04 00 1B 20 00 00 0C 
0x890  00 00 00 10 BD 0F 0A 07 10 00 26 01 01 53 06 07 
0x8A0  10 00 AD 20 5A 04 F0 02 56 56 54 43 96 20 40 00 
0x8B0  00 83 11 00 01 04 0A 4C 14 0A 2F 01 6B FF FF 00 
0x8C0  00 A0 20 00 00 00 AC 00 1C 00 00 AB 05 30 11 14 
0x8D0  0C 15 16 40 06 00 00 10 E8 00 00 00 00 09 31 39 
0x8E0  90 39 0C 04 40 20 16 38 06 00 05 04 03 02 01 01 
0x8F0  03 00 00 00 30 00 00 00 00 00 00 00 00 00 00 00 
0x900  30 00 00 00 00 64 00 00 00 00 00 00 24 04 47 04 
0x910  00 2F 00 00 00 03 0A 00 15 35 09 00 02 2A 67 08 
0x920  07 04 05 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x930  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x940  00 07 00 03 02 00 10 00 0A 00 03 04 00 14 0C 00 
0x950  00 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00 
0x960  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x970  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x980  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x990  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 


Receiver ready - RXBUFFER_SIZE 32

4s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,1,Errors,0,IRQreg,16
5s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,2,Errors,0,IRQreg,16
6s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,3,Errors,0,IRQreg,16
7s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,4,Errors,0,IRQreg,16
8s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,5,Errors,0,IRQreg,16
9s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,6,Errors,0,IRQreg,16
10s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,7,Errors,0,IRQreg,16
12s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,8,Errors,0,IRQreg,16
13s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,9,Errors,0,IRQreg,16
14s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,10,Errors,0,IRQreg,16
15s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,11,Errors,0,IRQreg,16
16s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,12,Errors,0,IRQreg,16
17s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,13,Errors,0,IRQreg,16
18s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,14,Errors,0,IRQreg,16
19s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,15,Errors,0,IRQreg,16
20s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,16,Errors,0,IRQreg,16
21s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,17,Errors,0,IRQreg,16
23s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,18,Errors,0,IRQreg,16
24s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,19,Errors,0,IRQreg,16
25s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,20,Errors,0,IRQreg,16
26s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,21,Errors,0,IRQreg,16
27s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,22,Errors,0,IRQreg,16
28s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,23,Errors,0,IRQreg,16
29s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,24,Errors,0,IRQreg,16
30s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,25,Errors,0,IRQreg,16
31s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,26,Errors,0,IRQreg,16
32s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,27,Errors,0,IRQreg,16
34s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,28,Errors,0,IRQreg,16
35s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,29,Errors,0,IRQreg,16
36s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,30,Errors,0,IRQreg,16
37s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,31,Errors,0,IRQreg,16
38s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,32,Errors,0,IRQreg,16
39s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,33,Errors,0,IRQreg,16
40s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,34,Errors,0,IRQreg,16
41s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,35,Errors,0,IRQreg,16
42s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,36,Errors,0,IRQreg,16
43s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,37,Errors,0,IRQreg,16
45s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,38,Errors,0,IRQreg,16
46s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,39,Errors,0,IRQreg,16
47s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,40,Errors,0,IRQreg,16
48s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,12dB,Length,23,Packets,41,Errors,0,IRQreg,16
49s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,42,Errors,0,IRQreg,16
50s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,43,Errors,0,IRQreg,16
51s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,44,Errors,0,IRQreg,16
52s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,45,Errors,0,IRQreg,16
53s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,46,Errors,0,IRQreg,16
55s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,47,Errors,0,IRQreg,16
56s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,48,Errors,0,IRQreg,16
57s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,49,Errors,0,IRQreg,16
58s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,50,Errors,0,IRQreg,16
59s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,51,Errors,0,IRQreg,16
60s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,52,Errors,0,IRQreg,16
61s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,53,Errors,0,IRQreg,16
62s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,54,Errors,0,IRQreg,16
63s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,55,Errors,0,IRQreg,16
64s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,56,Errors,0,IRQreg,16
66s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,57,Errors,0,IRQreg,16
67s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,58,Errors,0,IRQreg,16
68s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,59,Errors,0,IRQreg,16
69s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,60,Errors,0,IRQreg,16
70s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,61,Errors,0,IRQreg,16
71s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,62,Errors,0,IRQreg,16
72s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,63,Errors,0,IRQreg,16
73s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,64,Errors,0,IRQreg,16
74s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,65,Errors,0,IRQreg,16
75s  Hello World 1234567890*,CRC,DAAB,RSSI,-94dBm,SNR,11dB,Length,23,Packets,66,Errors,0,IRQreg,16
77s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,67,Errors,0,IRQreg,16
78s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,68,Errors,0,IRQreg,16
79s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,69,Errors,0,IRQreg,16
80s  Hello World 1234567890*,CRC,DAAB,RSSI,-93dBm,SNR,11dB,Length,23,Packets,70,Errors,0,IRQreg,16

This was with the Dorji set to its maximum transmit power of 22dB, as compared to the E28-2G4M27S, which has the advantage of an even higher 27dB transmit power.

[Edit: oops. Reviewing the output, I see that the library defaulted to 434Mhz! So, these results were great even with the wrong length antenna installed for 434Mhz. I'll try again at the proper frequency. ]

[NeverDie]

OK, here it is corrected for 915Mhz, as it should have been the first time:

12:34:34 May 20 2022
V1.1

104_LoRa_Receiver_Detailed_Setup Starting

LoRa Device found

SX1262,915000000hz,SF7,BW125000,CR4:5,LDRO_Off,SyncWord_0x1424,IQNormal,Preamble_8
SX1262,PacketMode_LoRa,Explicit,LNAgain_Boosted

Reg    0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
0x800  00 00 00 00 29 07 20 09 00 10 19 D4 10 4E 10 13 
0x810  10 4B 10 1E 10 4B 10 1E 00 DA AA E6 DB 00 00 00 
0x820  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x830  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x840  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x850  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x860  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x870  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x880  03 00 00 5F 10 08 00 00 08 04 00 39 30 00 00 0C 
0x890  00 00 00 10 BD 0F 0A 07 10 00 26 01 01 53 06 07 
0x8A0  10 00 AD 20 5A 04 F0 02 56 56 54 43 96 20 40 00 
0x8B0  00 83 11 00 01 04 0A 4C 14 0A 2F 01 6B FF FF 00 
0x8C0  00 A0 20 00 00 00 AC 00 1C 00 00 AB 05 30 12 13 
0x8D0  0C 15 16 40 06 00 00 10 E8 00 00 00 00 00 39 39 
0x8E0  90 39 0C 04 40 20 16 38 06 00 05 04 03 02 01 01 
0x8F0  03 00 00 00 30 00 00 00 00 00 00 00 00 00 00 00 
0x900  30 00 00 00 00 64 00 00 00 00 00 00 24 04 47 04 
0x910  00 2F 00 00 00 03 0A 00 15 35 09 00 02 29 67 08 
0x920  07 04 05 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x930  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x940  00 07 00 03 02 00 10 00 0A 00 03 04 00 14 0C 00 
0x950  00 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00 
0x960  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x970  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x980  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x990  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x9F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 


Receiver ready - RXBUFFER_SIZE 32

4s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,1,Errors,0,IRQreg,16
5s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,2,Errors,0,IRQreg,16
6s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,3,Errors,0,IRQreg,16
7s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,4,Errors,0,IRQreg,16
8s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,5,Errors,0,IRQreg,16
9s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,6,Errors,0,IRQreg,16
11s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,7,Errors,0,IRQreg,16
12s  Hello World 1234567890*,CRC,DAAB,RSSI,-44dBm,SNR,12dB,Length,23,Packets,8,Errors,0,IRQreg,16
13s  Hello World 1234567890*,CRC,DAAB,RSSI,-44dBm,SNR,12dB,Length,23,Packets,9,Errors,0,IRQreg,16
14s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,10,Errors,0,IRQreg,16
15s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,11,Errors,0,IRQreg,16
16s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,12,Errors,0,IRQreg,16
17s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,13,Errors,0,IRQreg,16
18s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,14,Errors,0,IRQreg,16
19s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,15,Errors,0,IRQreg,16
21s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,16,Errors,0,IRQreg,16
22s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,17,Errors,0,IRQreg,16
23s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,18,Errors,0,IRQreg,16
24s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,19,Errors,0,IRQreg,16
25s  Hello World 1234567890*,CRC,DAAB,RSSI,-44dBm,SNR,11dB,Length,23,Packets,20,Errors,0,IRQreg,16
26s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,21,Errors,0,IRQreg,16
27s  Hello World 1234567890*,CRC,DAAB,RSSI,-44dBm,SNR,11dB,Length,23,Packets,22,Errors,0,IRQreg,16
28s  Hello World 1234567890*,CRC,DAAB,RSSI,-44dBm,SNR,12dB,Length,23,Packets,23,Errors,0,IRQreg,16
29s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,24,Errors,0,IRQreg,16
30s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,25,Errors,0,IRQreg,16
32s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,26,Errors,0,IRQreg,16
33s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,27,Errors,0,IRQreg,16
34s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,28,Errors,0,IRQreg,16
35s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,29,Errors,0,IRQreg,16
36s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,30,Errors,0,IRQreg,16
37s  Hello World 1234567890*,CRC,DAAB,RSSI,-44dBm,SNR,11dB,Length,23,Packets,31,Errors,0,IRQreg,16
38s  Hello World 1234567890*,CRC,DAAB,RSSI,-44dBm,SNR,12dB,Length,23,Packets,32,Errors,0,IRQreg,16
39s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,33,Errors,0,IRQreg,16
40s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,34,Errors,0,IRQreg,16
41s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,35,Errors,0,IRQreg,16
43s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,36,Errors,0,IRQreg,16
44s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,37,Errors,0,IRQreg,16
45s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,38,Errors,0,IRQreg,16
46s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,39,Errors,0,IRQreg,16
47s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,40,Errors,0,IRQreg,16
48s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,41,Errors,0,IRQreg,16
49s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,42,Errors,0,IRQreg,16
50s  Hello World 1234567890*,CRC,DAAB,RSSI,-44dBm,SNR,12dB,Length,23,Packets,43,Errors,0,IRQreg,16
51s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,44,Errors,0,IRQreg,16
52s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,45,Errors,0,IRQreg,16
54s  Hello World 1234567890*,CRC,DAAB,RSSI,-44dBm,SNR,11dB,Length,23,Packets,46,Errors,0,IRQreg,16
55s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,47,Errors,0,IRQreg,16
56s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,48,Errors,0,IRQreg,16
57s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,49,Errors,0,IRQreg,16
58s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,50,Errors,0,IRQreg,16
59s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,51,Errors,0,IRQreg,16
60s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,52,Errors,0,IRQreg,16
61s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,53,Errors,0,IRQreg,16
62s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,54,Errors,0,IRQreg,16
64s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,55,Errors,0,IRQreg,16
65s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,56,Errors,0,IRQreg,16
66s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,57,Errors,0,IRQreg,16
67s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,58,Errors,0,IRQreg,16
68s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,59,Errors,0,IRQreg,16
69s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,60,Errors,0,IRQreg,16
70s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,61,Errors,0,IRQreg,16
71s  Hello World 1234567890*,CRC,DAAB,RSSI,-42dBm,SNR,12dB,Length,23,Packets,62,Errors,0,IRQreg,16
72s  Hello World 1234567890*,CRC,DAAB,RSSI,-42dBm,SNR,12dB,Length,23,Packets,63,Errors,0,IRQreg,16
73s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,64,Errors,0,IRQreg,16
75s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,12dB,Length,23,Packets,65,Errors,0,IRQreg,16
76s  Hello World 1234567890*,CRC,DAAB,RSSI,-44dBm,SNR,12dB,Length,23,Packets,66,Errors,0,IRQreg,16
77s  Hello World 1234567890*,CRC,DAAB,RSSI,-44dBm,SNR,11dB,Length,23,Packets,67,Errors,0,IRQreg,16
78s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,68,Errors,0,IRQreg,16
79s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,69,Errors,0,IRQreg,16
80s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,70,Errors,0,IRQreg,16
81s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,71,Errors,0,IRQreg,16
82s  Hello World 1234567890*,CRC,DAAB,RSSI,-43dBm,SNR,11dB,Length,23,Packets,72,Errors,0,IRQreg,16
83s  Hello World 1234567890*,CRC,DAAB,RSSI,-45dBm,SNR,12dB,Length,23,Packets,73,Errors,0,IRQreg,16
84s  Hello World 1234567890*,CRC,DAAB,RSSI,-46dBm,SNR,11dB,Length,23,Packets,74,Errors,0,IRQreg,16

Interestingly, even though the RSSI is vastly better, the SNR stays at around 11 to 12dB. Well, regardless, the Dorji plainly appears to perform much better in my particular home environment, at least so far, at the given frequencies and other library defaults (which do appear to be different between the SX1280 and the SX1262 (e.g. default bandwidth), so a fair comparison will need to be more equal than what's provided by only just the library defaults).

When I'm a bit more prepared, I'll compare/contrast the two different radios performance along what I would guess is the worst possible transmission path in my house. When that time comes, I'll report the results on a new thread that will be meant for comparing the performance of different radio modules. For now this was just a preliminary test to confirm that the DORJI radio module was working at all, but the results were interesting anyway.

[Larson]

@NeverDie You Rock. That looks like a great testing platform... and tiny. In my 5-minute review I have two points to add that your post(s) solicit: 1. To protect the battery gap, as it is, how about a thin piece of cardboard? It appears that the offsets in the machine pin headers have a little room to slip a small zip-tie to restrain the cardboard so that it does not interfere with the test rig on top. It is easier to hack it than redesign, resubmit, repay and all that. 2. Love to join you on this venture so you are not single handed. I'm guilty of leaching and not teaching. I can't do it now (excuses) but hope to join you and help contribute.

[Larson]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

I don't see any uCurrent Gold's for sale at the moment, but I did find a clone of it, which has what looks like a nice improvement over the original: you can plug it directly into an oscilloscope via its BNC connector.

Andreas Spiess [https://www.youtube.com/watch?v=LUB8RWzzLWc] has convinced me to buy a Power Profiler Kit II, or one that is assembled. That way I don't need to also buy a scope! I have more work to do.

[NeverDie]

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@NeverDie You Rock. That looks like a great testing platform... and tiny. In my 5-minute review I have two points to add that your post(s) solicit: 1. To protect the battery gap, as it is, how about a thin piece of cardboard? It appears that the offsets in the machine pin headers have a little room to slip a small zip-tie to restrain the cardboard so that it does not interfere with the test rig on top. It is easier to hack it than redesign, resubmit, repay and all that. 2. Love to join you on this venture so you are not single handed. I'm guilty of leaching and not teaching. I can't do it now (excuses) but hope to join you and help contribute.

By all means! The more the merrier!

I posted some PPK2 screenshots on another thread that I recently started: https://forum.mysensors.org/topic/11954/most-reliable-best-radio

It does a nice job of measuring milliamps. I wouldn't say the PPK2 is good at measuring <1ua currents though, such as sleep currents. If that matters to you, you'll want a Current Ranger, or TinyCurrents or similar.

[NeverDie]

Worth mentioning is that the SX1280 includes a FLRC (Fast Long Range Communications) modem that can, in theory, go as fast as 1.3mbps. When time allows it may be worth giving it a try.

[Larson]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

I wouldn't say the PPK2 is good at measuring <1ua currents though, such as sleep currents. If that matters to you, you'll want a Current Ranger, or TinyCurrents or similar.

I'd say the PPK2 is the way to go. Your other post defines the <1ua current as ... nearly infinite in human terms and battery self-discharge rates. Squeezing a stone can yield no more water. Thanks for the posts, once again.

[Larson]

@NeverDie
For me, it is one step at a time.
PPKII: Bought one! I'm back ordered at DigiKey and expect delivery in early June. I'll have to wait on the uCurrent or CurrentRanger until I get a scope. ... I know, the SSD screen on the CurentRanger and a bit of math would suffice. I may get there. Sounds it sound like you have already settled on the best-radio, so your test-rig may be for naught. If you need help, and the PPKII is sufficient, let me know. I am indebted to you for your work.

[NeverDie]

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@NeverDie
For me, it is one step at a time.
PPKII: Bought one! I'm back ordered at DigiKey and expect delivery in early June. I'll have to wait on the uCurrent or CurrentRanger until I get a scope. ... I know, the SSD screen on the CurentRanger and a bit of math would suffice. I may get there. Sounds it sound like you have already settled on the best-radio, so your test-rig may be for naught. If you need help, and the PPKII is sufficient, let me know. I am indebted to you for your work.

I haven't truly settled on anything just yet. It's a bit much for just one person to sort out, so maybe I'll take a pause until after you get your gear. It would be more fun working with somebody else than doing it all alone.

[Larson]

@NeverDie I'll keep you posted. I'm just emerging from hibernation and am 'shaking-it-off'. My main interest is regenerating my PIR home network that was 433 MHz based and am interested in your LoRa ideas/posts. Is your test rig publicly available at OSH Park? I haven’t looked lately. If so I’ll order some, or have some assembled at JLCPCB. When I do that, I'll send you my spares (my minimum order is 5 and I can't use that many.)

[NeverDie]

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@NeverDie I'll keep you posted. I'm just emerging from hibernation and 'shaking-it-off'. My main interest is regenerating my PIR home network that was 433 MHz based and am interested in your LoRa ideas/posts. Is your test rig publicly available at OSH Park? I haven’t looked lately. If so I’ll order some, or have some assembled at JLCPCB. When I do that, I'll send you my spares (minimum order is 5.)

I certainly could post it if you like. One reason I haven't already is that it is very much a version 1.0, and it doesn't seem worthy. I've thought of things I would improve about it for a much better version 2.0.

[Larson]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

... very much a version 1.0, and it doesn't seem worthy.

Your humility is profound! But I understand your reluctance as I always find problems with my boards that I later need to hack. Gotta start somewhere, right? Post it please. Next I'll order some SX1280 & 1282 boards. I've got a long way to go.

[NeverDie]

OK, will do, but for full disclosure, some things I would do differently for version 2.0:

1. include an ISP header
2. make it a better fit for machine pins.
3. Change the routing on one of the power traces so that it doesn't run under the keystone AA battery holder. I found out that solder mask isn't such a good insulator, and I've had a couple of test boards short out there. The workaround was to raise up the keystone, but it's kludgy.
4. Separate the AA battery holders a bit more so that they don't risk shorting each other out.
5. Widen the board a bit so that the battery holders don't risk shorting against header pins.
6. Change the layout so that the radio modules would sit on the end, rather rather than in the center. That way, radio modules with trace antenna could hang over the end of the test setup.
7. Some changes relating to the silkscreening to make assembly less ambiguous.
8. Make all of the unused atmega328p pins accessible.

I guess what I can do is post the version 1.0 boards on openhardware.io as "work in progress" and then upgrade them to version 2.0 when/if that ever happens.

[Larson]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

I guess what I can do is post the version 1.0 boards on openhardware.io as "work in progress" and then upgrade them to version 2.0 when/if that ever happens.

I have gathered that openhardware.io can make the effort collaborative. That would be good for me. I've got limited skill in Eagle as that has been my schematic/board platform (plus, of course, board manufactures like OSH Park). Your 8 points are very actionable.

[Larson]

@NeverDie Wow, that was fast. I just found it. Thanks. I'm on the bus.

[NeverDie]

Glad you found it already. For anyone else reading this:
https://www.openhardware.io/view/22651/Version-10-atmega328p-test-platform
https://www.openhardware.io/view/22652/SX1280-adapter-board-for-test-platform

[Larson]

@NeverDie Thanks again. I've downloaded both and am putting together a BOM to send to DigiKey. Hopefully I'll sneek an order in with my back-ordered PPKII. I'm sure I'll have lots of questions. The Assembly plant I use allows one-side component placement. I'll have to choose one and it will probably be the sole 386p chip. I've never come close to soldering that fine of pitch. Surely it would be a mess.

[NeverDie]

@Larson You should leave out one 0.1uF capacitor on the atmega328p test platform. If it's installed it won't work. It's the one closest to the LEDs and the picoblade. Including it in the design was an error on my part, but the platform works perfectly fine without it.

Also you won't need the LED or resistor on the E28-2G4M27S adapter, because you'll have two LEDs to choose from on the atmega328p test platform.

[NeverDie]

@Larson As to soldering the atmega328p, it's actually easy if you use a lot of rosin flux. Only takes a minute or two to solder by hand and it comes out great. Then clean off the excess flux with IPA. This old school flux works like magic: https://www.amazon.com/gp/product/B008ZIV85A/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

[Larson]

@NeverDie I'll give it a go. I've added the flux to my running BOM list. I'm upgrading my alcohol too because my 70% isn't cutting it!

[ejlane]

@Larson While I definitely agree about the importance of using plenty of flux - it's almost magic - another very important tool is to have plenty of desoldering braid around. It's super cheap, and along with plenty of flux it makes it easy to clean up excess solder on the board or bridging between two pins, or whatever.

That combination will let you solder all kinds of things that otherwise look very daunting.

[alphaHotel]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

As you can see, I wouldn't want the batteries to be any closer together than they already are, or they would likely short out between them. As it stands, they're firmly in place, so no worries for now. These kinds of placement tolerance issues are hard to vet in advance prior to building a prototype. The keystone datasheet gave no guidance at all on side by side positioning. If I were to do it over, I think I'd give it another millimeter or two of safety factor separation.

Add some Kapton tape to the sides of the terminals next to each other to insulate against accidents without making it more cramped.

[NeverDie]

I just now added schematics to the openhardware.io projects that I posted above.

I'm trying to post the KiCAD archive, which would be ideal, but the present system extracts the .zip file and only posts a fraction of the files in the KiCAD archive. If I find some another way that works, I'll post it then.

[NeverDie]

The SX1280 has three possible DIO pins, but, as implied by the library header file, I left two of them disconnected. In hindsight, I wouldn't recommend that. It turns out you can connect any of those DIO pins to any of 16 different SX1280 interrupts using an onchip switching fabric, which I foresee will be quite handy to, for example, rapidly know precisely when a CAD cycle completes or if anything was detected during a CAD cycle. Therefore, until version 2 of the adapter board, I may bodge DIO2 and DIO3 to some of the unused atmega328p interrupt pins as a workable stopgap measure.

[NeverDie]

OK, I posted the KiCAD 6 archives for both the Ebyte adapter and for the Barebones atmega328p testbed. They appear as a .rar file in the project files on openhardware.io. I'm no longer a bottleneck. Anyone can open them up and pick up exactly where I left off if they want to make changes or fork.

Inside the .rar file is a zip file. Simply import the project zip file into Kicad, and you're golden.

[Larson]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

Also, I'm really curious as to how sensitive (or not) the ESP8266 2.4Ghz ESP-NOW communications will be to interference in a home environment that, at least so far, seems to have shredded 2.4Ghz LoRa.

My ESP-NOW (8266) 2.4 Ghz experience has been pretty uninterrupted that I know of. For about 3 years, I've been monitoring the water pressure of my home system. The sensor/ESP transmitter is at the water heater and the receiver is remote. To give some sense of the density of my WiFi environment: my browser scan detects 7 networks and I live in a medium-density neighborhood (about 4 homes/acre), so it is not too bad. Funny, the recharge curves of the system water pressure, after use, looks just like a capacitor voltage in a RC circuit, only much slower.

Unlike the low-power theme of this thread, my ESP’s drink as much as they need as they are always on and mains powered.

[Larson]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

It does a nice job of measuring milliamps. I wouldn't say the PPK2 is good at measuring <1ua currents though, such as sleep currents. If that matters to you, you'll want a Current Ranger, or TinyCurrents or similar.

Out of gratitude I'd like to buy a TinyCurrent for you. Saw the Donate button on the openhardware.io. Does that go to you?

The TinyCurrents device would be interesting to own. But if the granularity of the PPKII (still on backorder) is down to 1uA, then anything more exceeds my practical interest. For my hypothetical 2000mAhr battery, a burn rate of 1uA would last 228 years... again, if I did the math right. That exceeds my interest, though it is fun to chase down the details.

Been re-reading this thread for days. I want to help and hope to, if I can keep up with the blog entries. I've got a shopping list running - some of it already ordered!

[NeverDie]

@Larson That's very generous of you, but by no means feel obligated. The TinyCurrent-R would be the one to get. Same price as the TinyCurrent, but it has the BNC connector facing the correct direction for connecting directly to an oscilloscope's input terminal.

I do this stuff because it's both challenging and fun. I enjoy the precision of it. I just keep chipping away at it and eventually make progress. If my posts are of any use to others, then all the better: it all works best when everyone helps everybody else, because collectively we know more than any one of us individually. We've barely scratched the surface of what can be done. Synchronizing clocks among all the different motes and doing time division multiplexing among them would offer ultimate efficiency I think. The technology to do that is already known but the details of how to do it are not on display in a manner that's widely accessible.

[Larson]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

We've barely scratched the surface of what can be done.

Openhardware.io gift coming. Please use it to replace your missing uCurrentGold with the proceeds. Someday I’ll contribute my own projects to these splendid forums, I hope.

[NeverDie]

@Larson Thanks! I purchased it off Ebay, which says I should receive it by July 15,

though my guess would be probably sooner than that. I'll post a picture after it arrives.
In combination with an o-scope, It should be good for those occasions where there's a need to capture very fast action in fine detail.

[Larson]

@NeverDie Super. It will be fun to see what you do with it. Glad you have the OC scope to leverage the tool. Cheers.

[NeverDie]

@Larson You're doing the right thing by getting the PPK2. It will do 99% of what you want, and much more easily than an oscilloscope.

By the way, in case anyone is interested, there are a couple of reasons why a direct-to-oscilloscope connection beats hooking a typical 1X/10X oscilloscope probe up to, say, a uCurrent Gold or TinyCurrent. The first is that, obviously, there's less noise involved because of the short connection. The second reason is far less obvious, though, which is that the typical 1X/10X oscilloscope probes make for fairly lousy 1X connnections. For measuring small voltages on a 1X connection, you're better off using regular coax or, better still, a direct connection and eliminate the coax altogether. Why? Well, the TL;DR is that oscilloscope probes are optimized for use as 10X (which really meas divide by 10), as explained in the EEVLOG video:
EEVblog #453 - Mysteries of x1 Oscilloscope Probes Revealed – 29:49
— EEVblog

---

Meanwhile.... I've been trying to get Channel Activity Detection to work on the SX1280, but so far no joy. In some sense it's its own mode, because it "supposedly" times out automatically and returns to Idle mode after a fixed number of symbol periods that's set by SetCadParams. So, I'm puzzled as to what's going on and will have to take a deeper dive to figure this one out. Unfortunately, the library does not support CAD, so there's no working example to start from. There have been some alternative libraries posted on github, so I'll see if they shed any light on how to get CAD working.

[NeverDie]

Well, this is a good example of how having a PPK2 helps to troubleshoot the CAD problem. We can see from the PPK2 that the CAD actually is activated, once per second, as per my code:

So, just knowing that narrows down the problem considerably. The problem now is no longer that but instead why it isn't setting the IRQ flag to indicate that it has finished its detection cycle? The Rx completion flags aren't being set either.

[NeverDie]

@Larson You'll want to add some jumpers to your BOM if you don't already have them:

The above are two motes. The one on the left is used for measurement, and the one on the right isn't.

[Larson]

@NeverDie Super, thanks for pointing out the jumpers - very clear to see how they would be used.

For a long time, I've wanted to make ESP programmer boards that would use springs to temporarily hold the ESP. I actually built one using pogo-pins and a 3-D printed housing pocket. It worked but was fiddly. I may try again on your radio carrier board but differently this time. I’d like to use stiff carbon steel music wire that would be mounted in drilled holes in the existing pads and create new pads on the back-side for mechanical-solder support. Some trace revision would be in order on the back-side, and Captain Tape could cover the new solder pads if needed. Think of it as a bed of nails. Carbon steel music wire is used in springs, I think, and that is what I'd like to use for its stiffness. Perhaps I’ll make the dimension between the rows of holes about 1 mm shy of the distance between the castellated indents. Then to use, push the SX1282 down into the field of springs getting 4 or 5 mm from the carrier board or until the springs start to splay out. If it works, the castellated indent would snuggly fit the wire if I can select the right gauge. One board could then serve different radios of the same class with the same pinouts. The downside may be that I have 16 new unintended antennae. Maybe I could trim these springs shorter after learning how it works.

The compelling reason for this is to preserve the radio for later permanent installation elsewhere, if needed. There may be some performance degradation as the effective trace length would be longer. I have no idea of the electrical properties of this wire. I'll find out. I’ve got too many ESP’s that are permanently attached to dead testing, or otherwise abandonded, boards. What do you think of the idea?

Atmega328P selection question: is this linked choice the right pin configuration for the footprint you used? There are so many other choices. Digikey is out of stock, but I'm presuming I'll find them elsewhere.

[NeverDie]

@Larson AFAIK, any atmega328p with a 32TQFP package should work. Yes, they are in surprisingly short supply right now. Because of that, some people (like Great Scott!) have taken to desoldering them from Pro Mini's, which aren't cheaper but are easier to find. If you go that route, I recommend you buy some ChipQuik to make your desoldering a whole lot easier: https://www.amazon.com/gp/product/B0019UZP7I/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1 But that's me. Maybe you have your own preferred method. Whatever works. If you have old projects you no longer use, now is a good time to recycle their parts.

[NeverDie]

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

What do you think of the idea?

I think it would be easier and less iffy to simply solder it on as per usual and then use ChipQuik if you later wanted to desolder it and move it to another board. But again, that's me. That said, I somewhere have one of those springy jigs that I bought on aliexpress for programming virgin ESP8266's, and it seems to work fine--well, at least for the purpose of installing bootloaders. I never tried to do wifi with them in such a jig, so I don't know what the RF consequencies might be, if any. If you can tolerate some impairment, maybe it's good enough.

[Larson]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

... then use ChipQuik if you later wanted to desolder it...

Okay. One more item for my BOM and skill set. Thanks for the 32TQFP tip also. I do happen to have several Pro Minis and Nanos on hand since I bought them by the dozen - but they are so perfect as they are. Okay, I'll risk one and see how it goes. I am very excited to test the power difference between fuse settings and excluding the external crystal. Andrew Retallack wrote a great series on Beyond the Arduino for power savings and programming in C. I'll have to go back and look but I think it all was based on the external crystal.

[NeverDie]

@Larson Here's all you need to know in one place on how to get to 100na sleep current on the atmega328p: https://www.gammon.com.au/power He covers all the different methods. TL;DR: burn your fuses to:
External: 0xFF
High: 0xDC
Low: 0xC2
and then run Sketch J from the Nick Gammon link. That's all there is to it, provided you have an external device/circuit to wake up your atmega328p.

[Larson]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

Meanwhile.... I've been trying to get Channel Activity Detection to work on the SX1280, but so far no joy.

Is there a CAD register that can be polled? In the SX1280 datasheet section “11.6.8 SetCAD” there is discussion of a CadDone IRQ. Maybe that can be used outside of the library? Maybe with its own interrupt? It looks to be bit 13 of the IRQ Register per table 11-73. I’ve never played with these radios but have found other devices (simpler devices) to be register friendly. Most of the references to CAD are in section 11. You, no doubt, have already been there. If so, I leave the comment for others.

[edit: on second read I see you have already been to section 11 with your comment on SetCadParams. Hmmm... wish I knew more. I'll play with it when I get set-up.]

[NeverDie]

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

Meanwhile.... I've been trying to get Channel Activity Detection to work on the SX1280, but so far no joy.

Is there a CAD register that can be polled? In the SX1280 datasheet section “11.6.8 SetCAD” there is discussion of a CadDone IRQ. Maybe that can be used outside of the library? Maybe with its own interrupt? It looks to be bit 13 of the IRQ Register per table 11-73. I’ve never played with these radios but have found other devices (simpler devices) to be register friendly. Most of the references to CAD are in section 11. You, no doubt, have already been there. If so, I leave the comment for others.

[edit: on second read I see you have already been to section 11 with your comment on SetCadParams. Hmmm... wish I knew more. I'll play with it when I get set-up.]

Yeah, I'd say the Semtech SX1280 architecture is quite different than a lot of previous Semtech chips, which, you're right, in prior times were very register oriented. There still are some registers, but for SX1280 Semtech adopted a less transparent op-code architecture where you can issue commands--but in some cases there's no way to verify whether the command "sticks" like there is with a register oriented architecture, where you can always read-back the register to confirm that what you think you wrote to a register was actually written exactly as you wrote it. This is making troubleshooting relatively hard, because the chip has some internal states that you can no longer read like you could with a more register oriented architecture. Instead, you send an op-code over SPI, and maybe some parameters to go with it (the type and number of which can vary), which you "hope" works. I don't like it at all, because, among other things, it assumes that the documentation is 100% complete and flawless--and documentation never is. In particular, the SX1280 datasheet never gives the exact protocol for launching CAD, and whatever that protocol is, I seemingly haven't found it yet, despite testing numerous possibilities--though I may have gotten close. And in a system with more than one SPI device, what happens if there's some conflict in your SPI communication? How do you ever unravel what it is if there's no way to verify? Seems like heartache waiting to happen. I don't understand why the opcode system is thought to be better. Anyone know?

Anyhow, Stuart's Projects never implemented CAD, and internally I'm finding it makes, IMHO, some seemingly improper assumptions about which IRQ's are assigned to which DIO's in how it operates. That makes it brittle. That's something one just can't know when looking purely at a library's veneer. Anyway, the good news is that late last night I found a different, more general library which claims to have a working SX1280 CAD example, so I'll be giving it a test drive soon. https://github.com/jgromes/RadioLib It's not radiohead, but it's a similarly ambitious library project that spans multiple different kinds of radios and multiple different kinds of MCUs. If the CAD demo code works, then I'll adopt the new library and drop Stuart's Projects. If nothing else, I admire the authors ambition to be the one library to rule them all. As I hate changing libraries, I truly hope this is "the One" library that can do that.

[NeverDie]

Well, the Radiolib CAD example compiles and runs, and it nominally looks like it should:

I just need to introduce a separate LoRa transmitter to the vicinity to confirm that the detection actually works. I'm guessing the LoRa parameters have to be an exact match (SF at minimum and maybe other parameters as well). Then, sending a long enough string--and maybe reducing delays in the CAD detector loop--should lead to a detection.

[Edit: Yup, I tried running the generic SX1280 Radiolib transmit example, with delay removed, and the CAD detector easily detects it. It works! ]

[NeverDie]

Since the Barebones v001 is, after all, a test platform, I'm going to assemble a mote and SX1280 adapter that use Dupont headers. The reason is that the 8 sense pins on the PPK2 work with Dupont wires, and I don't see an easy way to make those work with machine pin headers. No change in the PCBs is required. @Larson You may want to assemble your motes this way from the get-go.

By the way, can anyone here recommend where I can buy "good" Dupont wiring and connectors? If I buy from China, I seem to often get very loose-goosey connections.

P.S. I could be wrong, but the RadioHead library seems to have stopped progressing. None of the newer LoRa chips are in any of its examples. Too bad, as it was a very progressive library in its day. That leaves RadioLib as the library to rule them all. However, it has a very different overarching paradigm than, say, StuartsLibrary, which was easier to grasp.

[Larson]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

Dupont headers

My plan is to use female headers on the Barebones board, then to use doubled long-legged male headers on the SX1280 adapter board like these from Digikey. It all stacks together and bed of nails will stick out the top of it all. That way the PPK2 Dupont females can nicely plug onto the any of the protruding males in the stack that I select to use as a signal or interrupt. Again, I risk a bed of 16 inadvertent antennae with all that metal in the air. I can always snip-off the pins I don’t use. PPK2 is expected on Monday!

I spent the day shopping for parts at Aliexpress, Digikey, and Amazon. I found some 328P's at Aliexpress. Could be some time for the Aliexpress parts (SX1280 module). In the meantime I'll be learning KiCAD. I'm hoping that Eagle and KiCAD might allow file swapping as Eagle is familiar ground for me. Or ... I could just take the easy path and go directly to OSHPark since you have made it so easy.

[NeverDie]

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

Dupont headers

My plan is to use female headers on the Barebones board, then to use doubled long-legged male headers on the SX1280 adapter board like these from Digikey. It all stacks together and bed of nails will stick out the top of it all. That way the PPK2 Dupont females can nicely plug onto the any of the protruding males in the stack that I select to use as a signal or interrupt. Again, I risk a bed of 16 inadvertent antennae with all that metal in the air. I can always snip-off the pins I don’t use. PPK2 is expected on Monday!

Somehow I had gotten it in my head to use extra long female headers (such as these, https://www.amazon.com/gp/product/B071GTP5V6/ref=ppx_od_dt_b_asin_title_s00?ie=UTF8&psc=1, or similar) on the adapter board and then regular female headers on the basic atmega328p PCB. Maybe it's a wash?

[NeverDie]

@Larson KiCAD 6 allows for importing Eagle projects right from within KiCAD 6 itself. Not sure what options, if any, might exist for exporting to Eagle. I think you'll like KiCAD 6. It's pretty easy to pick it up--much easier than earlier versions. I previously used Diptrace, because it was so easy, but I've since moved completely over to KiCAD 6 because it's just as easy, but also more widely supported in terms of parts libraries. Also, unlike Diptrace, it makes sharing projects a snap--just create an archive (literally a one menu click operation), and share the resulting zip file.

[Larson]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

Somehow I had gotten it in my head...

So many ways to cook an egg. The pleasure is in eating it. I'll take a picture of my wedding-cake-of-a-board stack when I finish. It may not be until July at my pace.

Re KiCAD: I look forward to trying. Recently JLCPCB made me learn EasyEDA and it really went well. Learning Eagle took me a week the first time, 2 days the second time, and still... I have to retrain. That is the joy of it all, right?

[NeverDie]

By the way, I've recently been reporting some other progress on the SX1280 on my radio-comparison thread: https://forum.mysensors.org/topic/11954/most-reliable-best-radio/27?_=1654402718278 For things that are both battery operated and subject to remote control, the importance of being able to quickly wake them up at a moments notice, but with minimal ongoing energy drain, is an important topic. Examples: key finder fobs, remotely opening/closing blinds at the push of a button, etc.

[Larson]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

reporting some other progress

Yes, I have been there, though not lately. Thanks for the reminder. What great information and exchanges.

[NeverDie]

From the perspective of having some kind of general purpose platform--not just for testing but as a "go-to" for general use--it would be nice to have some kind of project box or enclosure of some kind for it. That would prevent things in the environment from pushing up against the electronics/PCB and possibly shorting it out. Anyone have any ideas on what form that should take? There's always the option of custom 3D printing something, but if there were a box of the right size already out there, that would be much easier. In that case one could customize the PCB to fit it precisely instead of 3D printing a box to precisely fit the PCB. Having a nice enclosure is one of the things that typically separates store-bought sensors from hobbyist projects.

By the way, the SHT45 TH sensor that I mentioned in the OP is now available on mouser. Unfortunately, it seems they nearly doubled their asking price over what they had earlier projected, so that's a bit of a disappointment. I guess these days a lot of chips are marked up due to the widespread shortages going on.... The chip itself is quite small, but it only has four landing pads, so I'm thinking that hand soldering it should be manageable. A simple adapter board, like this one for the SHT40, would allow it to easily fit the platform:

because the platform's pinout already anticipates adding up to two I2C devices without any fuss, like thus:


FYI, I updated the project page with a bunch of photos.

[Larson]

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

Anyone have any ideas on what form that should take?

Looks great! I’ve had good luck at Aliexpress with a variety of boxes like these. Some boxes have mounting lugs on the bottom. Your board has no space for mounting holes. I could help with the redesign??? Then I'd use stand-offs to get to the lugs and suspend the batteries in the air off the bottom. The antenna could be curled inside the box, but I've found that to have a negative impact (probably the polairity thing.

[Edit: Forgot to say that I've thrown in the little bags of desiccants for good measure. I find them in my pill bottles.]