[Tinyos-help] Precise contents and length of the 802.15.4 frames
(and most especially with the TestNetwork App)
roberto pagliari
bobtinyos07 at gmail.com
Mon Jul 16 16:42:54 PDT 2007
does it happen even during the transmission of a packet? I mean, if I write
N bytes into the transmission queue, does the cc2420 check the FCF fram
before transmitting it?
thank you
On 7/16/07, Steve McKown <rsmckown at yahoo.com> wrote:
>
> On Sunday 15 July 2007 06:00:45 pm roberto pagliari wrote:
> > hi All,
> > I'm wondering to know how does the cc2420 knows the length of the
> address
> > field within the mac section of a packet. That field has a size from 0
> up
> > to 20 bytes so, even if the receiver knows the length of the MPDU how
> does
> > the address information is handled? I'm thinking, for instance, to the
> > address recognition that may be done automatically by the cc2420
>
> There are bits within the fcf that control how addresses are represented
> within the packet. TinyOS's stack uses only one mode, where short
> addresses
> (16 bits) and pan id compression (one pan id for both source and dest) are
> used. You can find this info in the 802.15.4 spec that's been recently
> posted a time or two to this list.
>
> Cheers,
> Steve
>
> >
> > On 7/2/07, roberto pagliari <bobtinyos07 at gmail.com> wrote:
> > > what is the field uint16_t fcf; ?
> > >
> > > On 7/1/07, Steve McKown <rsmckown at yahoo.com> 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 < rsmckown at yahoo.com> 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 <erwing.sanchez at gmail.com> 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 <pedralm at gmail.com> wrote:
> > > > > > > > > Hello all;
> > > > > > > > >
> > > > > > > > > I would like to know the exact length of the 802.15.4frame.
> > > >
> > > > 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
> > > > > > > > > Tinyos-help at Millennium.Berkeley.EDU
> > > >
> > > >
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-he
> > > >lp
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Tinyos-help mailing list
> > > > Tinyos-help at Millennium.Berkeley.EDU
> > > >
> > > >
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-he
> > > >lp
> >
> > !DSPAM:469b6f6194282362839998!
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20070716/971520fd/attachment.html
More information about the Tinyos-help
mailing list