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
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
