Despite what is “shown” on the Gateway (within the Laird interface), the physical region is pulled from your TTN Console. This can also be confirmed by inspecting the NOC API endpoint, which lists what region the Gateway is configured to.
So is my issue the Legacy Packet Forwarder? If so, how can I change this?
Legacy packet forwarder will work the same as the other - no issues there.
What is “shown” in the Laird user interface has nothing to do with what region is “actually” being used. This is one of the features of The Things Network, when the Gateway connects to the application layer to negotiate access - it inherits the region as defined from within your TTN console.
For proof, navigate to the NOC API endpoint, and inspect the key for region. The frequencies prescribed for that region are what will be used for your Gateway.
To avoid all confusion with this, can you share the link to the NOC API endpoint, or, your Gateway ID if you are unfamiliar with how to use NOC?
Failing both of those, a screenshot of the Gateway settings from your TTN console.
You already looked at the NOC and concluded that the gateway was working on AU915. Here is the eui again:
eui-c0ee40ffff2960dc
Ok, let’s assume that the gateway is working correctly on AU915 and that both of my AU915 nodes are not working correctly. Unfortunately the only gateways around here are using AS923. I can’t understand why we are using 2 different standards in the this country, but that’s how it is. I have connected nodes that I have on AS923 to these gateways and sent data, so I know how to do that. So to test the Sentrius gateway, is there a ‘plug and play’ AU915 node that you can recommend?
http://noc.thethingsnetwork.org:8085/api/v2/gateways/eui-b827ebfffe08c9aa
At the time of writing, you’ve changed it to AS923 - though moments after that change the Gateway would have switched over to those region frequencies (despite what’s shown in the Laird user interface). You could just as easily change it back to AU915 and it will switch back within seconds (providing the Laird has access to the internet).
LoRaWAN devices rely on three settings for security purposes.
- Device EUI
- App EUI
- App Key
Some LoRaWAN devices implicitly take care of the Device EUI, while others don’t. Either way, you’ll always need to define the App EUI and Key for a successful join sequence and packet data. All LoRaWAN devices work that way, and all of them are fairly basic to use.
Because of those reasons, there’s seldom a use-case where off the shelf LoRaWAN hardware is truly plug-and-play unless in a polished product (and priced accordingly $$$$).
Hi Guys
I should have responded weeks ago but life got in the way. @Graham the problem was the Legacy Packet Forwarder. I deleted the gateway and reinstalled it without ticking the Legacy Packet Forwarder box and the gateway has worked flawlessly ever since.
Regards
Heinz
2 Likes
Been trying to troubleshoot the Gateway I have.
I’ve got a Sentrius RG168, and I tried following the things you have listed out in your replies.
I didn’t see the Laird IP when I ran the arp command. So I looked in my ISP’s DHCP Client list and saw the IP address my gateway has been assigned with. After running the ping command using the IP Address, this was the output of the command…
Thinking that it got pinged I tried accessing the dashboard using that IP address but it didn’t work.
