I’ve noticed some problems handling large downlinks on both v2 and v3 of TTN.
I’m testing in the AU915 region, so I don’t know if these issues apply elsewhere.
On v2:
TTN seems to accept downlinks of arbitrary size, and actually tries to send them to the gateway.
So if you queue a maximum size downlink (say, 53 bytes at SF12 in AU915) it will send
BUT, if there are MAC commands pending, they will be added to the packet, making it oversize
My gateway happens to transmit the oversize packets happily, so long as they are <= 255 bytes
But my devices reject oversized packets, for technical reasons
Obviously this is a standards compliance issue, but the v2 stack is sunsetting, so it will resolve with a bit of time
On v3:
TTN seems to know that a maximum packet size exists, and will keep an oversize downlink queued until the DR allows it to be sent
However, while an oversize downlink is in the queue, confirmed uplinks will not be acknowledged
And more critically for me, the maximum sizes seem to be wrong
At SF12/500 in AU915, I’m measuring a maximum of 28 bytes, instead of 53 bytes
At SF7/500 in AU915, I’m measuring a maximum of 217 bytes, instead of 242 bytes
You shouldn’t use confirmed uplink anyway - downlinks are too expensive to burn one for such purpose. If you really need a rare confirmation, do it at application level with extreme care, not crudely at link level.
At SF12/500 in AU915, I’m measuring a maximum of 28 bytes, instead of 53 bytes
Agreed. Just mentioning it because its broken. And some devices will use a confirmed uplink to force pending sticky mac commands to be acknowledged, and therefore stop taking up space in subsequent uplinks.
Realistically, long downlinks are a bad idea
Agreed. But long downlinks are sadly essential to support Semtech’s latest LR1110 chip, which consumes large almanac files. And if you have to downlink something, you want to use the largest downlinks you can, because the overhead of sending a LoRaWAN packet is on the order of 32 bytes for an empty payload. So its important that the network be able to send the specified MTUs - or devices will have to waste resources probing the MTU.
or in payload size:
[51 51 51 115 222 222 222 0 33 109 222 222 222 222].
But, the 33 and 109 are a mistake - the editor seems to have subtracted 20 from all of the repeater-incompatible numbers, instead of just subtracting it from the largest payload sizes. This mistake is corrected in the latest regional parameters, where the sizes appear as:
Just because a technology exists doesn’t mean TTN supports that rather demanding use case or long downlinks to enable it; you still have a pretty restrictive use policy to think about.
which consumes large almanac files
That’s where you start to need to think about a more viable multicast scheme than the spec yet really envisions
some devices will use a confirmed uplink to force pending sticky mac commands to be acknowledged
dubious - MAC commands typically interact with MAC commands, not the confirm/ack bits