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