Hacking away is good 
.
I have used the Chirpstack multiplexer to bypass restrictive firewalls by sending the UDP packets over NTP port (123/udp) since this is usually always open. The multiplexer will just forward 123/udp to 1700/udp and back seemlessly. 
It’s fairly straightforward to run a completely local LoRa stack with Chirpstack. Basically just run all the apps in separate containers on a single Pi. Basicstation → Gateway Bridge → Network Server → Application Server from there you could point webhooks or MQTT to other local apps.
I did it once a while back and it wasn’t difficult at all. One thing I like is that installing Gateway Bridge on the actual gateway with your concentrator makes it pretty easy to pipe to an MQTT broker (I liked emqx) from which you could send anywhere, local or cloud.
You could do this with TTS (or is it still called the things stack?) by installing locally too.
@xoseperez that multiplexer is an interesting find, thanks for sharing.
Thank you for the detailed overview - I am sorry I must have caused some confusion here.
I actually had a Chirpstack already running, courtesy of RAKwireless Firmware for the RAK5146 - so not on balena :). But I actually manged to setup my own, private gateway at that time.
I think I will try to go into the direction of setting up the udp-packet-forwarder - but sending all data into an (maybe existing) balena Chirpstack instance and include the multiplexer. I basically want my own household sensors off TTNv3 - espcially as I want them to continue working even if the internet is flaky. Yesterday night I prepared the otherside of things, made an MQTT bridge to TTNv3 for my current sensors, brought the payload down and decoded it offline - and setup the InfluxDBv2 and Grafana instances (this is all done on my homeserver, so no balena there, but some Docker). So now I only need to send the calibrated data to InfluxDB and graph them in Grafana to be able to move away from external data logger/graphers (I never had the time to make it right, so… yeah, shameful to admit it. But now I want to get that done as I have to do something similar for my company, so doing this at home is a good learning oppurtunity. Also, I will include some balena Sensor nodes and pipe the data to the same Mosquitto instance and got then one central calibration/ingestion script which will make including different/additional sensors very easy as a preprocessing entity to InfluxDB).
As for emqx - I think I will take a look at it. Seeing the link I was laughing because some weeks ago I installed their MQTTX which is one of the most capable MQTT browsers/clients I have seen so far. I like that thing a lot :). However, as my Master Thesis centered around the performance of Message Brokers in extreme situations, I am very loyal to the winner (and my personal favorite since ever), Mosquitto . But thank you very much for all the infos!
Have you seen timescale, I’ve been testing rather than Influx which has been so much easier since its Postgres under the hood 
Nice one. Though I must admit I am a total fan of good old MySQL and MariaDB - sometimes MSSQL. I do need to configure quite some Postgres for my job, but I never really got the hang of it 
Does this integrate into Grafana easily, just out of curiosity?
Yeah, its the same as picking postgres as a source in Grafana
So… my ultimate goal was to integrate my gpsTime ( GitHub - nmaas87/gpsTime: balena enabled GPS NTP timeserver ) project with the RAK5146 - as the RAK5146 got a nice GPS module and even output the PPS signal - but sadly RAK did not manage to output it via the RAK2287/RAK5146 Pi HAT to the Raspberry Pi.
My initial idea was to solder directly to the PCI-E socket - just getting the PPS signal from there. However, the thing I REALLY WOULD NEED in my lab would be a 10-20x binocular/stereomicroscope - because these jobs are too tiny for my 2x magnifying glass. I tried, but failed. So I shelved the idea again. Until today.
In the meantime, I had migrated my LoRaWAN sensors from ThingSpeak to my private InfluxDB/Grafana instance and still had one ESP8266/BME280 combo hanging at my desk that reported to ThingSpeak. I wanted to this combo to be gone - or more than that, replaced by some RPi with belanaSensor. Hm… let me think. I got an RPi 3 just running the udp-packet-forwarder… basically having its i2c interface free… and a lot of cpu cycles and memory left… wait a minute…
I started again with the RPi hat and noticed the unpopulated 9x2 area on the board.
A radio? Maybe meant for some SX-something-something? Hm… Would not make sense…
I pulled out my multimeter, getting the first gnd point measured. Then I saw that some points where connected to i2c. Ok, damn, this is no SX. The 9x2 grid makes no sense, these pads should be for some non-radio function. But,… it got an antenna out so… Let me see. I think this hat is just recycled… What else got RAK in stock? BINGO! - the RAK2247 Pi Hat ( Connect RAK2247 Concentrator module to Raspberry Pi with this Pi HAT – RAKwireless Store ) - with a big fat Ublox MAX-7Q module at the unpopulated spot. Where is the damn manual?! Ah… it matches my findings! ( https://www.u-blox.com/sites/default/files/products/documents/MAX-7_DataSheet_UBX-13004068.pdf )
Could it be that even the 1 PPS output would be linked from this unpopulated area to the 1 PPS port on the PCI-E?! IT IS!
So I got my 3v3, GND and SDA/SCL for my BME280 sensor - and the 1 PPS output already tied to the RAK5146 without the need to solder a fine pitch!
With that, I needed to go through all RPi pins and find one which was not used by the hat. Spoiler: They are nearly all used, except the I2C ID ports and GPIO 4 - so GPIO 4 it is! I soldered the 1 PPS output to the GPIO 4 - which will be used later by my gpsTime project.
Then I added a breakout for 3v3, GND, SDA, SCL
(Some reference stuff RAK2287/RAK5146 Pi HAT Datasheet | RAKwireless Documentation Center / RAK5146 WisLink LPWAN Concentrator Datasheet | RAKwireless Documentation Center )
After that - I put everything together on the wall behind my TV.
Loaded up a new docker-compose binding udp-packet-forwarder (with GPS=0), a gpsTime instance using GPIO4 and balenaSensor with my network mosquitto server. And thats it
Now I got my RAK5146 working (with fake GPS, because I don’t need it, the PPS output will probably be used on the RAK5146 module as it is hardwired), gpsTime with precise GPS/PPS signal from the RAK5146 M8Q module and balenaSensor taking care of my BME280 - so that now everything is on one neat system.
And well, what shall I say? It works!
Still have to see about the LoRa multiplexer, but thats something for another weekend or so
So, I got the chirpstack-packet-multiplexer running as the fourth service on my RPi 3 - and it has still a lot of resources free :). The mux is currently only used as plumping between the udp-packet-forwarder and TTNv3 - but as soon as I get my own Chirpstack setup again on my side, I will add this as another destination and rework my Mosquitto/InfluxDBv2/Grafana setup to an all-in-house system. Very welcome, after I had some ISP outages last week
Looking forward to see this running on balena @nmaas87
do you have a public repo for this?
Hi Marc,
I don’t really know which part you specifically mean.
The Mosquitto / InfluxDBv2 / Grafana stack is running on Docker x86,
the udp-packet-forwarder / chirpstack-packet-multiplexer / gpsTime / balenaSensor on balenaOS RPi 3 / AARCH64.
I have send my current files to this repo, but you need to tweak the files to your own systems (and the gpsTime will not work if you have not hacked your hat like I did): GitHub - nmaas87/loragw
Thanks @nmaas87 i was thinking on having Chirpstack LNS running on balena
So, in the meantime I setup my local Chirpstack instance on my home server and now get everything working.
The Multiplexer does deliver all messages to TTNv3 as well as my local Chirpstack instance and I could migrate my Sensors to be “at home” only. I also ordered some RAK11300 so that I can more easily build my own LoRa nodes, but I need to get working in KiCad 6 (finally) and wait for the parts to arrive (and design the boards, order those and the needed parts etc etc etc). And I updated my blog on the topic :).
In case you were interested @nmaas87 @mpous, I’ve been trying to get my Oratek Tofu carrier up and running with the RAK5146. At first I was using RAK’s Pi Hat, because the Tofu only has a m.2 connection on the bottom of their board. But recently they came out with an m.2 → mpcie adapter.
At first, I didn’t think it would work (because nothing is ever that easy) but in fact it’s working very nicely.
Combined with @xoseperez’s bascistation repo I now have a 4GB CM4 with LoRa, Cellular backhaul (Sixfab LTE Hat), UPS power with about 5 hours of battery backup (Sixfab Power Hat) that is solar ready, and plenty of computing power to grow into.
Here it is, no power cables 
Extremely rad setup you got going on there :)! Love it!
I added some sensors to mine and am going to add an advanced C02 sensor and radiation sensor as well soonish - and that with an RPi 3. And I still got tons of memory and cpu cycles left 
- so you can do so much more with the CM4
@xoseperez I was poking around in your repo’s tools folder basicstation/tools at master · xoseperez/basicstation · GitHub.
Was going to experiment a bit with it this weekend. Looks like you’re trying to parse the bs logs. How is it working for you?
Been wanting to do this for a long while! Wishing that Semtech would write some prometheus metrics and/or allow for structured json logs out of the box.
Oh, they are still a WIP. Actually, thank you for reminding me about them!
Pretty much a dirty hack to get some metrics, I’m sure there are better ways to do it. My goal is to display some basic metrics on an OLED display connected to the Raspberry Pi based gateway.
I am mostly interested in the log2api one, since I have no need to persist data… will try to work on it a bit this week.
@barryjump I have reviewed the parsers and decided to move them to their own repo instead of being under the basicstation repo (after all there is a parser for the UDP Packet Forwarder image too). You can now find them here:
Still having some issues with the log2idb logger but will fix them soon. Any feedback will be very welcome!
EDIT: by the way, you can run the parser itself inside a container but I have yet to test it with balena…
@nmaas87 @barryjump et al. Thank you for this detailed thread. I’m in the market to build a Raspberry Pi-based LoRaWAN gateway with the following features:
I’ve only found a few SX1303 concentrators on the market and all of them have minimal documentation. The one I’m most interested in ATM is the RAK5146, hence my interest in this discussion.
Correct me if I’m wrong, but I gather that the RAK2287/RAK5146 Pi HAT generally works with the RAK5146, but does not route the PPS to the RPi. That being said, I also see that RAK suggests their mPCIe-to-USB adapter for the RAK5146 USB version, but this of course has 0 documentation. I’m wondering if anyone knows whether this adapter will route everything necessary (e.g. PPS) to the RPi to satisfy the above features?
I’m also a little confused as to the general state of LoRaWAN support for SX1303 concentrators using the USB interface. I’ve seen many instances, in different repositories, of developers warning that the USB versions aren’t supported. Admittedly, these were a number of months ago. Would I be shooting myself in the foot in terms of supporting the above features if I get a USB concentrator? The reason I ask in this case is because the SPI version of the RAK5146 does not support LBT (why?).
Does anyone know of any reasonable Pi-based solution, that doesn’t require any hardware modification, that will satisfy the above features? I’m not partial to the RAK5146.
Thank you.
this is correct, the PPS is internally wired to the RAK5146. The Hat does connect the GPS module of the RAK5146 to the RPi via the GPIO connector and the RAK5146 via USB, but not the PPS signal of the GPS module.
This is an absolute generic/off-the-shelf adapter, if you look at the backside of the module you will see that it even got an SIM card slot and only some minimal power circuitry. Meaning: You will only be able to use the RAK5146 itself, but not even the GPS itself is going to be connected to your RPi (and the PPS neither)
I cannot answer that question, maybe @xoseperez has more knowledge about that.
As for basic station, Xose made a good repo which should be working very well with the 5146 ( GitHub - xoseperez/basicstation: Basics™ Station Packet Forward protocol using Docker ). I am still running it on the old udp-packet-forwarder as it suits my needs. Also its sadly my only RAK5146 and it is running in production right now, so I got no spare one to test stuff with.
Cheers
