Cnf uplinks with a payload > 17 bytes are not working

1

I’m currently experiencing the problem, that confirmed uplinks with more than 17 bytes are not working with TTN when sending with a dr of sf12 or sf11.

The following tests are working fine:

  • Sending uplinks with < 17 bytes
  • Sending unconfirmed
  • Sending with a dr <= sf10
  • Sending to another LoRaWAN network server (ChirpStack)

But as soon as I increase the uplink payload to 18 bytes or more, and send them to TTN, I see the following behavior:
ttn

The antenna is in the same room. The RSSI of the uplinks are at around -40dBm. Join (OTAA) and uplinks are sending with sf12, cnf = true, adr = true, send trials = 3.

As much as I know, sending uplinks up to 51 bytes shouldn’t be a problem with sf12.

Anyone experiencing/ed the same or something similar?

Any suggestion?

Thanks in advance for your help.

2

You may well be overloading most of the RF circuitry on your gateway - try moving one of them in to another room or better, 25m away.

3

Thanks for the suggestion.
I just tried moving my device 30-40m away but no difference (except for a RSSI at around -100dBm).

But I also think that an overloaded RF circuit is unlikely since it’s working with a payload of 17 bytes but not with 18 bytes.

4

As it seems the downlinks are actually being transmitted, I’d peek in the network Traffic to see what’s in the failing downlinks and what is in the successful ones. Using SF11 or SF12 may very well trigger some network ADR MAC command sooner than for other data rates; maybe the device’s LoRaWAN doesn’t like that? (That would not explain why 17 bytes uplinks would work on SF12, while 18 bytes would not. But well.)

5

Here’s an example of a working and a failing scenario:
ttn2

Good idea, I’ll check if I can see something in the network traffic.

If I remember correctly, I’m using the STM32 implementation with the 1.0.2 RevB LoRaWAN specs.

7

Please post the gateway’s full LoRaWAN packets as text, so one can investigate in an online decoder.

8

I just tested a newer version of the used LoRa stack from ST (from V1.1.4 to V1.3.1) but couldn’t reproduce this error. It seems to have been fixed during the last two years.

We will search for a solution to update to this version.

Thanks a lot you for you fast support.

1 Like
9

Before anything else, you should take some time to think about how unreasonably long the on-air time of a packet with 18 payload bytes at SF11 or SF12 actually is. Even at SF10 it’s pretty long.

Also, LoRaWAN confirmed uplink isn’t very well thought out, as if its the ack that is lost, the node will never get another for that sequence number and instead will simply retry until its give up limit. Generally you’re better off doing your own application-level confirmation, not only because of that, but because for many applications it make as much sense to retry with fresher data as it does to keep trying to get increasingly stale data through.

And regardless if a confirming downlink is network-level or application-level, it’s still a very large cost on gateway capacity, since a gateway cannot receive on any channel while it is transmitting a downlink.

1 Like