Rather than re-run the installer, find the copy of global_conf.json being used, and change it there. Also make sure there isn’t an overriding address in local_conf.json
But you’re using really ancient code without the jit queue that v3 expects - uplinks will work, but downlinks may be iffy (with negative impact to others, not just yourself). You really should update to a more modern version of the packet forwarder software, which should still be compatible with your hardware (you can use a different SD card for the install if you want to be absolutely sure of being able to go back)
and startup scripts doing the gpio based reset about as you were before
But again this has nothing to do with the immediate problem of changing the server address, but rather only the subsequent problem that the outdated packet forwarder doesn’t support the way v3 wants to schedule downlinks to tolerate Internet backhaul latency.
● ttn-gateway.service - The Things Network Gateway
Loaded: loaded (/lib/systemd/system/ttn-gateway.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2021-02-16 17:09:53 CET; 1h 35min ago
Main PID: 251 (start.sh)
├─251 /bin/bash /opt/ttn-gateway/bin/start.sh
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway: # PULL_DATA sent: 3 (100.00% acknowledged)
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway: # PULL_RESP(onse) datagrams received: 0 (0 bytes)
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway: # RF packets sent to concentrator: 0 (0 bytes)
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway: # TX errors: 0
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway: ### [GPS] ###
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway: # Invalid gps time reference (age: 1613497389 sec)
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway: # Manual GPS coordinates: latitude xx.60830, longitude x.32160, altitude 65 m
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway: ##### END #####
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway: INFO: [up] PUSH_ACK for server router.eu.thethings.network received in 45 ms
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway: INFO: [down] for server router.eu.thethings.network PULL_ACK received in 44 ms
As I will likely face the same issue when migrating my IMST-based gateway to V3, I’m very interested in this topic as well!
I have checked out the install script maintained by gonzalocasas on github and learned that a fork of Lora-net/lora_gateway is part of the ttn-zh gateway software.
I skimmed briefly through the libloragw sources and noticed that quite a few adaptions have been made to make the code work with the IMST IC880A concentrator board.
I understand why packet forwarders aren’t specific to host or concentrator boards. But since I’m not an experienced software developer I’d like to suggest the assumption that adapting newer versions of Lora-net/lora_gateway to make it work with the IC880A board is probably not an trivial task.
If this thread is going to evolve into an IC880/RPi V3 HOWTO I will be happy to contribute by testing and sharing results/findings.
The install script for Pi needs a bit of fettling but as I’ve only two weeks back moved my RAK833 Pi gateway from V2 to V3 by compiling using this, I can revisit the Pi’s history and get the script working cleanly.
I believe that’s a mistaken conclusion, especially absent any cited specifics. That old code you reference certainly works fine with other brands.
What ends up hardware unique really mostly has to do with the host computer - which GPIO is used to reset the concentrator, and which linux spidev it’s on.
Where things are concentrator-unique, that’s mostly to do with which radio clocks the baseband and which is used to transmit, but that’s something specified in the global_conf.json, not the C sources.
The one exception to this would be the RAK cards that foolishly have a sluggish and unecessary level translator, there you have to also drop the SPI clock speed, probably to 1 MHz for true reliability.
I refer to commit f98d1d1 of TheThingsNetwork/lora_gateway, which is a fork of Lora-net/lora_gateway. It adds an IMST related header- and c-file to the package.
The install script downloads and compiles the code. I referred to it as “adaptions to make the code work with…”, for the reason that I did not find the same definitions in Lora-net/lora_gateway.
I went over the sources again and the code differences actually reflect your explanations.
Hi all. The solution i propose will not answer the question for your situation but will add more flexibility to your gateway trough remote management as well as a solution to connect the gateway to both V2 and V3.
That means that during the quoted interval you haven’t seen any valid radio traffic; only limited help can be provided without a log actually showing some. Failures could be due to a node with a few tens of meters of the gateway overloading it, but they far more often result from random non-LoRaWan (and even non-LoRa radio energy.
Feb 20 09:17:42 eu1.cloud.thethings.network ttn-gateway: # PUSH_DATA acknowledged: 0.00%
That means your gateway is not in contact with TTN, either.
No Dependency on Local Time Keeping: A Station obtains time synchronization from the LNS. There is no need for a local UTC-based clock. For Class B, a Station only requires a PPS routed to the concentrator. Synchronization of the PPS pulse with the global GPS time then is negotiated with the LNS. No NMEA-based interface, or any other kind of interface to a GPS module, is required. If present, however, it is used to augment health information.
So one of the great features of Basic Station is it doesn’t need any local time. Provided your GPS PPS (Pulse Per Second) line is connected into the SX1301 Concentrator, all you need to do is add
to your radio_conf object.
Not quite sure about the last sentence “If present, however, it is used to augment health information.” I can’t find where you can pass the tty_path.