Can I disable OpenThread polling for nrf5 temperature every 30 seconds?

[jeraymond]

Hello,

I'm using the OpenThread from v4.0.0 of the Thread/Zigbee library and the TEMP driver to read nRF52840 temperature via a nrfx_temp_data_handler_t. I noticed the handler is being triggered every 30 seconds in addition to when I trigger a reading myself via nrfx_temp_measure() via a timer. I think I tracked this down to the OpenThread library doing a temperature reading every 30s.

Is there a way to disable OpenThread from triggering a read every 30s or should I just do some additional book keeping to read at the interval I desire?

Thanks,

Jeremy

[Edvin]

Hello Jeremy,

Do you mean that all the examples that use the openthread library use this temperature measurement? How do you determine that this is called in the examples in the SDK?

If you want to change something in the openthread library, you can rebuild it using this guide. The tag that is used with the SDK is marked in SDK\external\openthread\project\readme.txt.

Best regards,

Edvin

[jeraymond]

I derived my code from the simple_coap_server OpenThread example. I registered a handler for temperature callbacks using nrfx_temp_init().

Setting a breakpoint in the handler I see the call stack is:

void my_handler()
void TEMP_IRQHandler()
void AlaramStartAt()
void Remove()
void ProcessTimers()
void nrf5AlarmProcess()
void thread_process()

The thread_process() function is from the examples (./components/thread/utils/thread_utils.c) which is called from the main loop and invokes the OpenThread processing functions otTaskletsProcess() and otSysProcessDrivers(). It looks like like OpenThread library is triggering the temp readings.

[Edvin]

I suspect that the reason the TEMP is checked is to calibrate the LFCLK (if you use an RC Oscillator, this will be necessary). Is it an issue for your application that this happens? Because I would have to check with our Thread team as of why this happens. Is it a problem due to current consumption? It doesn't sound like something that would draw a lot of power.

BR,

Edvin

[jeraymond]

It'd be great if you could reach out to the Thread team to understand the necessity of the temp readings on 30s intervals.

The additional temp reading interrupts cause unexpected behavior in my application. I can work around this my tracking when my app triggers a reading and ignoring the other events as a workaround if necessary.

[Edvin]

Your application should be able to handle unexpected interrupts. It would be as if you receive a packet over the thread network. It is not possible to foresee when these messages are coming. 

And my guess is that it is required for some sort of calibration. Either timing or output power perhaps.

I have forwarded this question to our Thread team. I will let you know when I hear something.

BR,

Edvin

[Edvin]

Hello,

The temperature value is used to compensate it's influence on measured RSSI. 

https://github.com/NordicSemiconductor/nRF-IEEE-802.15.4-radio-driver/blob/4b9d0d4ebca14b2ea1c430c01989abed715bcea5/src/nrf_802154_rssi.c#L41

You see that depending on the temperature the RSSI value can be shifted by the offset in range -3 to +3 dBm, depending on the temperature. 

This value impacts: 

-RSSI

-LQI

-ED

-CCA_ED

In case we were not compensating for the RSSI changes, or react very slowly, we could see two issues:

- Impacted routing (so the frame would take a different path than it should, or even a node could be considered out of range, due to inaccurate RSSI measurements).

- impacted frame sending as the Energy Threshold could not be exceeded - so at the edge of range the connection would be even less reliable.

These examples are exaggerated, but could happen - especially important in environments in which the temperature changes radically, e.g. lighting solutions. 

If the environment is stable it should be safe to increase the TEMP_MEASUREMENT_INTERVAL, or not to compensate it at all. 

You could for example take 0 as the compensation offset. In worst case the RSSI would be 3 off. Please note that the above scenarios are from a theoretial analyzis. We did not perform any testing with the temperature measurements turned off.

--------------

This was the answer from our Thread team.

It has been a while since you originally had this question, and I don't know if you have managed to find some workaround from the issues that you had with the interrupts. I still mean that your application should be able to handle interrupts, but if you want to turn off the temperature measurements, you need to rebuild the openthread stack.

Remember to use the same tag that is used in the SDK that you are using. The tag is noted in the file:

SDK\external\openthread\project\readme.txt.

Best regards,

Edvin

[jeraymond]

Hi,

Thanks for the detailed explanation, I appreciate these details. This all makes sense.

I did do as you suggested and added some tracking to determine when I triggered a reading so I can ignore the OpenThread triggered interrupts.

Jeremy