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.
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.
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?
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!
After my SD card crashed, I had to set up my LORAWAN Gateway again and followed the instructions as before, but unfortunately I now get the following error message when I look at the status with the following command (SPI is on):
sudo journalctl -u ttn-gateway -f
Aug 31 10:58:27 LORAWAN ttn-gateway: INFO: [main] Starting the concentrator
Aug 31 10:58:27 LORAWAN ttn-gateway: ERROR: [main] failed to start the concentrator
Aug 31 10:58:27 LORAWAN systemd: ttn-gateway.service: Main process exited, code=exited, status=1/FAILURE
Aug 31 10:58:27 LORAWAN systemd: ttn-gateway.service: Failed with result ‘exit-code’.
Aug 31 10:58:32 LORAWAN systemd: ttn-gateway.service: Scheduled restart job, restart counter is at 24.
Aug 31 10:58:32 LORAWAN systemd: Stopped The Things Network Gateway.
Aug 31 10:58:32 LORAWAN systemd: Started The Things Network Gateway.
That’s the result of: service ttn-gateway status
pi@LORAWAN:/opt/ttn-gateway/bin $ service ttn-gateway status
● ttn-gateway.service - The Things Network Gateway
Loaded: loaded (/lib/systemd/system/ttn-gateway.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Wed 2022-08-31 11:27:43 CEST; 4s ago
Process: 9223 ExecStart=/opt/ttn-gateway/bin/start.sh (code=exited, status=1/FAILURE)
Main PID: 9223 (code=exited, status=1/FAILURE)
Aug 31 11:27:43 LORAWAN systemd: ttn-gateway.service: Main process exited, code=exited, status=1/FAILURE
Aug 31 11:27:43 LORAWAN systemd: ttn-gateway.service: Failed with result ‘exit-code’.
The clue is in the “failed to start concentrator” error message. (Note: Forum search for this should generate many hits/threads as common problem)
When reflashing uSD card did you remember to configure/change the reset pin assignment in the appropriate _conf.json or start.sh file (depending on what firmware you are using or which interface board or set of dupont cable config you have built to interface the conc board to the Pi). Had fun doing this myself just last night…4 bursty power cuts in the area over a 48hrs period managed to corrupt/knock out 5 local Pi based GW’s - including an iMST LoRaWAN Lite Gateway using PiB+ & iMST GW board with official interface card…saved that one to last night and had happy hour or two trying to remember/guess BCM_PIN assignment for that config from 4-5 years earlier! :scratching_head:. Common pin numbers used by many boards are 17, 22, 25 & 5…guess which one was last tried and worked!