Gateway Dragino shows traffic of my devices; but the devices dont (solved)

Gateways Dragino Gateways
1

Hello, I bought a Dragino LPS8 Indoor Gateway.

I added the gateway to my ttn profile, where also some devices are registered. In my console the TTIG is listing connections with the dev address of my device; but on the device page (same dev address) the device is listed “Status green 2 days ago” and no data. (Also my another device shows the same)

Did my setup not work?

Thanks for help.
Joseph

2

It’s a bit confusing what you are saying.

First you mention a Dragino LPS8 gateway, then you mention a TTIG which is is a completely different gateway.

And then you say that the gateway shows connections with a device… but gateways don’t really make connections. Do you mean the gateway shows raw packets from the device address?

If you are only ever getting raw packets and nothing through to the application that could indicate either wrong keys (perhaps the bytes in the wrong order) or a rewound or otherwise out of range frame counter

3

Hi, sorry for my complicated description of my problem. I thought TTIG was the shortcut for the things indoor gateway. English is not my first language.
yesterday i was in the office and was able to successfully connect to the things network with the daragino from there with my login and my devices. today I also bought a dragino for at home and set it up on my account. I saw that my devices delivered data to the gateway. But when I switched to the tab of the two devices, the connections from yesterday were still specified as the last contact and no data was shown.
I expected that the connection data to the gateway with my device_ids would be visible in the devices tab as in the office yesterday.

Joseph

4

Given the symptoms you are using ABP and you did not reset the counters for the nodes. LoRaWAN does not accept packets where the counter is lower than a previously seen value to prevent replay attacks.
In the console go to the node and on the device overview page click on ‘reset frame counters’. That should solve the issue of packets not being displayed in the application data.

2 Likes
5

That is correct. TTIG is short for The Things Indoor Gateway which is a specific product.

However, TTIG is not a general abbreviation for every (make of) indoor gateway connected to The Things Network.

1 Like
6

Hi Jac,
thank you for your help. With the reset of the counters everything is working fine.
Is a reset necessary for every connection to a previously unknown gateway?

7

See Frame Counters in https://www.thethingsnetwork.org/docs/lorawan/security.html, in which the following is circumvented by using TTN’s “reset frame counters” option:

Therefore, you should re-register your device in the backend every time you reset it.

(See also some notes about TTN Console’s Frame Counter Checks option.)

Also, devices don’t connect to a gateway. The just transmit and hope one or more gateways receive their packet, and forward that to TTN.

1 Like
8

Hi Arjan,
thank you for the info; at the moment we are still in dev.
But it is very good to know, that we have to re-register the devices when prod is starting.
Thanks
Joseph

9

Well, that’s not what I wrote. First of all, the “reset frame counters” may be much easier. And second: you’ll need to take care of the frame counters whenever you reset an ABP device, regardless if that’s development or production. This could also happen when, e.g., its battery is low. So, read about those frame counters, it’s important to understand. Or use OTAA rather than ABP.

10

In the design of LoRaWAN, frame counters and related state are really meant to be continuously retained even when nodes are restarted, lose power, have their firmware upgraded, etc. This is indeed challenging to achieve, especially for unexpected restarts.

But it’s important to realize that gateways hold no node state whatsoever. Their role is transparent. You can reboot a gateway, smash it with a hammer and start up another, and nothing changes. You can move the node from near one gateway to near another, and nothing has to change, unless the radio conditions now require a different power or spreading factor choice to get through at all, or suggest a change to a more efficient one where conditions are now easier.

Actual state is held exclusively in the node and servers; the gateways are just a transparent and interchangeable conduit in between.

2 Likes
11

I’m pretty new to ttn. So I use the already working ABP. Of course I would also use OTAA if it is not too complicated.
I have already read how it could be using the example of “The Things Uno”.
Our devices are operated with battery power and should remain in deepSleep (esp32) most of the time. Is an ABP connection faster than an OTAA connection?

12
  1. Your node should preserve LoRaWAN state. That is required for both ABP and OTAA. On an esp32 that is difficult because ram contents is lost when using deepSleep. It means you have to find a LoRaWAN stack for the esp that already saves state or write the code yourself. (If you want to know why, read up on framecounters and replay attacks)
  2. ABP is faster only when joining the network. But it is less secure and requires reset of counters in the TTN console at each join so is inconvenient. OTAA join resets the counters so no need to perform steps in the TTN console. Once a node is joined (and correctly preserves the LoRaWAN stacks state) there is no difference in connection speed. LoRaWAN is not WiFi where a new connection is setup each time you want to send data, once a node is joined to the network it will just send the packet to air and hope there is a gateway receiving the data with transmission coverage area.

Keep in mind a node should only join very seldom. When the nodes batteries are replaced or the node is reset by a user would be moments a join should be performed (assuming the LoRaWAN state does not survive those events). Joining every time the devices wakes from sleep is a definite no-no.

1 Like
13

That sounds a bit complicated. How does the gateway recognize that a device is connected
and the LoRaWAN stacks state is correctly preserved? Is this also a kind of session key which is sent along?
The ESP32 manages an sdi-12 bus with some sensors. Can you recommend a simpler board for me?
The data should be sent to TTN every hour. Can the connection be kept that long?

14

May I suggest heading to the LoRaWAN academy for the LoRaWAN basics? It will provide you with a good working knowledge of the technology.

A node is not connected to a gateway. A node connects to the network (TTN). A gateway just received RF data and forwards it to the network if the CRC is correct and transmits data when instructed by the network. It is pretty dumb.

The state that you need to preserve contains (among other things) the session encryption keys, the address, uplink and downlink counters, spreading factor, transmission power, channel frequencies.

LoRaWAN ‘connections’ (the combination of session encryption keys, address and counters as saved by the node and the network) are valid for months. If you device just sends one packet every few months it will still work. So ‘keeping’ a connection is not an issue.

There are boards with ARM based controllers that integrate the LoRaWAN hardware that are able to keep RAM state while in very low power sleep. I don’t have a recommendation for a specific board right now, may-be one of the other forum users can chime in?
You should also search the forum, iirc someone posted some code to safe the state for esp32 devices.

15

Whatever version of the SAMD21 is in the Adafruit feather M0, and the STM32L073 (or 083 etc) are common choices for ARM based LoRa nodes. The former likely because there was a board with the MCU and radio that almost worked (needed one jumper wire between external pins to get a radio status signal back in to the MCU), the latter because it’s a fairly good choice and shows up both discretely and in combined radio/MCU sub-modules.