All,
Ok, I'm intrigued again... (why does this keep happening??)
Accordint to TEP 111, the message_t is defined by:
typedef nx_struct message_t {
nx_uint8_t header[sizeof(message_header_t)];
nx_uint8_t data[TOSH_DATA_LENGTH];
nx_uint8_t footer[sizeof(message_footer_t)];
nx_uint8_t metadata[sizeof(message_metadata_t)];
} message_t;
Given my platform is a MicaZ, I'd have (from platform_message.h):
typedef union message_header {
cc2420_header_t cc2420;
serial_header_t serial;
} message_header_t;
typedef union message_footer {
cc2420_footer_t cc2420;
} message_footer_t;
typedef union message_metadata {
cc2420_metadata_t cc2420;
} message_metadata_t;
the contents of which we already know from CC2420.h:
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;
nxle_uint8_t type;
} cc2420_header_t;
typedef nx_struct cc2420_footer_t {
} cc2420_footer_t;
/**
* CC2420 Packet metadata. Contains extra information about the message
* that will not be transmitted
*/
typedef nx_struct cc2420_metadata_t {
nx_uint8_t tx_power;
nx_uint8_t rssi;
nx_uint8_t lqi;
nx_bool crc;
nx_bool ack;
nx_uint16_t time;
nx_uint16_t rxInterval;
/** Packet Link Metadata */
#ifdef PACKET_LINK
nx_uint16_t maxRetries;
nx_uint16_t retryDelay;
#endif
} cc2420_metadata_t;
From the same TEP, "The metadata field of message_t stores data that a
single-hop stack uses or collects does not transmit. This mechanism allows
packet layers to store per-packet information such as RSSI or timestamps."
Furthermore, it is stated that the metadata is a 7 byte struct (at least 2
bytes less than the one in the header file above: "nx_uint16_t rxInterval"
removed):
typedef nx_struct cc2420_metadata_t {
nx_uint8_t tx_power;
nx_uint8_t rssi;
nx_uint8_t lqi;
nx_bool crc;
nx_bool ack;
nx_uint16_t time;
} cc2420_metadata_t;
So some questions rise:
1 - Is the metadata actually carried out in the message being sent over the
radio and actually included in the message_t (cause it says something about
not being transmitted, but it still show up in the message structure in the
TEP)?
2 - If it is, does the actual size of the 802.15.4 message payload
(Data field) extends by its size (after sizeof(struct) as we've seen
before)? How many bytes then? 7 or more?
3 - If it's not.. what use does it have?
Thank you and continuous apologies on my behalf,
Pedro
On 7/2/07, Steve McKown <[EMAIL PROTECTED]> wrote:
On Saturday 30 June 2007 06:35:32 pm Pedro Almeida wrote:
> Hello, Steve!
>
> Wow, that was a very thorough and explicit explanation, i'm all cleared
> now! Only in
>
> Radio Frame = SHR(5) + PHR/len(1) + MHR/addr(8) + AMtype(1) +
> AMdata(TOSH_DATA_LENGTH) +
> CRC(2)
>
> you mean 9 in the MHR, right?
Dang. Yeah. Thanks for catching that!
>
> MHR = FCF(2B) + DSN(1B) + PANID(2B) + DST(2B) + SRC(2B) = 9
> (note that PANID is populated by TOS_AM_GROUP)
>
> So it's TOSH_DATA_LENGTH + 18 instead of 17. Making the size = 46 bytes.
>
> Just as a final clearance: the length supplied to AMSend.Send() is
directly
> related to TOSH_DATA_LENGTH, so regardless the size of the struct being
> sent is 1 or 20 bytes, the payload length is that of defined by
> TOSH_DATA_LENGTH, correct? I cant have a payload smaller than
> TOSH_DATA_LENGTH?
>
> Thank you so much, I believe your reply might come in handy for more
> people! Once again many thanks,
>
> Sincerely,
>
> Pedro
>
> On 6/30/07, Steve McKown <[EMAIL PROTECTED]> wrote:
> > On Saturday 30 June 2007 09:34:39 am Pedro Almeida wrote:
> > > Hi, Erwing;
> > >
> > > I've taken a good look at the data sheet. I've looked at it before
but
> > > I totally forgot the details from seeing just the TEP and the header
> >
> > files.
> >
> > > according to the sheet, total PPDU frame is:
> > >
> > > PPDU = SHR (5 bytes) + PHR (length: 1 byte) + MPDU
> > >
> > > now the MPDU starts with the rest of the struct (apart from the
> > > length):
> > >
> > > 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;
> > > nxle_uint8_t type;
> > > } cc2420_header_t;
> > >
> > > MPDU = FCF + DSN + DestPAN + DestAdd + SRC + FCS = 11 bytes
> > >
> > > Total so far : 11 + 6 = 17
> > >
> > > The "type" I don't know where it belongs, maybe the start of the
data
> > > payload? It does say in here:
> > >
> > > The TinyOS 802.15.4 T-frame format is as follows:
> >
> >
+-------------------+---------+------------------------------+-----------
> >--
> >
> > >-+
> > >
> > > | 802.15.4 Header | AM type | data | 802.15.4 CRC |
> >
> >
+-------------------+---------+------------------------------+-----------
> >--
> >
> > >-+
> > >
> > > so should be "somewhere" between the Header and the data.
> > >
> > > Anyway, the "data" field i still dont know if its size is the exact
> > > size
> >
> > of
> >
> > > the struct i'm using, if there's some more bytes added or if it is
> >
> > always
> >
> > > defined by the MAX setting, regardless of being filled or not.
> > >
> > > Finally, the CRC in the scheme above, i dont know if its the same as
> > > the FCS (as the FCS is only from the MPDU) or if after the FCS, 2
CRC
> > > bytes actually are inserted (extending actual size to another 2
bytes).
> >
> > You're close. It's a bit confusing because the 802.15.4 spec breaks
up
> > the
> > radio frame into 3 layers, and in t2 the length field in
cc2420_header_t
> > is
> > not part of the MPDU but is in fact the PHR. Here's how I understand
t2
> > active messages on 802.15.4:
> >
> > The physical protocol data unit (PPDU), or the actual bytes that make
up
> > the
> > full radio frame are:
> >
> > PPDU = SHR(4B preamble + 1B SFD) + PHR (1B len) + PSDU
> >
> >
> > The phy service data unit (PSDU) contains the mac protocol data unit
> > (MPDU),
> > so they are synonmous:
> >
> > PSDU = MPDU = MHR + MSDU + FCS(2B)
> >
> >
> > The mac header (MHR) is variable based upon bits set in the FCF. For
the
> > t2
> > stack it is 8 bytes long:
> >
> > MHR = FCF(2B) + DSN(1B) + PANID(2B) + DST(2B) + SRC(2B)
> > (note that PANID is populated by TOS_AM_GROUP)
> >
> > The frame check sequence (FCS) contains the CRC and is 2 bytes long.
> >
> > The mac service data unit (MSDU) contains the data payload. For
active
> > messages, this is the AMtype field and a variably sized AMdata field.
> > The AMdata field contains the payload of the message_t sent to
> > AMSend.send(), whose length is another argument to the same
AMSend.send()
> > invocation. The
> > maximum size of the data field is defined by TOSH_DATA_LENGTH:
> >
> > MSDU = AMType(1B) + Data(<= TOSH_DATA_LENGTH bytes)
> >
> >
> > So putting it all together, for t2 active messages on the cc2420
radio,
> > the
> > radio frame looks like this:
> >
> > SHR(5) + PHR/len(1) + MHR/addr(8) + AMtype(1) +
AMdata(TOSH_DATA_LENGTH)
> > + CRC(2)
> >
> > If I haven't fouled up somewhere, the maximum size of the radio frame
is
> > TOSH_DATA_LENGTH +17 bytes, or 45 bytes using the standard definition
for
> > TOSH_DATA_LENGTH. The actual size of a particular radio frame is len
+
> > 17 bytes, where len is the length parameter supplied to AMSend.send().
> >
> > All the best,
> > Steve
> >
> > > Thanks for the help!
> > >
> > > Pedro
> > >
> > > On 6/30/07, Erwing Sánchez <[EMAIL PROTECTED]> wrote:
> > > > Hi Pedro,
> > > > you may want to take look to the cc2420 datasheet. I found a lot
of
> > > > useful information regarding IEEE 802.15.4 there!
> > > > www.chipcon.com/files/CC2420_Data_Sheet_1_3.pdf
> > > > Or you may want to try the IEEE 802.15.4 standard, where you can
> > > > certainly find all this information.
> > > > Take into consideration that, for instance, the length of the
frame
> > > > Header varies according to the value of the fcf field (I think
most
> > > > of the time it is not changed in TinyOS applications). Besides,
the
> > > > frame length changes in accordance to the application because the
> > > > payload changes.
> > > > However, If you're looking for maximum values, the maximum frame
> > > > length is 128 bytes in 802.15.4.
> > > > Regards,
> > > > Erwing
> > > >
> > > > On 6/30/07, Pedro Almeida <[EMAIL PROTECTED]> wrote:
> > > > > Hello all;
> > > > >
> > > > > I would like to know the exact length of the 802.15.4 frame. The
> >
> > reason
> >
> > > > that
> > > >
> > > > > i'd like to know the exact length is because i need to do some
duty
> > > >
> > > > cycles
> > > >
> > > > > numbers and one of the inputs is the frame length. It would seem
to
> > > >
> > > > equal
> > > >
> > > > > the payload, but given it makes no sense to me the payload on
the
> > > > > serial frame, i might as well doubt i can figure the length on
the
> > > > > 802.15.4's.
> > > > >
> > > > > So according to TEP 125:
> > > > >
> > > > > The TinyOS 802.15.4 T-frame format is as follows:
> >
> >
+-------------------+---------+------------------------------+-----------
> >
> > > >---+
> > > >
> > > > > | 802.15.4 Header | AM type | data | 802.15.4 CRC |
> >
> >
+-------------------+---------+------------------------------+-----------
> >
> > > >---+
> > > >
> > > > > I presume the 802.15.4 Header, as according to CC2420.h, to be
10
> > > > > bytes:
> > > > >
> > > > > 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;
> > > > >
> > > > > AM Type, according to previous struct, another byte before
"data".
> > > >
> > > > Total:
> > > > > 11.
> > > > >
> > > > > I suppose CRC to be 2 extra bytes added in the end. Total: 13
> > > > >
> > > > > The "data" field intrigues me.
> > > > >
> > > > > I see this being defined in CC2420.h
> > > > >
> > > > > #ifndef TOSH_DATA_LENGTH
> > > > > #define TOSH_DATA_LENGTH 28
> > > > > #endif
> > > > >
> > > > > Does this mean it's a fixed length that gets 'populated'
according
> >
> > to
> >
> > > > each
> > > >
> > > > > different situation (making a fixed total of 42 bytes), or is 28
a
> >
> > max,
> >
> > > > or
> > > >
> > > > > am i understanding this all wrong?
> > > > > The struct in TestNetwork is 15 bytes. Would that means the
total
> >
> > frame
> >
> > > > size
> > > >
> > > > > is 13+15=28 bytes? Or is there anything extra added?
> > > > >
> > > > > Any help greatly appreciated!
> > > > > Thanks,
> > > > >
> > > > > Pedro
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Tinyos-help mailing list
> > > > > [email protected]
> >
> >
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
> !DSPAM:468761d4237032051017194!
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
