[Tinyos-help] Documentation regarding exact contents of the
MACProtocol Data Unit frame
Pedro Almeida
pedralm at gmail.com
Thu Jun 14 07:48:07 PDT 2007
Hello, Steve;
I am using an application that came with the MicaZ CD, called "Terminal
v1.9b by Bray++". I can use it to read/write to the serial port.
If I indeed read it with the java Listen, I dont get those encapsulation
bytes. But the purpose of this app is to be read in a Windows environment,
where the USB ports are converted into virtual serial ports, and in my app I
do get the encapsulation bytes when reading from the "serial" port.
Thanks,
Pedro
On 6/14/07, R. Steve McKown <rsmckown at yahoo.com> wrote:
>
> HI Pedro,
>
> How did you generate your original hex string? TestNetwork appears to be
> set
> up to use the C serial forwarder sf, so if I program some motes, start sf
> on
> the serial port and tn-listener on the port opened by sf, I get active
> message frames output without the serial frame encapsulation. Are you
> connecting to the serial port directly?
>
> On Wednesday 13 June 2007 19:39:21 Pedro Almeida wrote:
> > 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 <dmm at rincon.com> 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:* tinyos-help-bounces at Millennium.Berkeley.EDU [mailto:
> > > tinyos-help-bounces at Millennium.Berkeley.EDU] *On Behalf Of *Pedro
> Almeida
> > > *Sent:* Wednesday, June 13, 2007 2:50 PM
> > > *To:* R. Steve McKown
> > > *Cc:* tinyos-help at 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* <rsmckown at yahoo.com > 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/d
> > > >ataf
> > > >
> > > >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 ),
> > > >
> > > > 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
> > >
> > > ),
> > >
> > > > 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 <rsmckown at yahoo.com > 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:46709f20185931044457613!
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20070614/47fc8191/attachment.html
More information about the Tinyos-help
mailing list