No payload in app but in gateway

TTN Network and Services v2 Console
1

Hi,

2l2r: I can’t get any data into the applications, but I can see them arriving at the gateway.

We do the “Freifunk” (OpenWiFi/OpenWRT) in the area and wanted to add LORAWAN to this. So we installed a gateway and wanted to test it now. But the TTN behaves somehow unexpectedly. Sometimes it takes ~5 minutes after a transmitter reset before any messages are even displayed in the application (but no old ones only new ones), sometimes nothing happens at all. However, the gateway,I believe, apparently records all transmissions correctly.

We have a Kerlink Wirnet iStation.
Sender is a SX127X.

app_gateway_problem

2

That will depend on how quickly the join process completes - lots of factors variables - and how the nodes firmware is set wrt how soon 1st message sent after join complete (if using OTAA), and how configured otherwise if using ABP.

Data is usually shown ‘live’ and will show list subsequently until session connection breaks or is truncated due to length. Console needs to be open and live to catch traffic - if it was closed and you then open it generally won’t show previous messages - GW console may cache a short prior period - usually showing e.g. historic status messages. Basically if you want to see traffic open the deveice or application page then trigger the messgaes or if needed the re-boot, join/config cycle through messages arrival.

1st glimpse the pictures look normal…what problem are you highlighting?

Can see uplink message on data live data page and can see similar traffic in GW page though as you have redacted DEV-EUI and DEV Addr - no neccessary as in the public domain! - can’t check if GW shows same device as Device page…

What do you mean when you say

Where are you sending it - are the decoders, payload formatters and appropriate webhooks, keys or what ever neccessary all corrrect?

3

It’s ABP.

Data is usually shown ‘live’

Yes and the consoles are also both live open. But only the GW shows the packets from the sender.

app_gateway_problem_0
app_gateway_problem_03830×904 337 KB

what problem are you highlighting?

The problem is that the packages are not shown in the application page but in the GW part.

app_gateway_problem_1

4

There is uplink/downlink activity on the device console page. So there will be a Forward uplink data message somewhere in that list. But ABP is filling up the log with the configuration settings that aren’t in your setup. Using v1.0.4 is very ambitious - was that in the instructions for the device.

OTAA is preferred as it sorts all that out for you.

That’s the radio module - what is the actual device.

5

30 sec updates far to frequent - especially at SF9 - please review TTN FUP, drop back to LoRaWAN v1.0.3 or even 1.0.2 rev B, ABP good for checking if node radio working, but if there are key issues etc best use OTAA as all gets resolved as part of join process if device firmware good and set up ok. What Node/Manufacturer/Firmware/Library. Signal stregth is very low and at SF9 so clearly either some distance from the GW or potentially ant/reception problems at one end or the other.

6

Yesterday. But WHY the link between gateway page and app page does’t work?

Using v1.0.4 is very ambitious

1.0.0 change nothing

actual device.

An Arduino Uno

msg on GW page

{
“name”: “gs.up.receive”,
“time”: “2022-11-01T09:20:58.910187134Z”,
“identifiers”: [
{
“gateway_ids”: {
“gateway_id”: “eui-7076ff00560710c2”,
“eui”: “7076FF00560710C2”
}
}
],
“data”: {
“@type”: “type.googleapis.com/ttn.lorawan.v3.GatewayUplinkMessage”,
“message”: {
“raw_payload”: “QNS8CyYACgABe7oOgYdhwetdxQ==”,
“payload”: {
“m_hdr”: {
“m_type”: “UNCONFIRMED_UP”
},
“mic”: “wetdxQ==”,
“mac_payload”: {
“f_hdr”: {
“dev_addr”: “260BBCD4”,
“f_ctrl”: {},
“f_cnt”: 10
},
“f_port”: 1,
“frm_payload”: “e7oOgYdh”
}
},
“settings”: {
“data_rate”: {
“lora”: {
“bandwidth”: 125000,
“spreading_factor”: 9,
“coding_rate”: “4/5”
}
},
“frequency”: “868500000”,
“timestamp”: 151890204,
“time”: “2022-11-01T09:20:58.870773Z”
},
“rx_metadata”: [
{
“gateway_ids”: {
“gateway_id”: “eui-7076ff00560710c2”,
“eui”: “7076FF00560710C2”
},
“time”: “2022-11-01T09:20:58.870773Z”,
“timestamp”: 151890204,
“rssi”: -120,
“channel_rssi”: -120,
“snr”: -10,
“location”: {
“latitude”: 52.3584486669596,
“longitude”: 14.0636748075485,
“altitude”: 85,
“source”: “SOURCE_REGISTRY”
},
“uplink_token”: “CiIKIAoUZXVpLTcwNzZmZjAwNTYwNzEwYzISCHB2/wBWBxDCEJzStkgaDAj6yYObBhDjkfexAyDgqvLqtYwn”,
“channel_index”: 7,
“received_at”: “2022-11-01T09:20:57.344918063Z”
}
],
“received_at”: “2022-11-01T09:20:58.910018787Z”,
“correlation_ids”: [
“gs:conn:01GGM6M9K056NF8GCNP7G064AS”,
“gs:uplink:01GGS7WX0YCW3M89FQ87M7QJRX”
]
},
“band_id”: “EU_863_870”
},
“correlation_ids”: [
“gs:conn:01GGM6M9K056NF8GCNP7G064AS”,
“gs:uplink:01GGS7WX0YCW3M89FQ87M7QJRX”
],
“origin”: “ip-10-100-12-248.eu-west-1.compute.internal”,
“context”: {
“tenant-id”: “CgN0dG4=”
},
“visibility”: {
“rights”: [
“RIGHT_GATEWAY_TRAFFIC_READ”
]
},
“unique_id”: “01GGS7WX0YFVH3QE44ZSSDY5AP”
}

30 sec updates far to frequent

thanks, I know. That’s not my question.

LoRaWAN v1.0.3 or even 1.0.2 rev B

Does not change anything

Signal stregth is very low and at SF9 so clearly either some distance from the GW or potentially ant/reception problems at one end or the other.

But the signal reaches the GW?

So why can’t I see it on the app page?

7

Perhaps not - but your reponse demonstrates wrong attitude - it is all our concern (the rest of us using TTN as a shared community resource), if you wish to get vounteer/community support please respect the guidelines we put in place and advice we give.

Yes, but again if you read the forum - including threads from just the last 24/48 hrs we recommend getting <-45 → -115, ideally <-55 → -110 when debugging as that reduces the chance of having to try and debug in the face of self inflicted RF signal or quality issues.

It could be that your devices are actually too close and too loud such that the signal being reported at e.g. -118dbm is actually channel bleed over from a far too loud and distorted signal that cant be handled correctly - that would explain a lot…

Now, please do as requested, dial back the Tx rate and provide more complete answers to the questions and suggestions you have been given above then perhaps we will get back to trying to help you debug your system, without full details and a co-operative user we are potentially shooting in the dark and likely have better things to do with our time! :slight_smile:

How configured (full details please we do not want to play a game of 20 questions…)

What happened when you tried OTAA?

1 Like
8

You are experiencing the LoRaWAN replay attack protection mechanism. Switch to OTAA to get rid of it or read up on frame counters and their use.

1 Like
9

If it’s Arduino it’s likely you are using MCCI LMIC or LMIC-node (which used MCCI LMIC) - which needs documents choices for v1.0.2 or v1.0.3

If you know, why do it? TTN is a community network that also shares the airwaves with other ISM users. And you are likely in breach of duty cycle which is a prosecutable offence. Hopefully you will give us the confidence that you have reduced your send rate.

There is a sense of bludgeoning your way through this process which isn’t seen to work very often. You would benefit from reading https://www.thethingsnetwork.org/docs/lorawan/ and if you are setting up OTAA which is highly recommended, then read the notes in the example about which way round the keys should go.

1 Like
10

If you know, why do it? TTN is a community network that also shares the airwaves with other ISM users. And you are likely in breach of duty cycle which is a prosecutable offence. Hopefully you will give us the confidence that you have reduced your send rate.

Thanks for focusing on a test detail. My realization was yesterday, after about 5 minutes there was suddenly something on the app page. If it (GW) doesn’t work, we’d have to take it out of the town hall again, and nobody around here can benefit from the GW. That would be a pity, but I can’t tell anyone everything is going well if it isn’t. we do Freifunk in our city and maybe LORAWAN as an addition. However, since I switch off the transmitter after a few minutes, I am completely in fair use, especially since it is useful for building the infrastructure.

You are experiencing the LoRaWAN replay attack protection mechanism. Switch to OTAA to get rid of it or read up on frame counters and their use.

The first possible answer to my question. Looks better now.

“better” OTAA: try to join…

ttyACM log

13:50:42.868 → Starting
13:50:42.901 → RXMODE_RSSI
13:50:42.901 → 169: engineUpdate, opmode=0x8
13:50:42.934 → Packet queued
13:50:42.967 → 212: EV_JOINING
13:50:42.967 → 1176: engineUpdate, opmode=0xc
13:50:49.952 → 440777: engineUpdate, opmode=0xc
13:50:49.985 → 441106: TXMODE, freq=868500000, len=23, SF=7, BW=125, CR=4/5, IH=0
13:50:54.883 → 747588: RXMODE_SINGLE, freq=868500000, SF=7, BW=125, CR=4/5, IH=0, rxsyms=255
13:50:55.148 → 763109: JaccRX1, dataLen=0
13:50:55.181 → 763174: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0, rxsyms=255
13:51:03.489 → 1282951: JaccRX2, dataLen=0
13:51:03.522 → 1282986: engineUpdate, opmode=0xc

lib: GitHub - dragino/arduino-lmic: LoraWAN-in-C library, adapted to run under the Arduino environment

GW is ~600m/2000ft away.

Let’s start again, what do you think you need?

11

Thanks for working with LoRaWAN without (seemingly) fully understanding the implications of what you are doing. Sending too often will result in DoS for other users of the same radio spectrum in you vicinity.
It is a broadcast protocol which is meant for Long Range and transmission might be heard tens of kilometers from you location. So please use airtime responsibly and do not transmit too often.

Also, keep in mind LoRaWAN is not like WiFi where accesspoints handle all traffic locally, each transmission uses resources on the central servers which you share with thousands of other users.

And while one test at one location will not break things (too badly), if everyone has the same attitude things will break. Or regulators will step in and regulate the ISM band just like the other radio bands. (The need for this has been suggested by several parties over the past few years. Mainly parties that might profit if this happens of course)

3 Likes
12

:+1: Jac @kersing and to add

is not an excuse - please see historic forum threads for much discussion on this point - deploying a GW doesnt allow you to break the community rules…nor even to ‘s t r e t c h’ a point… the people helping you have deployed many GW’s and still have to follow the rules or go private! so again attitude doesnt wash!

  1. respect for your fellow community users and helpers :-)!
  2. answers to questions above - details details…
  3. read the documents and please listen to & take advice
  4. have you looked at the commit dates for the lib you are linking to? You have been recommended e.g. MCCI (or poss a recent TTN Lib) to reflect modern LNS behaviour (as reflected in TTS(CE) build)
  5. OTAA response? - that was suggested early as it solves a lot of problems - not just keys issues but also as called out directly by Jac the FCount replay problem under ABP…this wasnt pointed out specifically earlier because it was clear you needed to

and the fact that your posts showed a tendency to

6.) What lies between you and

A little knowledge of local environment where deploying always helps resolve issues :wink:

BTW Friefunk = :+1: But just calling it out does not imply a halo effect or applicable knowledge and domain expertise. I remember it well in a previous life (major semiconductor and systems player) - I & several colleagues donated lots of AP’s for use in building the network 2003-05 and again a little later (maybe even as early as 2002 :thinking: … I’m getting old!), frequent travel in DE around that time was a pain without good open WiFi as often in hotels and cafes but they were cautious closing down access due to the stupid secondary legislation/responsibility issues…so stopped giving AP’s after a while. Today I give LoRaWAN GW’s instead :slight_smile:

2 Likes
13

Thank you for looking down on others from above.

each transmission uses resources on the central servers which you share with thousands of other users.

So it’s better we shutdown our GW, so more fun for you guys. (?) I think yesterday roundaboud total sending 20 sec.

is not an excuse - please see historic forum threads for much discussion on this point - deploying a GW doesnt allow you to break the community rules…nor even to ‘s t r e t c h’ a point… the people helping you have deployed many GW’s and still have to follow the rules or go private! so again attitude doesnt wash!

Is okay, GW is up in the town hall. Have fun with it?

  1. respect for your fellow community users and helpers :-)!

Then others should also take a look at your own nose.

  1. answers to questions above - details details…

I try it. So my question what did i forget.

Zusammenfassung

If you know, why do it?

Copper roof, not sure if it works or we need another location 4 GW.

What happened when you tried OTAA?

Seems like no completely handshake. (ttyACM log)

How configured

lib as link in thread

too close and too loud

no, i think -118dbm are realistic

  1. have you looked at the commit dates for the lib you are linking to? You have been recommended e.g. MCCI (or poss a recent TTN Lib) to reflect modern LNS behaviour (as reflected in TTS(CE) build)

The point is, it worked sometimes with the libs. How am I supposed to explain to someone unfamiliar with technology what he sees there (usually nothing). “Why my bought LORAWAN sensor does not work?” “No idea!”

6.) What lies between you and

Town/copper roof/trees ( Gateway ID: eui-7076ff00560710c2), but shouldn’t the signal then be nonsense in the GW? The GW gets “packages” and apparently the packages are not inconsistent. And yes copper roof is not the best idea but the location is 4 free.

GW

File:Rathaus Fürstenwalde Spree 2016.jpg - Wikimedia Commons

over the Clock and the little windows is a Kerlink Wirnet iStation (Indoor)

14

If you put a RF device in a faraday cage, you cant expect it to work, it is not the technology, it is a scientific thing

15

From your topic starter:

Unexpectedly if you are not familiar with the protocol and its limitations. That is why you are looking for help and we are trying to provide answers and guidance.

We’re trying to help as well as make sure the community network stays available for all users.

At least two of the people responding to your questions deployed tens of gateways each and know what is involved. They also run local communities and have been helping out on the forum for multiple years and as such are well aware of the kind of issues new users face and are willing to help those users. However that works a lot better if those asking for help listen to all advice, not just what they like and dismiss everything else.

You do need to look for another location. As @Johan_Scheepers mentions your gateway is deployed in (almost) a faraday cage. About the worst deployment scenario.
If you put the antenna at the level of the windows things will improve a bit. If possible below the roof in the white tower might be an even better option depending on the construction of the walls, you will need to test. In this case higher is not better.

1 Like
16

If you put the antenna at the level of the windows things will improve a bit.

Bad news, there are our 5GHz WiFi antennas.

But thanks, you are wrong. Got a link with SF7.
Maybe we should work on problems and not ride policies to death.

The network still seems to be available to everyone. Gives a medal to @kersing. For defending the network without attacker.

Thanks @Jeff-UK, maybe PM is better.

18

Whilst we all have a timeout from this.

Arduino & SX1276 - best code to use would be:

OTAA will solve many configuration issues - there are notes in the sample code about which way round the EUI’s need to be. You will also need to increase the interval to at least 300 seconds for use on TTN.

Plus the link to the absolute basics: https://www.thethingsnetwork.org/docs/lorawan/

And the overview section in the docs: https://www.thethingsindustries.com/docs/getting-started/

The console is for debugging, it’s not a dashboard, you need to explore it a little to see where the information & buttons are, as many payloads are different there is no one universal way of displaying it other than a hex string.

As for others deploying common devices, if they follow the instructions for the configuration, setup on TTN and use, they will be fine. Those that chose to build their first device using marginally suitable components inevitably run in to issues. However all the instructions are there to be read if you take your time.

1 Like