[Tinyos-help] Documentation regarding exact contents of the MAC Protocol Data Unit frame

[Pedro Almeida]

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).

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/dataframe.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

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:4669af84166828120612385!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20070613/b9ee1e64/attachment.htm