Registering a device using OTAA

End Devices (Nodes)
21

I see you’ve popped your uplink cherry.

So only four fundamental issues:

According to that tutorial your data travelled all the way to Amsterdam and back again. Now that tutorial is from an Australian company. So I suspect that it was bathed in Fosters and then had a puff of the weed on the way through AMS and all the signals got scrambled.

The other three issues are the blocks of text that you took a screen shot of - please please please post text as text using the </> tool. Console screen shots are fair game.

The fifth issue is that even whilst under the influence, the Fosters/Weed tutorial shows the payloads being visible in the application/device console. Not the gateway console which shows traffic through the gateway which is, at that point, encrypted and, big difference, not encoded. Encoding comes later. The gateway will show all uplinks for TTN that it hears, some/many/all may not be for you. This is how LoRaWAN works.

Sixth issue is that the difference between a join and an uplink is a crucial fundamental. Scroll to the top of the page, click Learn in the menu and read the LoRaWAN material - it’s the minimum knowledge required. So now you are actually up & running with some hardware, any question you ask that is answered in that section will likely result in you being directed to it.

Last and ultimately critical issue is that the script does two naughty things, one is illegal. We don’t send text, except for our first uplink, then we never do it again, it’s hugely inefficient. But most importantly, we don’t breach the Fair Use Policy by sending uplinks so fast. You can read the details in the Learn section. Sending too fast / too often can also involve a car with an orange stripe, a court appearance and fines as there are legal limits on how often you can send. The Learn section will fill you in.

As for the mixed bag that the Tutorial of Oz brings to the party, lots of screen shots that can’t be expanded to see properly but with abbreviated descriptions lead to this exact situation. Maybe it’s them that tried a tug on a spliff as having chosen a data centre in Australia it seems a very odd thing to send the packet via Amsterdam. In fact no packets go via Amsterdam. All the EU1 packets go via Dublin and the EU2 packets via London (because Brexit, some uplinks only have a new style UK passport (that was printed in France)).

Pretty much every tutorial on the interwebs for LoRaWAN has something left-field or downright wrong about it - or is written by someone how doesn’t know what details other people don’t know. So always best to read them with a pinch of salt, read more than one to compare & contrast, cross-reference what they say with what the Learn + Docs sections say. And ask informed questions here. But not if it’s in the Learn section …

22

Images duly replaced with text

I whole heartedly agree that there dirth of good examples/tutorials on how to do most of this stuff, hence I guess so many people, like me, end up following not so good examples, making mistakes and infringing guidelines/laws.

From your reply I understand that the gateway console isn’t the place to look as the data is still encrypted at this point, which is why it looks “at a glance” to Base 64 I guess? I did mention in my post that it looks like they are looking at the application, however, I can’t see anything here either. From Overview > See all activity I can see the join, then 2 uplink messages

image
image1147×294 16.3 KB

However, clicking either of the messages I get

{
  "name": "as.up.data.forward",
  "time": "2023-11-10T22:28:44.813062499Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "eui-2cf7f1203230bd5e",
        "application_ids": {
          "application_id": "test-pen-01"
        }
      }
    }
  ],
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01HEXNM54D71VW6YMD18WWEX7P"
}

which obviously doesn’t have a payload, going via the device yields the same message.

23

That is the encoding. However the data is AES encrypted as well.

You need to have the application console open when the message arrives. Opening it afterwards will only display a minimal amount of meta data.

24

To reinforce, as this is a common gotcha, the LNS/console is not a data store, so you have to have the live data console for the device or application open at the time the uplink occurs. Otherwise you just get a summary of recent activity.

Your next step is to capture the uplinks so you can do something with them once you have byte array encoded data being sent no more than once every 5 to 10 minutes or so :wink:

As no doubt you’ll have read all the Learn section, here’s the Working with Bytes link:

https://www.thethingsnetwork.org/docs/devices/bytes/

It’s OK to ignore the pink box, all the info on that page is of a general nature but super useful for efficient transfers.

As set of starter files to capture your uplinks you can rely on because the TTN tutor for integrations wrote it and you can ask him questions (after trying things) here:

The WebHook puts the least load on the servers and as it’s usually on external webspace just keeps on trucking, unlike anything at home that gets kiboshed 37.89 seconds after someone cranks up Call of Duty on the home router.

Or you can pass it on to any number of the web dashboard integrations. I wouldn’t bother asking for a recommendations, prices vary wildly from free to lots, best get a beer and spend another evening just looking at the tutorials & docs & see what speaks to you - for all of them they are the official docs for that integration (wot with it being on that actual companies website) so should be fairly reliable & in sync with TTN.

There is also the Storage Integration which saves the last 24 hours of uplinks with mildly less meta info - a backup plan but not something to use as a primary source as it’s not realtime.

1 Like