Upgrading to the new TTN V2 (PI with iMST gateway board)

Hello - I am just getting back into LoRaWAN after a significant period of serious ill health, and obviously a lot has changed. I logged into the console today and it looks like the well publicised upgrade to V3 has taken place.

To my surprise, I noticed that my Raspberry PI gateway has been migrated across from the old system (maybe I did it, but have forgotten - it has been a rough year!) - however it does not appear to connect to my PI gateway.

Are there any guides that I can read that will tell me what to do so that I can get my PI gateway with iMST radio board working again? I presume I need to make some changes at the PI end?

I will have a google, but if anyone knows of a good guide that would be gratefully received. As my strength improves I find I’m getting bitten by the LoRaWAN bug again.

Regards to all

Mark

It depends on what software you are running in the Pi. Basically you need to edit/replace the existing json file which points to the TTN servers.

It all starts with ADDing your gateway in the new console. Once you’ve done that you should find a download button for a new global_conf.json which contains all the right settings. Download that file, find the existing one on the Pi and replace it. If the Pi also has a local_conf,json you should remove that.

1 Like

Jac thank you so much - yes I can see a global_conf.json file in the TTN console. I’ll get to work. IIRC, the software I’m using on the PI is an old ChirpStack build (though it updates itself so perhaps its not so out of date) from before it was renamed to ChirpStack. My gateway has been running trouble-free 24/7 for around 4 years (I made some edits to the file system to use memory for log files rather than the SD card and its still running).

Is there a better/more appropriate gateway build that I could install?

Regards

Mark

Chirpstack is primarily a server suite to create a private network that would exist as an alternative to TTN, rather than as part of it.

That said, they’ve published some software for operating pi-style gateways, that is part standard and part custom. The standard element would be a UDP packet forwarder, though indeed probably in the older checkout it sounds like you have an older one (particularly if there’s no mention of “JIT” in the logs). The custom one would be a bridge component that then repacks the traffic as JSON or protobuf to send it over MQTT to a private chirpstack server - rather than TTN’s. So if you were going to use their gateway software, you’d have to change the global/local json configuration file to point the UDP forwarder component to TTN servers instead, rather than the local or remote instance of the chirpstack bridge (and you’d probably want to stop the various chirpstack services other than the packet forwarder from running)

Updating to a modern UDP forwarder, or even better a basicstation one would probably be better. Since it’s a pi, you can always set aside the existing card and start over with a fresh install on a new card.

The one key piece of information you need to determine and preserve is the knowledge of which GPIO on the pi controls the concentrator chip reset under whatever wiring scheme you’ve used to connected them. This is probably in a gateway start or reset script.

Hey there thanks very for the reply and the information - very useful. Basicstation looks very interesting, especially as it can be built directly on the Pi. It looks like it supports the IC880A sheild, too, which has worked 24/7 for the last four years.

Excellent - thanks so much for this info - I’ll go and start reading now!

Regards

Mark

The (probably) easiest option would be to use Deploy a LoRa Basics™ Station gateway with TTN and balena if you want to go the BasicStation route.

1 Like