Trouble with migration a RPi ic880A GW to V3

BK-Vest · February 16, 2021, 4:38pm

Trouble with migration a RPi ic880A GW to TTS! (It worked in TTN V2)

I used this Image: GitHub - ttn-zh/ic880a-gateway: Reference setup for iC880a gateways running The Things Network

To migrate I thought just restart the configuration:

sudo ./install.sh spi

and changes the server (hostname) “eu.thethings.network” to “eu1.cloud.thethings.network”!

But in the TTN V3 console no event are shown! (A new GW with same EUI are installed)

The messages comming in in TTN (V2)!

What must i do ?

E_T

Following config file i found: /opt/ttn-gateway/bin/local_config.json

{
„gateway_conf“: {
„gateway_ID“: „B827EBFFxxxxxxxx“,
„servers“: [ { „server_address“: „router.eu.thethings.network“, „serv_port_up“: 1700, „serv_port_down“: 1700, „serv_enabled“: true } ],
„ref_latitude“: xx.6083,
„ref_longitude“: x.x216,
„ref_altitude“: xx,
„contact_email“: „xx@xxx“,
„description“: „xxxxxxxxxx“
}

Is the „server_address“: „router.eu.thethings.network“

cslorabox · February 16, 2021, 5:03pm

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)

BK-Vest · February 16, 2021, 5:11pm

Hallo cslorabox.

thank you for the answer!

Has you a possible link to a more current installation for RPI and ic880A?

E_T

cslorabox · February 16, 2021, 5:20pm

Packet forwarders aren’t really specific to host computer, or to brand of the board holding the concentrator chip.

You should be able to use

GitHub - Lora-net/packet_forwarder: A LoRa packet forwarder is a program running on the host of a LoRa gateway that forwards RF packets receive by the concentrator to a server through a IP/UDP link, and emits RF packets that are sent by the server.

with its supporting

GitHub - Lora-net/lora_gateway: Driver/HAL to build a gateway using a concentrator board based on Semtech SX1301 multi-channel modem and SX1257/SX1255 RF transceivers.

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.

BK-Vest · February 16, 2021, 5:47pm

Here some more infos:

● 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)
CGroup: /system.slice/ttn-gateway.service
├─251 /bin/bash /opt/ttn-gateway/bin/start.sh
└─545 ./poly_pkt_fwd

Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway[251]: # PULL_DATA sent: 3 (100.00% acknowledged)
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway[251]: # PULL_RESP(onse) datagrams received: 0 (0 bytes)
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway[251]: # RF packets sent to concentrator: 0 (0 bytes)
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway[251]: # TX errors: 0
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway[251]: ### [GPS] ###
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway[251]: # Invalid gps time reference (age: 1613497389 sec)
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway[251]: # Manual GPS coordinates: latitude xx.60830, longitude x.32160, altitude 65 m
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway[251]: ##### END #####
Feb 16 18:43:26 eu1.cloud.thethings.network ttn-gateway[251]: 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[251]: INFO: [down] for server router.eu.thethings.network PULL_ACK received in 44 ms

BK-Vest · February 16, 2021, 5:48pm

Thank you! I will try!

E_T

bluejedi · February 17, 2021, 12:35am

FYI, see: How do I format my forum post?

FoxWhiskey · February 17, 2021, 6:19pm

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.

Best regards,
-bernie

descartes · February 17, 2021, 6:33pm

I’ll page @kersing who made this:

It supports the IMST board.

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.

cslorabox · February 17, 2021, 7:31pm

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.

FoxWhiskey · February 17, 2021, 11:02pm

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.
Thanks!

LGW-GreEN-ER · February 18, 2021, 5:37pm

Hello, Im interrested by this solution because I have a lite gateway from IMST.
Can you explain steps you used to go from v2 to V3?
Thanks you for your help

cpeacock · February 18, 2021, 10:53pm

I would be trying to move to Basic Station. I note under supported platforms Basic Station pre-release was tested on the Raspberry PI + IMST iC880A Shield

The GitHub is

Basic Station offers better security with encrypted and authenticated gateways. It’s also surprisingly easy to install, the build tools will fetch dependencies such as the libloragw HAL.

BK-Vest · February 20, 2021, 8:25am

Here my result with local_config to eu1.cloud.thethings.network ttn-gatewa

CGroup: /system.slice/ttn-gateway.service
├─322 /bin/bash /opt/ttn-gateway/bin/start.sh
└─576 ./poly_pkt_fwd

Feb 20 09:17:42 eu1.cloud.thethings.network ttn-gateway[322]: # Manual GPS coordinates: latitude xx.60830, longitude x.32160, a
Feb 20 09:17:42 eu1.cloud.thethings.network ttn-gateway[322]: ##### END #####
Feb 20 09:17:42 eu1.cloud.thethings.network ttn-gateway[322]: ##### 2021-02-20 08:17:42 GMT #####
Feb 20 09:17:42 eu1.cloud.thethings.network ttn-gateway[322]: ### [UPSTREAM] ###
Feb 20 09:17:42 eu1.cloud.thethings.network ttn-gateway[322]: # RF packets received by concentrator: 1
Feb 20 09:17:42 eu1.cloud.thethings.network ttn-gateway[322]: # CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
Feb 20 09:17:42 eu1.cloud.thethings.network ttn-gateway[322]: # RF packets forwarded: 0 (0 bytes)
Feb 20 09:17:42 eu1.cloud.thethings.network ttn-gateway[322]: # PUSH_DATA datagrams sent: 1 (224 bytes)
Feb 20 09:17:42 eu1.cloud.thethings.network ttn-gateway[322]: # PUSH_DATA acknowledged: 0.00%
Feb 20 09:17:42 eu1.cloud.thethings.network ttn-gateway[322]: ### [DOWNSTREAM] ###

pe1mew · February 20, 2021, 8:37am

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.

Read this thread and install the balena solution @jpmeijers created: Howto connect a Balena gateway to V2 and V3 - #5 by kersing

BK-Vest · February 24, 2021, 5:12pm

Here a fast solution:

LoRaWAN: Upgrading to Basic Station and The Things Network V3 Stack – Beyondlogic

Thanks to all for the support and suggestions!

One question I still have, how can I now integrate my GPS module again!

That went earlier in the local_config.jason with:

"gps_tty_path": "/dev/ttyUSB0",
"gps" true,
"fake_gps": false,

Greetings

E_T

cslorabox · February 25, 2021, 12:58am

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[322]: # PUSH_DATA acknowledged: 0.00%

That means your gateway is not in contact with TTN, either.

cpeacock · February 25, 2021, 2:38am

This is a extract from the BasicStation documentation on core features:

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

"pps": true,

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.

BK-Vest · February 25, 2021, 9:42am

Hello cpeacock,

yes it is right No Dependency on Local Time Keeping : But it is possivble and an other feature is

Update from status messages
Update the location of this gateway based on incoming status messages

In the documentation (doc.sm.tc/station/conf.html) i found:

Time Synchronization Configuration
Stations support two different methods for time synchronization:

With access to a PPS

Without a PPS

When available, the PPS can come from hardware, or it can be simulated using software by means of a FIFO file. The configuration entry is as follows:

{
“station_conf”: {
…
“gps”: “DEVICEFILE” | “FIFO”
“pps”: “gps” | “fuzzy”
}
}

so the following entry has been added to my config-file:

“gps”: “/dev/ttyACM0”,
“pps”: “gps”

The GPS-Modul provides valid GPS data, but the location-info in the TTS-Gatewa-Console were not shown!

I think Gateways with own GPS enables better positioning of nodes!

Greetings
E_T