[Tinyos-help] Documentation regarding exact contents of the
MACProtocol Data Unit frame
Pedro Almeida
pedralm at gmail.com
Thu Jun 14 12:01:18 PDT 2007
Hi, Steve!
Thanks for helping me in this neverending subject.
That C SDK you mentioned is for the PC side, right? The app i'm developing
is done in C#, and i've got the parser all set for the 32 bytes, everything
is working fine, it's not really a problem about how to read.
What I solely wish to know is what are those 32 bytes, byte by byte. The
framing and encapsulation is more or less decoded, it's the "inside" part
that I am yet to figure out, as it's not making complete sense, at least to
me...
Thanks once more,
Pedro
On 6/14/07, R. Steve McKown <rsmckown at yahoo.com> wrote:
>
> On Thursday 14 June 2007 08:48:07 Pedro Almeida wrote:
> > Hello, Steve;
> >
> > I am using an application that came with the MicaZ CD, called "Terminal
> > v1.9b by Bray++". I can use it to read/write to the serial port.
> > If I indeed read it with the java Listen, I dont get those encapsulation
> > bytes. But the purpose of this app is to be read in a Windows
> environment,
> > where the USB ports are converted into virtual serial ports, and in my
> app
> > I do get the encapsulation bytes when reading from the "serial" port.
>
> Ah. Then you should look at the C SDK @ $TOSROOT/support/sdk/c. It can
> handle the the serial protocol for you; you get to read and write serial
> active messages and dispense with the framing/ack/crc stuff. Highly
> recommended; I use it in a couple of systems. The sdk also provides tools
> to
> get/set header fields and arbitrary payload fields that are defined by
> your
> application. There's been a couple of discussions about the C SDK on this
> list in the last few months.
>
> You might also want to look at the MultiHopOscilloscope app, included in
> TinyOS-2.0.1, which uses the Collection interface. The PC side code uses
> the
> Java SDK, but I'd imagine it's a good source of information.
>
> All the best,
> Steve
>
> >
> > Thanks,
> >
> > Pedro
> >
> > On 6/14/07, R. Steve McKown <rsmckown at yahoo.com> wrote:
> > > HI Pedro,
> > >
> > > How did you generate your original hex string? TestNetwork appears to
> be
> > > set
> > > up to use the C serial forwarder sf, so if I program some motes, start
> sf
> > > on
> > > the serial port and tn-listener on the port opened by sf, I get active
> > > message frames output without the serial frame encapsulation. Are you
> > > connecting to the serial port directly?
> > >
> > > On Wednesday 13 June 2007 19:39:21 Pedro Almeida wrote:
> > > > Hello all;
> > > >
> > > > After reading the TEP provided by David, it greatly helped, yet some
> > >
> > > things
> > >
> > > > still don't match. It is said that:
> > > >
> > > > typedef nx_struct SerialAMHeader {
> > > > nx_am_addr_t addr;
> > > > nx_uint8_t length;
> > > > nx_am_group_t group;
> > > > nx_am_id_t type;
> > > > } SerialAMHeader;
> > > >
> > > > and the frame like
> > > >
> > > > ____________________________________________
> > > >
> > > > |_|_|_|_|_______________________________|__|_|
> > > >
> > > > F P S D Payload CR F
> > > > F = Framing byte, denoting start of packet: HdlcTranslateC
> > > > P = Protocol byte: SerialP
> > > > S = Sequence number byte: SerialP
> > > > D = Packet format dispatch byte: SerialDispatcherC
> > > > Payload = Data payload (stored in SerialDispatcherC):
> SerialDispatcherC
> > > > CR = Two-byte CRC over S to end of Payload: SerialP
> > > > F = Framing byte denoting end of packet: HdlcTranslateC
> > > >
> > > > would give something like
> > > > 7e 40 09 00 be ef 05 7d 5d 06 01 02 03 04 05 7e
> > > > (explanation: For example, a platform independent AM packet of type
> 6,
> > > > group 0x7d, and length 5 to destination 0xbeef with a payload of 1 2
> 3
> > > > 4
> > >
> > > 5.
> > >
> > > > Note that the group 0x7d is escaped to 0x7d 0x5d. The protocol field
> > > > (P)
> > >
> > > is
> > >
> > > > 0x40 (64), corresponding to SERIAL_PROTO_ACK (in Serial.h).)
> > > >
> > > > yet what i read is (mind only the beggining and end now)
> > > > 7E 45 00 FF FF 00 00 13 00 EE 00 01 00 00 00 07 80 EE 00 07 00 80 00
> 00
> > >
> > > 00
> > >
> > > > 00 20 00 00 53 63 7E
> > > >
> > > > so there's some bytes missing, and the start has more similarities
> with
> > > > this struct than the SerialAMHeader:
> > > >
> > > > typedef nx_struct serial_header {
> > > > nx_am_addr_t dest;
> > > > nx_am_addr_t src;
> > > > nx_uint8_t length;
> > > > nx_am_group_t group;
> > > > nx_am_id_t type;
> > > > } serial_header_t;
> > > >
> > > > So if i disregard the
> > > >
> > > > D = Packet format dispatch byte: SerialDispatcherC
> > > >
> > > > it actually starts out nicely. Still do decide if the last 2 bytes
> > >
> > > before
> > >
> > > > the 0x7E are the 2 byte CRC (which are not even showing up in the
> > >
> > > example
> > >
> > > > sequence from the TEP) or the rssi+fcsCheck.
> > > >
> > > > So, doing it all again and completing with new information:
> > > >
> > > > 7E : Framing byte, denoting start of packet
> > > > 45 : Protocol Byte (0x45 = SERIAL_PROTO_PACKET_NOACK = 69 from
> > > > Serial.h) 00 : Sequence Number Byte (from the #define NO_TX_SEQNO in
> > > > SerialP.nc)
> > >
> > > ??
> > >
> > > > FF FF : destination address (from UART)
> > > > 00 00 : source address (root node)
> > > > 13 : length ?
> > > > 00 EE : Collection ID (from CTP) ?? / Type ?? / Destination PAN
> > >
> > > Identifier
> > >
> > > > (from MAC Header) ??
> > > > 00 : ????
> > > > 01 : hopcount (seems out of place, but sure looks like it) ????
> > > > 00 00 : Destination Address (root ID=0) (from MAC Header) ???
> > > > 00 07 : Source Address (from the MAC Header) ????
> > > > 80 : sendCount ??? (this field increments like the seqno below)
> > > > EE : Collection ID (from CTP) ?? / Type ??
> > > > 00 07 : source
> > > > 00 80 : seqno
> > > > 00 00 : parent
> > > > 00 00 : metric
> > > > 20 00 : data
> > > > 00 : ???
> > > > 53 63: rssi+fcsCheck / CRC ??
> > > > 7E : Framing byte, denoting end of packet
> > > >
> > > > Thanks everyone for helping with this "research"!
> > > >
> > > > Pedro
> > > >
> > > > On 6/13/07, David Moss <dmm at rincon.com> wrote:
> > > > > I haven't been following this discussion much, but if you haven't
> > > > > done
> > >
> > > so
> > >
> > > > > already, take a look at TEP 113, second 3.6:
> > > > >
> > > > >
> > > > >
> > > > > http://www.tinyos.net/tinyos-2.x/doc/html/tep113.html
> > > > >
> > > > >
> > > > >
> > > > > Some of your unknown bytes are explained there in the serial HDLC
> > >
> > > header,
> > >
> > > > > which I don't believe is documented explicitly in a struct.
> > > > >
> > > > >
> > > > >
> > > > > [HDLC header][Serial Header][Payload][HDLC Footer]
> > > > >
> > > > >
> > > > >
> > > > > The length byte in the serial header is the length of only the
> > > > > message payload I believe. There should be no radio message_t
> > > > > metadata information transmitted by default as part of the serial
> > > > > payload.
> > > > >
> > > > >
> > > > >
> > > > > http://en.wikipedia.org/wiki/High-Level_Data_Link_Control
> > > > >
> > > > >
> > > > >
> > > > > -David
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ------------------------------
> > > > >
> > > > > *From:* tinyos-help-bounces at Millennium.Berkeley.EDU [mailto:
> > > > > tinyos-help-bounces at Millennium.Berkeley.EDU] *On Behalf Of *Pedro
> > >
> > > Almeida
> > >
> > > > > *Sent:* Wednesday, June 13, 2007 2:50 PM
> > > > > *To:* R. Steve McKown
> > > > > *Cc:* tinyos-help at Millennium.Berkeley.EDU
> > > > > *Subject:* Re: [Tinyos-help] Documentation regarding exact
> contents
> > > > > of the MACProtocol Data Unit frame
> > > > >
> > > > >
> > > > >
> > > > > Hello, Steve!
> > > > >
> > > > > Things are starting to look less blurry now. Some still sound
> > > > > strange, though.
> > > > > If the 13 (19 in decimal) was the length, then the payload would
> end
> > > > > (unless it doesn't start counting in the byte immediately after
> the
> > >
> > > 13)
> > >
> > > > > right after the byte with "20", which is a 2 byte field.
> > > > >
> > > > >
> > > > > Here's the line again:
> > > > >
> > > > > 7E 45 00 FF FF 00 00 13 00 EE 00 01 00 00 00 07 80 EE 00 07 00 80
> 00
> > >
> > > 00
> > >
> > > > > 00 00 20 00 00 53 63 7E
> > > > >
> > > > > About that 20 and the "0xCAFE", it's because I have changed the
> > > > > struct for my app, and now the 2 byte field "data" in the struct
> is
> > > > > now split
> > >
> > > in
> > >
> > > > > 2, datah and datal, each with 1 byte (datah is the "20", datal is
> the
> > > > > "00"). So the 19 count cannot (unless i'm wrong) end in the "20".
> > > > >
> > > > > The payload struct looks like this:
> > > > >
> > > > > typedef nx_struct TestNetworkMsg {
> > > > > nx_am_addr_t source;
> > > > > nx_uint16_t seqno;
> > > > > nx_am_addr_t parent;
> > > > > nx_uint16_t metric;
> > > > > nx_uint8_t datah;
> > > > > nx_uint8_t datal;
> > > > > nx_uint8_t hopcount;
> > > > > nx_uint16_t sendCount;
> > > > > nx_uint16_t sendSuccessCount;
> > > > > } TestNetworkMsg;
> > > > >
> > > > > How about the "+4" in
> > > > > call UARTSend.send(0xFFFF, recvPtr, call Receive.payloadLength(msg)
> +
> > >
> > > 4)
> > >
> > > > > == SUCCESS), can it influence anything? It does add more bytes to
> > > > > what
> > >
> > > I
> > >
> > > > > get.
> > > > >
> > > > > typedef nx_struct serial_header {
> > > > > nx_am_addr_t dest;
> > > > > nx_am_addr_t src;
> > > > > nx_uint8_t length;
> > > > > nx_am_group_t group;
> > > > > nx_am_id_t type;
> > > > > } serial_header_t;
> > > > >
> > > > > So far, i've ran more tests to try and figure the fields out.
> Here's
> > >
> > > how
> > >
> > > > > I understand it so far, with your help and using the structs
> above:
> > > > >
> > > > > 7E : Sync
> > > > > 45 00 : ????
> > > > > FF FF : destination address
> > > > > 00 00 : source address (root node)
> > > > > 13 : length ?
> > > > > 00 EE : Collection ID (from CTP) ?? / Type ?? / Destination PAN
> > > > > Identifier (from MAC Header) ??
> > > > > 00 : ????
> > > > > 01 : hopcount (seems out of place, but sure looks like it) ????
> > > > > 00 00 : Destination Address (root ID=0) (from MAC Header) ???
> > > > > 00 07 : Source Address (from the MAC Header) ????
> > > > > 80 : sendCount ??? (this field increments like the seqno below)
> > > > > EE : Collection ID (from CTP) ?? / Type ??
> > > > > 00 07 : source
> > > > > 00 80 : seqno
> > > > > 00 00 : parent
> > > > > 00 00 : metric
> > > > > 20 00 : data
> > > > > 00 : ???
> > > > > 53 : rssi ?
> > > > > 63 : fcs check ?
> > > > > 7E : Sync
> > > > >
> > > > > Almost there, but still unclear. How does it look?
> > > > >
> > > > > Many thanks for all the help so far on this,
> > > > >
> > > > > Pedro
> > > > >
> > > > > On 6/13/07, *R. Steve McKown* <rsmckown at yahoo.com > wrote:
> > > > >
> > > > > On Tuesday 12 June 2007 18:22:41 Pedro Almeida wrote:
> > > > > > Thank you, Steve McKown and Alexander Becher for your replies.
> > > > > >
> > > > > > Thanks to your help I more or less figured out how many bytes
> there
> > > > > > were from the Address Information to be included in the MAC
> Header.
> > > > > >
> > > > > > According to:
> > > > > >
> > > > > > 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;
> > > > > >
> > > > > > I then have 9 bytes from the MHR, adding to 1 from length (PHR)
> and
> > > > > > the 5 from the Synchronization Header
> > > > > > (SHR), assuming (I don't think I'm mistaken here) the I-frame is
> > > > > > not
> > >
> > > in
> > >
> > > > > > use, giving a total of 15 bytes. The type byte is include in the
> > > > > > payload
> > > > > >
> > > > > > (according to Steve).
> > > > >
> > > > > In terms of the 802.15.4 frame format, section 14.2 of the CC2420
> > > > > data sheet
> > > > > shows that the data received into software from the radio. The
> SHR
> > >
> > > are
> > >
> > > > > never
> > > > > received by software, so it can't be part of the data you are
> trying
> > >
> > > to
> > >
> > > > > decode. The data returned is a length byte, the MPDU bytes, an
> RSSI
> > >
> > > byte
> > >
> > > > > and
> > > > > an FCScheck/corr byte (note the 2-byte FCS is replaced by RSSI and
> > > > > FCScheck/coor on receive). Also, if you look at CC2420.h and
> > > > > CC2420ActiveMessageP.nc , you'll see that the last 2 bytes
> > > > > (MAC_FOOTER_SIZE)
> > > > > are not calculated as part of the length field returned to the
> upper
> > > > > layers
> > > > > of software on a receive. Instead, the data in the last two bytes
> > > > > are placed
> > > > > in the metadata structure.
> > > > >
> > > > > So, I don't think SHR and FCS can be part of the packet format you
> > > > > are trying
> > > > > to decode.
> > > > >
> > > > > > The payload, from the TestNetwork application, is
> > > > > >
> > > > > > typedef nx_struct TestNetworkMsg {
> > > > > > nx_am_addr_t source;
> > > > > > nx_uint16_t seqno;
> > > > > > nx_am_addr_t parent;
> > > > > > nx_uint16_t metric;
> > > > > > nx_uint16_t data;
> > > > > > nx_uint8_t hopcount;
> > > > > > nx_uint16_t sendCount;
> > > > > > nx_uint16_t sendSuccessCount;
> > > > > > } TestNetworkMsg;
> > > > > >
> > > > > > since nx_am_addr_t is 2 bytes, this struct is 15 bytes. Adding
> the
> > > > > > 1
> > > > >
> > > > > from
> > > > >
> > > > > > the type (as seen above), there's 16 bytes in payload.
> > > > > > Since
> > > > > >
> > > > > > typedef nx_struct cc2420_footer_t {
> > > > > > } cc2420_footer_t;
> > > > > >
> > > > > > and according to Steve, "The current radio stack has the cc2420
> > > > > > generate the FCS (crc) automatically", so I presume it's not
> > >
> > > included.
> > >
> > > > > > This totals 31 bytes, and I read 32! If FCS was indeed included
> (2
> > > > >
> > > > > bytes),
> > > > >
> > > > > > i'd get 33 bytes!!
> > > > > >
> > > > > > Please notice i'm using a representation such as this
> > >
> > >
> http://www.eng.yale.edu/enalab/courses/eeng460a/homeworks/hw1_results/d
> > >
> > > > > >ataf
> > > > > >
> > > > > >rame.gifto try and figure it out.
> > > > > >
> > > > > > This application uses CTP. Can it have anything to do with it?
> > > > > > According
> > > > >
> > > > > to
> > > > >
> > > > > > TEP-123 (http://www.tinyos.net/tinyos-2.x/doc/html/tep123.html),
> > > > > >
> > > > > > The CTP data frame format is as follows (check the URL for
> correct
> > > > > > formatting):
> > > > > > 1
> > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >
> > > > > > |P|C| reserved | THL |
> > > > > >
> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >
> > > > > > | ETX |
> > > > > >
> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >
> > > > > > | origin |
> > > > > >
> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >
> > > > > > | seqno | collect_id |
> > > > > >
> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >
> > > > > > | data ...
> > > > > >
> > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > > >
> > > > > > But I don't know how to understand that, so it doesnt help me
> much.
> > > > > > Also, I don't understand why the frame starts and ends with
> 0x7E.
> > > > > > Is
> > >
> > > 7E
> > >
> > > > > > both preamble and last byte in payload?
> > > > > >
> > > > > > Here's one example sequence again:
> > > > > >
> > > > > > 7E 45 00 FF FF 00 00 13 00 EE 00 01 00 00 00 07 80 EE 00 07 00
> 80
> > > > > > 00
> > >
> > > 00
> > >
> > > > > 00
> > > > >
> > > > > > 00 20 00 00 53 63 7E
> > > > >
> > > > > This is output from tn-listener, right? 0x7E is the serial sync
> > > > > byte. I'm
> > > > > not sure about the next 2 bytes, but the serial header starts at
> the
> > > > > fourth
> > > > > byte. Look at $TOSDIR/lib/serial/Serial.h and they'll match up:
> > > > >
> > > > > typedef nx_struct serial_header {
> > > > > nx_am_addr_t dest;
> > > > > nx_am_addr_t src;
> > > > > nx_uint8_t length;
> > > > > nx_am_group_t group;
> > > > > nx_am_id_t type;
> > > > > } serial_header_t;
> > > > >
> > > > > dest: FFFF - the dest addr as set by UARTSend.send(), as you note
> > > > > below.
> > > > > src: 0000 - the src addr of the sending mote. May be the PC
> > > > > connected mote itself.
> > > > > length: 13 (decimal 19)
> > > > >
> > > > > The next 19 bytes are CTP data, and I don't know the format so
> > >
> > > well. It
> > >
> > > > > looks
> > > > > like there's an initial byte, 2 8-byte entries, and a 2-byte
> footer,
> > >
> > > but
> > >
> > > > > I'm
> > > > > guessing.
> > > > >
> > > > > Note that tn-listener.c seems to have some problems. For example,
> it
> > > > > accesses
> > > > > packet after it has been freed. The data you are seeing could be
> > > > > corrupt,
> > > > >
> > > > > since there's a malloc() after packet is freed and the space could
> > >
> > > have
> > >
> > > > > been
> > > > > reused. The safe thing to do would be to move the free(packet) to
> > >
> > > just
> > >
> > > > > under
> > > > > the free(myPacket). I'm thinking there may be corruption because
> the
> > > > > second
> > > > > CTP unit is supposed to have a 16-bit constant value that should
> read
> > >
> > > "ca
> > >
> > > > > fe"
> > > > > in the raw data stream (see TestNetworkC.nc).
> > > > >
> > > > > Because the link to the PC is a serial link, the mote is sending a
> > >
> > > serial
> > >
> > > > > active message to the PC, which is the payload wrapped in the
> serial
> > > > > frame.
> > > > > This is why you don't see any of the CC2420/802.15.4 frame
> formatting
> > >
> > > in
> > >
> > > > > the
> > > > > data you are trying to match.
> > > > >
> > > > > Cheers,
> > > > > Steve
> > > > >
> > > > > > I believe the EE is the Collection ID, as seen from
> TestNetworkC.h,
> > > > > > which might relate to the CTP frame
> > > > > > (
> > >
> > > http://www.tinyos.net/tinyos-2.x/apps/tests/TestNetwork/TestNetworkC.h
> > >
> > > > > ),
> > > > >
> > > > > > but I'm not sure that helps. The FF FF could also be from, but I
> > >
> > > can't
> > >
> > > > > be
> > > > >
> > > > > > sure:
> > > > > >
> > > > > > call UARTSend.send(0xFFFF, recvPtr, call Receive.payloadLength
> (msg)
> > >
> > > +
> > >
> > > > > > 4)
> > > > >
> > > > > ==
> > > > >
> > > > > > SUCCESS)
> > > > > >
> > > > > > Many thanks and sorry for the confusing posts!
> > > > > > Hope you help me figure this out byte by byte and make sense out
> of
> > >
> > > it.
> > >
> > > > > > Very best regards,
> > > > > >
> > > > > > Pedro
> > > > > >
> > > > > >
> > > > > >
> > > > > > /**
> > > > > > * CC2420 Packet Footer
> > > > > > */
> > > > > > typedef nx_struct cc2420_footer_t {
> > > > > > } cc2420_footer_t;
> > > > > >
> > > > > > On 6/11/07, Steve McKown <rsmckown at yahoo.com > wrote:
> > > > > > > On Friday 08 June 2007 13:21, Pedro Almeida wrote:
> > > > > > > > Hello;
> > > > > > > >
> > > > > > > > I'm trying to look for documentation where I can understand
> the
> > > > >
> > > > > exact
> > > > >
> > > > > > > > contents, byte by byte, of the MPDU. I've looked into the
> TEPs
> > >
> > > and
> > >
> > > > > the
> > > > >
> > > > > > > > source files themselves, butI wasn't completely clear.
> > > > > > > >
> > > > > > > > I'm using now the TestNetwork demo, where I receive 32 bytes
> > > > > > > > per
> > > > > > >
> > > > > > > message,
> > > > > > >
> > > > > > > > of which I know little about, except for the contents of the
> > > > >
> > > > > message_t
> > > > >
> > > > > > > > itself:
> > > > > > > >
> > > > > > > > typedef nx_struct TestNetworkMsg {
> > > > > > > > nx_am_addr_t source;
> > > > > > > > nx_uint16_t seqno;
> > > > > > > > nx_am_addr_t parent;
> > > > > > > > nx_uint16_t metric;
> > > > > > > > nx_uint16_t data;
> > > > > > > > nx_uint8_t hopcount;
> > > > > > > > nx_uint16_t sendCount;
> > > > > > > > nx_uint16_t sendSuccessCount;
> > > > > > > > } TestNetworkMsg;
> > > > > > > >
> > > > > > > > That are not, by far, 32 bytes.
> > > > > > > > So far I understood the MPDU is made of
> > > > > > > >
> > > > > > > > 2 bytes - Frame Control
> > > > > > > > 1 byte - Data Sequence Number
> > > > > > > > 4 to 20 bytes - Address Information
> > > > > > > > n bytes - Data Payload
> > > > > > > > 2 bytes - Frame Check Sequence
> > > > > > > >
> > > > > > > > which adds 5 bytes of the SHR and 1 byte of the PHR. So what
> > > > > > > > exactly are those 32 bytes??? Which ones are the payload
> (MSDU)
> > >
> > > and
> > >
> > > > > > > > which
> > > > >
> > > > > ones
> > > > >
> > > > > > > > are
> > > > > > >
> > > > > > > not
> > > > > > >
> > > > > > > > (and what are they?)?
> > > > > > > >
> > > > > > > > An example of the 32 bytes is as follows:
> > > > > > > >
> > > > > > > > 7E 45 00 FF FF 00 00 13 00 EE 00 01 00 00 00 07 80 EE 00 07
> 00
> > >
> > > 80
> > >
> > > > > > > > 00
> > > > >
> > > > > 00
> > > > >
> > > > > > > 00
> > > > > > >
> > > > > > > > 00 20 00 00 53 63 7E
> > > > > > >
> > > > > > > The data above looks like an active message (AM) delivered via
> a
> > > > >
> > > > > serial
> > > > >
> > > > > > > physical layer. The hint are the 0x7E bytes, which are sync
> > > > >
> > > > > bytes. If
> > > > >
> > > > > > > this
> > > > > > > output came from the PC, then you should be able to map it to
> the
> > > > > > > serial_packet_t in $TOSDIR/lib/serial/Serial.h. The payload
> are
> > > > > > > delivered within the frame appropriate for the link on which
> the
> > >
> > > data
> > >
> > > > > is
> > > > >
> > > > > > > sent. Hence,
> > > > > > > one sees the serial headers and not the radio headers.
> > > > > > >
> > > > > > > I haven't played with Collection or the TestNetwork app, so I
> > >
> > > can't
> > >
> > > > > help
> > > > >
> > > > > > > out
> > > > > > > there. But I can provide some info on how the CC2420
> component
> > > > >
> > > > > populates
> > > > >
> > > > > > > the
> > > > > > > 802.15.4 compatible frame. You can see the mapping in the
> > > > > > > cc2420_header_t structure in
> $TOSDIR/chips/cc2420/CC2420.h. The
> > > > >
> > > > > physical
> > > > >
> > > > > > > radio frame looks
> > > > > > > like this:
> > > > > > >
> > > > > > > preamble + sfd + cc2420_header_t + app_data + FCS (crc)
> > > > > > >
> > > > > > > In terms of 802.15.4, the second field of cc2420_header_t,
> fcf,
> > > > > > > is the
> > > > > > >
> > > > > > > first
> > > > > > > field of the MAC header. The last field of cc2420_header_t,
> > > > > > > type,
> > >
> > > is
> > >
> > > > > > > actually part of the MAC payload. The current radio stack has
> > > > > > > the
> > > > >
> > > > > cc2420
> > > > >
> > > > > > > generate the FCS (crc) automatically.
> > > > > > >
> > > > > > > In terms of addressing, short addresses with the 802.15.4 PAN
> ID
> > > > > > > Compression
> > > > > > > is set, so the address info consists of pan_id + dest_addr +
> > > > >
> > > > > source_addr.
> > > > >
> > > > > > > You can see these fields in the cc2420_header_t
> structure. The
> > >
> > > fcf
> > >
> > > > > > > is
> > > > > > >
> > > > > > > set in
> > > > > > > CC2420CsmaP.nc's Send.send() implementation, where length, dsn
> > > > > > > and
> > > > >
> > > > > source
> > > > >
> > > > > > > are
> > > > > > > also set (destination has already been set in the header by
> this
> > > > >
> > > > > time).
> > > > >
> > > > > > > All the best,
> > > > > > > Steve
> > > > > > >
> > > > > > > > Help!
> > > > > > > >
> > > > > > > > Thank you!!!
> > > > > > > >
> > > > > > > > Pedro
> >
> > !DSPAM:4671561a153541336712104!
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20070614/feeffa26/attachment.htm
More information about the Tinyos-help
mailing list