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:
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?
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.)
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.
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.