LoRa malfunction after a few weeks run

[iotitk]

Hi

We have sensors in which we are using 4.4.2 LoRa version running on different hardware infrastructures (network, Gateway, components...)
Since a few weeks we have observed a strange thing, the sensor is not receiving anymore the downlink messages and then stop completly its communication.
Our first observation is that there is a drift between transmission delay and reception delay that increase and after a while we have the timers included in the library which stop.

Does anybody already observed this strange behaviour ?

Regards

[mluis1]

Personally I did not observe this situation.

To fix your problem I would start by investigating what could be the root cause for the observed drift.
The possible time drift causes I see are:

• Temperature changes over time
• If using an RC oscillator as time base try to change to a XTAL or TCXO oscillator more precise and stable over temperature changes.
• If your platform is not one of the ones provided by this project check that your timer driver implementation does not introduce time errors.

For debug purposes you may consider to increase the system maximum tolerated rx error.
Be cautious when increasing this value (at maximum I would recomend a few tenths of milliseconds).

LoRaMac-node/src/apps/LoRaMac/periodic-uplink-lpp/NucleoL073/main.c

Lines 291 to 292 in 24d55f6

	// Set system maximum tolerated rx error in milliseconds
	LmHandlerSetSystemMaxRxError( 20 );

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.

[iotitk]

Thank you for your answer.

So we have realized a few test with our design :

• temperature tests in climatic chamber during month (temperature from -15°C to +70°C)
• consumption tests with multimeter during weeks
• timings analysis during weeks (Tx, Rx...)

It seems that temperature have no effect on our system we haven't seen a problem when temperatures are hot or cold.
For the consumption of our system we haven't seen stange things, we have correct current consumption.

For the Maximun Rx error we have checked in our code and seems to have a smaller value set :

So we will try to set this SystemMaxRxError to 20

[dmeehan1968]

I've just encountered some similar behaviour but in a much shorter time span. v4.4.5 on AS923-1 with ADR enabled, we have periodic uplink alonside regular uplinks, and the periodic is used to solicit a downlink and also carry LinkCheckReq. Once ADR had raised to DR4, the end device was no longer receiving the downlink or LinkCheckAns. It appeared that there was a mismatch in DR or channel between the TX and RX window, but couldn't actually confirm that, and it could have been a timing offset. We already had some devices on test where, on analysis of historial data, revealed that one device had worked ok, acheiving DR5, and another exhibited the same when crossing through DR4. This is likely due to differening local environment causing ADR to progress at different rates relative to the uplink/downlink interval.

In the application, the periodic downlink is used to validate the network connectivity and allows the end device to receive new configuration information. If it is not received after multiple attempts with randomised back off (which equates for 60-120 minutes typically) we assume the network session has been lost and rejoin is initiated. When this happens, bi-directional comms is reestablished (as it always starts at DR2 on AS923), and things progress correctly until DR4 is achieved via ADR.

We found that by disabling end device ADR and using DR2 throughout was enough to make it work, this was a for a proof-of-concept so we will have to revisit it if things move ahead. I am planning an upgrade to v4.6.0 at least as part of this to eliminate whether this is an issue already resolved.