On Jul 31, 2007, at 3:59 PM, Todd Roper wrote:
The CTP root node current sends beacons very often, in order to
ensure that a network forms quickly.
You can always change the rate at which it sends beacons by
increasing the value of the second parameter to CtpRoutingEngineP in
CtpP.nc. E.g., if you set it to 30 it will send beacons every 30s.
Phil
I have discovered the issue regarding nodes disappearing after some
amount of time using the CTP. I have 3 nodes (31,33,34) in the mesh
talking to a Root (basically Antitheft without dissemination). All of
the nodes were talking for about 3 days, then two of them disappeared
from reporting. I connected up a BaseStation and snooped to see what
was occurring and I discovered that the nodes were still trying to
communicate every 5 minutes as programmed, however, it looks as if
they
are trying to send through some nodes that are not in the mesh.
Node 34 is still active, Nodes 31 and 33 are trying to send through
nodes 0001 and 0080 respectively. I have attached a brief part of the
serial data. It shows the last part of node 33 trying to send, then
stabilizing back to the beacon timer from the Root.
I am curious as to how it may get into this state and whether there
is a
way to detect it and force the routing table to rebuild (if that is
the
issue).
If it's trying to send to a node that doesn't exist, that's strange.
It suggests memory corruption in the routing table. In theory, it
should not stick with such a node very long, as the ack-based
estimates will let it know that this is not a good node.
Looking at your trace, though, I'm a bit worried: node 33's data
packets say that it has a route ETX of 0! This seems very unlikely.
It also takes many packets for 33 to switch over. Are you sure there
is no node 80 in your network? If it is issue link-layer ACKs, then
33 might stick with it for a while.
I don't think net2 has ever seen behavior like this. It doesn't mean
that it's never happened, we've just never observed it.
Phil
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
