Phil; Thanks for the help! After all I can't use the sequence number to prevent the flooding, as they're unique for each mote... But what I found strange was that the receiving blink kept accusing that flurry or received packets, whilst the sending blink on the other motes wasn't blinking any faster. Anyway, it seems I can't help the situation and need to ensure the existance of the root node.
Thank you! Pedro On 6/21/07, Philip Levis <[EMAIL PROTECTED]> wrote:
On Jun 20, 2007, at 6:00 PM, Pedro Almeida wrote: > Hello, Phil! > > I supposed it to be so, but the message that ends being snooped is > the repetition of the actual normal package that was last sent by > the TestNetwork nodes. I can see it not only from the contents of > the payload, but from the sequence number, that is the same during > the frenzy blinking and returns to normal counting once the root > note goes back up. > Shouldn't the messages from the route discovery be any different? > If they were any different, I could filter the return so the serial > port wouldn't be flooded (I guess I can do that as well, with the > sequence number, though...). > Ah, good point. The CTP link estimator uses data traffic to probe links. If you look at the ETX field of the packets you should see them going up. Basically, loops manifest as flurries of packets to discover and repair the loop. Since there is no possible repair, this approach runs into issues. Basically, CTP tries really hard to deliver packets, and so doesn't drop them except in extreme situations. So the nodes keep on sending... Phil
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
