Wow! That new data obsfucation technique really works!
So it looks like the main difference is in cc2420_header_t
where, compared to the T1 micaZ AM.h, these:
nxle_uint16_t src;
nxle_uint8_t network;
have been inserted before the AM message type. There is
a 'permanent' message serial number added right after the
header info, and I think the max length is 1 byte shorter.
I also 'think' I remember that the T1 fields are little-end,
which is what the "nxle_" would seem to indicate...whereas
new improved nx_int is big-endian, just to expand the data
obfuscation techniques all the way into the bit realm.
Someone who was motivated to talk to T1 could probably
translate all those nested structs into a congruent AM.h
TOS_Msg definition and just ignore or default all the new
fields. But it would mean re-compiling all the legacy apps.
onward into the future
MS
Eric Decker wrote:
> All paths are from the top of a current T2 source tree:
>
> tos/types/message.h contains the structure that pulls all the pieces
> together.
>
> # 19 "/Users/cire/mm_t2/t2_cur/tinyos-2.x/tos/types/message.h"
> typedef nx_struct message_t {
> nx_uint8_t header[sizeof(message_header_t )];
> nx_uint8_t data[28];
> nx_uint8_t footer[sizeof(message_footer_t )];
> nx_uint8_t metadata[sizeof(message_metadata_t )];
> } __attribute__((packed)) message_t;
>
>
> The header pieces are a union defined in platform_message.h. I have a
> platform
> called mm3 which is almost identical to the telosb (telosa is what
> contains the
> platform_message.h file).
>
> # 48 "/Users/cire/mm_t2/t2_mm3/tos/platforms/mm3/platform_message.h"
> #line 45
> typedef union message_header {
> cc2420_header_t cc2420;
> serial_header_t serial;
> } message_header_t;
>
> typedef union TOSRadioFooter {
> cc2420_footer_t cc2420;
> } message_footer_t;
>
> #line 54
> typedef union TOSRadioMetadata {
> cc2420_metadata_t cc2420;
> serial_metadata_t serial;
> } message_metadata_t;
>
>
>
>
> For the radio part we see:
>
> # 39 "/Users/cire/mm_t2/t2_cur/tinyos-2.x/tos/chips/cc2420/CC2420.h"
> typedef uint8_t cc2420_status_t;
> #line 66
> #line 49
> 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 network;
> nxle_uint8_t type;
> } __attribute__((packed))
>
> cc2420_header_t;
>
>
> #line 71
> typedef nx_struct cc2420_footer_t {
> } __attribute__((packed)) cc2420_footer_t;
> #line 97
> #line 81
> typedef nx_struct cc2420_metadata_t {
> nx_uint8_t rssi;
> nx_uint8_t lqi;
> nx_uint8_t tx_power;
> nx_bool crc;
> nx_bool ack;
> nx_bool timesync;
> nx_uint32_t timestamp;
> nx_uint16_t rxInterval;
> } __attribute__((packed))
>
> For the serial part we see:
>
> # 72 "/Users/cire/mm_t2/t2_cur/tinyos-2.x/tos/lib/serial/Serial.h"
> #line 112
> 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;
> } __attribute__((packed)) serial_header_t;
>
>
> #line 120
> typedef nx_struct serial_packet {
> serial_header_t header;
> nx_uint8_t data[];
> } __attribute__((packed)) serial_packet_t;
>
>
> #line 125
> typedef nx_struct serial_metadata {
> nx_uint8_t ack;
> } __attribute__((packed)) serial_metadata_t;
>
>
> 2008/9/7 Michael Schippling <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
>
> OK I found TEP 111 http://www.tinyos.net/tinyos-2.x/doc/html/tep111.html
> which does a nice job of explaining why we "need" so many levels
> of data obfuscation, but doesn't actually show what the final
> structs are and what's the difference. I presume the 2420 headers
> must be identical because they are part of 802.11.14 (I think...).
> It's hard to imagine that the low level radio code would need (much)
> massaging in order to make T1&2 compatible for a one-off system.
>
> Since I'm not now nor ever have been a T2'er, could someone post
> or point to the two structs for me?
>
> thanks
> MS
>
> Eric Decker wrote:
> >
> >
> > 2008/9/7 Renee Azhen <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>
> >
> > yep, Eric, I want to communicate by radio.
> > In T2, the message format_t is named msaage_t, and in T1, it is
> > named TOS_msg, and it is almost different. So each nodes in
> > different T# can't analyze other type radio message as expected.
> >
> >
> > Not sure what you mean by "almost different". Slightly different?
> >
> >
> > Can we revise the code in the mac-lay of T2 to receive and
> analysze
> > radio message send by T1 node?
> >
> >
> > It is possible. It would have to be done at a fairly low level
> in the
> > stack. My gut feeling is you'd be biting
> > off a lot. Asking for lots of problems.
> >
> > What problem are you trying to solve? In other words what are you
> > trying to do with the node that
> > is communicating using the T1 stack?
> >
> >
> > Can we move on by some other method to resolve this problem, then
> > let them communicate between different platform. Or
> definitely no way?
> >
> >
> > A different approach would be to build a T1-T2 gateway. A node
> that has
> > two radios or possibly one radio
> > attached to two stacks. But this too seems like more trouble
> then it is
> > worth.
> >
> >
> >
> > thanks
> > zhijian
> > */Eric Decker <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>/* 写道：
> >
> > Communicate in what way? Using the radio?
> >
> > It is my understanding that there is a small difference
> between
> > the packet format in
> > T2 vs. T1. I would recommend looking at message_t for the
> > communications medium
> > used for T2. I don't remember what the packet structure is
> > called in T1 but that is
> > what you want to compare against.
> >
> > That is where I would start.
> >
> > eric
> >
> >
> > 2008/9/6 Renee Azhen <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
> > <mailto:[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>>>
> >
> > hi, all,
> > Most of my nodes are programed with tinyos 2.0, but
> there is
> > a message sender is programed with tinyos 1.x.
> >
> > It is possble to let the nodes with tinyos 2.0
> receive the
> > msg sent by tinyos 1.x??
> > thanks
> > zhijian
> >
> ------------------------------------------------------------------------
> > 雅虎邮箱，您的终生邮箱！ <http://cn.mail.yahoo.com/>
> > _______________________________________________
> > Tinyos-help mailing list
> > [email protected]
> <mailto:[email protected]>
> > <mailto:[email protected]
> <mailto:[email protected]>>
> >
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
> >
> >
> >
> >
> > --
> > Eric B. Decker
> > Senior (over 50 :-) Researcher
> > Autonomous Systems Lab
> > Jack Baskin School of Engineering
> > UCSC
> >
> >
> >
> ------------------------------------------------------------------------
> > 雅虎邮箱，您的终生邮箱！ <http://cn.mail.yahoo.com/>
> >
> >
> >
> >
> > --
> > Eric B. Decker
> > Senior (over 50 :-) Researcher
> > Autonomous Systems Lab
> > Jack Baskin School of Engineering
> > UCSC
> >
> >
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Tinyos-help mailing list
> > [email protected]
> <mailto:[email protected]>
> >
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
>
>
>
> --
> Eric B. Decker
> Senior (over 50 :-) Researcher
> Autonomous Systems Lab
> Jack Baskin School of Engineering
> UCSC
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
