Dropped Packets - Just the TTN Console Issue?

1

Hey everyone!

Long time lurker, first time poster.
After reading and learning about LoRaWAN for ages (on this forum, YouTube, and TTN Conference videos), I finally bit the bullet and wanted to get my hands dirty.
I’ve used the RFM95 heaps in the past, but only for Point-to-Point LoRa at the PHY level.
So, I’m fairly comfortable and familiar with low-level SX1276 drivers, as well as practical RF (i.e. I’ve even matched to a 1.2:1 VSWR on my node, just to be sure I have reliable EIRP).

I got the B-L072Z-LRWAN1 and a MatchX Gateway.

Node-Gateway

I managed to work out how to redirect my Gateway to TTN.

I also (think) I managed to get some decent firmware going on my node (both Arduino and STM32Cube level, showing the same result in both).

However, I’m seeing missed packets (yet the uplink counter is matching the correct number of transmitted frames).
Note that I’m just incrementing the packet value, to try and see the correlation.

Packets

All I want to ask is if this is the same issue pinned at the banner post here: TTN Console not working properly all the time [console] [gateway] [not connected] [no traffic] [application] [no data]

Obviously I may sound like an idiot to those experienced (“duh, of course it is”), but for someone just starting out and fairly late to the LoRaWAN party, new to the console and how it works in general, I just wanted to check if this is probably the case - or if there is something deeper going on with my gateway / RF issue.

That is - since the “Counter” column does match the correct value, does this mean my packets are probably going through fine and it’s just a console issue?

And lastly, if I wanted to get a bit more serious (i.e. setup a few nodes in a hobby project, and want a reliable setup for evaluating my system) any suggestions on alternative websites/servers/methods for testing? I’m happy to support The Things Enterprise when things get serious, but for the interim (as I saw on the banner post there is no plans to fix console issues) I just wanted to ask for suggestions on how to pivot from here.

Thank you!

2

No, it’s unlikely to be related to TTN Console display issues which is mainly about not seeing gateway Traffic, not about application/device Data. But you could compare TTN Console’s gateway Traffic page to the application/device Data page.

And to be sure: use an MQTT client to connect to the MQTT API. Also, if you enable the Data Storage integration, you don’t depend on TTN Console being open while receiving data.

And make sure there’s at least a few meters between your device and the gateway; crosstalk may interfere on short distances.

3

Hey Arjan,

Thanks for the reply. I’ll try out the MQTT API to be sure.

As a side-question, if the packets are dropping, why is the UpLink counter correctly ticking up?

My node is only transmitting if it is it’s LoRaWAN.joined() function returns true (obviously this is just an abstracted, easy to use function and may not be working as expected - but still), and I see this uplink frame counter is a TTN-side variable not stored locally (i.e. when I reset or even completely reprogram my node, this frame counter does not reset on either my node spitting out data via serial, or on the TTN console).

Also I didn’t mention in my post - but as you can see by the timestamps, I’m only transmitting 1 byte every 2 minutes, so as to eliminate duty cycle rule issues.

4

The uplink counter is part of the LoRaWAN packet. So, the uplink counter is set by the device, not by TTN, and is included in the message the device transmits. For downlinks, the counter is set by TTN.

So, missing counters often imply that the device did send, but no gateway(s) received its transmission.

Great, so your node is persisting the counter value (and likely much more state, such as any network settings it may have received from TTN) between restarts. :+1: (On the other hand: are you sure? I do see counter value zero as well.)