[Tinyos-help] Decoding the contents of a Serial frame returned by TestNetwork App (reprise : please help)

[Pedro Almeida]

Phil!

Can't
thank you enough for your reply! It was helpful beyond words. Now TEP 123 (and
other things) make a lot more sense!

Some questions rise now, though:
- Why is ETX always 0 in all frames from all sources? Because the root
node is considered the "single-hop sender" (@TEP123)
and therefore its ETX (0) inserted in the frame?
- Why is the seqNo in TestNetwork's struct a 2 byte field and originSeqNo in
the CTP data header only 1 byte long? Won't there be any problem after the
counter reaches the end of 1 the byte field?
- Why is a hopCount included in the TestNetwork struct if the payload cannot
be modified by a forwarding node? It ends up always being 0.
- Why arent the sendCount and sendSuccessCount fields visible in the serial
frame? Last read byte (before the CRC) is the hopCount. Does it have
anything to do with the +4 included in the UARTSend.send
? If i wanted to see those 4 missing bytes, should I include +8?

Huge thanks once again for your answer!

Very best regards,

Pedro

On 7/9/07, Philip Levis <pal at cs.stanford.edu> wrote:
>
> On Jul 8, 2007, at 11:32 AM, Pedro Almeida wrote:
>
> > Hello all;
> >
> > Some weeks ago I asked about the exact contents of a frame I was
> > receiving through the serial port, of which I couldn't decode
> > whatsoever (first mail here: http://mail.millennium.berkeley.edu/
> > pipermail/tinyos-help/2007-June/025739.html).
> > With the help of some people (Alexander Becher, Steve McKown, David
> > Moss and Benjamin Madore), we managed to make some sense out of it.
> > However, I am reaching that time period where it would be really
> > handy to have the rest cleared.
> >
> > So summing it all up, I receive this in the serial port (example
> > frame):
> >
> > 7E 45 00 FF FF 00 00 13 00 EE 00 01 00 00 00 07 80 EE 00 07 00 80
> > 00 00 00 00 20 00 00 53 63 7E
> >
> > and the sent structure is like this:
> >
> > typedef nx_struct TestNetworkMsg {
> > nx_am_addr_t source;
> > nx_uint16_t seqno;
> > nx_am_addr_t parent;
> > nx_uint16_t metric;
> > nx_uint8_t datah;
> > nx_uint8_t datal;
> > nx_uint8_t hopcount;
> > nx_uint16_t sendCount;
> > nx_uint16_t sendSuccessCount;
> > } TestNetworkMsg;
> >
> > the platform is the MicaZ and the app is the TestNetwork.
> >
> > we've went this far on the decoding process (* marks confirmed field):
> >
> > *7E : Framing byte, denoting start of packet
> > *45 : Protocol Byte (NO_ACK)
> > *00 : Packet Format Dispatch Byte
> > *FF FF : destination address (from UART)
> > *00 00 : source address (root node)
> > 13 : length
> > 00 EE : Collection ID (from CTP) ?? / Type ?? / Destination PAN
> > Identifier (from MAC Header)
> > 00 : ????
> > 01 : hopcount (seems out of place, but sure looks like it!!!) ????
> > 00 00 : Destination Address (root ID=0) (from MAC Header) ???
> > 00 07 : Source Address (from the MAC Header) ????
> > 80 : sendCount ??? (this field increments like the seqno below)
> > EE : Collection ID (from CTP) ?? / Type ??
> > *00 07 : source
> > *00 80 : seqno
> > *00 00 : parent
> > *00 00 : metric
> > *20 00 : data
> > 00 : ???
> > *53 63:two byte CRC
> > *7E : Framing byte, denoting end of packet
> >
> > Can you help me?
> > Thank you for the (once again) inconvenience;
> >
>
> The three structures you care about are, in this order:
>
> The serial header (tos/lib/Serial.h)
> The CTP data header (tos/lib/net/ctp/Ctp.h)
> The TestNetwork packet (apps/tests/TestNetwork/TestNetwork.h)
>
> If you put them in order, this is what you get:
>
> typedef nx_struct serial_header {
>    nx_am_addr_t dest;
>    nx_am_addr_t src;
>    nx_uint8_t length;
>    nx_am_group_t group;
>    nx_am_id_t type;
> } serial_header_t;
>
> typedef nx_struct {
>    nx_ctp_options_t    options;
>    nx_uint8_t          thl;
>    nx_uint16_t         etx;
>    nx_am_addr_t        origin;
>    nx_uint8_t          originSeqNo;
>    nx_collection_id_t  type;
>    nx_uint8_t          data[0];
> } ctp_data_header_t;
>
> typedef nx_struct TestNetworkMsg {
>    nx_am_addr_t source;
>    nx_uint16_t seqno;
>    nx_am_addr_t parent;
>    nx_uint16_t metric;
>    nx_uint16_t data;
>    nx_uint8_t hopcount;
>    nx_uint16_t sendCount;
>    nx_uint16_t sendSuccessCount;
> } TestNetworkMsg;
>
> So if you laid this out as one big packet, you'd see:
>
> typedef nx_struct {
>    nx_am_addr_t dest;
>    nx_am_addr_t src;
>    nx_uint8_t length;
>    nx_am_group_t group;
>    nx_am_id_t type;
>
>    nx_ctp_options_t    options;
>    nx_uint8_t          thl;
>    nx_uint16_t         etx;
>    nx_am_addr_t        origin;
>    nx_uint8_t          originSeqNo;
>    nx_collection_id_t  type;
>
>    nx_am_addr_t source;
>    nx_uint16_t seqno;
>    nx_am_addr_t parent;
>    nx_uint16_t metric;
>    nx_uint16_t data;
>    nx_uint8_t hopcount;
>    nx_uint16_t sendCount;
>    nx_uint16_t sendSuccessCount;
> } msg_format_t;
>
> Then all you need to do is consider the serial framing, dispatch, and
> CRC bytes (which your breakdown above does):
>
> typedef nx_struct {
>    nx_uint8_t serialDelimiter;
>    nx_uint8_t serialProto;
>    nx_uint8_t serialDispatch;
>
>    nx_am_addr_t dest;
>    nx_am_addr_t src;
>    nx_uint8_t length;
>    nx_am_group_t group;
>    nx_am_id_t type;
>
>    nx_ctp_options_t    options;
>    nx_uint8_t          thl;
>    nx_uint16_t         etx;
>    nx_am_addr_t        origin;
>    nx_uint8_t          originSeqNo;
>    nx_collection_id_t  type;
>
>    nx_am_addr_t source;
>    nx_uint16_t seqno;
>    nx_am_addr_t parent;
>    nx_uint16_t metric;
>    nx_uint16_t data;
>    nx_uint8_t hopcount;
>    nx_uint16_t sendCount;
>    nx_uint16_t sendSuccessCount;
>
>    nx_uint16_t serialCrc;
>    nx_uint8_t serialDelimiter;
> } msg_format_t;
>
> Phil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20070710/216e604c/attachment.htm