On Monday 16 July 2007 05:42:54 pm roberto pagliari wrote:
> 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?
If I understand your question, the answer is no. The radio doesn't have to
qualify the address parts of the header on transmit. Unlike receive, were
address decode logic will look at it.
>
> thank you
>
> On 7/16/07, Steve McKown <[EMAIL PROTECTED]> 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 <[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.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
> > > > > > > > > > [email protected]
> >
> > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-he
> >
> > > > >lp
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Tinyos-help mailing list
> > > > > [email protected]
> >
> > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-he
> >
> > > > >lp
>
> !DSPAM:469c049b285701336712104!
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
