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

[ClaireJWyld]

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]

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.

LoRaMac-node/src/mac/region/Region.h

Lines 940 to 977 in 6384af8

	/*
	* Rx window precise timing
	*
	* For more details please consult the following document, chapter 3.1.2.
	* https://www.semtech.com/uploads/documents/SX1272_settings_for_LoRaWAN_v2.0.pdf
	* or
	* https://www.semtech.com/uploads/documents/SX1276_settings_for_LoRaWAN_v2.0.pdf
	*
	* Downlink start: T = Tx + 1s (+/- 20 us)
	* |
	* TRxEarly | TRxLate
	* | | |
	* | | +---+---+---+---+---+---+---+---+
	* | | | Latest Rx window |
	* | | +---+---+---+---+---+---+---+---+
	* | | |
	* +---+---+---+---+---+---+---+---+
	* | Earliest Rx window |
	* +---+---+---+---+---+---+---+---+
	* |
	* +---+---+---+---+---+---+---+---+
	*Downlink preamble 8 symbols | | | | | | | | |
	* +---+---+---+---+---+---+---+---+
	*
	* Worst case Rx window timings
	*
	* TRxLate = DEFAULT_MIN_RX_SYMBOLS * tSymbol - RADIO_WAKEUP_TIME
	* TRxEarly = 8 - DEFAULT_MIN_RX_SYMBOLS * tSymbol - RxWindowTimeout - RADIO_WAKEUP_TIME
	*
	* TRxLate - TRxEarly = 2 * DEFAULT_SYSTEM_MAX_RX_ERROR
	*
	* RxOffset = ( TRxLate + TRxEarly ) / 2
	*
	* RxWindowTimeout = ( 2 * DEFAULT_MIN_RX_SYMBOLS - 8 ) * tSymbol + 2 * DEFAULT_SYSTEM_MAX_RX_ERROR
	* RxOffset = 4 * tSymbol - RxWindowTimeout / 2 - RADIO_WAKE_UP_TIME
	*
	* Minimal value of RxWindowTimeout must be 5 symbols which implies that the system always tolerates at least an error of 1.5 * tSymbol
	*/

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.