David, Thank you for that attention call! So it's not the Packet Format Dispatched Byte that is out, it's the Sequence Number Byte. Makes a lot more sense than my previous "disregard". One more byte we're sure of!
Thanks! Pedro (first posts were deleted because it exceeded max size : 40Kb) On 6/14/07, Pedro Almeida <[EMAIL PROTECTED]> wrote:
David, Thank you for that attention call! So it's not the Packet Format Dispatched Byte that is out, it's the Sequence Number Byte. Makes a lot more sense than my previous "disregard". One more byte we're sure of! Thanks! Pedro On 6/14/07, David Moss <[EMAIL PROTECTED]> wrote: > > The protocol byte denotes "no ack" when communicating from the mote->PC, > as you've pointed out. Without an ack request, there is no need for a > sequence number, so it is removed. The next byte is the packet dispatch > format, which is 0. This corresponds with TOS_SERIAL_MESSAGE_ID as defined > in Serial.h. > > > > -David > > > > > > > ------------------------------ > > *From:* Pedro Almeida [mailto:[EMAIL PROTECTED] > * Sent:* Wednesday, June 13, 2007 6:39 PM > *To:* David Moss > *Cc:* [email protected] > > > *Subject:* Re: [Tinyos-help] Documentation regarding exact contents of > the MACProtocol Data Unit frame > <[email protected]> > > > > Hello all; > > After reading the TEP provided by David, it greatly helped, yet some > things still don't match. It is said that: > > typedef nx_struct SerialAMHeader { > nx_am_addr_t addr; > nx_uint8_t length; > nx_am_group_t group; > nx_am_id_t type; > } SerialAMHeader; > > and the frame like > > ____________________________________________ > | | | | | | | | > | | | | | | | | > |_|_|_|_|_______________________________|__|_| > F P S D Payload CR F > F = Framing byte, denoting start of packet: HdlcTranslateC > P = Protocol byte: SerialP > S = Sequence number byte: SerialP > D = Packet format dispatch byte: SerialDispatcherC > Payload = Data payload (stored in SerialDispatcherC): SerialDispatcherC > CR = Two-byte CRC over S to end of Payload: SerialP > F = Framing byte denoting end of packet: HdlcTranslateC > > would give something like > 7e 40 09 00 be ef 05 7d 5d 06 01 02 03 04 05 7e > (explanation: For example, a platform independent AM packet of type 6, > group 0x7d, and length 5 to destination 0xbeef with a payload of 1 2 3 4 5. > Note that the group 0x7d is escaped to 0x7d 0x5d. The protocol field (P) is > 0x40 (64), corresponding to SERIAL_PROTO_ACK (in Serial.h).) > > yet what i read is (mind only the beggining and end now) > 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 > > so there's some bytes missing, and the start has more similarities with > this struct than the SerialAMHeader: > > 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; > > So if i disregard the > > D = Packet format dispatch byte: SerialDispatcherC > > it actually starts out nicely. Still do decide if the last 2 bytes > before the 0x7E are the 2 byte CRC (which are not even showing up in the > example sequence from the TEP) or the rssi+fcsCheck. > > So, doing it all again and completing with new information: > > 7E : Framing byte, denoting start of packet > 45 : Protocol Byte (0x45 = SERIAL_PROTO_PACKET_NOACK = 69 from Serial.h) > > 00 : Sequence Number Byte (from the #define NO_TX_SEQNO in SerialP.nc) > ?? > 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: rssi+fcsCheck / CRC ?? > 7E : Framing byte, denoting end of packet > > Thanks everyone for helping with this "research"! > > Pedro > > On 6/13/07, * David Moss* < [EMAIL PROTECTED]> wrote: > > I haven't been following this discussion much, but if you haven't done > so already, take a look at TEP 113, second 3.6: > > > > http://www.tinyos.net/tinyos-2.x/doc/html/tep113.html > > > > Some of your unknown bytes are explained there in the serial HDLC > header, which I don't believe is documented explicitly in a struct. > > > > [HDLC header][Serial Header][Payload][HDLC Footer] > > > > The length byte in the serial header is the length of only the message > payload I believe. There should be no radio message_t metadata information > transmitted by default as part of the serial payload. > > > > http://en.wikipedia.org/wiki/High-Level_Data_Link_Control > > > > -David > > > > > > > > > ------------------------------ > > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > ] *On Behalf Of *Pedro Almeida > *Sent:* Wednesday, June 13, 2007 2:50 PM > *To:* R. Steve McKown > *Cc:* [email protected] > *Subject:* Re: [Tinyos-help] Documentation regarding exact contents of > the MACProtocol Data Unit frame > > > > Hello, Steve! > > Things are starting to look less blurry now. Some still sound strange, > though. > If the 13 (19 in decimal) was the length, then the payload would end (unless it doesn't start counting in the byte immediately after the 13) right after the byte with "20", which is a 2 byte field. > > > Here's the line again: > > 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 > > About that 20 and the "0xCAFE", it's because I have changed the struct > for my app, and now the 2 byte field "data" in the struct is now split in 2, > datah and datal, each with 1 byte (datah is the "20", datal is the "00"). So > the 19 count cannot (unless i'm wrong) end in the "20". > > The payload struct looks 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; > > How about the "+4" in > call UARTSend.send(0xFFFF, recvPtr, call Receive.payloadLength(msg) + 4) > == SUCCESS), can it influence anything? It does add more bytes to what I > 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; > > So far, i've ran more tests to try and figure the fields out. Here's how > I understand it so far, with your help and using the structs above: > > 7E : Sync > 45 00 : ???? > FF FF : destination address > 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 : rssi ? > 63 : fcs check ? > 7E : Sync > > Almost there, but still unclear. How does it look? > > Many thanks for all the help so far on this, > > Pedro >
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
