the packet queue has filled up
Then when I checked the server's neighbours to see if it can find the node, i find this ipv6 address, but it has 65535 added to the end of the address, which was really weird
I'm using the simple_udp functions as in the udp-client example
Any tips on what could cause the address to be corrupted like this?
Due to my application need tsch to synchronize the clock, and need nodes to send message to the root at a rather high frequence, could you give me some advice on what protocol should be used to transmit data?
thank you
@mycstudy as Atis mentioned, seems you are generating packets faster than you have slots to send them in. A look at the timeslot duration for cc1350 might be a good start as it tells you the max. theoretical MAC throughput, and see if that will at all fit your application req. (also note you need room for control packets (TSCH beacons, and RPL if you are using it)). If it looks ok, and you only have one TXing node, using the 6TiSCH minimal schedule (set
BUILD_WITH_ORCHESTRAto 0) and setting its length, TSCH_SCHEDULE_CONF_DEFAULT_LENGTH, to 1 (making TSCH into a slotted aloha) should be a good start in terms of throughput.
that's the reason why TSCH-Sim was developed, by the way. Of course, it does not have support for CoAP or MQTT, but it's fully capable of handling very big networks at the PHY and MAC layers.
Try looking at ns-3 and Omnet++, people may have done something similar
1 reply
the first thing you need to do is to increase the max virtual memory size of the JVM: https://stackoverflow.com/questions/1493913/how-to-set-the-maximum-memory-usage-for-jvm
the other potential problems are more about optimizing the speed of the simulations. If I remember correctly, Cooja radio medium code has a few instances of O(N^2) algorithms, meaning that if you have 5000 nodes, the simulation will have to do some things 5000x5000 times. It was possible to partially get rid of this, but not entirely without a large effort
Hi all, I have been running some TSCH experiments on FIT IoT-lab (m3 nodes) and I am seeing an alarming amount of
!dl-miss RxBeforeAck, which indicate to me that the node was unable to schedule its transmission of ACK. However, looking at the logs, it seems the ACKs was transmitted and received correctly. Anyone know what I am missing? Excerpt from log:m3-356;{asn 00.00005caf } uc-1-0 tx LL-0002->LL-0003, seq 95, st 0 1 <--- indication of successful TX (including ACK RX)
m3-354;{asn 00.00005caf} !dl-miss RxBeforeAck 140 141 <--- indication of Ack fail
m3-354;{asn 00.00005caf} uc-1-0 rx LL-0002->LL-0003, len 108, seq 95, edr 0 <--- indication of successful RX
And answering myself: After looking closer at
tsch_schedule_slot_operation() it seems I am mistaken about the implications on ACK: The !dl-miss RxBeforeAck indeed indicate we were unable to schedule the timer, but we rather go to a blocking busywait plan B instead. So the implications would be sub-optimal performance for energy and processing, while ACK will be sent as scheduled.
Reference to above - any ND protocol example for Contiki-NG/Cooja shall be highly appreciated. Thanks
Where to download it?
But even if the current time is significantly after the expected Rx start time, you might still get an ACK: some platforms do not turn off the radio between the packet and the ACK, meaning that the radio would still receive the ACK, just it might be read by the TSCH layer later than normally expected
@atiselsts Thanks for details, makes sense. I was looking at this because I was experiencing RPL topology changes even after a significant convergence time, and tried to figure out if it was expected or something with my settings or schedule. May I ask if you experienced topology changes after the warm-up time in your experiments? (I glanced at your value, 30 minutes, https://github.com/atiselsts/tsch-scheduling-comparison/blob/80ca07857900f554814a9b9df233b0bf901a97a3/examples/autonomous/common-conf.h#L198)
Hello everyone,
I want to implement an RL mechanism to select the best parent in RPL, But when I select the best parent randomly sometimes. I get the loop error in my simulation. I tried to check if (current node->rank < preferred_parent-> rank ) so there is a loop . with this command ( if (dag->rank >preferred_parent->rank ) so this parent is selected otherwise there is the loop and this random parent is not a good parent because of the loop. but I don't know why it isn't working properly. Do you have any suggestions? I need to select the best parent randomly sometimes so I need to check the loop and design a good loop avoidance mechanism in my random selection part. Any help may be useful for me.
I appreciate you in advance.
I want to implement an RL mechanism to select the best parent in RPL, But when I select the best parent randomly sometimes. I get the loop error in my simulation. I tried to check if (current node->rank < preferred_parent-> rank ) so there is a loop . with this command ( if (dag->rank >preferred_parent->rank ) so this parent is selected otherwise there is the loop and this random parent is not a good parent because of the loop. but I don't know why it isn't working properly. Do you have any suggestions? I need to select the best parent randomly sometimes so I need to check the loop and design a good loop avoidance mechanism in my random selection part. Any help may be useful for me.
I appreciate you in advance.
in contiki,not in contiki-ng
for the price, isn't this a solid option?
2 replies
Hi All, Im facing difficulty in contiki-ng of temperature and humidity sensor with this type of filter should smooth the readings using an exponentially weighted moving average filter
xˆt = ˆxt−1 + α (zt − xˆt−1)
xˆ1 = z1
where α is the filter weight (use 0.1), zt
is the current measurement, xˆt
is the smoothed estimate, xˆt−1 is the
estimate from the previous time-step;
An appropriate set of unit tests for this calculation should include a check that the sequence z = 5, 6, 7
yields x = 5, 5.1, 5.29. and need of unit testing as well
xˆt = ˆxt−1 + α (zt − xˆt−1)
xˆ1 = z1
where α is the filter weight (use 0.1), zt
is the current measurement, xˆt
is the smoothed estimate, xˆt−1 is the
estimate from the previous time-step;
An appropriate set of unit tests for this calculation should include a check that the sequence z = 5, 6, 7
yields x = 5, 5.1, 5.29. and need of unit testing as well