Hi Steve
Thanks for ur reply...and i apologize for replying late
I want to elaborate on these sentences of mine in the previous mail
Two packets coming from different kinds of motes running different
applications can be distinguished using AM types. Am I right ?
[This was your reply]
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.
Actually what I mean is suppose there are two mica2 motes running distinct
applications on eachother. Then how can I distinguish between these messages
at the receiver. Can I have two Receive.receive events in my receiver
application. Or should I use the same Receive.recvieve event and then
separate out (or distinguish) between the messages by looking into the
packet.
Can i do sth like this..
In mote 1 configuration
Mote_1.AMSend -> AMSenderC.AMSend[AM_Type_1];
In mote2 configuraton
Mote_2.AMSend -> AMSenderC.AMSend[AM_Type_2];
IN THE RECEIVER MOTE
Now I dont understand how I can have separate ActiveMessageC.Receive events.
Is this permitted
uses interface Receive as Mote_1_Receive;
uses interface Receive as Mote_2_Receive;
Rx_Mote.Mote_1_Receive -> ActiveMessageC.Receive[AM_Type_1];
Rx_Mote.Mote_2_Receive -> ActiveMessageC.Receive[AM_Type_2];
My aim is to have a receiving mote receive data from two motes running
different applications. Without parsing through the received message can I
separate out these packets { The ones received from different motes }. I
basically want to separate them during Receive events.
I am not sure whether i have a valid question or not. I would really
appreciate your help and others' as well.
Thanking You
MMA
On 14/06/07, Steve McKown < [EMAIL PROTECTED] > wrote:
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
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
