Maximum value to be input to otLinkSetPollPeriod function as parameter.

[Abhijith m.s]

Hi,

Using windows 10 OS, and SES v5.40.

I am using nRF52833 device in my project along with nRF5_SDK_for_Thread_and Zigbee_v4.1.0_32ce5f8 SDK.

I am using openthread protocol and specifically otError otLinkSetPollPeriod( otInstance *aInstance, uint32_t aPollPeriod ) function to input the poll period.
Problem statement : the above said function is nothing but the communication poll period and i see from the documentation(https://openthread.io/reference/group/api-link-link) that it is a U32 variable which has max limit of 0x3FFFFFFF and min 10ms for its operation.
But if i run a test by inputting aPollPeriod to some higher value i can see that the value is somehow cutting down to 188s(approx. 3mins).
Ex : Test 1 : if i run with 60 sec(60000) as input i can see that the value of poll period is 60s(59999ms).
Ex : Test 2 : if i run with 200 sec(200000) as input i can see that the value of poll period is 188s(188676ms).
Ex : Test 2 : if i run with 350 sec(350000) as input i can see that the value of poll period is 188s(188676ms).

I am trying to test this with a inbuilt feature of our code that can measure the time and i have attached the debug information for further reference.

Questions:
1. what is the max value that can be input to this aPollPeriod (practically)?
2. Is 188s is the threshold for the pollperiod? 

Regards
Abhijith Desai

[Jonathan Hui]

In determining the IEEE 802.15.4 Data Request transmission period, OpenThread will also consider the existing Child Timeout value - see src/core/mac/data_poll_sender.cpp#L545.

If you want to increase the poll period further, you should also look into increasing the Child Timeout value.

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/ae088fd7-437d-409e-a409-0fa81dfa717fn%40googlegroups.com.

[Abhijith m.s]

Hi,

Thanks for your response on that.

As you suggested i tried to increase the child timeout value to 1000 but it still seem that poll period has not changed and it is still 188s if i input 200s as poll period.

Could you tell me how is the relation of child timeout and poll period. and what exact value of time input we need for poll period to set to desired value. 

[Jonathan Hui]

I'm not sure why you are not able to configure a larger poll period. You can try adding a log to see what mPollPeriod is being set to in DataPollSender::ScheduleNextPoll().

When I add the log, it shows that `mPollPeriod` is being set to 200000 (i.e. 200 seconds).

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/72f02a3f-0af3-4219-98da-ff6a49114b7bn%40googlegroups.com.

[Abhijith m.s]

Hi as you suggested it tried to use some return function  uint32_t otLinkGetPollPeriod( otInstance *aInstance)  to see after i input the poll period value.

But the strange thing is it returns the value i have set but the communication happens at 188s itself. i verified this using the debugger and also using sniffer at 188s i see some traffic in the sniffer.

just a workaround : if possible could you just use sniffer and check at what exact time it communicates when input is 200s.

Best regards

Abhijith Desai

[Jonathan Hui]

Can you provide the sniffer capture and OpenThread logs?

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/3d3f2291-62d9-49d5-8f82-8126ca1fcb03n%40googlegroups.com.

[Abhijith m.s]

Yes please find the attachment of sniffer, and debug log(where we can monitor the wakeup time of application and thread) of the same session. 

[Jonathan Hui]

For the log, I don't see any OpenThread logs. Can you enable DEBG level logging and provide the logs?

For the pcap file, can you provide the Thread Network Key so that we can decrypt the messages?

Also, can both the log and pcap file cover the device's MLE attach process and going into steady state data polling?

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/d6c7cb5b-4cd4-4c9c-a170-c430cf571898n%40googlegroups.com.

[Abhijith m.s]

Yes  ea88129601832ebc05dc06b68fe39420  could you please check with this one for sniffer logs.

And regarding enabling the DEBG level logging, could you just tell me how to enable this thing and i fould very less information on this. 

[Jonathan Hui]

I was not able to find an occurrence of IEEE 802.15.4 Data Request messages being sent with a period of 188 milliseconds in the sniffer capture.

Are you sure your log output is not printing time values in microseconds? Note that when a SED is expecting a response from its parent, it will send IEEE 802.15.4 Data Request messages with a period of 188 milliseconds, which is very close to the numbers you reported (e.g. 188676).

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/ba061665-8d95-4c41-b02f-9a543c12945bn%40googlegroups.com.

[Abhijith m.s]

I verified that the value i am printing in the debug log is definetly in milli-seconds (188676ms)

Just a clue : when ever i see this 188676ms thing prints in debug window i see that the wireshark logs something.

[Jonathan Hui]

Can you point to specific packets in the sniffer trace that are demonstrating the 188 second timing?

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/55935d52-7875-47ee-aaae-eb8169889a72n%40googlegroups.com.

[Abhijith m.s]

Hi,

Yes I have attached a screen shot, debug log and also the sniffer capture to locate the packets at 188s. I see them for every 188s and in screen shot maybe you can consider 808 to 812(same way 822 to 826) messages in wireshark, i see when 188676ms is printed in my debug log. hope this is helpful.

[Jonathan Hui]

Do you have the Child Supervision feature enabled? Note that Child Supervision is an independent mechanism from data polling. Child Supervision allows a child to validate that its parent still has the child in its child table.

The packets you pointed out are MLE Child Update Request message and the sniffer trace shows that these are being sent every 190 seconds, which corresponds to the default value (see OPENTHREAD_CONFIG_CHILD_SUPERVISION_CHECK_TIMEOUT).

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/ac437b02-c690-47ae-8e38-79f648667436n%40googlegroups.com.