Could you please send the sequence of 14 pkts? Also, the node id's of all the nodes in the network.
Thanks. - om_p > > --Boundary_(ID_fV07YJXUQXrxAiWVf3N4vw) > Content-type: text/plain; charset=ISO-8859-1; format=flowed > Content-transfer-encoding: 7BIT > Content-disposition: inline > > Hello, Omprakash! > > The messages are basically like this: > > 7E 45 00 FF FF 00 00 13 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 53 63 7E > > In the 0's there should be the CTP header and data structures (they get > correctly populated after 14 receives from the network). > > Thanks, > > Pedro > > On 7/16/07, Omprakash Gnawali <[EMAIL PROTECTED]> wrote: > > > > > > If you post those messages you get on the serial port and if I > > recognize them, I will tell you what they are. > > > > - om_p > > > > > > > > Hello, Omprakash, thank you for your answer! > > > > > > I have commented everything related to collection debug and debug > > overall > > > code, but something might have slipped, it's possible. > > > Even if they are debug messages, why do you think it takes that amount > > of > > > messages to start receiving actual correct frames? Can it be by any > > chance a > > > way to measure the time taken to establish a tree? If they're debug, and > > if > > > the tree forms instantly (or close), why the wait? > > > > > > Thank you! > > > > > > Pedro > > > > > > On 7/14/07, Omprakash Gnawali <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > So let me redo the questions: > > > > > > > > > > How does the P bit enabling works? Who/what causes it and why? > > > > > > > > To add to what Phil said, the current implementation sets PULL bit > > > > like this: > > > > > > > > ... > > > > else if (routeInfo.parent == INVALID_ADDR) { > > > > beaconMsg->etx = routeInfo.etx; > > > > beaconMsg->options |= CTP_OPT_PULL; > > > > } else { > > > > ... > > > > > > > > (When a node does not have a parent, for example, when a node boots > > > > up.) > > > > > > > > > > > > > > > > > The question about the 14 data messages remain. > > > > > > > > > > > > > Did you disable the debug messages? Those messages on the serial > > > > interface are probably debug messages. CTP should not send bogus > > > > messages on the serial port - if the tree is built, it will send data > > > > messages, otherwise there will be no data messages to forward. Debug > > > > messages are independent of the data messages and if they are enabled, > > > > not only the base station, but all the motes should send some debug > > > > messages on the serial port. > > > > > > > > - om_p > > > > > > > > > > > --Boundary_(ID_fV07YJXUQXrxAiWVf3N4vw) > Content-type: text/html; charset=ISO-8859-1 > Content-transfer-encoding: 7BIT > Content-disposition: inline > > Hello, Omprakash!<br><br>The messages are basically like this:<br><br>7E 45 > 00 FF FF 0 *0 00 13 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 53 63 7E<br><br *>In the 0's there should be the CTP header and data structures (they get correctly * populated after 14 receives from the network). > <br><br>Thanks,<br><br>Pedro<br><br><div><span class="gmail_quote">On > 7/16/07, <b clas *s="gmail_sendername">Omprakash Gnawali</b> <<a href="mailto:[EMAIL PROTECTED]">gnawal [EMAIL PROTECTED]</a>> wrote:</span><blockquote class="gmail_quote" style="margin-top: 0; m *argin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-col *or: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex"> > <br>If you post those messages you get on the serial port and if > I<br>recognize them, *I will tell you what they are.<br><br>- om_p<br><br>><br>> Hello, Omprakash, tha *nk you for your answer!<br>><br>> I have commented everything related to collect *ion debug and debug overall > <br>> code, but something might have slipped, it's possible.<br>> > Even if th *ey are debug messages, why do you think it takes that amount of<br>> messages to st *art receiving actual correct frames? Can it be by any chance a > <br>> way to measure the time taken to establish a tree? If they're > debug, and *if<br>> the tree forms instantly (or close), why the wait?<br>><br>> Thank yo *u!<br>><br>> Pedro<br>><br>> On 7/14/07, Omprakash Gnawali < > <a href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</a>> wrote:<br>> > ><br>> & *gt;<br>> > ><br>> > > So let me redo the questions:<br>> > > *;<br>> > > How does the P bit enabling works? Who/what causes it and why? > <br>> ><br>> > To add to what Phil said, the current > implementation sets P *ULL bit<br>> > like this:<br>> ><br>> > ...<br>> > * else if (routeInfo.parent == INVALID_ADDR) {<br>& *gt; > beaco *nMsg->etx = > routeInfo.etx;<br>> > >   *; beaconMsg->options |= CTP_OPT_PULL;<br>> > &nb *sp; } else {<br>> > ...<br>> ><br>> > (When *a node does not have a parent, for example, when a node boots<br> > > > up.)<br>> ><br>> ><br>> ><br>> > > The > question a *bout the 14 data messages remain.<br>> > ><br>> ><br>> > Did you *disable the debug messages? Those messages on the serial > <br>> > interface are probably debug messages. CTP should not send > bogus<br>> * > messages on the serial port - if the tree is built, it will send data<br>> &g *t; messages, otherwise there will be no data messages to forward. Debug > <br>> > messages are independent of the data messages and if they are > enabled,<b *r>> > not only the base station, but all the motes should send some debug<br>> *; > messages on the serial port.<br>> ><br> > > > - om_p<br>> ><br>><br></blockquote></div><br> > > --Boundary_(ID_fV07YJXUQXrxAiWVf3N4vw)-- _______________________________________________ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help