Closed jamesl-dm closed 3 years ago
Isn't this a duplicate of #3939, or more of a clarification?
Isn't this a duplicate of #3939, or more of a clarification?
No, 3939 applies to all regions. This issue is a typo in the regional parameters for AU915 only.
Summary
The downlink sizes in https://github.com/TheThingsNetwork/lorawan-stack/blob/d4791aeafa01f8f85eb258c534a5706a1d0c4a74/pkg/band/au_915_928.go#L95 are based on older versions of the regional parameters, which appear to have a clerical error in the repeater-compatible size list. Repeater compatibility requires ensuring that the packets can be encapsulated in a large (242 byte payload / 250 byte MACPayload / 255 byte PHYPayload) lorawan packet. This means reducing the maximum user payload size by 20 bytes on the high end only. But by mistake, the editor seems to have reduced ALL the sizes by 20 bytes. This mistake seems to be fixed in the latest regional parameters.
I think TTN should correct the values 41 and 117 in the table, to 61 and 137. This is consistent with the latest regional parameters, and with all of the other regions in the older regional parameters. And devices should be happy to accept the larger sizes, since they MUST be capable of accepting larger sizes when a repeater is not in use.
Steps to Reproduce
Try to send a maximum size downlink in AU915
What do you see now?
The maximum downlink sizes are too small, by 20 bytes, plus a further 5 bytes due to an unrelated bug (edit see #3939).
What do you want to see instead?
The maximum downlink sizes should ideally match the sizes in the RP002-1.0.2 document.
Environment
AU915 subband 2
How do you propose to implement this?
Increment the affected values by 20.
How do you propose to test this?
Attempt to send a maximum size downlink
Can you do this yourself and submit a Pull Request?
I could - but you may decide to reject the idea and use the published incorrect values.