search

Lora-net / LoRaMac-node

Reference implementation and documentation of a LoRa network node.
Other
1.86k stars 1.08k forks source link

Bug: LoRaWAN OTAA Join Timings just over a second late on opening RX1 window: MACv5 potentially also v4.7 #1560

Closed ClaireJWyld closed 9 months ago

ClaireJWyld commented 10 months ago

Region EU868 Hardware, ported to MAX32670 MACv5

Hi, so I've sucessfully ported over LoRaMAC-node to the Maxim/Analog MAX32670.

Standard LoRa works very well, RTC, SPI, GPIO all confirmed ot be OK.

I have however noticed that I need a manual negative offset to MacCtx.RxWindow1Delay only when joining, of approx 1.4 seconds (just so happens to be the calciulated time on air of a join request) to ComputeRxWindowParameters, then I get a successful join.

If I remove this offset and add a blocking delay of atleast 4023ms to the bottom of SendReJoinReq, just after schedule Tx, the timings after Tx Done being processed is also correct. Obviously this blocking delay skews the actual timings so no join accept is received.

Without the offset or delay, only one Rx window is opened approx 6 seconds after TxDone. With the delay or offset, two Rx windows are opened at 5 and 6 seconds after TxDone.

I'm assuming this is some sort of race condition but I'm a little stumped.

mluis1 commented 9 months ago

The observed issue is most probably related to the porting. I would recommend to verify the time handling functions specific to your port (RTC).

The reception windows timing and delay are automatically computed based on the TxDone interrupt time (end of transmission). Please refer to following documentation to understand how it works. https://github.com/Lora-net/LoRaMac-node/blob/6384af8f4c4a57016c83f3d34430f0f68855e695/src/mac/region/Region.h#L940-L977

To compensate potential timing errors the LmHandlerSetSystemMaxRxError API will change the DEFAULT_SYSTEM_MAX_RX_ERROR described in previous equations. The provided examples call this API to compensate at least 20 ms potential maximum error for all platforms except SAMR34 where we compensate 50 ms. Care must be taken when choosing this value as when choosing a bigger value one end up with a bigger power consumption.

As a first quick test I would set a bigger value when calling LmHandlerSetSystemMaxRxError API. This will enable you to verify that everything is working as expected. Then as second step I would carefully verify the porting specific time handling functions implementation.

Please also note that when porting to an unsupported new platform one should not modify any files under Mac, Radio or System directories. When porting to a new platform only the API defined under board directory should be implemented.

In the future it would be nice if you could post this kind of questions on the project Discussions tab. It is a better place to engage discussions and then we can agree if it is an issue or not. If you don't mind I move this issue to the Discussions tab.