I need help getting the Semtech Basics Station Forwarder of the Laird RG186 Gateway working with TTN.
This is my 5th Laird gateway, we use them at our company. Laird removed the TTN forwarder that we were using from the firmware of the gateway.
See thread at Laird Sentrius RG1xx Firmware Update.
Thus, I want to get all of our gateways running with the Basics Station forwarder.
Hi @jvbelle, you may be able to extract some support out of Laird? It took a while last time for my downgrade advice but I did get some.
Improving that log to include more information is otherwise a bit of a priority. Under the old (TTN forwarder) firmware level it was as per this image. Hopefully itâs still somewhere close to that?
After selecting the Basics Station forwarder, the whole âadvancedâ menu dissapears. Setting the debug level is impossible⌠(thanks for the picture)
I will try (as workaround) to select another forwarder, set de debug level and then select the Basics Station forwarder again to see if the setting carries overâŚ
I donât think the video is meant for explaining the configuration of Basics Station on the RG1xx. Its just a general review of several available LoraWAN gateways, which shows also the configuration (web) interface for each gateway.
Very confusing in the video is the âshow the configurationâ part, which shows a configuration being entered for a CUPS server. While actually you should be configuring an LNS server according to the documenation of Laird, see Application Note - Setting Up Basics Station on TTN | Laird Connectivity.
Allas⌠both dont work for me⌠So Iâm still looking for a solution.
You should be using CUPS, as CUPS automatically configures LNS and allows for any future credentials updates to be propagated automatically to your gateway.
To configure CUPS, you also need to use the CLI to provide the Stack with your LNS key, so it can send that to the gateway when it connects. Weâre working to simplify this process, but for now the instructions are all in the CUPS documentation â Configuration and Update Server (CUPS) | The Things Stack for LoRaWAN
EDIT: Sorry, I didnât see that you were trying to connect to The Things Network V2. You should indeed use LNS, with the DST Root X3 certificate.
We also recommend that you upgrade to The Things Network V3, which we just released at the conference. Your existing login credentials should already be migrated, login using The Things ID and your existing username and password â https://eu1.cloud.thethings.network/
Hi, Thanks for replying. I was just typing⌠Iâm indeed using TTN (and not TTI), thus via https://www.thethingsnetwork.org/ . And for configuration my gateways on the TTN side I use https://console.thethingsnetwork.org/gateways. These still use the V2 version of the stack, like you state at the end of the message
I also see your statement regarding upgrading to the TTN V3 stack, Iâll try that using the documentation at: The Things Network upgrade to V3
(and of course watch the opening keynote :))
I hope the documentation on TTN will also be updated soon (which I can understand takes a while on the community driven TTN)
Thanks! Iâll let you the results after taking some time for adapting to the changes.
Mmm Iâm now in the âforestâ of documentation that should lead me to a working Gateway.
At Configuration and Update Server (CUPS) | The Things Stack for LoRaWAN, chapter " Configure CUPS to Send the LNS API Key" it is pointed out that I should use the command line interface of TTN V3 to âWe need to configure CUPS in The Things Stack to transmit the LNS API key when a gateway connectsâŚâ Why is this not supported in the web interface? For ânormalâ users it takes a lot of hassle to get things done in this way⌠Still want to be a happy user ofcourse, But the documentation in this form is way to difficult for average users who just want to add there gateway to the community network. If we want to build a community network, things should be simpler imho.
The export command does not exist in windows. Nor does the xxd command that is uses after the pipe.
So im trying in my mingw environment now⌠(for average users⌠not very doable).
Iâm getting error: error:cmd/ttn-lw-cli/commands:unauthenticated (not authenticated with either API key or OAuth access token)
at this step.
So i tried â$ttn-lw-cli.exe loginâ (both in mingw as in windows cmd shell) to log in/get the oath token. my browser opened when running the command but it cant connect to the said url at localhost.
Thus Iâm stuck at the moment.
In the âoldâ situation (TTN) I could manage everything from the web UI of the TTN console. Which was much more user friendly.
One has to login before command
ttn-lw-cli gateways update $GTW_ID --lbs-lns-secret.value $SECRET"
I opened manually the browser with address on terminal since it didnât arrive to open.
I got the json answer with lbs_lns_secret key_id f.
Had yet to finish, since have other things to do now.
Once youâve got that, youâll be able to use it to add the LNS key. Again, really sorry that this is still a CLI only command, weâre building this in to the console now.
Thanks @benolayinka for the tips, Iâve got my RG191 across from v2 to v3 (in AU) with basic station forwarding - the instructions above with CUPS were helpful for me. Its mostly working, although I note a few issues on device joins via this gateway using v3 stack which I did not have when I was using v2 - a little unreliable and takes my device a few attempts to join the network, so I need to troubleshoot this issue separately. But I donât intend to go back to v2 given it will become read-only shortly.
Just a hint to those having issues with not having linux. I installed the windows binaries for the CLI support and then used GIT BASH shell to give me xxd etc. It worked well, hope this information helps someone else trying to get their gateway going with CUPS.
Itâs possible to get it working only using LNS, which is easier if maybe a little less stable in the O(5 years) timeframe.
I followed the instructions in the Laird App Note here. Thereâs a bug in the instructions though, and then another bug which compounds it:
It says
For Unix based OS - â\râ must be added to end of key for proper line endings
but then gives the command Echo -e "Authorization: Bearer NNSXS.xxxxx\n">tc.key
Which is wrong. Do what it says, not what it did. The correct command is: echo -e "Authorization: Bearer NNSXS.xxxxx\r">tc.key
The second bug is that if you upload a key file with the same name it doesnât seem to stick â rename it to tc2.key and upload it and itâll be fine. And itâll go to the configured band plan and not the one hardcoded on the device (important for RG191s sold into other countries prior to this hard-setting and country-specific versioning).
If you do this key file incorrectly there is an error in the log (bottom lines, turn on auto-updating) saying the key file is in the wrong format but it wasnât updating the first time I uploaded everything (and in fact locked itself into online state but didnât do anything). Rebooting helped.