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: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] Documentation regarding exact contents of the MACProtocol Data Unit frame 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] <mailto:[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] <mailto:[EMAIL PROTECTED]> ] On Behalf Of Pedro Almeida Sent: Wednesday, June 13, 2007 2:50 PM To: R. Steve McKown Cc: tinyos-help@Millennium.Berkeley.EDU 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 On 6/13/07, R. Steve McKown <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote: On Tuesday 12 June 2007 18:22:41 Pedro Almeida wrote: > Thank you, Steve McKown and Alexander Becher for your replies. > > Thanks to your help I more or less figured out how many bytes there were > from the Address Information to be included in the MAC Header. > > According to: > > typedef nx_struct cc2420_header_t { > nxle_uint8_t length; > nxle_uint16_t fcf; > nxle_uint8_t dsn; > nxle_uint16_t destpan; > nxle_uint16_t dest; > nxle_uint16_t src; > /** I-Frame 6LowPAN interoperability byte */ > #ifdef CC2420_IFRAME_TYPE > nxle_uint8_t network; > #endif > nxle_uint8_t type; > } cc2420_header_t; > > I then have 9 bytes from the MHR, adding to 1 from length (PHR) and > the 5 from the Synchronization Header > (SHR), assuming (I don't think I'm mistaken here) the I-frame is not in > use, giving a total of 15 bytes. The type byte is include in the payload > (according to Steve). In terms of the 802.15.4 frame format, section 14.2 of the CC2420 data sheet shows that the data received into software from the radio. The SHR are never received by software, so it can't be part of the data you are trying to decode. The data returned is a length byte, the MPDU bytes, an RSSI byte and an FCScheck/corr byte (note the 2-byte FCS is replaced by RSSI and FCScheck/coor on receive). Also, if you look at CC2420.h and CC2420ActiveMessageP.nc , you'll see that the last 2 bytes (MAC_FOOTER_SIZE) are not calculated as part of the length field returned to the upper layers of software on a receive. Instead, the data in the last two bytes are placed in the metadata structure. So, I don't think SHR and FCS can be part of the packet format you are trying to decode. > > The payload, from the TestNetwork application, is > > 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; > > since nx_am_addr_t is 2 bytes, this struct is 15 bytes. Adding the 1 from > the type (as seen above), there's 16 bytes in payload. > Since > > typedef nx_struct cc2420_footer_t { > } cc2420_footer_t; > > and according to Steve, "The current radio stack has the cc2420 generate > the FCS (crc) automatically", so I presume it's not included. > This totals 31 bytes, and I read 32! If FCS was indeed included (2 bytes), > i'd get 33 bytes!! > > Please notice i'm using a representation such as this > http://www.eng.yale.edu/enalab/courses/eeng460a/homeworks/hw1_results/dataf >rame.gifto try and figure it out. > > This application uses CTP. Can it have anything to do with it? According to > TEP-123 ( http://www.tinyos.net/tinyos-2.x/doc/html/tep123.html <http://www.tinyos.net/tinyos-2.x/doc/html/tep123.html> ), > > The CTP data frame format is as follows (check the URL for correct > formatting): > 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |P|C| reserved | THL | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ETX | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | origin | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | seqno | collect_id | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | data ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > But I don't know how to understand that, so it doesnt help me much. > Also, I don't understand why the frame starts and ends with 0x7E. Is 7E > both preamble and last byte in payload? > > Here's one example sequence 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 This is output from tn-listener, right? 0x7E is the serial sync byte. I'm not sure about the next 2 bytes, but the serial header starts at the fourth byte. Look at $TOSDIR/lib/serial/Serial.h and they'll match up: 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; dest: FFFF - the dest addr as set by UARTSend.send(), as you note below. src: 0000 - the src addr of the sending mote. May be the PC connected mote itself. length: 13 (decimal 19) The next 19 bytes are CTP data, and I don't know the format so well. It looks like there's an initial byte, 2 8-byte entries, and a 2-byte footer, but I'm guessing. Note that tn-listener.c seems to have some problems. For example, it accesses packet after it has been freed. The data you are seeing could be corrupt, since there's a malloc() after packet is freed and the space could have been reused. The safe thing to do would be to move the free(packet) to just under the free(myPacket). I'm thinking there may be corruption because the second CTP unit is supposed to have a 16-bit constant value that should read "ca fe" in the raw data stream (see TestNetworkC.nc). Because the link to the PC is a serial link, the mote is sending a serial active message to the PC, which is the payload wrapped in the serial frame. This is why you don't see any of the CC2420/802.15.4 frame formatting in the data you are trying to match. Cheers, Steve > > I believe the EE is the Collection ID, as seen from TestNetworkC.h, > which might relate to the CTP frame > ( http://www.tinyos.net/tinyos-2.x/apps/tests/TestNetwork/TestNetworkC.h <http://www.tinyos.net/tinyos-2.x/apps/tests/TestNetwork/TestNetworkC.h> ), > but I'm not sure that helps. The FF FF could also be from, but I can't be > sure: > > call UARTSend.send(0xFFFF, recvPtr, call Receive.payloadLength(msg) + 4) == > SUCCESS) > > Many thanks and sorry for the confusing posts! > Hope you help me figure this out byte by byte and make sense out of it. > > Very best regards, > > Pedro > > > > /** > * CC2420 Packet Footer > */ > typedef nx_struct cc2420_footer_t { > } cc2420_footer_t; > > On 6/11/07, Steve McKown < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote: > > On Friday 08 June 2007 13:21, Pedro Almeida wrote: > > > Hello; > > > > > > I'm trying to look for documentation where I can understand the exact > > > contents, byte by byte, of the MPDU. I've looked into the TEPs and the > > > source files themselves, butI wasn't completely clear. > > > > > > I'm using now the TestNetwork demo, where I receive 32 bytes per > > > > message, > > > > > of which I know little about, except for the contents of the message_t > > > itself: > > > > > > 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; > > > > > > That are not, by far, 32 bytes. > > > So far I understood the MPDU is made of > > > > > > 2 bytes - Frame Control > > > 1 byte - Data Sequence Number > > > 4 to 20 bytes - Address Information > > > n bytes - Data Payload > > > 2 bytes - Frame Check Sequence > > > > > > which adds 5 bytes of the SHR and 1 byte of the PHR. So what exactly > > > are those 32 bytes??? Which ones are the payload (MSDU) and which ones > > > are > > > > not > > > > > (and what are they?)? > > > > > > An example of the 32 bytes is as follows: > > > > > > 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 > > > > The data above looks like an active message (AM) delivered via a serial > > physical layer. The hint are the 0x7E bytes, which are sync bytes. If > > this > > output came from the PC, then you should be able to map it to the > > serial_packet_t in $TOSDIR/lib/serial/Serial.h. The payload are > > delivered within the frame appropriate for the link on which the data is > > sent. Hence, > > one sees the serial headers and not the radio headers. > > > > I haven't played with Collection or the TestNetwork app, so I can't help > > out > > there. But I can provide some info on how the CC2420 component populates > > the > > 802.15.4 compatible frame. You can see the mapping in the > > cc2420_header_t structure in $TOSDIR/chips/cc2420/CC2420.h. The physical > > radio frame looks > > like this: > > > > preamble + sfd + cc2420_header_t + app_data + FCS (crc) > > > > In terms of 802.15.4, the second field of cc2420_header_t, fcf, is the > > first > > field of the MAC header. The last field of cc2420_header_t, type, is > > actually part of the MAC payload. The current radio stack has the cc2420 > > generate the FCS (crc) automatically. > > > > In terms of addressing, short addresses with the 802.15.4 PAN ID > > Compression > > is set, so the address info consists of pan_id + dest_addr + source_addr. > > You can see these fields in the cc2420_header_t structure. The fcf is > > set in > > CC2420CsmaP.nc's Send.send() implementation, where length, dsn and source > > are > > also set (destination has already been set in the header by this time). > > > > All the best, > > Steve > > > > > Help! > > > > > > Thank you!!! > > > > > > Pedro > > !DSPAM:466f3c33326061804284693!
_______________________________________________ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
