TTS GPS and Basicstation

Has anyone managed to get Basicstation to send gateway GPS to the things stack? We’re running a private TTS on GCP with Balena & Basicstation running on a RAK2245 developer gateway and I can’t seem to get the gateway’s gpd coordinates to flow through to TTS.

Interestingly using the same gateway setup but with Chirpstack network server I had no problem.

Hey could you add some specific details? What gateway are you using? And where are you expecting to see the GPS coordinates appear on TTS?

Hi, so we’ve got 2 gateways.

  • RAK7244 Developer Gateway - running Balena flavor of Basicstation (no real modifications)

  • Laird Sentrius RG1xx IP67 outdoor gateway - running whatever Laird considers up to date firmware.

The Laird doesn’t have GPS so I guess that’s irrelevant. The RAK however does, and as I mentioned had no problem getting the GPS to the Chirpstack UI. Having trouble when pointing it TTS though. My hope was that it would appear with the payload stream and subsequently in the console UI.

I will say however, it might be a problem with basicstation and not TTS - as I’m also experiencing timing sync and rejection issues which I believe is derived from the GPS fix.

I’ll add too that I never got basicstation to work with chirpstack (impossible certificate issues) so that GPS data was coming over via the original packet forwarder. I’m still having cert issues with TTS and basicstation so who knows, maybe basicstation is just a no go at this point.

  1. The basic station protocol does not support GPS location fields. Ideally these would be a part of a status message which the protocol doesn’t yet support.
  2. What certificate issues are you having?

Now I’m embarrassed that I didn’t know that GPS wasn’t supported yet. Whoops.

RE the certs, I can’t seem to get basicstation to agree with a letsencrypted version of TTS running on GCP.
I’m running GitHub - mpous/basicstation: LoRa Basics™ Station - The LoRaWAN Gateway Software variant of the official app. That version runs the live-s2.sm.tc example with an some balena variables.
I’m trying to make sense of the docs to connect via cups on 443, but I’m not having much luck, so I’ve been doing the following:

When trying to connect to lns via wss:

22.12.20 06:43:24 (-0500)  basicstation  2020-12-21 11:43:23.985 [any:INFO] ./tc.trust: 
22.12.20 06:43:24 (-0500)  basicstation  cert. version     : 3
22.12.20 06:43:24 (-0500)  basicstation  serial number     : 44:AF:B0[REDACTED]6:2E:F8:40:6B
22.12.20 06:43:24 (-0500)  basicstation  issuer name       : O=Digital Signature Trust Co., CN=DST Root CA X3
22.12.20 06:43:24 (-0500)  basicstation  subject name      : O=Digital Signature Trust Co., CN=DST Root CA X3
22.12.20 06:43:24 (-0500)  basicstation  issued  on        : 2000-09-30 21:12:19
22.12.20 06:43:24 (-0500)  basicstation  expires on        : 2021-09-30 14:01:15
22.12.20 06:43:24 (-0500)  basicstation  signed using      : RSA with SHA1
22.12.20 06:43:24 (-0500)  basicstation  RSA key size      : 2048 bits
22.12.20 06:43:24 (-0500)  basicstation  basic constraints : CA=true
22.12.20 06:43:24 (-0500)  basicstation  key usage         : Key Cert Sign, CRL Sign
22.12.20 06:43:24 (-0500)  basicstation  2020-12-21 11:43:23.985 [AIO:INFO] tc has no key+cert configured - running server auth only
22.12.20 06:43:24 (-0500)  basicstation  2020-12-21 11:43:24.031 [TCE:INFO] Connecting to INFOS: wss://thethings.[REDACTED]8887
22.12.20 06:43:24 (-0500)  basicstation  2020-12-21 11:43:24.323 [TCE:INFO] Infos: 24[REDACTED]:3 muxs-::0 wss://thethings.[REDACTED]:8887/traffic/eui-02[REDACTED]3
22.12.20 06:43:24 (-0500)  basicstation  2020-12-21 11:43:24.323 [AIO:DEBU] [3] ws_close reason=1000
22.12.20 06:43:24 (-0500)  basicstation  2020-12-21 11:43:24.324 [AIO:ERRO] Recv failed: SSL - The peer notified us that the connection is going to be closed
22.12.20 06:43:24 (-0500)  basicstation  2020-12-21 11:43:24.324 [AIO:DEBU] [3] WS connection shutdown...
22.12.20 06:43:24 (-0500)  basicstation  2020-12-21 11:43:24.324 [any:INFO] ./tc.trust: 
22.12.20 06:43:24 (-0500)  basicstation  cert. version     : 3
22.12.20 06:43:24 (-0500)  basicstation  serial number     : 44:A[REDACTED]8:40:6B
22.12.20 06:43:24 (-0500)  basicstation  issuer name       : O=Digital Signature Trust Co., CN=DST Root CA X3
22.12.20 06:43:24 (-0500)  basicstation  subject name      : O=Digital Signature Trust Co., CN=DST Root CA X3
22.12.20 06:43:24 (-0500)  basicstation  issued  on        : 2000-09-30 21:12:19
22.12.20 06:43:24 (-0500)  basicstation  expires on        : 2021-09-30 14:01:15
22.12.20 06:43:24 (-0500)  basicstation  signed using      : RSA with SHA1
22.12.20 06:43:24 (-0500)  basicstation  RSA key size      : 2048 bits
22.12.20 06:43:24 (-0500)  basicstation  basic constraints : CA=true
22.12.20 06:43:24 (-0500)  basicstation  key usage         : Key Cert Sign, CRL Sign
22.12.20 06:43:24 (-0500)  basicstation  2020-12-21 11:43:24.324 [AIO:INFO] tc has no key+cert configured - running server auth only
22.12.20 06:43:24 (-0500)  basicstation  2020-12-21 11:43:24.375 [TCE:VERB] Connecting to MUXS...
22.12.20 06:43:24 (-0500)  basicstation  2020-12-21 11:43:24.630 [AIO:ERRO] [3] WS upgrade failed with HTTP status code: 404
22.12.20 06:43:24 (-0500)  basicstation  2020-12-21 11:43:24.630 [AIO:DEBU] [3] WS connection shutdown...
22.12.20 06:43:24 (-0500)  basicstation  2020-12-21 11:43:24.630 [TCE:VERB] Connection to MUXS closed in state 3
22.12.20 06:43:24 (-0500)  basicstation  2020-12-21 11:43:24.630 [TCE:INFO] INFOS reconnect backoff 10s (retry 1)

When trying to connect to lns via ws:

22.12.20 06:40:28 (-0500)  basicstation  2020-12-21 11:40:28.437 [AIO:DEBU] [3] ws_close reason=1000
22.12.20 06:40:28 (-0500)  basicstation  2020-12-21 11:40:28.437 [AIO:DEBU] Echoing close - reason=1000
22.12.20 06:40:28 (-0500)  basicstation  2020-12-21 11:40:28.438 [AIO:DEBU] [3] Connection closed unexpectedly
22.12.20 06:40:28 (-0500)  basicstation  2020-12-21 11:40:28.438 [AIO:DEBU] [3] WS connection shutdown...
22.12.20 06:40:28 (-0500)  basicstation  2020-12-21 11:40:28.483 [TCE:VERB] Connecting to MUXS...
22.12.20 06:40:28 (-0500)  basicstation  2020-12-21 11:40:28.540 [AIO:ERRO] [3] WS upgrade failed with HTTP status code: 404
22.12.20 06:40:28 (-0500)  basicstation  2020-12-21 11:40:28.540 [AIO:DEBU] [3] WS connection shutdown...
22.12.20 06:40:28 (-0500)  basicstation  2020-12-21 11:40:28.540 [TCE:VERB] Connection to MUXS closed in state 3
22.12.20 06:40:28 (-0500)  basicstation  2020-12-21 11:40:28.540 [TCE:INFO] INFOS reconnect backoff 10s (retry 1)
22.12.20 06:40:38 (-0500)  basicstation  2020-12-21 11:40:38.584 [TCE:INFO] Connecting to INFOS: ws://thethings[REDACTED]1887
22.12.20 06:40:38 (-0500)  basicstation  2020-12-21 11:40:38.676 [TCE:INFO] Infos: 24[REDACTED]:3 muxs-::0 ws://thethings.[REDACTED]:1887/traffic/eui-024[REDACTED]03

Have you set the Frequency Plan of the gateway?

1 Like

This is my station.conf.

{
/* If slave-X.conf present this acts as default settings */
"SX1301_conf": {		     /* Actual channel plan is controlled by server */
"lorawan_public": true,      /* is default */
    "clksrc": 1,		     /* radio_1 provides clock to concentrator */
/* path to the SPI device, un-comment if not specified on the command line e.g., RADIODEV=/dev/spidev0.0 */
/*"device": "/dev/spidev0.0",*/  
/* freq/enable provided by LNS - only HW specific settings listed here */
"radio_0": {
    "type": "SX1257",
    "rssi_offset": -166.0,
    "tx_enable": true,
    "antenna_gain": 0
},
"radio_1": {
    "type": "SX1257",
    "rssi_offset": -166.0,
    "tx_enable": false
}
/* chan_multiSF_X, chan_Lora_std, chan_FSK provided by LNS */
},
"station_conf": {
"log_file":  "stderr",
"log_level": "DEBUG",  /* XDEBUG,DEBUG,VERBOSE,INFO,NOTICE,WARNING,ERROR,CRITICAL */
"log_size":  10000000,
"log_rotate":  3,
"CUPS_RESYNC_INTV": "1s"
}

Interestingly, I’ve configed TTS to allow unsecured ws and if I reboot enough times I can connect on ws://thethings.[REDACTED]:1887. But its only about 50% of the time after a reboot.

I mean have you set the frequency plan on the TTS console?

Ah, yes: US_902_928_FSB_2

Hmm ok. You’ll need to check the logs on your stack. That will clearly tell you the issue.

1 Like

I think I’ve uncovered the problem! For some reason my gateway keeps creating a new Gateway EUI. It appears to happen at each disconnect. I’ve just double checked the logs as you recommended and was looking for the wrong problem apparently. I added a new gateway in the console using the new random eui that my device generated and its connection to wss @ 8887 so great news.

However, any ideas on why the gateway would continually create a new eui for itself?
Every time it happens apparently I get a (gateway eui-024[REDACTED]03 is not registered and no fallback frequency plan defined).

For example, from my console:

balena1: DC[REDACTED]B52 (first, actual gateway eui based on mac)
balena2: 02[REDACTED]002 (second, unsure where this came from)
balena3: 02[REDACTED]003 (latest)

All the same actual gateway. Was able to connect on all three, once I realized the gateway picked a new eui for itself.

Every time it happens apparently I get a (gateway eui-024[REDACTED]03 is not registered and no fallback frequency plan defined) .

Indeed this is why I asked you to check the Frequency Plan setting for the 404 error.

However, any ideas on why the gateway would continually create a new eui for itself?

"station_conf": {
"log_file":  "stderr",
"log_level": "DEBUG",  /* XDEBUG,DEBUG,VERBOSE,INFO,NOTICE,WARNING,ERROR,CRITICAL */
"log_size":  10000000,
"log_rotate":  3,
"CUPS_RESYNC_INTV": "1s"
}

Your station_conf does not have the routerid field so I assume that it generates EUIs based on the MAC. If your gateway doesn’t inject this field at runtime, then please set the EUI here and it should use that value. Also keep an eye on the format as this field is ID6.

Hey @mrpher this is Marc from balena.
One of the authors of the repository! Feel free to introduce an issue on the repository https://github.com/balenalabs/basicstation in order to solve this issue.

Hi @gy4nt thanks for the info - curious though, shouldnt the compose file include /dev/ttyAMA0 device link if using your basicstation repo in a multi-container setup?

basicstation:
    build: ./basicstation
    privileged: true
    devices: 
      - "/dev/ttyAMA0"

2 posts were merged into an existing topic: RPi Ic880A; GPS; Base Station; update GPS-Position from status messages in TTS-Console