On Apr 24, 2008, at 3:29 PM, Bulut ERSAVAS wrote:
Hi Omprakash & Phil,We have had a chance to test latest CTP with net/le & LPL for a longer period today. We had the same network placement:3rd Floor: root (0) -> 1 -> 2 2nd Floor: 3 1st Floor: 6 -> 4 -> 5We inserted a TelosB (#7) into the network at first floor. Its debug logs from UART is in the attached file. Omprakash, how can we direct debug logs to the radio? Could you send me an example?We timestamped the logs on the PC side, but I guess Omprakash wants us to timestamp packets on the mote. Again, I would appreciate if you can provide us examples or a web link with more specific info.At around 15:52, we moved node #2 outside the building. It took almost 2 hours for node #2 to find a new path. Unfortunately, I don't have the debug logs for this node as it doesn't have UART support and we didn't know how to direct the logs to radio.Tomorrow, we'll try testing the network without LPL and see if it reduces the amount of data losses.
What's really important is to get a serial log of the node that's not able to send packets. That lets us know exactly what that node is seeing and why it's doing what it is. For example, parsing the log of node 7 that you sent, I see:
1) It starts with no route 2) After 4 beacons, it gets a parent: node 3 3) After 24 data packets, it changes its parent to node 6 4) After 3 data packets, it changes its parent back to node 3 5) After another 30 or so, it tries node 4 6) A few more parent changes occur 7) At packet 160 or so, it changes its parent to node 2 8) Node 1 asks node 7 to forward a packet 9) Node 7 now encounters a very long period of terrible connectivity - It first tries node 2 a lot, drops a few packets, delivers a few - Then it tries node 4 - Switches back to node 2 - Switches to node 6 (this forms a routing loop)- Switches back and forth between 1, 3, 4, and 5, with lots of retransmissions
I've attached a zip of the parsed log.Om -- there is definitely something weird going on with this log. I know CTP can't log beacon receptions due to the load this incurs sometimes, but the fact that there can be such long retransmissions series with no parent changes suggests something is off.
My guess is that node 2's problem is that CTP isn't designed with mobility in mind, in particular how that might cause a neighbor table to be completely invalidated. This means that a node should, if its neighbor table looks like it's hosed, send beacons with the pull bit to get beacons from other nodes and replenish the table.
Phil
debug7.txt.gz
Description: GNU Zip compressed data
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
