On Friday 08 June 2007 13:58, Murtuza wrote:
> Hello friends,
>
> I have 2 different questions.
>
> 1. I wanted to know how can I receive messages of different payload format
> i.e the payload are of different sizes and structures from different motes
> to a common mote. I have seen the code for BaseStation. It does a similar
> thing. But the doubt which bogs me is the AM type of a message. Can anyone
> tell me the meaning of AM type. I understand that different message types
> have different AM types. And we can differentiate different message based
> on this.
Yes. Every type of message can have its own AM type value. So a receiver
receiving a message with type==1 can treat it differently than for a message
with type==2.
> Two packets coming from different kinds of motes running different
> applications can be distinguished using AM types. Am I right ?
I'm not sure I understand this question. Can you share what are you trying to
accomplish? The AM type field allows one to distinguish the contents of the
active message payload only. Any correlations between "kind of mote" or
application and AM type value sets is up to the programmer.
> If I am [right] then
> how can we make sure that the AM types are always distinct.
If you want unique AM type values, you'll have to manage this yourself.
One option would be to maintain a header containing the list of all message
types for all your applications, to ensure they are unique. Each time you
need a new app msg, add one to the list and give it the next number in
sequence. Include this with all apps as the sole source of am type
definitions.
#define AM_TYPE_APP1_MSG1 0x20
#define AM_TYPE_APP1_MSG2 0x21
#define AM_TYPE_APP2_MSG1 0x22
#define AM_TYPE_APP2_MSG2 0x23
#define AM_TYPE_APP2_MSG3 0x24
> 2. When i receive messages from motes to the base station I get a messages
> that do not match the tinyos message_t structure. For example I ran a
> simple test in which the source mote sends its TOS_NODE_ID and a serial
> number of the message over the radio. The TOS_NODE_ID of this node was 3.
> The structure of the message payload was as shown below.
>
> typedef nx_struct test{
> nx_am_addr_t nodeid;
> nx_uint16_t num;
> }test;
>
> I got this as the output displayed on my computer.
> 00 FF FF 00 03 04 22 06 00 03 00 01
> 00 FF FF 00 03 04 22 06 00 03 00 02
> 00 FF FF 00 03 04 22 06 00 03 00 03
This looks good. I presume you have a java or C serial forwarder running
against the serial port to which the base station mote is attached, then the
output above is from a program attaching to the local port opened by the
serial forwarder. Here's how the first packet's values break down:
The first byte is the serial packet format dispatch byte. A
value of 0 (TOS_SERIAL_ACTIVE_MESSAGE_ID) means the
data following are a serial active message. See
$TOSDIR/lib/serial/Serial.h and TEP113 for the details.
00
The next 7 bytes are the serial am header, as defined in
Serial.h's serial_header_t structure.
FF FF dest addr
00 03 src addr
04 length of the data payload
22 group (TOS_AM_GROUP)
06 type (AM type). This value controls how the
remainder of the packet should be interpreted.
The next 4 bytes are the data payload, represented by the
structure 'test' that you defined:
00 03 nodeid
00 01 num
> The output of the BlinkToRadio application. But why is it that the output
> sent by the motes is not according to the message_t structure.
>
> typedef nx_struct cc1000_header {
> nx_am_addr_t addr;
> nx_uint8_t length;
> nx_am_group_t group;
> nx_am_id_t type;
> } cc1000_header_t;
Since the PC is receiving the message over a serial port, the message has a
serial header. The header of a message is tied to the network device used to
send or receive it (aka the link), so it can change from device to device.
> Why is it that there is always the TOS_NODE_ID inserted after the
> destination ID. In the header the
> first field is the destination address right. Then its the length. But
> why is it that i always get
> the source node ID.
>
> Thanking You
> MMA
>
>
> !DSPAM:4669b6a1175882362839998!
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
