On Thursday 14 June 2007 13:01, Pedro Almeida wrote:
> 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...
Sure, I understand. I just wanted to point out other bits of code that had
already done what you are doing. If you do need to reimplement, they are
useful for understanding the data stream.
cheers,
Steve
>
> Thanks once more,
>
> Pedro
>
> On 6/14/07, R. Steve McKown <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:* [EMAIL PROTECTED] [mailto:
> > > > > > [EMAIL PROTECTED] *On Behalf Of *Pedro
> > > >
> > > > Almeida
> > > >
> > > > > > *Sent:* Wednesday, June 13, 2007 2:50 PM
> > > > > > *To:* R. Steve McKown
> > > > > > *Cc:* [email protected]
> > > > > > *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* <[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED] > 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:467191fd230212032620075!
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
