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.

[ClaireJWyld]

Some measurments taken today using a debug pin.

1. Time taken to return result from RtcGetCalendarTime - 134us
2. Set up a timer to timeout after 5000ms - got 5000.7ms
3. Time taken to start timer - 100us

Safe to say, the timing implementation is spot on.

I'm now investigating what other causes there could be for a VERY late opening of RX1 and ONLY when doing joins

Current setting of MAX RX Error is 50ms. I will do some more debug to get timings from end of Tx Done to start of RX1 window

[ClaireJWyld]

I think that because this only affects joins and not uplinks, then I can reasonably safely assume that this is not a porting error.

I have used to timer functions(which hook into RTC) to set GPIOs on/off and observed the timings on an oscilloscope to be correct. I have also implemented reading from sys time and this is also correct.

When I get a chance betwene other work, I will post my findings here after another set of tests.

[cmorganBE]

@ClaireJWyld did you find root cause on this issue? We'd be interested in how you made out.