Hi, Roberto!
FCF stands for Frame Control Field. I'll copy the explanation from the
CC2420 spec.
7.2.1.1 Frame control field
The frame control field is 16 bits in length and contains information
defining the frame type, addressing
fields, and other control flags. The frame control field shall be formatted
as illustrated in Figure 35.
2 first bits say if the frame is a Beacon, Data, Ack, etc. frame, for
instance.
If you want to see it bit per bit, check chapter 7.2.1.1 in the following
document: www.chipcon.com/files/CC2420_Data_Sheet_1_3.pdf
Cheers.
On 7/3/07, roberto pagliari <[EMAIL PROTECTED]> wrote:
what is the field uint16_t fcf; ?
On 7/1/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
> > > > > > Tinyos-help@Millennium.Berkeley.EDU
> > >
> > >
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
> >
> > !DSPAM:468761d4237032051017194!
>
>
>
> _______________________________________________
> Tinyos-help mailing list
> Tinyos-help@Millennium.Berkeley.EDU
>
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
