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).
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/dataframe.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
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:4669af84166828120612385!
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
