On Tuesday 03 July 2007 11:47:35 am Pedro Almeida wrote: > Thank you once again, Steve, you're a tireless help! =) > I guess I found strange the concept of something being included in a > message structure that never gets to be sent...
Yeah, you have to think of message_t as a subset of the actual message sent. Cheers! > > On 7/3/07, Steve McKown <[EMAIL PROTECTED]> wrote: > > On Tuesday 03 July 2007 11:01:48 am Pedro Almeida wrote: > > > All, > > > > > > Ok, I'm intrigued again... (why does this keep happening??) > > > > > > [snip] > > > > > > 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." > > > > > [snip] > > > > > > 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)? > > > > You just quoted from the TEP that answers your question. ;^) message_t > > stores metadata that the stack uses or collects but does not transmit. > > > > > 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? > > > > The metadata is useful for writing network functionality. It's used in > > CTP > > for example, to manage neighbors and routing. I don't think you'd want > > an application to use metadata directly, since you're then tying that > > application to a specific bit of radio hardware. > > > > > 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 > > > > > > > > > Tinyos-help@Millennium.Berkeley.EDU > > > > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > !DSPAM:468a8cc3261818873072749! _______________________________________________ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help