On Monday 25 June 2007 12:05:37 am Murtuza wrote:
> Hi Steve
>
> Thanks for ur reply...and i apologize for replying late
>
> > 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.
Using the type field to get two different Receive events will work great here.
The advantage of this approach is that all active messages have a type field,
whereas your application-specific messages can contain anything. So working
off the type field makes the dispatching logic in your gateway/receiver more
application independent.
>
> 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];
If you are using TinyOS-2.x, you can use the AMSenderC() and AMRecevierC()
generic components:
components new AMServerC(AM_Type_1) as Send1;
SendApp.AMSend -> Send1;
...
components new AMReceiverC(AM_Type_1) as Receive1,
new AMReceiverC(AM_Type_2) as Receive2;
RecvApp.Receive1 -> Receive1;
RecvApp.Receive2 -> Receive2;
All the best,
Steve
>
> 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
>
>
>
>
> I want to elaborate on these sentences of mine in the previous mail
>
> 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:467fbffb68678539715904!
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
