RAK4600 packet bug

[jorge_v (Jorge Villamarin)]

Hi,
Issue: RAK4600 occasionally throws up error code 87 when sending a packet of size between 48 to 51 bytes.

Setup: AU915 band, SF12 / 125kHz, 20dBm, ADR enabled, Class A, 7 retries configured, FW version: 3.4.0.16

Server: loriot.io

Details: Altought in AT Command Manual, Appendix II is shown that the max usable payload size for AU915 and DataRate 0 is 51 bytes, the RAK4600 fails to send the packet after 9-12 FCntUp if the packet is equal or greater than 48 bytes.

I’ll appreciate any suggestions to solve this issue.

[beegee (Bernd Giesecke)]

Hello @jorge_v welcome to the RAK forum.

You have ADR enabled. This allows the LoRaWAN server to change the datarate.

Can you try to disable ADR with at+set_config=lora:adr:0 and see if the error still occurs.

[jorge_v (Jorge Villamarin)]

Hi, @beegee
Thanks for the response. Actually, i’ve noticed that with the ADR disabled and DataRate 0 (lowest possible), the problem seems to be solved, allowing me to send packets up to 51 bytes. But I still find quite weird the fact that with ADR enabled, the problem still happens. Is there a major constrain related to the payload size when I enable ADR? Our project still requires ADR.

[beegee (Bernd Giesecke)]

Hi @jorge_v
I am not sure what is causing the problem. We see it as well sometimes in our WisBlock products (RAK4631), but it always goes away if you disable ADR. And the problem is not only happening on AU915, we see it as well in US915 and AS923.

[nicolasech (Nicolas)]

Hello @beegee. Perhaps is there a list you could share of the products affected by the problem?

It would be really nice to know for sure the options we have for choosing a LoRaWAN module that fully supports ADR.

[beegee (Bernd Giesecke)]

Hello,

There is no such list. I had the same problem on a Circuitrocks Alora board which uses an eByte LoRa module.

[cstratton (Chris)]

@beegee

I am not sure what is causing the problem. We see it as well sometimes in our WisBlock products (RAK4631), but it always goes away if you disable ADR. And the problem is not only happening on AU915, we see it as well in US915 and AS923.

One possibility would be that the node is sending MAC command responses in the FOPts field of the uplink to MAC commands previously sent by the server (responses required by the LoRaWan spec) and these are reducing the amount of the overall packet length lefft available for application payload. 3 bytes in FOpts wouldn’t be a surprise at all.

From the Regional Parameters spec section 2.5.6:

The maximum application payload length in the absence of the optional FOpt MAC control field (N) is also given for information only. The value of N might be smaller if the FOpt field is not empty

The thing to do might be to repeat the test but with smaller application payloads so that they can actually send without error, and then look at the raw uplinks (to see if there are MAC responses stuck in some of them). Or even with the packet sizes that are failing, one could check logs for any preceding downlinks and manually decode any MAC commands out of those to see if they are ones requiring a response.

While MAC commands aren’t uniquely associated with ADR, it’s not unreasonable that a server would send fewer of them towards a non-ADR node.

If one has use a use that really requires a 51 byte packet (which is absurdly long in time duration at SF12) then the thing to do might be on error to queue a zero length packet (or else a short one) to carry the MAC command responses, and then resume sending the full length packets.

[nicolasech (Nicolas)]

Hello,
Perhaps are there any news on this issue? hopefully a firmware update?

[carlrowan]

Hi @nicolasech ,

I am not sure about the specific of issue you have.

On the original question of @jorge_v , it was solved by disabling the ADR as he mentioned.

The reason for this is explained by Chris.

@cstratton

The maximum application payload length in the absence of the optional FOpt MAC control field (N) is also given for information only. The value of N might be smaller if the FOpt field is not empty

I have no screenshots of logs in a gateway right now showing this. But FOpt can be occupied by MAC commands which can affect the maximum payload size possible.