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:46709f20185931044457613!
