TTN Console shows uplink in Application, but without its payload

Hi guys,

I am facing some problems in receiving the payload coming from my end node.

Let me explain better:

CONFIGURATION

Everything till there is working. The code runs smoothly, the raspberry connects to TTN, and the packet is correctly received by TTN gateway.

Now comes the problem. It’s looks like the TTN gateway does not transmit the payload received by the LoRa gateway to the application. Only communication parameters are streamed.

I have tried to understand what is going on, but after 3 days struggling I am close to give up.

Here same pics of the data received

This is the packet received by the LoRa gateway

LoRaGateway

This is the data received by the TTN gateway

GatewayData

Finally, the data received by the application

AppData

Where the payload received by the TTN gateway goes :thinking: ?
Why the app says, “Payload not provided” even if the gateway has received it?

with “TTN gateway”, I mean the gateway that I have registered @ https://console.thethingsnetwork.org/gateways.

I don’t understand , you have a dragino lora gateway AND a TTN gateway ?

with “TTN gateway”, I mean the gateway that I have registered @ https://console.thethingsnetwork.org/gateways, where I can check If the raspberry single channel gateway is working/connected

(mmm yeah… maybe calling it “TTN gateway” is a bit misleading)

Hi
have you tried a shorter payload ?

Is there the code to decode the payload in “Payload formats” -> decoder?

Hi,
yes, I have tried payload with length from 1 to 50 Bytes. Same results.

Regarding the decoder, It still un-configured. I have tried some codes, but no one works.
Once configured, for example, following this, in the application page, I get an empty object in “Fields” and no payload.

The message that my end node sends, is a json string that is then encrypted and converted to base64 by LoRaWAN.

Seeing that TTN was able to map the device to your application implies it has checked the MIC, so the DevAddr and NwkSKey are okay. The MIC is calculated for the encrypted payload, so TTN won’t notice if you’re using the wrong AppSKey in your device, but then you’d simply see random data after decrypting. So all fine as for the keys.

However, an online decoder shows that you’re sending on port 0. That’s not good; the LoRaWAN specifications state:

If present, an FPort value of 0 indicates that the FRMPayload contains MAC commands only

So: use a different value.

I’ve changed my dummy decoder that you found to support empty data, but it’s probably not even invoked when the port is 0.

(As an aside: never send text, and never ever send JSON text. But that is unrelated to your problem. Also, LoRaWAN does not convert anything to Base64; that’s the gateway doing that before sending it to TTN in a JSON message with additional metadata, and TTN might also display bytes in Base64 to get something that is always human readable.)

2 Likes

Thank you for your tips.

I will try changing FPort. Btw we also have another gateway (from multitech), and that gateway receives the payload without any problem with FPort = 0.

I doubt that gateway is connected to TTN as well?

Ha perfect.Tnx Arjan.

Yes. As full LoraWAN gateway, It does not need TTN.

I’d say it’s not LoRaWAN compliant if it’s showing the payload to be the application payload rather than (invalid) MAC commands when using FPort = 0… Anyway, additional functionality in the gateway’s software does not make it a “full” gateway.

1 Like

I have tested the communication with a different port, and now the payload is correctly displayed. Thank you for your help and useful tips.