Openmote node stops communication after about 10 minutes of pinging it using timeslot 15ms
Description
Environment
-firmware: openwsn-fw branch develop HEAD 81d738840cdd6257bdce69b996ef6e54cd7736dd
or
openwsn-fw branch develop_FW-548 HEAD 66e6cd495a617629c5e92f1546fc31a28609f11a
-software: openwsn-sw branch develop HEAD 5e0c137164260cde22b6c415d41a6b21c6abd024
-hardware: openmote-cc2538
*-Timeslot: 15ms" set by removing the definition of SLOTDURATION_10MS in bsp/boards/openmote-cc2538/board_info.h file
Attachments
relates to
Gliffy Diagrams
Activity
Tengfei Chang September 7, 2018 at 2:01 PM
Any updates on this issue?
Tengfei Chang March 26, 2018 at 9:52 AM
, for the large timeCorrection error message, I think it's the timing issue. The way to archive the right timing value is using the logic analyzer, you can refer this page to measure the timing: https://openwsn.atlassian.net/wiki/spaces/OW/pages/688255/Timing+Constants
Farouk Mahfoudhi March 22, 2018 at 10:28 AM
Do you have any feedback about my last comment ?
Farouk Mahfoudhi March 21, 2018 at 9:42 AM
Yes it is very weird that we have different results. For sure, we have something different, may be the hardware, building options, etc..
I tested the ping on the develop and with 5 seconds period and I didn't have the issue for about 5 hours.
So I will say ping or sending data with low periodicity around 1s is no more possible in the new develop branch, using 15ms time slot.
The reasons why I am reporting this, is that I had the same issue with openmote 868MHz using timeslot 15ms and or develop branch.
The 868MHz driver work I took it from this cc1200-OpenMote 868MHz openws-fw branch.
The communication with the chip is SPI (bsp/chip/cc1200-OpenMote)and the radio values are
#define PORT_maxTxDataPrepare 66 // 2014us (measured 1757us)
#define PORT_maxRxAckPrepare 30 // 915us (measured 597us)
#define PORT_maxRxDataPrepare 33 // 1007us (measured 724us)
#define PORT_maxTxAckPrepare 33 // 1007us (measured 944us)
#define PORT_delayTx 14 // 427us (measured 421u
I see that it is not possible to use 10ms timeslot with this module so I keep using timeslot 15ms.
When having the same scenario (one node and one dagrrot) and pinging the node with period 1s, I got the same behavior I described before with 2.4GHz and timeslot 15ms.
Now, as previously mentioned, with 5s periodicity of pinging, I had for 5 hours no issue with develop and FW548 with 2.4GHz and 15ms timeslot.
But using the 868MHz driver, The ping stop after about 5 minutes: the node or the dagroot stops.
Please find the logs in the attachment.
I can see in the logs this error is repeated :
09:44:15 ERROR 639 [IEEE802154E] large timeCorr.: 21 ticks (code loc. 0)
So I said may be the issue is due to these errors and the radio parameters should be adjusted.
Could you please take a look at the logs and tell me how can I solve this ?
Tengfei Chang March 19, 2018 at 4:27 PM
For develop branch, I tried on my side with 15 ms and I don't have this problem. It's indeed weird that we have different results. What if you try with a low speed of pinging? like every 5 seconds?
Preconditions:
One openmote-cc2538 as node (15ms timeslot)
One openmote-cc2538 as dagrrot (15ms timeslot)
The two motes are synchronized
run openvisualizer
Scenario:
ping the node continuously (infinite)
Expected behavior:
The node is always reachable by ping as long as it is running
Both node and dagroot are connected
Seen behaviour:
After about 10 minutes of continuous ping, the node (sometimes the dagrrot) hangs and become not reachable by ping. It radio LED is off
The issue is systematically reproduced