Hi,
I am trying to come up with a different approach to SED reattachment using a backing off MLE session. Is there a way for the SED to keep on the polling even when in detached state? As far as I know, the polling would get ACK/NAK from the parent. So when the SED gets ACK after a period of NAK, that indicates a possible parent come back and the SED can issue a MLE session then. But as I can see, the SED stops polling after detached from the thread network.
Cheers,
Kaushalya
Also I can see current pulses from the SED like this, even when detached. Could you explain what are they? None of them seem to increase MAC counters, so I think none of these are actual radio tx/rx sessions(?).
The pulses are like this in detail.
Also there is another pulse here
Which looks like this in detail
Hi Kaushalya,
Is there a way for the SED to keep on the polling even when in detached state?
Polling in a detached state does not make sense, as the SED would not have a parent to poll. When a SED detaches from its parent it will send parent requests until a potential parent responds, then it performs a parent selection and attaches to the best parent.
If you want to implement another way to reattach your SED it seems from your description that you will not follow the specification.
kaushalyasat said:Also I can see current pulses from the SED like this, even when detached. Could you explain what are they? None of them seem to increase MAC counters, so I think none of these are actual radio tx/rx sessions(?).
I must admit that these pulses are unfamiliar to me. The current level could align with the radio being on, though the actual value is lower than the expected typical value from this table. The SED periodically turning on the radio and not sending parent requests in a detached state is also not expected behaviour.
Since you are mentioning the lack of increase for MAC counters during these spikes, I assume that you are already sniffing and analyzing the packets?
Are you able to get device logs from the SED? The current consumption will of course increase by enabling logging, but it could help to explain what the spikes are.
The 8s interval spikes are strange, and I don't have a first step to begin to investigate those at this point. Sorry about that.
Please also let me know if you are working with a DK or a custom board.
Best regards,
Maria
Hi Maria,
Thanks.
Polling in a detached state does not make sense, as the SED would not have a parent to poll
Ok, can we do any MAC level monitoring to see if the parent is back? I know my parent's commissioned details.
The issue of SED sending MLE approach is
1. if I want to save power, then I have to extend backoff. This means the SED may see the parent after a long time.
2. if I have shorter MLE cycles, then the battery will drain quickly.
This is why I am looking at another approach.
The SED periodically turning on the radio and not sending parent requests in a detached state is also not expected behaviour.
You think I can monitor the radio space using wireshark to see if this SED is sending any radio packets? I was looking for MLE traffic but not anything else from the SED. I will relax my filters and see any traffic from the SED.
Are you able to get device logs from the SED
I can. The logging is not disabled. The issue is as soon as I enable console to get the logs, it increases current consumption and I cant see the current pulses anymore. If I use RTT console, does it still affect current consumption?
The 8s interval spikes are strange, and I don't have a first step to begin to investigate those at this point
Does the radio performs any calibration during detached state?
The SED periodically turning on the radio and not sending parent requests in a detached state is also not expected behaviour.
These parent requests are the MLEs? I have relaxed my MLE backoff minimum to 5 minutes and max to 1Hr. I can see MLE current pulses occasionally.
Cheers,
Kaushalya
Hi Kaushalya,
Thank you for your patience.
kaushalyasat said:Ok, can we do any MAC level monitoring to see if the parent is back? I know my parent's commissioned details.
The issue of SED sending MLE approach is
1. if I want to save power, then I have to extend backoff. This means the SED may see the parent after a long time.
2. if I have shorter MLE cycles, then the battery will drain quickly.
This is why I am looking at another approach.
I asked internally about an alternative method for reattaching a SED to its parent. The feedback I got was that the only method we only provide is the MLE Attachment procedure. You are free to configure the MLE Parent Search back-off algorithm to meet your needs.
It could be possible to use and out-of-band method to determine if a parent is in range and use the OpenThread API to manually startthe attachment. otThreadBecomeChild does this, but it is only meant for demo purposes, as noted in the source code. Using the API may cause the device to cease following the Thread specification.
Maria Gilje said:The SED periodically turning on the radio and not sending parent requests in a detached state is also not expected behaviour.
kaushalyasat said:These parent requests are the MLEs? I have relaxed my MLE backoff minimum to 5 minutes and max to 1Hr. I can see MLE current pulses occasionally.
Yes, they are MLE Parent Requests.
kaushalyasat said:I can. The logging is not disabled. The issue is as soon as I enable console to get the logs, it increases current consumption and I cant see the current pulses anymore. If I use RTT console, does it still affect current consumption?
Understood. Based on my experience, the backend used for logging does not make a big difference in current consumption. Let's not go forward with this as a debugging tool for now.
kaushalyasat said:You think I can monitor the radio space using wireshark to see if this SED is sending any radio packets? I was looking for MLE traffic but not anything else from the SED. I will relax my filters and see any traffic from the SED.
Yes, this was what I was thinking. Let me know if you saw some possible source for the spikes in the packets after relaxing your filters.
In my internal inquiry I also asked about the 8s interval spikes, which was also not familiar to them. Some more information on your application is likely needed to move forward. Could you please share some more information on what your application is doing? Did you start with a sample?
Best regards,
Maria
Hi Maria,
I have now given up on this MAC level parent detection mechanism.
I am trying to keep the sensors which have attached and in child state, in child state for longer in the presence of host powering down. The sensor data and polls will get NAK as transmissions fail. The idea is when the host powers up in a hour or two, it will retain the same network credentials and the sensors which are in child state can resume data tx as if nothing happened, without any MLE session.
I have tried
[00:00:41.370,300] <inf> [N] Mle-----------: Attach attempt 2, AnyPartition
[00:00:43.500,854] <inf> [N] Mle-----------: RLOC16 fffe -> dc01
[00:00:43.500,976] <inf> [N] Mle-----------: Role detached -> child
[00:00:43.508,239] <inf> coap_client_utils: ------- Sensor Start --------
[00:00:43.508,239] <inf> coap_client_utils: Ext Addr: e2:59:51:2d:d1:ac:01:37
[00:00:43.508,270] <inf> coap_client_utils: MAC: f4:ce:36:4b:d5:b9:c6:71
[00:00:43.508,270] <inf> coap_client_utils: RLOC: dc01
[00:00:44.069,854] <inf> coap_client: SHT4X: 22.78 Temp. [C] ; 39.90 RH [%]
[00:00:44.069,885] <inf> coap_client: Temp: 22.78 RH: 39.90
[00:00:44.074,615] <inf> coap_client_utils: ZS 0, RSSI -75, LQI 3, LQO 2, FW 1241 RET: 0, RLOC: dc01
[00:01:00.036,407] <dbg> temp_nrf5_mpsl: temp_nrf5_mpsl_sample_fetch: sample: 87
[00:01:00.036,437] <dbg> temp_nrf5_mpsl: temp_nrf5_mpsl_channel_get: Temperature:21,750000
[00:01:05.037,567] <dbg> coap_client_utils: parent_monitor_work_handler: Parent status: RESPONSIVE (in CHILD role)
[00:01:13.514,221] <inf> coap_client_utils: ---- Host ACK -----
[00:01:13.514,251] <inf> coap_client_utils: Result : 0
[00:01:13.514,282] <inf> coap_client_utils: ✓ CoAP transmission successful
[00:01:35.037,689] <dbg> coap_client_utils: parent_monitor_work_handler: Parent status: RESPONSIVE (in CHILD role)
[00:01:44.083,007] <inf> coap_client: SHT4X: 22.79 Temp. [C] ; 39.88 RH [%]
[00:01:44.083,038] <inf> coap_client: Temp: 22.79 RH: 39.88
[00:01:44.087,768] <inf> coap_client_utils: ZS 0, RSSI -75, LQI 3, LQO 2, FW 1241 RET: 0, RLOC: dc01
[00:01:44.232,666] <inf> [N] MeshForwarder-: Failed to send IPv6 UDP msg, len:103, chksum:2033, ecn:no, to:0xdc00, sec:yes, error:NoAck, prio:normal
[00:01:44.232,940] <inf> [N] MeshForwarder-: src:[fdde:ad00:beef:0:dccd:79d4:8f11:f62d]:5683
[00:01:44.233,184] <inf> [N] MeshForwarder-: dst:[fdde:ad00:beef:0:8c62:93f7:ebb6:e2c4]:5683
[00:01:45.612,365] <inf> [N] Mle-----------: Role child -> detached
[00:01:45.612,579] <inf> [N] Mle-----------: RLOC16 dc01 -> fffe
[00:01:46.076,538] <inf> coap_client: Paired->Not Connected
[00:01:46.356,872] <inf> [N] Mle-----------: Attach attempt 1, AnyPartition
How can I relax the MLE detachment in one tx error?
OPENTHREAD_CONFIG_FAILED_CHILD_TRANSMISSIONS=100
# Also increase MAC retries
OPENTHREAD_CONFIG_MAC_DEFAULT_MAX_FRAME_RETRIES_DIRECT=15
# Disable parent search
OPENTHREAD_CONFIG_PARENT_SEARCH_ENABLE=0
# Disable link request on timeout
OPENTHREAD_CONFIG_MLE_SEND_LINK_REQUEST_ON_ADV_TIMEOUT=0
Nothing seem to help. Still one tx fail, the child detaches.
Please help.
Cheers,
Kaushalya