Having worked professionally and amateurishly with LoRa and LoRaWAN, I feel that the modulation scheme and supporting hardware are awesome. Low power, it's awesome; each LED blink on the dev board draws more current than the LoRa transmission itself. The packets are modulated and transmitted at a sub-gigahertz frequency that comfortably slips through concrete walls and then bounces off buildings made of the same material to magically reach the receiver a few measures of distance away. Often those signals reach a gateway antenna and stuff (IoT?) happens. The LoRaWAN gateway comes with a concentrator baked in it. It concentrates very hard to receive simultaneously 8 channels in the EU and friends or up to 64 in NA and friends. It can therefore receive many transmissions at the same time and then queue up possible responses to them, most of which should make in to the end device rx window before they close, wonderful. Out of words,concetrator=more power,single channel=less,less=more
Files
debug_console.png
First serial debug with Wio-E5 mini connected to OpenWRT router
Life is a struggle, and I've been struggling for the past few days with this project and many other things.
I've spent most of my free time with CNC path operations for a small boat plug that I'm building out of XPS foam layers at school, but thats another story.
With this project I've mostly had problems with passing/converting the serial output of the e5 mini 'gateway' to UDP packets that Chirpstack would understand.
Nevertheless, I've succeeded in forwarding messages with my own python script. I thought that I'm too cool for the legacy Semtech Packet Forwarder so I wrote my own. Well... it took me ages, I'm a bit rusty with my boat adventures and everything happening lately. First I wanted to test the packet forwarder functionality with netcat, but ran into encoding issues. Then I tried C and got lost. Finally python solved the problem, python is not my forte, but it just worked. Next I need to implement downlink functionality to my UDP socket python script.
I decided to follow the easy route for now with the packet formatting, its JSON. Forget about the "time" and "tmst" values above, the rest is real information :)
JSON is not ideal, but I'm worried that I'll get tangled up in writing gateway bridge code for OpenWRT. I can just compile the Semtech Packet Forwarder. Furthermore I'd have to anyway convert most other formats to something that Chirpstack understands. Eventually, when this single Channel LoRaWAN gateway traffic pipeline is complete and has been running for some time I will change JSON for a better packed format.
The best part is that it can "emit characters as you go", and I like to go. It means that the E5 can stream out JSON over USB character by character when a packet arrives. Combine that with the Mbed OS Event Queue and you can stream like there's no tomorrow without any major memory issues, other than my own.
Next I'll compile the packet forwarder on the router and sniff what it wants from what it thinks is a 'normal' gateway. We will give it all the JSON it needs, but not more.
Picked up the Wio-E5 mini and wrote a simple Mbed OS LoRaWAN traffic sniffer using the LoRa radio driver api.
Reinstalled OpenWRT on my Spitz (GL-X750V2) along with everything needed for my family to get back online and the needed USB kernel modules.
Plugged the E5 to the only USB port on the router and to my pleasant surprise I could see some debug messages indicating that the 'gateway' is indeed receiving LoRaWAN join request packages.
Next I will probably write a simple packet decoder for the stm32, I could also dump every hot potato raw payload to the router, but thinking ahead some message format/protocol would be in order. There will be downlink messages after all. Who knows, the LoRaWAN packet does carry most of the necessary information anyway. Traditionally the communication is JSON, but I've been meaning to play around with alternative options like MessagePack and Protobuf. One thing to consider is the target single channel gateway mcu families, we would value a low footprint in the memory department.
Eventually I will measure power draw. The Wio-E5 STM32WLE5JC Module draws 6.7mA in receive with mcu (active?) as per the manufacturer. The STM32WLE5JC datasheet does show similar figures when all the peripherals are switched off. Lowering the clock speed will drop that value as will sleep modes. It would be interesting to see if the SoC transceiver can wake up the MCU from deep sleep with a receive interrupt. Much to discover, and to get tangled up in, been there done that - looking at you Mbed OS...
One the router side I currently feel like I want to pass the potato to the cloud as fast as possible with minimal effort. I might start with the traditional Semtech UDP forwarder method, it works. The traffic will probably land in my Chirpstack instance. However, yet again there is a chance to experiment, it would be nice to try MQTT message queuing/buffering when the connection to the external LoRaWAN network server is down. Someday I would like to write my own LoRa protocol for mesh networks and at least some infrastructure could be built now.
So here we go again... on our own? Today's goal was to get this project set up here, baby steps.
I ran out of project description space, I admit it's a good idea to limit that, ain't nobody gonna read my story. I'm no author and I don't know where that was going anyway :)
What I'm planning on making is often called a single channel LoRaWAN gateway. I've done it before, a long time ago, at least in technology terms. Somewhere around 2017 I had just started a new job and was tasked to fiddle around with LoRa and LoRaWAN. It was all new to me, and I couldn't believe that a transmission often covering multiple kilometers without line of sight aka LOS with minuscule power was possible. One thing led to another and I ended up being the LoRa guy at my company, carrying out LoRa certification testing among other things.
But before I got deep into the LoRa adventures/madness, I made an esp8266 single channel LoRaWAN gateway. I found code on Github, and back then there wasn't much available on this topic (I need to find the source to give credit to). I might have paired the esp8266 with a RFM95 or some other module. It worked and that was that, moved on to full blown LoRaWAN gateways and Bob is actually not my uncles name.
Enter 2021, I get myself a small OpenWRT 4G GL router (GL-X750v2) - nifty apparatus by the way, and eventually try to use it as a LoRaWAN gateway with a USB dongle concentrator. The poor router didn't have enough pixies to power the dongle from the USB port. And that brings me to the current scenario, I have a bunch of LoRa hardware and no gateway.
The idea is to design a board/motherboard with either a mcu and a LoRa tranceiver or the stm32wle5jc. Anyway the radio listens, mcu sleeps, gets interrupted and pushes what it received through USB to the router or whatever capable is hooked up and back and out again if so wishes the network server. MQTT might be mixed into this. A low power LoRaWAN gateway that's the goal.
Hello and thank you for the question, very interesting since I'm not familiar with rnode. Looks like it's a different network architecture so not compatible with LoRaWAN. I will look into RNode, it might be what I've been looking for.
Hello and thank you for the question, very interesting since I'm not familiar with rnode. Looks like it's a different network architecture so not compatible with LoRaWAN. I will look into RNode, it might be what I've been looking for.