Hello, Phillip, thanks for your reply; I thought the antenna to be omni-directional, the orientation to be unimportant. I had a friend holding the mote from a distance, no concern of orientation. I guess the test went kind of buggy, then... I had the sink connected to the serial port and I was reading the serial messages, and a LED going on after Collection.Receive (which i guess only triggers on data packets), but that also won't help me with the debug messages (which i honestly don't know how to use).
But i don't understand your last sentence, " the node can't discover a route due to broadcast packet losses, but it can maintain a route through data traffic." Is this related to keeping a route when going "away", but not easily being able to re-establish it on the way "back"? Also, could you pleasem, if possible, reply to my initial questions too? I would like to understand this better. It's too complicated for me to find the answers by looking through the code (and not knowing where to search...). Thank you for your help! Pedro On 7/5/07, Philip Levis < [EMAIL PROTECTED]> wrote:
On Jul 5, 2007, at 11:35 AM, Pedro Almeida wrote: > Hello, all! > > I have some doubts: > > Let's suppose i have a CTP network made out of 2 nodes only (this > is a test I ran), the sink and a "standard". Now let's assume that > I step apart these two nodes for as far as they're barely "visible" > to each other (I found this to be around 60 meters). > Faced whith this situation, I observed several packages being re- > sent by the "standard" node into the sink, never failing the order > (i analysed the sequence number), and i presume this to be caused > by the ACKs that never got back, thus causing the re-sending. > Stepping them a little bit farther apart, i started noticing some > gaps in the sequence number, as if some packets were totally lost. > I also noticed that if I stay at 60 meters and have relatively fair > transmission, going to 80 and getting back to 60 doesnt always > provide same delivery rates (sometimes i didnt get anything when > going back to 60, even though i received something before). > > So my questions are: > - How many attempts does it take for a packet to be discarded from > retransmission, after many attempts without getting ACKs back? TEP > 123 says they're placed in a queue for future retransmission, but I > presume they don't stay there forever? Or else I wouldnt notice > sequence number gaps in the received packages...? Does the CTP tree > breaks here and starts looking for a new path? > - If the link gets weak enough, does the "standard" node re-attempt > to recreate a CTP tree and discards all queued messages? How weak > (or strong) needs a link to be for the nodes to establish a route? > I ask this because the apart/together thing, where it seems the > tree wasnt being "rebuilt" when it was perfectly healthy minutes > before in the same position (with the several retransmission to > assure packet delivery). > > Thank you for your help! Reception isn't always constant over time; so it might be that you put the node back at 60 feet, but the orientation was slightly different, or the environment had changed, such that there was a 1dB difference in signal strength, which could have a big effect on delivery rates. What I would recommend doing is either hook your transmitter up to a serial port and see what debug messages it is sending (if you have debugging enabled) or set up a BaseStation to see if it's sending routing beacons, data packets, or both. One possibility is that at 60ft, the node can't discover a route due to broadcast packet losses, but it can maintain a route through data traffic. Phil
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
