Added RAK833 RPi HAT GW to V3 - remains in disconnected status

Hi, I´m trying to add a RAK833 RPi HAT gateway to V3 (fresh setup, no V2 migration). I have tried to follow your tutorials & troubleshooting but still get “disconnected” status in the console.

  • the GW is connected to internet via ethernet cable
  • as a test, I managed to register the gw on Balena - worked fine on first attempt.
  • after that I have rebooted the gw from scratch and followed the guidelines on https://www.thethingsnetwork.org/docs/gateways/pisupply-hat/ (however this seems to be made for V2 rather than V3).
  • Semtech / legacy forwarder mode
  • Gw ID: as provided on the gateway´s IoT Lora GW Management page (doublechecked that it´s identical in console and GW)
  • Gw EUI: My RPI Mac address adding “FF FE” in the middle
  • server address: eu1.cloud.thethings.network
  • “gateway secret key” (“This is the Gateway Key from the TTN Console”) but this doesn´t seem to exist for V3? I have tried to generate an API key, but this is 98 byte long and the packer forwarder config requires a key with 101 byte length
  • region plan: Europe 868 (I’m in Sweden)

Note that I have not done anything with the global_conf.json file and have not set any ports as I don´t know what / how / where)

Any support is appreciated.

regards,
Ulf Jonsson
Sweden

The Gateway ID is just your reference - double checking won’t help

OK

Correct

This is no longer a thing - the instructions & setup are indeed for v2

Correct.

It would be worth checking in on the Pi-Supply website to see if they have updated for v3.

I moved my Pi-Supply HAT over early February by recompiling the Kersing Packet Forwarder on the Pi and using the global_conf.json that you can download from the gateway configuration page

Are you using Balena? In that case go to Basics Station Protokoll in Docker-Compose for balena.cloud Gateways V2 / V3 - #3 by biermi for two option, BasicStation or MP forwarder. For both there is a link to GitHub where you can find the setup instructions.

Hi guys, thanks for your incredibly fast responses (do you work around the clock?)

Anyway, obviously I am not the only one with this issue, according to this thread in GitHub: not compatibile with the TTN v3 · Issue #77 · PiSupply/iot-lora-image · GitHub
I tried the key min length workaround, but didn´t work for me (haven´t done any real investigation though).

As said, the GW connected immediately when I tried to register to Balena some weeks ago. So I will test Jac´s Balena route tomorrow. I´ll let you know the outcome.

regards, Ulf

Not me, I rock around the clock, usually in my blue suede shoes.

The older code relies on V2 to get part of the configuration and requires valid V2 credentials for that. My updated version (the second GitHub link in that topic) has been modified to get rid of the V2 dependencies.

Hello.

I hope my problem fits into this topis. It is regarding migration from v2 to v3 and from packet forwarder to basic station. I’m using RPi (3 and 0), iC880A and RAK 831, all in Balena. (I’ve migrated Lorix before without any problem). First migration of RPi&iC880A was easy. Even more: problematic iC880a, which I had to start packet forwarder on it even more than 4-5 times, now starts without any problems.
Next was RPi&RAK831, as it is described here: GitHub - balenalabs-incubator/basicstation: LoRa Basics™ Station - The LoRaWAN Gateway Software. Again, succesful. But that’s it.
Another two RPi&RAK831 couldn’t connect despite the equal settings, with the same error. No way …
Does someone have any idea where to start “witch hunt”?

TTN console says:

  • flash_on
    17:14:11 Disconnect gateway

  • network_check
    17:14:10 Receive gateway status Versions firmware"1.0.0"package"1.0.0"platform"rpi - Firmware 1.0.0 - Protocol 2"station"2.0.5(rpi/std)"

  • flash_on
    17:14:10 Connect gateway

Balena’s log says:
main 2021-07-20 15:18:51.856 [RAL:VERB] SX1301 ifchain 9: enable=1 rf_chain=1 freq=300000 bandwidth=3 datarate=50000 sync_word=0/0
main 2021-07-20 15:18:51.856 [RAL:VERB] SX130x LBT not enabled
main 2021-07-20 15:18:51.856 [RAL:VERB] Station device: /dev/spidev0.0 (PPS capture disabled)
main 2021-07-20 15:18:51.857 [RAL:ERRO] Concentrator start failed: lgw_start
main 2021-07-20 15:18:51.857 [RAL:ERRO] ral_config failed with status 0x08
main 2021-07-20 15:18:51.857 [any:ERRO] Closing connection to muxs - error in s2e_onMsg
main 2021-07-20 15:18:51.857 [AIO:DEBU] [3] ws_close reason=1000
main 2021-07-20 15:18:51.857 [AIO:DEBU] Echoing close - reason=1000
main 2021-07-20 15:18:51.904 [AIO:DEBU] [3|WS] Server sent close: reason=1000
main 2021-07-20 15:18:51.904 [AIO:DEBU] [3] WS connection shutdown…
main 2021-07-20 15:18:51.905 [TCE:VERB] Connection to MUXS closed in state -1
main 2021-07-20 15:18:51.905 [TCE:INFO] INFOS reconnect backoff 10s (retry 1)

Thank You for any hint!

That line seems to be the issue. Is the reset pin defined correctly for the hardware?

Agree. For whole application in Balena I have the same settings (except for iC880A, which has overriden GW_RESET_GPIO with 25):
image

One open question is, should this be checked and/or fulfilled:

image

Hi, followed by the “Basicstation” repository guide with a board “IC880A” and a RAPSBERRY PI3 and in the TTN V3 console comes out as disconnected. Apart from what appears in the guide would have to do something else?

flash_off
08:11:32
Disconnect gateway
network_check
08:11:32
Receive gateway status

Versions
firmware"1.0.0"package"1.0.0"platform"rpi - Firmware 1.0.0 - Protocol 2"station"2.0.5(rpi/std)"

flash_on
08:11:32
Connect gateway

This is what live data responds to and the following one is the balena logs.

2021-07-26 06:26:45.533 [RAL:VERB] SX130x LBT not enabled
main 2021-07-26 06:26:45.533 [RAL:VERB] Station device: /dev/spidev0.0 (PPS capture disabled)
main 2021-07-26 06:26:45.534 [RAL:ERRO] Concentrator start failed: lgw_start
main 2021-07-26 06:26:45.534 [RAL:ERRO] ral_config failed with status 0x08
main 2021-07-26 06:26:45.534 [any:ERRO] Closing connection to muxs - error in s2e_onMsg
main 2021-07-26 06:26:45.534 [AIO:DEBU] [3] ws_close reason=1000
main 2021-07-26 06:26:45.534 [AIO:DEBU] Echoing close - reason=1000
main 2021-07-26 06:26:45.570 [AIO:DEBU] [3|WS] Server sent close: reason=1000
main 2021-07-26 06:26:45.570 [AIO:DEBU] [3] WS connection shutdown...
main 2021-07-26 06:26:45.570 [TCE:VERB] Connection to MUXS closed in state -1
main 2021-07-26 06:26:45.570 [TCE:INFO] INFOS reconnect backoff 10s (retry 1)
main 2021-07-26 06:26:55.572 [any:INFO] ./tc.trust:

Hi, for Pi there is a some software created by @kersing that should do the job - he created gateway software way back in time - the forum search should track it down, it was in the last week or so if I recall.

OK, thank you very much, the question is that i dont know where to start looking. For the moment i will search @kersing to see if there’s luck. If I manage to fix it or find the software, I’ll leave the link attached to this mensage.

Scroll up?? When I get on a desktop computer I’ll be better placed to find & copy & paste a link.

This link?

Ta Dah!

Thank you very much. Amazing flawless assistance. :grin:

Hi, I follow Kersing’s tutorial as you told me but now it gives me another mistake, apparently I have the gw_key and gw_id badly but I put them according to the documentation. What could the problem be?

Anyway, on the gw_key I put “API KEY secret key” and on the gw_id “gateway ID.”

BalenaCloud log error
HTTP Error 404: Not Found
main Unable to fetch configuration from TTN. Is the TTN API reachable from gateway? Are your GW_ID and GW_KEY correct? Retry in 30s

i did try to ping the gateway server address but it does not comunicate with any on of the devices in my network.

Do you mean ping the Gateway (on your network) or ping the Network Server the Gateway is pointed to (in the TTN Backend?

If latter then do not expect a ping response. The TTI/TTN infrastructure is behind load balancers and will not respond to pings…

This means it reached a server and was told the file wasn’t to be found, so it’s not even got to trying to use the keys yet.

Maybe review the URL that you are using?

ok so it will not respond. Thank you for the information