from:"Avinash Sridharan"

Hi Phil,
 You are right about the packet drop rate being too high. I double
checked my traces. I didn't realize was having issues with queue
overflows as well (apart from the false ACK's) and hence the higher
drop rates I reported. This is primarily due to the system operating
under very heavy loads. I am going through an older trace (runs on the
USC tutornet testbed for a different protocol) and they are in line
with the numbers you mentioned approximately 0.1-0.5% drop.

Will try to run tests at lower rates to get a better handle on the
false acknowledgment numbers.

Thanks,
Avinash

On Thu, Feb 19, 2009 at 8:44 PM, Philip Levis  wrote:
>
> On Feb 19, 2009, at 8:36 PM, Avinash Sridharan wrote:
>
>> Hi Phil,
>>  Thanks for the explanation. That was quite helpful. I agree with your
>> explanation. I agree that to have perfect reliability we have to
>> implement end-to-end reliability (or at least network layer
>> reliability). I do not have the exact numbers for the  false
>> acknowledgment rates, but at high data rates was starting to see
>> around 10-20% of packets failing to make it through.
>
> You mean, you get an ack, but the data packet didn't arrive successfully?
> This sounds like a high number.
>
>> Hence was trying
>> to  see if I can improve the reliability at the MAC layer. The only
>> problem with implementing acknowledgments at the network layer is that
>> it will introduce latency and also consume capacity (since the data
>> packets are slightly larger). Hence was trying to take the shorter
>> route by improving reliability at the MAC layer (without much success
>> though :) ).
>>
>> I also wasn't aware of the limitation caused by the DSN bits in the
>> ACK's, in a dense deployment this can definitely cause problems.
>> Thanks again for your explanation.
>>
>
> CTP, under reasonable but not super-heavy load, sees around 0.1% false
> positive acks. It actually ends up becoming a limiting factor for end-to-end
> reliability.
>
> Phil
>



-- 
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] CRC in CC2420

Hi Phil,
 Thanks for the explanation. That was quite helpful. I agree with your
explanation. I agree that to have perfect reliability we have to
implement end-to-end reliability (or at least network layer
reliability). I do not have the exact numbers for the  false
acknowledgment rates, but at high data rates was starting to see
around 10-20% of packets failing to make it through. Hence was trying
to  see if I can improve the reliability at the MAC layer. The only
problem with implementing acknowledgments at the network layer is that
it will introduce latency and also consume capacity (since the data
packets are slightly larger). Hence was trying to take the shorter
route by improving reliability at the MAC layer (without much success
though :) ).

I also wasn't aware of the limitation caused by the DSN bits in the
ACK's, in a dense deployment this can definitely cause problems.
Thanks again for your explanation.

regards,
Aviansh

On Thu, Feb 19, 2009 at 8:06 PM, Philip Levis  wrote:
>
> On Feb 19, 2009, at 6:42 PM, Avinash Sridharan wrote:
>
>> Ah ok,
>> Thanks a lot. The specs makes sense, I guess need to look at other
>> places to understand the false acknowledgments. Any idea as to why
>> this might be occurring ?
>
> What false positive acknowledgement rate are you seeing?
>
> 802.15.4 suffers from false acknowledgements in part because acknowledgement
> packets do not have source addresses. Since the DSN is only 8 bits, it is
> possible that a node hears an acknowledgement for another transmission and
> thinks it is for its own.
>
> Also, it's possible that a packet is corrupted but passes CRC. The receiver
> will issue an ACK. But, if, say, the AM type is different, your network
> protocol may never receive the packet.
>
> Link-layer acknowledgements are not perfect -- no acknowledgements are. This
> is the end-to-end argument. If you want to know that a packet has arrived at
> the network layer, you need the network layer to send acknowledgements.
>
> The problem is a little more pronounced in 802.15.4 because CRCs are only 16
> bits and there aren't checks at many layers (layer 2, layer 3, layer 4,
> etc.).
>
> Phil
>
>

-- 
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] CRC in CC2420

Ah ok,
 Thanks a lot. The specs makes sense, I guess need to look at other
places to understand the false acknowledgments. Any idea as to why
this might be occurring ?

regards,
Avinash

On Thu, Feb 19, 2009 at 6:30 PM, Razvan Musaloiu-E.  wrote:
> Hi!
>
> On Thu, 19 Feb 2009, Avinash Sridharan wrote:
>
>> Dear Razvan,
>> I am using Tiny OS-2.0.2, I wanted to follow up on this question. I
>> have enabled software ACK in my system and see quite a few false
>> positives (for topologies with link qualities as bad as 30%). My guess
>> is that though the CRC is failing, the CRC field is not checked before
>> the complete packet is read. While the software acknowledgment is sent
>> out the minute the header information is read (which could still be
>> correct though the data is corrupted).  Please correct me if my
>> description of the behavior of software acknowledgment is not exact.
>
> The specs [1] (page 42, first paragraph after Figure 23) says that SACK and
> SACKPEND will not generate an ACK if the CRC is not valid. So the current
> implementation should work properly.
>
> [1] http://www.ti.com/lit/gpn/cc2420
>
> --
> Razvan ME
>
>> Given my above description is correct, just to see if I can see any
>> reduction in the number of false positive ACK's I wanted to move the
>> software acknowledgment to be generated after performing the CRC test.
>>
>> I was planning to modify the current code from :
>> if ( ( buf[ rxFrameLength ] >> 7 ) && rx_buf ) {
>>   uint8_t type = ( header->fcf >> IEEE154_FCF_FRAME_TYPE ) & 7;
>>   signal CC2420Receive.receive( type, m_p_rx_buf );
>>   if ( type == IEEE154_TYPE_DATA ) {
>> post receiveDone_task();
>> return;
>>   }
>> }
>>
>>
>> to --
>>
>> if ( ( buf[ rxFrameLength ] >> 7 ) && rx_buf ) {
>>   uint8_t type = ( header->fcf >> IEEE154_FCF_FRAME_TYPE ) & 7;
>>   signal CC2420Receive.receive( type, m_p_rx_buf );
>>   if ( type == IEEE154_TYPE_DATA ) {
>>  call CSN.set();
>> call CSN.clr();
>> call SACK.strobe();
>> call CSN.set();
>> call CSN.clr();
>>
>> post receiveDone_task();
>> return;
>>   }
>> }
>>
>> Of course I will turn of the current initiation of software
>> acknowledgment.   Wanted your feedback on these code changes.
>>
>> Thanks and regards,
>> Avinash
>>
>>
>> On Tue, Feb 17, 2009 at 12:18 PM, Razvan Musaloiu-E. 
>> wrote:
>>>
>>> Hi!
>>>
>>> On Tue, 17 Feb 2009, Jordi Pérez wrote:
>>>
>>>> Hi!
>>>>
>>>> I have just tried it, and it works correctly. I see the bad and the
>>>> correct
>>>> packets.
>>>>
>>>
>>> There was a bug in my patch (Mike point it out to me). I attached the
>>> correct one now. :-)
>>>
>>> --
>>> Razvan ME
>>>
>>>> 2009/2/17 Razvan Musaloiu-E. 
>>>>
>>>>> Hi!
>>>>>
>>>>> On Mon, 16 Feb 2009, Jordi Pérez wrote:
>>>>>
>>>>>  Hi Razvan!
>>>>>>
>>>>>> I tryed to understand the code to disable the filtering you said, but
>>>>>> I
>>>>>> can't. Do you mind explaining me the things I have to change?
>>>>>>
>>>>>> In RXFIFO.readDone event when I modify something, the program doesn't
>>>>>> work.
>>>>>> So I don't know how disable it.
>>>>>>
>>>>>> In the SubReceive.receive event I changed the word Snoop to Receive,
>>>>>> but I
>>>>>> don't really know if it is correct.
>>>>>>
>>>>>> Can you help me please?
>>>>>>
>>>>>
>>>>> I attached a patch that takes out the parts that discards the packets
>>>>> with
>>>>> bad CRC. It's against the latest CVS and you can apply it with this
>>>>> requence
>>>>> of commands:
>>>>>  cd $TOSROOT
>>>>>  patch -p1 < cc2420-ignore-crc-patch.diff
>>>>>
>>>>> Warning: I didn't have time to test this! I only made sure that it
>>>>> compiles
>>>>> fine. :-) Give it a try and if it doesn't work at it should I'll look
&g

Re: [Tinyos-help] CRC in CC2420

Dear Razvan,
I am using Tiny OS-2.0.2, I wanted to follow up on this question. I
have enabled software ACK in my system and see quite a few false
positives (for topologies with link qualities as bad as 30%). My guess
is that though the CRC is failing, the CRC field is not checked before
the complete packet is read. While the software acknowledgment is sent
out the minute the header information is read (which could still be
correct though the data is corrupted).  Please correct me if my
description of the behavior of software acknowledgment is not exact.

Given my above description is correct, just to see if I can see any
reduction in the number of false positive ACK's I wanted to move the
software acknowledgment to be generated after performing the CRC test.

I was planning to modify the current code from :
 if ( ( buf[ rxFrameLength ] >> 7 ) && rx_buf ) {
uint8_t type = ( header->fcf >> IEEE154_FCF_FRAME_TYPE ) & 7;
signal CC2420Receive.receive( type, m_p_rx_buf );
if ( type == IEEE154_TYPE_DATA ) {
  post receiveDone_task();
  return;
}
  }

to --

 if ( ( buf[ rxFrameLength ] >> 7 ) && rx_buf ) {
uint8_t type = ( header->fcf >> IEEE154_FCF_FRAME_TYPE ) & 7;
signal CC2420Receive.receive( type, m_p_rx_buf );
if ( type == IEEE154_TYPE_DATA ) {
   call CSN.set();
  call CSN.clr();
  call SACK.strobe();
  call CSN.set();
  call CSN.clr();

  post receiveDone_task();
  return;
}
  }

Of course I will turn of the current initiation of software
acknowledgment.   Wanted your feedback on these code changes.

Thanks and regards,
Avinash

On Tue, Feb 17, 2009 at 12:18 PM, Razvan Musaloiu-E.  wrote:
> Hi!
>
> On Tue, 17 Feb 2009, Jordi Pérez wrote:
>
>> Hi!
>>
>> I have just tried it, and it works correctly. I see the bad and the
>> correct
>> packets.
>>
>
> There was a bug in my patch (Mike point it out to me). I attached the
> correct one now. :-)
>
> --
> Razvan ME
>
>> 2009/2/17 Razvan Musaloiu-E. 
>>
>>> Hi!
>>>
>>> On Mon, 16 Feb 2009, Jordi Pérez wrote:
>>>
>>>  Hi Razvan!

 I tryed to understand the code to disable the filtering you said, but I
 can't. Do you mind explaining me the things I have to change?

 In RXFIFO.readDone event when I modify something, the program doesn't
 work.
 So I don't know how disable it.

 In the SubReceive.receive event I changed the word Snoop to Receive, but
 I
 don't really know if it is correct.

 Can you help me please?

>>>
>>> I attached a patch that takes out the parts that discards the packets
>>> with
>>> bad CRC. It's against the latest CVS and you can apply it with this
>>> requence
>>> of commands:
>>>   cd $TOSROOT
>>>   patch -p1 < cc2420-ignore-crc-patch.diff
>>>
>>> Warning: I didn't have time to test this! I only made sure that it
>>> compiles
>>> fine. :-) Give it a try and if it doesn't work at it should I'll look
>>> more
>>> into it.
>>>
>>> --
>>> Razvan ME
>>>
>>>
>>>  2009/2/12 Razvan Musaloiu-E. 

  Hi!
>
>
> On Wed, 11 Feb 2009, Jordi Pérez wrote:
>
>  Dear all,
>
>>
>> For CC2420, if AUTOCRC is set, will the hardware reject CRC-error
>> packet automatically?
>> If true, then is it possible to receive those packets but with AUTOCRC
>> still
>> being set? I want to receive this packets and rebuild them.
>>
>>
>>  The CC2420 is not discarding the packets with bad CRC. What does is
>> to
>
> indicate using a bit that the packet was bad (page 38, section 16.4
> from
> [1]). The TinyOS driver for CC2420 inspects this bit and discards the
> packets if that bit is not 1. You can see this happening in the
> RXFIFO.readDone event from CC2420ReceiveP.nc. The switch branch of
> interest
> is 'case S_RX_PAYLOAD:'.
>
> The other filtering that you'll have to disable is in the
> SubReceive.receive event from CC2420ActiveMessageP.nc.
>
> [1] http://focus.ti.com/lit/ds/symlink/cc2420.pdf
>
> --
> Razvan ME
>

>>
>
> ___
> Tinyos-help mailing list
> Tinyos-help@millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
>

-- 
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar

___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] replacement for CollectionExample in 2.1

2008-09-23 Thread Avinash Sridharan

There used to be a CollectionExample app in 2.0.2, to explain the usage of
CTP in 2.x. I can't find such an app in 2.1 . Is there an alternative app
that is provided ?

-- 
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Metadata in CC2420 => message_t

2008-09-22 Thread Avinash Sridharan

Yes that is the max payload that the message_t structure can handle.

-Avinash

On Mon, Sep 22, 2008 at 6:01 PM, Michael von Hauff <
[EMAIL PROTECTED]> wrote:

> hmmm,
>
> I thought the payload of the radio packet was variable.
>
> So what you are saying is that it is fixed at whatever the TOS_DATA_LENGTH
> is set to?
>
>
>
> On Mon, Sep 22, 2008 at 4:48 PM, Greg Hackmann <[EMAIL PROTECTED]> wrote:
>
>> Michael von Hauff wrote:
>>
>>> I think that some of the metadata is missing (or I am expecting more than
>>> what is there!)
>>>
>>> here is the output using Listen.
>>> 00 00 60 00 00 1C 00 04 12 41 88 2D 22 00 FF FF 01 00 06 00 01 FF FF C9
>>> D2 06 EB 00 00 00 00 00 00 00 00 00
>>> 00 00 60 00 00 1C 00 04 12 41 88 2E 22 00 FF FF 01 00 06 00 01 FF FF C9
>>> D1 06 EB 00 00 00 00 00 00 00 00 00
>>> 00 00 60 00 00 1C 00 04 12 41 88 2F 22 00 FF FF 01 00 06 00 01 FF FF C9
>>> D0 06 EB 00 00 00 00 00 00 00 00 00
>>> 00 00 60 00 00 1C 00 04 12 41 88 30 22 00 FF FF 01 00 06 00 01 FF FF C9
>>> CF 06 EC 00 00 00 00 00 00 00 00 00
>>>
>>> everything after the count down value (FF FF C9 D2 on first line) should
>>> be the metadata i think (I expected some extra zeros because my serial
>>> payload is bigger than the radio packet).
>>>
>>
>> None of the metadata is being copied into the serial packet.  You're
>> dumping the first 28 bytes of the message_t structure, so what you're seeing
>> is the 11-byte cc2420_header_t followed by the first 17 bytes of payload
>> data (out of 28).
>>
>> Greg Hackmann
>>
>
>
> ___
> Tinyos-help mailing list
> Tinyos-help@millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
>


-- 
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Book NesC and TinyOS

2008-01-25 Thread Avinash Sridharan

This is an online book by Phil Levis. I found it really useful when I was
getting my feet wet with  nesC and TinyOS. Apart from this the tutorial for
T2 is and T1 are quite comprehensive and should get most people going of to
a flier.

http://csl.stanford.edu/~pal/pubs/tinyos-programming.pdf
-Avinash

On Jan 25, 2008 9:49 AM, Tiago Wanderley <[EMAIL PROTECTED]>
wrote:

> Hi,
>
> could somebody indicate a good book to learn the language NesC e TinyOS?
> ___
> Tinyos-help mailing list
> Tinyos-help@millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>

-- 
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] current MAC protocol in TinyOS

2007-12-19 Thread Avinash Sridharan

Could be you be more specific about the platform and the version of TinyOS
you are using ?

-Avinash

On Dec 18, 2007 8:23 PM, Tie Luo <[EMAIL PROTECTED]> wrote:

> Dear All,
>
> Is the current MAC protocol in TinyOS B-MAC or X-MAC? I searched on
> tinyos.net and it seems to be B-MAC. I just want to confirm. Thanks.
>
> --
> Regards,
> Tie
> ___
> Tinyos-help mailing list
> Tinyos-help@millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
>


-- 
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] using Packet Link interface in TinyOS 2.0.2.2

2007-09-05 Thread Avinash Sridharan

Hi All,
 I was trying to use the Packet Link interface in TinyOS 2.0.2.2 release. I
read in TEP 127 that you could use the Packet link interface to set the max
number of retries and the retry delay. However in the CC2420 stack although
the CC2420ActiveMessageC  component exposes the PacketLink implementation it
is not exposed further in the ActiveMessageC component in the platform
specific files ( in my case telosa).

Does that mean in order to use the PacketLink interface I will require to
directly wire into the CC2420ActiveMessageC interface instead of the
platform specific ActiveMessageC component ? Am I missing something over
here ? Shouldn't the ActiveMessageC component in the telosa also expose this
interface.? Or is this because currently the PacketLink interface is very
specific to CC2420 (TEP 127)?

regards,
Avinash

-- 
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Query: TX timing randomness in multihopping???

2007-08-28 Thread Avinash Sridharan

The CC2420 radio stack provides CSMA and I assume other platforms provide a
similar mechanism.  So does TOSSIM (not sure if you are running your code on
real motes or are simulating it). However the CSMA by nature is a best
effort servcie in the sense that it tries to avoid collision by performing a
carrier sense and implementing random back offs. This does not mean
collision cannot take place.

There is also the case of the hidden terminal problem (for which you
probably need something like an RTS/CTS scheme (CA) ) which could also
induce collisions.

So in short you need not do random back offs at the application layer,
however you cannot do away with packet losses completely (even if you do
random back offs) short of retransmitting the packets using acknowledgments.

On 8/29/07, Ravi Prasad <[EMAIL PROTECTED]> wrote:
>
>
> Hi,
>
> I am trying to implement a true mesh routing. I have
> finished implementing an elementary routing layer
> above the ActiveMessage layer. But I am facing a lot
> of packet drops. This I guess is due to collision. I
> added the packetacknowledgements to solve the problem
> but still the case is same. I think MAC layer should
> take care of link level collision avoidance. But it
> seems it is not doing it efficeintly.
>
> My question is that when I call send of ActiveMessage
> to send a packet, will it use proper CSMA/CA at MAC
> level to avoid any collision and packet losses?? OR I
> need to use a random delay to call send at application
> level (i.e my routing layer)??
>
>
> Also if anyone can provide some guidelines about
> avoiding packet losses in a multihop environment.
>
>
> -Regards
>
>
>
>
>
>
>
>
>
> 
> Sick sense of humor? Visit Yahoo! TV's
> Comedy with an Edge to see what's on, when.
> http://tv.yahoo.com/collections/222
> ___
> Tinyos-help mailing list
> Tinyos-help@Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>

-- 
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] TOSSIM 2.x running slow

2007-08-22 Thread Avinash Sridharan

Hi ,
 We are running some throughput simulations on TOSSIM 2.0.2 that we
installed from the TinyOS website. In the simulation we have a single
receiver and two senders. The topology is such that all nodes can hear each
other. In the simulation the senders continuously send packets to the
receiver by posting a send task the minute sendDone is returned.

The throughput values that we are getting are quite believable (~300
pkts/sec), however the simulation is quite slow. For a 5 second simulation
it takes close to an hour to complete. Could this be due to the new noise
model being used ? We are using the complete meyers-heavy.txt file for
generating the noise model.

Thanks,
Avinash

-- 
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] making CC2420 work in promiscuous mode

2007-08-09 Thread Avinash Sridharan

I am working on TinyOS-2.x. Is there an interface to turn the CC420 on in
promiscuous mode. I want all unicast packets to be heard by nodes in a
single broadcast domain. I don't want to broadcast the packets since that
would turn off the ACK's.

Thanks,
Avinash

-- 
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Tinyos-help conflicting types ???

2007-07-27 Thread Avinash Sridharan

You might want to check your search path from which the interfaces are being
picked up. It looks like you might have an older copy of EASAP.nc that the
compiler might be looking at ??

-Avinash

On 7/27/07, Inderjit Singh <[EMAIL PROTECTED]> wrote:
>
> Hi, I have a small problem compiling my module.
>
> I have an interface (EASAP.nc):
>
> interface EASAP
> {
>   ...
>command struct Node* findNode(uint8_t id);
>   ...
> }
>
> And in my module ( EASAPM.nc)
> {
>...
>command struct Slot* EASAPImp.findSlot(uint8_t slot)
>{
> ...
>}
>
>...
>command struct Node* EASAP.findNode(uint8_t id)
>{
>  ...
>}
> }
>
> I am get comiling error:
> EASAPM.nc:672: conflicting types for `EASAP.findNode'
> EASAP.nc:59: previous declaration of `EASAP.findNode'
> make: *** [exe0] Error 1
>
>
> I can't find a duplicate of the findNode function anywhere. Can anyone see
> what I can't?
>
> Thanks,
> Inderjir
>
> ___
> Tinyos-help mailing list
> Tinyos-help@Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
>


-- 
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] detecting packet losses in TOSSIM 2.0

2007-07-19 Thread Avinash Sridharan

Hi Phil,
Thanks.

Just one more question, which branch should I check in order to get the
2.0.2 code ?

Thanks,
Avinash

On 7/18/07, Philip Levis <[EMAIL PROTECTED]> wrote:

Avinash Sridharan wrote:
> Hi Phil,
>  Are you referring to the CpmModelC.nc, since in the TinyOS 2.0.1
> version that I have, the file in question has only 361 lines. I did a
> grep for the exact dbg statement you had mentioned, in your reply, for
> all files under the tossim folder as well, without success.
>
> I used the grep with the -i option with similar results.
Oh -- the version I had was from CVS.

Basically, to figure out why packets are being lost, look for any place
where the lost field is set to 1. The 2.0.1 version of CpmModelC handles
a few tough edge cases simply (not perfectly); 2.0.2/CVS will be/is much
better.

Phil

--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] detecting packet losses in TOSSIM 2.0

2007-07-18 Thread Avinash Sridharan

Hi Phil,
Are you referring to the CpmModelC.nc, since in the TinyOS 2.0.1 version
that I have, the file in question has only 361 lines. I did a grep for the
exact dbg statement you had mentioned, in your reply, for all files under
the tossim folder as well, without success.

I used the grep with the -i option with similar results.

Thanks,
Avinash

On 7/18/07, Philip Levis <[EMAIL PROTECTED]> wrote:

Avinash Sridharan wrote:
> I detected the total numbers of packet lost in the channel by doing a
> grep on the word "Lost" from the debug statements from the channel
> model, since this is printed out whenever is a packet is dropped by
> the channel model. I have two questions:
This doesn't seem like a very sound methodology to me. Take a look at
the debug statement on line 390:

dbg("Gain,SNRLoss", "Going to lose packet from %i with signal %lf as am
receiving a packet from %i with signal %lf\n", list->source,
list->power, source, rcv->power);

If your grep was not with -i (case insensitive), there's also line 308:

dbg("CpmModelC,SNRLoss", " - lost packet from %i as SNR was too low.\n",
(int)mine->source);

Phil

--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] detecting packet losses in TOSSIM 2.0

2007-07-18 Thread Avinash Sridharan


Hi All,

I am currently using TOSSIM 2.0 on TinyOS 2.0.1. I wanted to understand the
packet losses that are taking place in my simulation. The problem is as
follows:

The topology I have is a simple 3 node linear topology (I have tried the
same with 4 and 5 nodes as well).

1<2<3

The gain file I am using is:
12  0
13  0
21  0
23   0
310
3 2   0

Basically everyone can hear everyone else and all bi-directional links have
0 db gain. I am using the default radio model in TinyOS 2.0.1.  I use a
short trace file , the first 100 lines from the meyers-heavy.txt file to
generate the noise model for each of the 3 nodes as per the tutorial.

In my simulation, 2 and 3 are sending packets to sink 1. 2 is transmitting
the packets directly to 1 and 3 is transmitting the packets to 1 through 2.
During simulation I saw that the success rate of packets from 2 to 1 is 99%
while the success rate of packets from 3 to 1 is just 82 %. This implied
that packets from 3 are getting lost. In order to ascertain the cause of
these losses I turned on debug statements in the forwarding queue of 2 and
the radio channel model. The packet that I count as sent are the ones that
are counted at the successful "sendDone " call at node 3 (hence these
packets are definetly put on the air).


From the debug statements at 2 I could see that the average queue size is 1

and there are no packet drops (I was printing out debug statements in case
of queue drops). From the debug statements of channel model I could see
there were loses due to collision but the number of packets lost at the
channel model was much less then that indicated by the loss rate of 82 % at
node 3 (e.g, if node 3 sent a total of 3 pkts, only ~24000 were reach
however the channel model indicated a drop of hardly 500 packets). I
detected the total numbers of packet lost in the channel by doing a grep on
the word "Lost" from the debug statements from the channel model, since this
is printed out whenever is a packet is dropped by the channel model. I have
two questions:


a> The packet loss detected at the channel model does not match up to the
loss rate I am detecting for node 3.  Is my method of calculating the lost
packets correct ? Is there some other component other then the channel model
where these losses could have occured or is there a better way to figure out
the lost packets ?

b> Given that it is a fully connected network and the number of nodes in
question is relatively small the collision rate at the MAC should be really
low ~95% (the CSMA should normally be able to resolve the contention).
However it seems from the above simulation this not so ?  Is there a setting
at the MAC or the radio that I might be missing ?

Thanks and regards,
Avinash


--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Running C++ TOSSIM Simulations

2007-07-18 Thread Avinash Sridharan

Hi Phil,
Firstly I apologize for the premptive mail. It turns out that with the
upgrade to Fiesty Fawn (Ubuntu 7.04) my python got upgraded to python 2.5 as
well. This led to the incompatibility in the API. When I reverted back to
2.4 the warnings went away.

The second major problem was I hadn't paid attention to all the instructions
put up on the TinyOS website while installing the 2.0.1 tree. It turns out
there is a bug in the 2.0.1 tree which results in the timers not working
with TOSSIM which is what was happening in my case. When I followed the
instructions on
http://www.tinyos.net/tinyos-2.x/doc/html/install-tinyos.html
(the one given just before step 6)
things worked out just fine.

I am currently in the process of running some experiments with a 5 hop
linear topology(the radio is working) will ping in case I have any more
issues.

Thanks a lot for your time,
regards,
Avinash

On 7/17/07, Philip Levis <[EMAIL PROTECTED]> wrote:

Avinash Sridharan wrote:
> Hi Phil,
>  I was trying to use the TOSSIM that comes with tinyos 2.0.1 by
> following the TOSSIM tutorial. I was primarily interested in using the
> new radio model that comes with TinyOS 2.0.1.
>
> However when I try to run the example code given in the TOSSIM
> tutorial with the RadioCountToLeds application the script just prints
> out the python statements and exits. Here is the output.
> /home/hobes/developement/tinyos-2.0.1/apps/RadioCountToLeds/TOSSIM.py:4:
> RuntimeWarning: Python C API version mismatch for module _TOSSIM: This
> Python has API version 1013, module _TOSSIM has version 1012.
>   import _TOSSIM
>   1   2   -54.0
>   2   1   -54.0
>   2   3   -64.0
>   3   2   -64.0
>   1   3   -64.0
>   3   1   -64.0
> Creating noise model for  1
> Creating noise model for  2
> Creating noise model for  3
>
>
> Could this be due to the warning ? I have just upgraded my system to
> Ubuntu 7.0.4. Do I need to recompile TOSSIM in order to remove the
> compatibility warnings ?
>
> I tried this simple example since with my other applications (that had
> been working with 2.0.0 UscGainInterference model) the radio wouldn't
> work with TOSSIM.
>
>
> The only difference between the code in the tutorial and my example
> run here is that instead of using the meyer-heavy.txt file I used a
> shorter noise trace by using the first 100 lines of the meyer-heavy.txt.
>
>
> Thanks in advance for the help.

I have no idea. I've never seen that error before.

Could you dig a bit deeper? That is, try typing in the script and see
what happens? Are any TOSSIM events executing? Your output is not much
to go on.

Phil

--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Running C++ TOSSIM Simulations

2007-07-17 Thread Avinash Sridharan


Hi Phil,
I was trying to use the TOSSIM that comes with tinyos 2.0.1 by following
the TOSSIM tutorial. I was primarily interested in using the new radio model
that comes with TinyOS 2.0.1.

However when I try to run the example code given in the TOSSIM tutorial with
the RadioCountToLeds application the script just prints out the python
statements and exits. Here is the output.
/home/hobes/developement/tinyos-2.0.1/apps/RadioCountToLeds/TOSSIM.py:4:
RuntimeWarning: Python C API version mismatch for module _TOSSIM: This
Python has API version 1013, module _TOSSIM has version 1012.
 import _TOSSIM
 1   2   -54.0
 2   1   -54.0
 2   3   -64.0
 3   2   -64.0
 1   3   -64.0
 3   1   -64.0
Creating noise model for  1
Creating noise model for  2
Creating noise model for  3


Could this be due to the warning ? I have just upgraded my system to Ubuntu
7.0.4. Do I need to recompile TOSSIM in order to remove the compatibility
warnings ?

I tried this simple example since with my other applications (that had been
working with 2.0.0 UscGainInterference model) the radio wouldn't work with
TOSSIM.


The only difference between the code in the tutorial and my example run here
is that instead of using the meyer-heavy.txt file I used a shorter noise
trace by using the first 100 lines of the meyer-heavy.txt.


Thanks in advance for the help.

regards,
Avinash

On 7/12/07, Tal Rusak <[EMAIL PROTECTED]> wrote:


Hi,
 I am trying to run C++ TOSSIM simulations in order to use the gdb
debugger to examine my code and the TinyOS library code. I have
followed the TOSSIM tutorial 11, at
http://www.tinyos.net/tinyos-2.x/doc/html/tutorial/lesson11.html
 I saved the suggested C++ file as Driver.c and the makefile driver as
Makefile.Driver. Then I complied to TOSSIM by running
make micaz sim
(for python)
and
make -f Makefile.Driver
(for C++)
 Then I run gdb. To begin, I simply wanted to run the program to
completion, so I entered "run" 7.04 at the GDB plot. Whenever I try
to run the program in this way, I get the following error message
after the program runs for several minutes:

Program received signal SIGSEGV, Segmentation fault.
0x0804dfe2 in sim_noise_trace_add (node_id=0, noiseVal=-60 '�')
at /opt/tinyos-2.x/tos/lib/tossim/sim_noise.c:88
88  memcpy(data, noiseData[node_id].noiseTrace,
noiseData[node_id].noiseTraceLen);

 It may be applicable to note that the program took up an increasing
amount or RAM space on Ubuntu 7.04. It used up 98.0% of the 1 GB RAM
(minus about 230 MB for the OS, ect) and, in one case, 51% of the my
4.6 GB swap partition (increased from 1 GB specifically for the
purpose of running this program). In most subsequent runs, however,
swap usage was lower.
 Is there some sort of stack or heap overflow occurring due to lack of
memory?
 I tried to optimize the file by reducing the number of motes to 2 and
the noise traces to 100 (the minimum allowed). However, memory usage
was similar to the above and the error still occurred.

 Are there any ideas about how I can resolve this issue? By the way,
are the memory values that I cite reasonable? If so, is it possible
to optimize the C++ somehow so it runs on computers with about 1 GB
of RAM?
 Any help is appreciated in advance.

Tal

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help





--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Fwd: question on forwarding engine in tinyos-2.x

2007-03-23 Thread Avinash Sridharan

Hi Phil,
By service rates of a packet I mean the service rate that the queue is
giving to each packet. Since the buffer space for the clients and the
forwarders are different the probability that you serve a client packet
should be lower then the probability that you serve a forwarded packet
(assuming both are generating packets at the same rate).

I agree fairness is at the flow level but the fair rates that you would
calculate for each flow is closely tied to the maximum possible rate that
each flow can be serviced at, which in turn is determined by the queuing
dynamics.  This reasoning  leads to my statement " that  there seems to be
an inherent unfairness in the queuing dynamics ".

Also under light loads the above affects might not show up as you stated
since if the average queue length of the forwarded packets is going to be
close to 1 then all the above dynamics I just described wouldn't come into
play. But again this would depend on what you define a "light" load as (what
if the average queue length is greater than 1 ?).

My objective here was to develop a rate control mechanism on top of the CTP
framework and the rates that I was calculating was based on the notion that
all flows are treated the same in the queues. However as I mentioned earlier
the rates I was getting were coming out to be disproportional, but I concede
that the experiments were being carried out at heavy load (all queues were
almost fully loaded).

regards,
Avinash
On 3/23/07, Philip Levis <[EMAIL PROTECTED]> wrote:

On Mar 23, 2007, at 9:11 AM, Avinash Sridharan wrote:

> Hi Phil,
>  I agree that if you apply rate control to the client it would
> limit the packet generation, but the reason I say the queueing
> dynamics would override these affects is that rate control
> algorithm assume all packets have the same service rate.

I don't understand what you mean by "all packets have the same
service rate." Fairness rarely operates in terms of packets; it
operates in terms of flows or node pairs. I'm not sure what fair
servicing on a packet basis means, as a packet is a singleton.

> But since the queue is biased towards the forwarder the service
> rate of a client packet will be less than the service rate of a
> frowarded packet. Wouldn't the rate allocated to the client have to
> take this into account ?

Again, I don't understand what you're asking. Are you asking about
how you would implement network fairness? Or are you commenting that
the current implementation of CtpForwardingEngineP does not have
commands/events which provide the information you would need to
implement fairness? This latter point is true -- you need to at least
see the queue depth. Rodrigo and Om are working on the implementation
so it can provide this information, in order to allow transport-level
fairness mechanisms (e.g., IFRC) to be built on top of a CTP topology.

I don't understand what you're trying to achieve that CTP won't let
you. I'll reiterate -- CTP has never claimed to provide network
fairness under high load. If anything, it focuses on the much more
common case in *low-power* sensornets of light load.

> I agree with the point you made on the segregation of queues its
> like applying a control algorithm on the queues itself. So would it
> make sense to have a single queue for clients and forwarded packets
> and serving them without bias (first come first serve) and allowing
> rate controllers to control their rates ?

Sure -- isn't that what I said originally?

Phil

--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Fwd: question on forwarding engine in tinyos-2.x

2007-03-23 Thread Avinash Sridharan

Hi Phil,
I agree that if you apply rate control to the client it would limit the
packet generation, but the reason I say the queueing dynamics would override
these affects is that rate control algorithm assume all packets have the
same service rate. But since the queue is biased towards the forwarder the
service rate of a client packet will be less than the service rate of a
frowarded packet. Wouldn't the rate allocated to the client have to take
this into account ?

I agree with the point you made on the segregation of queues its like
applying a control algorithm on the queues itself. So would it make sense to
have a single queue for clients and forwarded packets and serving them
without bias (first come first serve) and allowing rate controllers to
control their rates ?

regards,
Avinash

On 3/23/07, Philip Levis <[EMAIL PROTECTED]> wrote:

On Mar 22, 2007, at 10:35 PM, Avinash Sridharan wrote:

> Hi Phil,
>  But even if we apply rate controllers at the sources (say for each
> of the clients) the inherent unfairness in the queuing dynamics
> would over ride the effects of the rate controllers to provide
> fairness.

If you apply rate control to packet generation, then this is going to
limit how many client packets are in the queue at any one time. How
would queueing dynamics override these effects?

>  The point I am trying to make is to make transport layers work
> with the forwarding engine that can ensure fairness there should be
> a fair treatment of all packets in the queue. One way I would think
> this could be done is to keep the client queue segregated from the
> forwarding queue, and make the send task alternate between these
> queues.

Alternating between the queues most certainly would not provide
fairness -- you give equal weight to packets you generate and *all*
packets you forward. Nodes close to the root would have a higher
throughput than those far. That being said, if you had two queues,
you *could* control the rate at which you service them to provide
fairness. But that's not any different than controlling the rate at
which packets can enter a shared queue.

Phil

--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Fwd: question on forwarding engine in tinyos-2.x

Hi Phil,
But even if we apply rate controllers at the sources (say for each of the
clients) the inherent unfairness in the queuing dynamics would over ride the
effects of the rate controllers to provide fairness.

The point I am trying to make is to make transport layers work with the
forwarding engine that can ensure fairness there should be a fair treatment
of all packets in the queue. One way I would think this could be done is to
keep the client queue segregated from the forwarding queue, and make the
send task alternate between these queues.

I apologize if I seem to have stretched the argument a bit.

regards,
Avinash

On 3/22/07, Philip Levis <[EMAIL PROTECTED]> wrote:

On Mar 22, 2007, at 7:17 PM, Avinash Sridharan wrote:

> Hi Phil,
>  A few more questions more on the bandwidth allocation between the
> client and forwarder in the forwarding engine.
>
> The forwarder effectively has a depth of FORWARD_COUNT (set to 5)
> in the FIFO queue and the client has a depth of 1. As you mentioned
> in your mail below this implies the client gets only 1/6 th of the
> bandwidth.
>
> Isn't this inherently unfair. In the sense that the forwarded
> packets would always get 5 times the bandwidth as compared to the
> source itself. I did a simple experiment with the following linear
> topology:
>
> 1<2<3
>
> This was done on TOSSIM, I kept an application level queue of size
> 50 for the forwarder 2. Both 2 and 3 were generating packets that
> were destined for the sink 1.
>
> It turned out that for every 3-5 packets forwarded by node 2 to
> node 1 that originated from node 3 you would have a single packet
> forwarded sent from node 2 to 1. Thus the bandwidth allocation was
> quiet uneven.
>

CTP is not intended to provide node-level fairness under high
bandwidth. If you look closely, none of the protocols that lots of
people use do (e.g., MintRoute, etc.).  There are a couple of
transport protocols that propose ways to do so -- IFRC, Ee's paper in
SenSys 2004, ARC in Mobicom 2001. The two general approaches are to
maintain per-child state or rate-limit at packet sources.

Phil

--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Fwd: question on forwarding engine in tinyos-2.x

Hi Phil,
A few more questions more on the bandwidth allocation between the client
and forwarder in the forwarding engine.

The forwarder effectively has a depth of FORWARD_COUNT (set to 5) in the
FIFO queue and the client has a depth of 1. As you mentioned in your mail
below this implies the client gets only 1/6 th of the bandwidth.

Isn't this inherently unfair. In the sense that the forwarded packets would
always get 5 times the bandwidth as compared to the source itself. I did a
simple experiment with the following linear topology:

1<2<3

This was done on TOSSIM, I kept an application level queue of size 50 for
the forwarder 2. Both 2 and 3 were generating packets that were destined for
the sink 1.

It turned out that for every 3-5 packets forwarded by node 2 to node 1 that
originated from node 3 you would have a single packet forwarded sent from
node 2 to 1. Thus the bandwidth allocation was quiet uneven.

-Avinash

On 3/22/07, Philip Levis <[EMAIL PROTECTED]> wrote:

On Mar 22, 2007, at 12:00 PM, Avinash Sridharan wrote:

> So this means for a client the send queue size is one and for the
> forwarded packets the send QUEUE size is FORWARD_COUNT ?
>
> Did I get this right ? since whenever a client forwards a packet
> unless the previous packet has been sent out it cannot insert its
> own packet in any case right ?
>

I think you're a bit confused; clients don't forward packets, they
generate them. FORWARD_COUNT defines the number of forwarding packets
a node can have in its queue. That is, packets it received from
another node. CLIENT_COUNT defines the number of generated packets it
can have in its queue. That is, the number of packets a higher layer
has requested to send to a collection point.

If a sending client wants a queue deeper than 1, then they can always
put their own queue on top of its single entry in the CTP
transmission queue. But the forwarding queue allocation discipline
means that this client gets at most 1/Nth of the bandwidth.

Phil

--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Fwd: question on forwarding engine in tinyos-2.x

Thanks Phil, got it.

regards,
Avinash

On 3/22/07, Philip Levis <[EMAIL PROTECTED]> wrote:

On Mar 22, 2007, at 12:00 PM, Avinash Sridharan wrote:

> So this means for a client the send queue size is one and for the
> forwarded packets the send QUEUE size is FORWARD_COUNT ?
>
> Did I get this right ? since whenever a client forwards a packet
> unless the previous packet has been sent out it cannot insert its
> own packet in any case right ?
>

I think you're a bit confused; clients don't forward packets, they
generate them. FORWARD_COUNT defines the number of forwarding packets
a node can have in its queue. That is, packets it received from
another node. CLIENT_COUNT defines the number of generated packets it
can have in its queue. That is, the number of packets a higher layer
has requested to send to a collection point.

If a sending client wants a queue deeper than 1, then they can always
put their own queue on top of its single entry in the CTP
transmission queue. But the forwarding queue allocation discipline
means that this client gets at most 1/Nth of the bandwidth.

Phil

--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Fwd: question on forwarding engine in tinyos-2.x

So this means for a client the send queue size is one and for the forwarded
packets the send QUEUE size is FORWARD_COUNT ?

Did I get this right ? since whenever a client forwards a packet unless the
previous packet has been sent out it cannot insert its own packet in any
case right ?

Thanks,
Avinash

On 3/22/07, Philip Levis <[EMAIL PROTECTED]> wrote:

On Mar 22, 2007, at 11:41 AM, Avinash Sridharan wrote:

> I apologize for the incomplete mail . (hit the sent button by
> mistake)
>
> Here is my question:
>  I am using the forwarding engine from the collection tree frame
> work. I had a question on the queue sizes of the client queues and
> the forwarding queues.
>
> I checked ctpP.nc and there is variable called QUEUE_SIZE which is
> set to CLIENT_COUNT + FORWARD_COUNT, which would be 6.
>
> Does that mean that the queue size for the client and the forwarder
> would be 6. I am a bit confused with these variables and would like
> to get some advice as to which variables reflect the queue sizes
> for the client queue and the forwarder queue.
>

Ah, yeah, this is a little bit of nesC magic.

Basically, each sending client has a single reserved entry in the
queue. So a client's call to Send.send() returns FAIL iff it already
has a packet pending. CLIENT_COUNT is uniqueCount("...") where the
string is the key used to distinguish clients (I can't recall it off
the top of my head).

In addition to these queue entries, there's a forwarding queue of
size FORWARD_COUNT.

So, for example, if you have no components instantiate a
CollectionSenderC, then the queue size will be FORWARDING_COUNT.

The clients and forwarded packets share a single FIFO queue. CTP just
controls how much of the queue each can use.

Phil

--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Fwd: question on forwarding engine in tinyos-2.x


I apologize for the incomplete mail . (hit the sent button by mistake)

Here is my question:
I am using the forwarding engine from the collection tree frame work. I had
a question on the queue sizes of the client queues and the forwarding
queues.

I checked ctpP.nc and there is variable called QUEUE_SIZE which is set to
CLIENT_COUNT + FORWARD_COUNT, which would be 6.

Does that mean that the queue size for the client and the forwarder would be
6. I am a bit confused with these variables and would like to get some
advice as to which variables reflect the queue sizes for the client queue
and the forwarder queue.


Thanks and regards,
Avinash

-- Forwarded message --
From: Avinash Sridharan <[EMAIL PROTECTED]>
Date: Mar 22, 2007 11:36 AM
Subject: question on forwarding engine in tinyos-2.x
To: tos 

Hi All,
I am using the forwarding engine from the collection tree frame work.

--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar <http://www-scf.usc.edu/%7Easridhar>

--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] question on forwarding engine in tinyos-2.x


Hi All,
I am using the forwarding engine from the collection tree frame work.

--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] warnings while compile with latest tinyos-2.x release

2007-01-04 Thread Avinash Sridharan


Thanks Phil,
 I just put the enable() in atomic section and the warnings went away.

regards,
Avinash

On 1/4/07, Philip Levis <[EMAIL PROTECTED]> wrote:


On Jan 4, 2007, at 11:00 AM, Avinash Sridharan wrote:

> Hi,
>  I just moved my code from the beta2 release of tinyOS-2.x to the
> latest release of tinyOS-2.x (Nov 6th). I got the following
> compilation warnings when I compiled my nesC app for the telosb
> platform.
>
> /opt/msp430/msp430/include/msp430/gpio.h:128: warning: non-atomic
> accesses to shared variable `P2IE':
> /home/asridhar/developement/sandbox/tinyos-2.x-t2/tos/chips/msp430/
> pins/HplMsp430InterruptP.nc:186: warning:   non-atomic r/w
>
>
> The compilation itself went through fine. I wanted to know the
> implication of these warnings and wether it would cause any race
> conditions while running the applications on Tmotes. I checked my
> msp430-gcc and msp430-libc installation and the versions are the
> same as the rpms given on the TinyOS-2.x installation website.
>

Hm. This is weird. I've never seen the issue before. I would
recommend calling enable() in an atomic section.

My guess is that almost every call to these functions is in an atomic
section, so you generally do not see this warning. The issue is that

x |= b;

is a read-modify-write.

Phil





--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] warnings while compile with latest tinyos-2.x release

2007-01-04 Thread Avinash Sridharan


Hi,
I just moved my code from the beta2 release of tinyOS-2.x to the latest
release of tinyOS-2.x (Nov 6th). I got the following compilation warnings
when I compiled my nesC app for the telosb platform.

/opt/msp430/msp430/include/msp430/gpio.h:128: warning: non-atomic accesses
to shared variable `P2IE':
/home/asridhar/developement/sandbox/tinyos-2.x-t2/tos/chips/msp430/pins/HplMsp430InterruptP.nc:186:
warning:   non-atomic r/w


The compilation itself went through fine. I wanted to know the implication
of these warnings and wether it would cause any race conditions while
running the applications on Tmotes. I checked my msp430-gcc and msp430-libc
installation and the versions are the same as the rpms given on the
TinyOS-2.x installation website.

Thanks and regards,
Avinash

--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] duration of sensing when CCA.get () called in tinyos-2.x

2006-11-08 Thread Avinash Sridharan

Hi All, I wanted to know as to what is the duration of sensing when using CC2420 when the CCA.get() is called in tinyOS-2.x. Is there any way to measure this ?Thanks,Avinash-- Phd Dept. of Electrical Engineering
University of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] C serial forwarder for tinyos-2.x beta2 on linux

2006-10-28 Thread Avinash Sridharan

Hi All,
 I am trying to compile the C serial forwarder for tinyos-2.x
beta2 on linux. I am using nesc-1.2.7.1a for compiling the serial
forwarder. I am getting the following errors when I try to compile it
from source

make  all-am
make[1]: Entering directory `/home/asridhar/developement/sandbox/beta2/tinyos-2.x/support/sdk/c'
if gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -MT
serialsource.o -MD -MP -MF ".deps/serialsource.Tpo" -c -o
serialsource.o serialsource.c; \
then mv -f ".deps/serialsource.Tpo" ".deps/serialsource.Po"; else rm -f ".deps/serialsource.Tpo"; exit 1; fi
serialsource.c:37: error: 'SERIAL_HDLC_FLAG_BYTE' undeclared here (not in a function)
serialsource.c:38: error: 'SERIAL_HDLC_CTLESC_BYTE' undeclared here (not in a function)
serialsource.c:40: error: 'SERIAL_SERIAL_PROTO_ACK' undeclared here (not in a function)
serialsource.c:41: error: 'SERIAL_SERIAL_PROTO_PACKET_ACK' undeclared here (not in a function)
serialsource.c:42: error: 'SERIAL_SERIAL_PROTO_PACKET_NOACK' undeclared here (not in a function)
serialsource.c:44: error: 'SERIAL_SERIAL_PROTO_PACKET_UNKNOWN' undeclared here (not in a function)
serialsource.c: In function 'serial_source_empty':
serialsource.c:441: warning: large integer implicitly truncated to unsigned type
serialsource.c: In function 'process_packet':
serialsource.c:609: warning: large integer implicitly truncated to
unsigned typeserialsource.c: In function 'read_serial_packet':
serialsource.c:633: warning: large integer implicitly truncated to unsigned typeserialsource.c: In function 'init_escaper':
serialsource.c:667: warning: large integer implicitly truncated to unsigned typeserialsource.c: In function 'terminate_escaper':
serialsource.c:674: warning: large integer implicitly truncated to unsigned typeserialsource.c: In function 'escape_byte':
serialsource.c:680: warning: comparison is always false due to limited range of data type
serialsource.c:680: warning: comparison is always false due to limited range of data type
serialsource.c:682: warning: large integer implicitly truncated to
unsigned typeserialsource.c: In function 'write_serial_packet':
serialsource.c:755: warning: large integer implicitly truncated to
unsigned typeserialsource.c:765: warning: large integer implicitly
truncated to unsigned typemake[1]: *** [serialsource.o] Error 1
make[1]: Leaving directory `/home/asridhar/developement/sandbox/beta2/tinyos-2.x/support/sdk/c'

I am not sure if I am missing some hearder files or I need to update to a new source tree ?

Thanks,
Avinash
-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] power control for CC2420 tinyos-2.x

2006-09-20 Thread Avinash Sridharan

Hi All, In order to power down the CC2420 is it enough to call
SplitControl.stop (implemented in CC2420CsmaP). I see that in the stop
command only the voltage regulator is stopped and not the oscillator. Is
it necessary to stop the oscillator as well to reduce the power consumption of the radio, or is turning off the voltage regulator enough?
Thanks,Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] powering down CC2420 in tinyos-2.x

2006-09-19 Thread Avinash Sridharan

Hi All, In order to power down the CC2420 is it enough to call SplitControl.stop (implemented in CC2420CsmaP). I see that in the stop command on the voltage regulator is stopped and not the oscillator. Is it necessary to stop the oscillator as well to power down the radio?
Thanks,Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] low power listening in tinyos-2.x for CC2420 ?

2006-09-13 Thread Avinash Sridharan

Thanks David for this info, I think it will be quiet useful for us.regards,AvinashOn 9/13/06, David Moss <
[EMAIL PROTECTED]> wrote:






I am 
in the final stages of implementing a CC2420 low power listening library for 
TinyOS 2.x.  I'm not intending it to be compliant with any kind of 
standard; instead, I want it to be functional.  This does not 
require long preambles, and does not require peer-to-peer 
synchronization.
 
Initial results on a tmote indicate 5.09 mAh/day at 2-second receive 
check intervals.  This will probably get 
lower.
 
Since 
it's not quite finished and I'm not sure if/when I'll contribute it, I'll 
explain how I have implemented this in case you want to try it 
yourself:
 
Summary: On the Rx end, it's a periodic channel energy check.  
On the Tx end, it's a repetitively transmitting message.
 
1. 
Edited CC2420TransmitP to provide a "CC2420Cca" interface that allows external 
components to sample the status of the CCA pin when the radio is on and not 
doing anything.  The "getCca()" command simply verifies the state is good 
to go, then sets the backoff timer to the CC2420_BACKOFF_PERIOD.  The 
backoff timer fires, ensuring the Rx mode has been set for enough symbol periods 
for the CCA pin to be valid, and then sends back the reading in an 
event.
 
2. 
Built a CC2420DutyCycle component that duty cycles the CC2420 radio on and 
off.  After the radio turns on, the CCA is checked three times in a 
row.  If one of these checks indicates that the channel is *not* clear, 
then someone is transmitting.  The radio is left on indefinitely at this 
level, only to be turned back off again by higher levels of this architecture 
after packets are done receiving.  If nobody is transmitting, turn the 
radio off immediately.  Total time the radio is on (in the current 
version): 3.7 ms from start to finish, but most of that time is spent at a 
lower power (<5mA) starting up the radio.
 
3. 
Built a low power listening module that provides send/receive interfaces and 
sits on top of the duty cycling component.  When low power listening is 
enabled, the duty cycling is turned on.  When a message is detected and 
received at this level, the message is passed up to the 
application level and leaves the radio on for a brief period of time in case 
other messages are coming.  If this time expires, the radio turns off and 
continues duty cycling.  Ideally, an ack is returned as 
well.
 
On the 
transmitting end, the send event in this LPL module actually retransmits 
the message over and over again up to the length of the duty cycle period, and 
adjusts the backoff period to be very short so there is not much space between 
messages.  If an ack is heard, it quits transmitting early (an advantage 
over the long preamble method!) and signals sendDone. Otherwise, sendDone 
gets signaled after the duty period expires.
 
 
There 
you have it, low power CC2420 duty cycling, very similar to 
CC1000's BMAC.  
 
The 
new TinyOS 2.x CC1000 low power listening does energy checks on the channel as 
well, instead of preamble checks, only firing up the bias of the radio and 
leaving the rest of the radio off.  This receive check ("RSSI Pulse Check") 
scheme does not require long preambles if your message (with short 
preambles) is being sent over and over again for a full receive 
period.  By sending repeating messages, you can also cut the 
transmission length short if you receive an ack in the middle, saving 
on Tx energy and decreasing transmission latency.  I've tested 
this.
 
-david
 

  
  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]] On Behalf Of Diego 
  Bartolomé ArquilloSent: Wednesday, September 13, 2006 8:24 
  AMTo: [EMAIL PROTECTED]
Cc: 
  tinyos-help@Millennium.Berkeley.EDUSubject: RE: [Tinyos-help] low 
  power listening in tinyos-2.x for CC2420 ?
  Hi Avinash,
  Low power listening have not sense using CC2420 because 
  this chip is compliant with the standard IEEE 802.15.4. This standard defines 
  a 4 bytes preamble length and LPL needs a long preamble in order to work 
  properly. The CC1000 is not compliant with 802.15.4 and allows you to 
  change the preamble length. When you send a packet using LPL, a long preamble 
  is transmitted. The recipient of the packet is idle and periodically it scans 
  the channel to look for a packet. If the preamble and the period are adapted, 
  the recipient can receive the useful information of the 
  packet.
  Best 
  regards,
  Diego

  
  
  De: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]] En nombre de 
  Avinash SridharanEnviado el: miércoles, 13 de septiembre de 
  2006 2:35Para: tosAsunto: [Tinyos-help] low power 
  listening in tinyos-2.x for CC2420 ?
  Hi, I am working with the tmote sky platform and running 
  tinyos-2.x (beta 2) on it. I wanted to check with the community if there is 
  low power listening support existing for CC2420 based platforms in tinyos-2.x. 
  Low power listening was introduced

[Tinyos-help] low power listening in tinyos-2.x for CC2420 ?

2006-09-12 Thread Avinash Sridharan

Hi, I am working with the tmote sky platform and running tinyos-2.x (beta 2) on it. I wanted to check with the community if there is low power listening support existing for CC2420 based platforms in tinyos-2.x. Low power listening was introduced as BMAC by Joe Polaster in 
tinyos-1.x for the CC1000 chips, but I could not find reference implementations of BMAC for CC2420 in tinyOS-2.x. Also if BMAC is not available for tinyOS-2.x (atleast in the near future) is it available as part of the Boomerang distribution.
Thanks,Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] problems installing msp430tools-base for tinyos-2.x on cygwin

2006-08-29 Thread Avinash Sridharan

Hi All, Trying to install the msp430tools-base on cygwin from tinyos-2.x beta2, but when I issue the commandrpm -i msp430tools-base-0.1-20050607.cygwin.i386.rpmit cribs giving the following error :error: Failed dependencies:
    /bin/sh is needed by msp430tools-base-0.1-20050607Is there another rpm I could download and install or a fix to the above problem ?Thanks,Avinash-- Phd Dept. of Electrical Engineering
University of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Fwd: problems with using block storage at high data rate in tinyos-2.x beta2

2006-08-09 Thread Avinash Sridharan

Hi All, Resending this mail for peoples attention.regards,Avinash-- Forwarded message --From: Avinash Sridharan <
[EMAIL PROTECTED]>Date: Aug 7, 2006 10:55 AMSubject: problems with using block storage at high data rate in tinyos-2.x beta2To: tos <tinyos-help@millennium.berkeley.edu
>Hi All, I was having problems using the block storage device when I am using it to log data at high data rates. The settings for the CSMA are , the initial backoff is between 0-10ms and the congestion backoff is 0-3ms. I am using the
tmote sky platform for my experiments. The logic I am using to use the block storage device is as follows:a> I have a buffer of size 10, with each element of 22 bytes. When ever I have to log data (an element of size 22 bytes) I log it to this buffer. Once I have sotred 10 elements in the buffer I call the
BlockWrite.write command.b> After 10 such writes I call commit, so I am commiting 22*10*10 bytes of data.Now the experiment I am running generates a constant packet rate data, I am generating a packet by firing a fixed size timer. The packet is logged whenever it is sent out into the air. I am generating data with timer sizes of 10ms, 11ms, 12ms,13ms, 15ms and 20ms.
The Problem: Due to contention at high data rates (when the timer size is close to 10ms) there is queueing taking place at the sender and the logging is also happening at a very fast rate. It turns out that at such a high rate when the commit call is made it blocks and does not return. It seems at these high data rates tinyos deadlocks and is not able to execute any other code.
More specifically I can observe this behavior at rates of 10ms and 11ms, as I go to lower rates the applications works fine. Also this behavior is erratic in the sense there are times when the logging at 10ms and 11ms works fine without blocking.
To test that the application has deadlocked and has not crashed, once I see that the application has been deadlocked (I know this since the application has to send a total of 5000 packets out if it has sent less than this many packets I assume there is a problem), I do a read on the flash (around 10 lines of data) and immediately the application starts sending out the remaining number of packets to the forwarding node.
Further I tried changing the initial backoff window to 3ms and the congestion backoffwindow also to 3ms, now my application is able to work easily at rates of 10ms and above but it starts failing close to 8ms.

Questions: a> Could somebody clarify the deadlock behavior I am observing ( Or if it is even deadlock) and if someone else has observed this behavior ?b> Are there some performance measures as to how fast and how much data can we write and commit on the block storage device ? This will help define the capacity of the system better.
PS: The problem is with the logging, since when I turn off my logger component, the application is able to run comfortable to datarates with fixed timer sizes close to 8ms without problems.regards,

Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern California
http://www-scf.usc.edu/~asridhar

-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] problems with using block storage at high data rate in tinyos-2.x beta2

2006-08-07 Thread Avinash Sridharan

Hi All, I was having problems using the block storage device when I am using it to log data at high data rates. The settings for the CSMA are , the initial backoff is between 0-10ms and the congestion backoff is 0-3ms. I am using the
tmote sky platform for my experiments. The logic I am using to use the block storage device is as follows:a> I have a buffer of size 10, with each element of 22 bytes. When ever I have to log data (an element of size 22 bytes) I log it to this buffer. Once I have sotred 10 elements in the buffer I call the
BlockWrite.write command.b> After 10 such writes I call commit, so I am commiting 22*10*10 bytes of data.Now the experiment I am running generates a constant packet rate data, I am generating a packet by firing a fixed size timer. The packet is logged whenever it is sent out into the air. I am generating data with timer sizes of 10ms, 11ms, 12ms,13ms, 15ms and 20ms.
The Problem: Due to contention at high data rates (when the timer size is close to 10ms) there is queueing taking place at the sender and the logging is also happening at a very fast rate. It turns out that at such a high rate when the commit call is made it blocks and does not return. It seems at these high data rates tinyos deadlocks and is not able to execute any other code.
More specifically I can observe this behavior at rates of 10ms and 11ms, as I go to lower rates the applications works fine. Also this behavior is erratic in the sense there are times when the logging at 10ms and 11ms works fine without blocking.
To test that the application has deadlocked and has not crashed, once I see that the application has been deadlocked (I know this since the application has to send a total of 5000 packets out if it has sent less than this many packets I assume there is a problem), I do a read on the flash (around 10 lines of data) and immediately the application starts sending out the remaining number of packets to the forwarding node.
Further I tried changing the initial backoff window to 3ms and the congestion backoffwindow also to 3ms, now my application is able to work easily at rates of 10ms and above but it starts failing close to 8ms.
Questions: a> Could somebody clarify the deadlock behavior I am observing ( Or if it is even deadlock) and if someone else has observed this behavior ?b> Are there some performance measures as to how fast and how much data can we write and commit on the block storage device ? This will help define the capacity of the system better.
PS: The problem is with the logging, since when I turn off my logger component, the application is able to run comfortable to datarates with fixed timer sizes close to 8ms without problems.regards,
Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] tinyos-2.x CSMA transmit timestamping CC2420

2006-07-20 Thread Avinash Sridharan

Hi Phil, If the time is a free running counter of a 32khz clock won't it overflow since its just a 16bit counter ?-AvinashOn 7/20/06, Philip Levis
 <[EMAIL PROTECTED]> wrote:On Jul 20, 2006, at 2:25 PM, Avinash Sridharan wrote:
> Hi All,>  I had a question on the timestamping of the packets when the 2.x> CSMA transmits a packet in the CC2420 stack. When going through the> code for CC2420CsmaTransmitP.nc, I realised that when the
> CaptureSFD event is called and the state is set to S_SFD the time> retrieved in this captured event is set into the sent packet. Now> before sending out the packet a call is made to> TimeStamp.transmittedSFD
 with the time of the CaptureSFD event. Now> the TimeStamp.transmittedSFD code is empty implying that whatever> was the CaptureSFD event time is actually set on the packet itself.>>  The time in the CaptureSFD event is a 16 bit value so I am
> assuming it cannot be capturing the 32Khz clock of the MSP430 timer> (I am using tmotes), so what does this value actually represent ?> Does it represent the time from the point the transmit request was
> made in which case the timestamping code should add this time to> the current time (obtained from the local clock) and put in the> packet metadata?Jonathan, please correct me if I'm wrong...
The SFD is when the radio actually sends the packet. The time is thefree-running counter of the 32khz clock. I believe the code is emptybecause the packet metadata and their mechanisms haven't been nailed
down yet.Phil-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] tinyos-2.x CSMA transmit timestamping CC2420

2006-07-20 Thread Avinash Sridharan

Hi All, I had a question on the timestamping of the packets when the 2.x CSMA transmits a packet in the CC2420 stack. When going through the code for CC2420CsmaTransmitP.nc, I realised that when the CaptureSFD event is called and the state is set to S_SFD the time retrieved in this captured event is set into the sent packet. Now before sending out the packet a call is made to 
TimeStamp.transmittedSFD with the time of the CaptureSFD event. Now the TimeStamp.transmittedSFD code is empty implying that whatever was the CaptureSFD event time is actually set on the packet itself. The time in the CaptureSFD event is a 16 bit value so I am assuming it cannot be capturing the 32Khz clock of the MSP430 timer (I am using tmotes), so what does this value actually represent ? Does it represent the time from the point the transmit request was made in which case the timestamping code should add this time to the current time (obtained from the local clock) and put in the packet metadata?
Thanks and regards,Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] starting and stopping tmotes on FC4

2006-07-18 Thread Avinash Sridharan

Hi, I am working with tinyos-2.x on tmotes on FC4.  These tmotes are connected to my linux machine through a USB hub so as long as the USB interface doesn't hang it is quiet convenient to program and reprogram these motes.
 There are times however due to segfaults in my code or due to simulataneous operations that my scripts perform on the USB interface (e.g reading from the flash while accidentaly programming the motes) that the USB serial interface hangs. 
My question was, is there any mechanism where I can restart these serial interfaces (/dev/ttyUSB*) through software (probably a script in linux that does this) or is it only possible to restart the USB device by unplugging and plugging the motes back in.
Thanks,Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] question about the tinyos 2.x CC2420 CSMATransmit implementation

2006-07-16 Thread Avinash Sridharan

In 2.x I think the setting of the ack to TRUE or FALSE happens by default. As Phil mentioned you can look at the result of the field using the packet acknowledged interface.On 7/16/06, 
Michael Schippling <[EMAIL PROTECTED]> wrote:
addenda...In v1.x, if you have enableAck()ed, sendDone() will wait forthe ACK or timeout and set the msgptr->ack phantom-phield to TRUE orFALSE as appropriate. I assume it's the same in 2.x...MSPhilip Levis wrote:
> On Jul 16, 2006, at 2:57 PM, Avinash Sridharan wrote:>>> Hi All,>>  I had a question on the return value of the send interface. The>> signal sendDone (called after the send command on the AMSend is
>> called) returns an error value. The error value is SUCCESS when the>> packet is sent on the air. It returns a failure if the stack was not>> able to transmit the packet (even after multiple backoffs).
>>>>  My question is that whenever a packet is sent the stack waits for the>> ACK before signalling a SUCCESS. If the ACK is not received received>> than does it return a FAILURE  or since the packet has been
>> successfully sent after a certain period of time it just returns>> SUCCESS ?>>>> The error_t on sendDone denotes sending, not reception success. There> are situations when a stack can accept a send but then not be able to
> service it (e.g., you turn off the radio before it can send). In these> situations, it signals sendDone with a FAIL.>> You can request and check for packet acknowledgments with the> PacketAcknowledgments interface.
>> Phil>> ___> Tinyos-help mailing list> Tinyos-help@Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help-- Phd Dept. of Electrical Engineering
University of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] question about the tinyos 2.x CC2420 CSMATransmit implementation

2006-07-16 Thread Avinash Sridharan

Hi All, I had a question on the return value of the send interface. The signal sendDone (called after the send command on the AMSend is called) returns an error value. The error value is SUCCESS when the packet is sent on the air. It returns a failure if the stack was not able to transmit the packet (even after multiple backoffs). 
 My question is that whenever a packet is sent the stack waits for the ACK before signalling a SUCCESS. If the ACK is not received received than does it return a FAILURE  or since the packet has been successfully sent after a certain period of time it just returns SUCCESS ? 
Thanks,Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] c serial forwarder in tinyos-2.x

2006-07-04 Thread Avinash Sridharan

The ncc --version output is :ncc: 1.2
nescc: 1.2.2
gcc: gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Output of make:
mig -o serialpacket.h -c-prefix=spacket c
/home/asridhar/developement/sandbox/latest/tinyos-2.x//tos/lib/serial/Serial.h
serial_packet
gcc: unrecognized option '-c-prefix=spacket'
warning: Cannot determine AM type for serial_packet
 (Looking for definition of AM_SERIAL_PACKET)
Unknown tool c
make: *** [serialpacket.h] Error 2


Thanks and regards,
AvinashOn 7/4/06, Philip Levis <[EMAIL PROTECTED]
> wrote:
On Jul 4, 2006, at 3:12 PM, Avinash Sridharan wrote:> Hi All,>  In order to compile the latest c serial forwarder in tinyos-2.x> what is the version of nesc(mig) that is required. I believe I have
> nesc 1.2.2 and hence this might be causing a problem with the> compilation ?>Can you send the error you see as well as the result of 'ncc --version'?Phil

-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] c serial forwarder in tinyos-2.x

2006-07-04 Thread Avinash Sridharan

Hi All, In order to compile the latest c serial forwarder in tinyos-2.x what is the version of nesc(mig) that is required. I believe I have nesc 1.2.2 and hence this might be causing a problem with the compilation ?
Thanks and regards,Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Obtaining microsecond timestamps in TinyOS 2

2006-06-26 Thread Avinash Sridharan

:) I apologize didn't pay attention to the granularity of the timestamp desired hereOn 6/26/06, David Gay <[EMAIL PROTECTED]
> wrote:On 6/26/06, Avinash Sridharan <
[EMAIL PROTECTED]> wrote:> Just checking ... in tinyos-2.x the msp430 chipset has a Counter32KhzC> component that implements the LocalTime interface which in turn returns a 32> bit clock value. So in the tmotes and the telosb we should be able to get
> microsecond accuracy clock readings with this component right ?No, that clock runs in units of 1/32768s, i.e. ~30.5 uS. It doescontinue running while the mote is asleep, though...David Gay
-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Obtaining microsecond timestamps in TinyOS 2

2006-06-26 Thread Avinash Sridharan

Just checking ... in tinyos-2.x the msp430 chipset has a Counter32KhzC component that implements the LocalTime interface which in turn returns a 32 bit clock value. So in the tmotes and the telosb we should be able to get microsecond accuracy clock readings with this component right ?
Thanks,AvinashOn 6/26/06, David Gay <[EMAIL PROTECTED]> wrote:
On 6/25/06, Philip Levis <[EMAIL PROTECTED]> wrote:> On Jun 25, 2006, at 5:38 PM, Ajit Mylavarapu wrote:>> > I was wondering how to obtain microsecond accurate timestamps in
> > TinyOS 2. We want to find out the accuracy of our synchronization> > scheme. I went through the TinyOS help archives. A couple of posts> > talk about using the LocalTimeMicroC component, but that is available
> > only in TinyOS 1.1 I think. How do we get timestamps with microsecond> > accuracy is TinyOS2?> >> > Or is the only way out to start an Alarm (TMicro) and count the ticks?>
> On the Telos, you can use Msp430CounterMicroC. If you want more than> 16 bits of granularity, then you'll need to do a conversion, or keep> a CounterMilli around.Or use the TransformCounterC generic component to make a 32-bit
counter out of a 16-bit one.One thing to note: I believe that the 1MHz counter stops countingwhile the microcontroller is in sleep mode. So it won't be countingreal time except if you prevent the mote from sleeping.
David Gay___Tinyos-help mailing listTinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help-- Phd Dept. of Electrical EngineeringUniversity of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] release date for beta2 tinyos-2.x ?

2006-06-22 Thread Avinash Sridharan

Hi All, Is there a time line that is already in place for tinyos-2.x releases ? I just wanted to know if there has been any date that was set for the tinyos-2.x beta2 release? Eagerly awaiting for all the features incorporated in this release.
Thanks and regards,Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern California
http://www-scf.usc.edu/~asridhar

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] getting the source address from message_t in tinyos-2.x

2006-06-18 Thread Avinash Sridharan

That makes sense. I didn't realise that mica2 didn't have the source in
its message stack. But there is also a CC2420Packet interface very
specific to the CC2420 radios, shouldn't that atleast provide this
functionality ?

Thanks and regards,
AvinashOn 6/18/06, Philip Levis <[EMAIL PROTECTED]> wrote:
On Jun 15, 2006, at 11:22 AM, Avinash Sridharan wrote:> Hi All,>  I was going through the various interfaces provided in tinyos-2.x> AMPacket,AMSend, Receive and in any of these interfaces I was not
> able to find a command that could return the source of a given> message. In AMPacket we have the ability to get the destination but> no the source.>> Is it that there is no way to retrieve the source of a message from
> the packet ? Currently I have to send the source as part of the> payload. If I could retrieve it directly from the message I could> save valuable bytes in the payload.Except that in the mica2 stack, there is no source address.
Phil-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] getting the source address from message_t in tinyos-2.x

2006-06-15 Thread Avinash Sridharan

Hi All,
 I was going through the various interfaces provided in tinyos-2.x
AMPacket,AMSend, Receive and in any of these interfaces I was not able
to find a command that could return the source of a given message. In
AMPacket we have the ability to get the destination but no the source. 

Is it that there is no way to retrieve the source of a message from the
packet ? Currently I have to send the source as part of the payload. If
I could retrieve it directly from the message I could save valuable
bytes in the payload.

Thanks for the help,
Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] tinyos-2.x TOSSIM with gdb?

2006-06-15 Thread Avinash Sridharan

>From the cvs you need to get the code from the branch with label
tinyos-2_0_devel-BRANCH. And you should find the tutorial under
docs/html/tutorial/lesson-t.html. 
  Although I am not sure how stable this branch is since it is the
dev branch for tinyos-2.x . You could work of the beta-rel3 branch and
get the tutorial from the dev branch.

Thanks,
AvinashOn 6/15/06, Liu Haibin <[EMAIL PROTECTED]> wrote:
If you download the latest code from the dev branch of 
tinyos-2.x. You should find a 
Where can I find the latest
code? Is the rpm the latest code, or any code on cvs. I found no
tinyos-2.x code on the sourceforge cvs server.

tutorial under tinyos-2.x/docs/html/tutorial/lesson-t.html. Not sure if this tutorial is I installed the rpm but could not find any relevant doc. However I found some tinyos-2.x
 doc at 
http://www.tinyos.net/tinyos-2.x/doc/html/tutorial/lesson[1-5].html but none of them talks about tossim. Any idea where I can find the doc you referred to?Regards,
Haibin

-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] tinyos-2.x TOSSIM with gdb?

2006-06-15 Thread Avinash Sridharan

If you download the latest code from the dev branch of tinyos-2.x. You should find a tutorial under tinyos-2.x/docs/html/tutorial/lesson-t.html. Not sure if this tutorial is complete at this point. But it has the specifics to give you an insight into how to use TOSSIM to run with python scripts.
 I am not sure how to use gdb with TOSSIM-2.x as yet though.-AvinashOn 6/15/06, Cormac Duffy <[EMAIL PROTECTED]
> wrote:dont understand how tossim is working yet,the best I can work out is that you compile with
make micaz simand in the ./build/micaz/ directory are some object files, and a fewpython files in the application directory.is it possible to use the new tossim with gdb? so i can step though app
and find problems with code before uploading??is there any documentation written on the subject yet? (i appreciatetinyos2.x is still in beta stage)found an old help digest> There is no TinyViz in 
2.0; TOSSIM, however, is briefly introduced ina> tutorial. The high-level difference is that TOSSIM in 2.0 is a Python> interpreter, so you can script simulations:>> 
http://cvs.sourceforge.net/viewcvs.py/*checkout*/tinyos/tinyos-2.x/doc/html/tutorial/Attic/lesson-t.html?rev=1.1.2.6>> Philbut that link doesnt work for me.all the bestCormac___
Tinyos-help mailing listTinyos-help@Millennium.Berkeley.EDUhttps://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] using flash in tinyos-2.x

2006-05-30 Thread Avinash Sridharan

You should be able to find a reference implementation under tinyos-2.x/apps/tests/storage. There seem to be quiet a few reference implementations.
 
-Avinash 
On 5/30/06, Manju <[EMAIL PROTECTED]> wrote:
Hi,I am working on tinyos-2_0_devel-BRANCH and telosb motes. I was tryingto read and write from the STM25P80 flash on telosb motes.
However, I realized that most of the interfaces as defined TEP103 hasnot been implemented (or even specified in interfaces/* directory). :(By browsing the tinyos-help achieves, I understand that Flash
(tos/lib/Flash) is pretty well supported on tinyos-1.x. However, Istarted working with TinyOS only with 2.x version and I am notfamiliar with tinyos-1.x.Questions:1 Is there any code, supporting reading and writing of flash in
tinyos-2.x for telosb motes?2) Is there a simulator type of support for flash (either separatelyor in TOSSIM), which would allow me to test my code of reading andwriting to flash, without actually using a mote (like telosb or
mica2)?3) How easy or difficult would it be to port the flash support forSTM25P80 to tinyos-2.x code base?Any help or suggestion would be greatly appreciatedThanks,Manju___
Tinyos-help mailing listTinyos-help@Millennium.Berkeley.EDUhttps://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar 
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Re: problem with serial comm on latest dev branch for tmote tinyos-2.x

2006-05-19 Thread Avinash Sridharan

Just to add to my observation, when I use the 'C' SerialForwarder and
send a command to the mote to read from the flash, I get the the
following error message :

Note: sync

I am not sure what this error message means in the context of the serial communication ?

Thanks,
Avinash
On 5/18/06, Avinash Sridharan <[EMAIL PROTECTED]> wrote:
Hi, I updated my tinyos-2.x dev branch a few days back. I
was trying to compile an application which reads data of the flash of a
tmote or micaz  using the serial forwarder and a JAVA app (that I
wrote using mig).
  This application was running without any problem a while back (
I hadn't updated my code for a while :) ). When I tried compiling my
app with the new tree, I got the following warnings related to the
serial comm, on doing make 'telosb' although the compilation went
through fine.
nesc1: warning: calls to Usart.isTxEmpty in Msp430SpiNoDmaP$0 are uncombinednesc1: warning: calls to Usart.isSPI in Msp430SpiNoDmaP$0 are uncombinednesc1: warning: calls to Usart.isUARTrx in Msp430SpiNoDmaP$0 are uncombined
nesc1: warning: calls to Usart.isUART in Msp430SpiNoDmaP$0 are uncombinednesc1: warning: calls to Usart.isI2C in Msp430SpiNoDmaP$0 are uncombinednesc1: warning: calls to Usart.isUARTtx in Msp430SpiNoDmaP$0 are uncombined
nesc1: warning: calls to Usart.getMode in Msp430SpiNoDmaP$0 are uncombinednesc1: warning: calls to Usart.isTxIntrPending in Msp430SpiNoDmaP$0 are uncombinednesc1: warning: calls to Usart.rx in Msp430SpiNoDmaP$0 are uncombined
nesc1: warning: calls to Usart.isRxIntrPending in Msp430SpiNoDmaP$0 are uncombinedI
was able to load the binaries on to the tmote and was able to connect
to the tmote using the 'C' serial forwarder. But when I send a read
flash command from my machine through the serial forwarder to a tmote
connected on USB0, I think the tmote is not receiving the command.
Although the serial forwarder says it has written the packet correctly.
  My questions is are the warnings above an indication of
any problems with serial communication or should I be looking at some
place else. And if yes, could I get pointers to fix them ?Thanks and regards,
Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern California
http://www-scf.usc.edu/~asridhar

-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] problem with serial comm on latest dev branch for tmote tinyos-2.x

2006-05-18 Thread Avinash Sridharan

Hi, I updated my tinyos-2.x dev branch a few days back. I was trying to compile an application which reads data of the flash of a tmote or micaz  using the serial forwarder and a JAVA app (that I wrote using mig).
  This application was running without any problem a while back ( I hadn't updated my code for a while :) ). When I tried compiling my app with the new tree, I got the following warnings related to the serial comm, on doing make 'telosb' although the compilation went through fine.
nesc1: warning: calls to Usart.isTxEmpty in Msp430SpiNoDmaP$0 are uncombinednesc1: warning: calls to Usart.isSPI in Msp430SpiNoDmaP$0 are uncombinednesc1: warning: calls to Usart.isUARTrx in Msp430SpiNoDmaP$0 are uncombined
nesc1: warning: calls to Usart.isUART in Msp430SpiNoDmaP$0 are uncombinednesc1: warning: calls to Usart.isI2C in Msp430SpiNoDmaP$0 are uncombinednesc1: warning: calls to Usart.isUARTtx in Msp430SpiNoDmaP$0 are uncombined
nesc1: warning: calls to Usart.getMode in Msp430SpiNoDmaP$0 are uncombinednesc1: warning: calls to Usart.isTxIntrPending in Msp430SpiNoDmaP$0 are uncombinednesc1: warning: calls to Usart.rx in Msp430SpiNoDmaP$0 are uncombined
nesc1: warning: calls to Usart.isRxIntrPending in Msp430SpiNoDmaP$0 are uncombinedI was able to load the binaries on to the tmote and was able to connect to the tmote using the 'C' serial forwarder. But when I send a read flash command from my machine through the serial forwarder to a tmote connected on USB0, I think the tmote is not receiving the command. Although the serial forwarder says it has written the packet correctly.
  My questions is are the warnings above an indication of any problems with serial communication or should I be looking at some place else. And if yes, could I get pointers to fix them ?Thanks and regards,
Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Re: LQI and probability of packet loss

2006-05-10 Thread Avinash Sridharan

Hi Venkat/Rob, To the best of my knowledge attleast in tinyos-1.x the default radio model (not sure how you can replace this in 1.x) the input is link PRR's. That is you can use experimental data or use an analytical model to generate link PRR's for your topology (for 
e.g. use lossy builder) and give this as an input to to TOSSIM-1.x. Hence the simulation has no notion of power. However in TOSSIM-2.x the radio model uses the notion of link gains to emulate packet losses and hence 
2.x might actually might be able to get singal strength as part of the message.-AvinashOn 5/10/06, Robert Szewczyk <
[EMAIL PROTECTED]> wrote:Perhaps one of the TOSSIM experts will weigh in here; I believe this
is totally dependent on the radio model used by TOSSIM.  I am not besuprised that the default radio model produces 0 RSSI.  Doing thisanalysis on the motes will give you real data, otherwise you'rebasically munging through someone else's experiments that generated
the TOSSIM models.RobOn 5/10/06, Venkat Manoj <[EMAIL PROTECTED]> wrote:>>> Hey Rob,>> Can't I get the RSSI value too in TOSSIM? When I try to access the RSSI
> value (strength) in TOSSIM, I get a 0 everytime. Is doing the analysis on> the motes the only way to get the RSSI and packet loss curve?>> Thanks,> Venkat.>>> - Original Message 
> From: Robert Szewczyk <[EMAIL PROTECTED]>> To: Venkat Manoj <[EMAIL PROTECTED]>> Cc: Prabal Dutta <
[EMAIL PROTECTED]>; tos> > Sent: Wednesday, May 10, 2006 2:04:09 AM
> Subject: Re: [Tinyos-help] Re: LQI and probability of packet loss lqi exists only on certain platforms (I believe it applies to Telos> and Tmote Sky, and probably MicaZ).  lqi will not exists in TOSSIM or
> in mica/mica2 motes.>> Note that RSSI value can be accessed via> Msg->strength>> Cheers>> Rob>> On 5/9/06, Venkat Manoj <
[EMAIL PROTECTED]> wrote:> >> >> > Guys,> >> > How can I get the LQI values? When I use this line in the code...> >> > TOS_MsgPtr Msg;> > a_variable = Msg->lqi;
> >> > I get an error saying that there is no member named lqi. So how is it> > possible for me to get the LQI and RSSI values?> >> > Thanks,> > Venkat.> >
> >> > - Original Message > > From: Prabal Dutta <[EMAIL PROTECTED]>> > To: [EMAIL PROTECTED]
> > Cc: tos > > Sent: Wednesday, May 10, 2006 1:35:51 AM> > Subject: [Tinyos-help] Re: LQI and probability of packet loss
> >> >> >> > Joe,> >> > There's nothing that I claim in this thread which you can't divine> > from the data in your Telos paper, although it's not presented in that
> > paper in way that clearly conveys it, or by reading Levis and> > student's paper.  Or, talk with Rob, he appears to agree.  The> > compelling data is out there already.  Just look at.
> >> > I'm sure you can think of a couple of reasons why we might not be> > ready to release our data/results yet.  Use your imagination.> >> > - Prabal> >> > On 5/9/06, Joe Polastre <
[EMAIL PROTECTED]> wrote:> > > What is preventing the release of your data? Levis and his student> > > have a paper already available in emnets, my paper was out last year,
> > > so why can't you release your data? they're called technical reports> > > for a reason.> > >> > > bottom line--you need to show compelling data to be taken seriously.
> > >> > > -Joe> > >> > > On 5/9/06, Prabal Dutta <[EMAIL PROTECTED]> wrote:> > > > Joe,> > > >
> > > > This discussion isn't about translating the paper's results to an open> > > > air environment.  It's about what PRR vs RSSI and PRR vs LQI looks> > > > like.  The mental exercise is visualizing that from the PRR vs
> > > > Distance, RSSI vs Distance, and LQI vs Distance data in the paper.> > > > It's not impossible but its not immediately obvious to the casual> > > > observer.> > > >
> > > > As I wrote in my earlier e-mail, we're not yet ready to release our> > > > findings, but we will in due time.> > > >> > > > - Prabal> > > >
> > > > On 5/9/06, Joe Polastre <[EMAIL PROTECTED]> wrote:> > > > > all of the variables were measured at the same time--lqi and rssi.
> it> > > > > does not take a mental leap to understand the findings in an open> air> > > > > environment.> > > > >> > > > > prabal, I would be extremely enthusiastic to review your real world
> > > > > data on this topic. please send your studies to the list as I> believe> > > > > we all could profoundly benefit from the data behind your opinions.> > > > >
> > > > > -Joe> > > > >> > > > > On 5/9/06, Prabal Dutta <[EMAIL PROTECTED]> wrote:> > > > > > The Telos graphs are nice in that they show the relationship
> between> > > > > > some of these variables but some mental gymnastics are required to> > > > > > make the leap from what's shown to PRR vs RSSI and PRR vs LQI.> And,
> > > > > > given the variances involved, I'm not sure that everyone would> come> > to> > > > > > the same conclusion.> > > > > >> > > > > > I would argue that from a PRR, RSSI, and LQI perspective, distance
> > is> > > > > >

[Tinyos-help] question on serialforwarder for 1.x and 2.x

2006-05-06 Thread Avinash Sridharan

Hi All,
 Would the serialforwarder for 1.x work with base station for 2.x.
Also if I have generated JAVA classes for the 2.x serial forwarder
using mig for 2.x can my JAVA app communicate with the 1.x serial
forwarder ? Basically what are the backward compatability issues
between 1.x and 2.x  (my questions are specific to the JAVA tool
chains, but if someone has a more general comment would be more than
willing to hear that as well ).

Thanks,
Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Is Deluge available for tinyos-2.x

2006-05-02 Thread Avinash Sridharan

Hi All, Is deluge available for tinyos-2.x ? If not could someone give pointers as to how this could be done ?Thanks and regards,Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] TOSSIM-2.x is a packet level simulator or a bit-level simulator ?

2006-04-20 Thread Avinash Sridharan

TOSSIM-2.x is a packet level simulator. I don't think TOSSIM-2.x emulates the serial interface. However if you want to inject packets into your network you can use the mig interface to generate a python class for your data packets and than use this to simulate the injection of packets into any node in your network using the TOSSIM python API's.
  To retrieve the data just print out dbg statements to a particular channel and print it out to screen or write it to a file.-AvinashOn 4/20/06, 
swim_in_sky <[EMAIL PROTECTED]> wrote:







Hi, 
   I think TOSSIM-1.x is a bit-level simulator . But 
the dynamics of  TOSSIM-2.x 
are quiet different from TOSSIM-1.x . The 
 TOSSIM-2.x  looks like  a  packet 
level simulator rather than  a bit-level 
simulator . 
  If the TOSSIM-2.x is a packet level simulator,how we 
use TOSSIM-2.x to simulate the 
serial communication whose  lowest component " 
Raw 
UARTC " provides a byte-level interface ?
 Thanks 
 
___Tinyos-help mailing listTinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] intel mote 2

2006-04-18 Thread Avinash Sridharan

Hi All,
 I am not sure wether this is the right forum to be posting this
question (and hence apologize if I end up spamming ), but I wanted to
get information on buying the new intel mote 2 platforms. I looked at
the intel research website for intel mote 2 but could find only the
prototypes. Are these available commericially ?
Thanks,
Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Re: tinyos-2.x for tmote sky

2006-03-31 Thread Avinash Sridharan

Hi All,
 This got resolved. I realized that the HIL layer in tinyos-2.x
does away with all the complexity of specific byte aligned code for
micaz and telosb. I was originally using the native uint16_t,uint8_t
and uint32_t declarations, after  looking at a few examples
replaced all these with nx_uint8_t,nx_uint16_t and nx_uint32_t. That
got it working. 
  I tmotes are talking to each other and it seems to the micaz platforms as well.

Thanks,
AvinashOn 3/30/06, Avinash Sridharan <[EMAIL PROTECTED]> wrote:
Hi All,
 I have the tinyos-2.x beta release 3 and I am trying to run the
tmote sky's on them. I am able to receive the data packets from micaz's
and also interpret the data in the tmote sky's but when I am trying to
send data packets out of the tmote sky the fields are being set to
zero. 
 Do I need to get the latest out of the developement branch.

Thanks,
Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern California
http://www-scf.usc.edu/~asridhar

-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] tinyos-2.x for tmote sky

2006-03-30 Thread Avinash Sridharan

Hi All,
 I have the tinyos-2.x beta release 3 and I am trying to run the
tmote sky's on them. I am able to receive the data packets from micaz's
and also interpret the data in the tmote sky's but when I am trying to
send data packets out of the tmote sky the fields are being set to
zero. 
 Do I need to get the latest out of the developement branch.

Thanks,
Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Serialforwarder not coming up on linux (tinyos-2.x)

2006-03-29 Thread Avinash Sridharan

Hi All,
 I am trying to get the serial forwarder up on linux. I have the
libgetenv.so in the tools directory. I copied it to the /usr/lib and
/usr/local/lib/tinyos folder. Still serial forwarder cribs about the
JNI library and quits. 
 I tried running the tos-install-jni scripts but it does not work,
since it uses the locate-jre script which in turn has outdated IBM
packages that are hardcoded because of which the script cannot find the
jni paths.

-Avinash -- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Fwd: [Tinyos-help] tinyos-2.x how is the CC2420Config interface exposed to higher layers in tinyOS-2.x

2006-03-26 Thread Avinash Sridharan

Hi, I saw a post by someone wanting to perform powercontrol on CC2420 in tinyOS-2.x and hence forwarding this mail. Jonthan had given me some pointers as to how it can be done with some of the code that he had checked in.
-Avinash-- Forwarded message --From: Jonathan Hui <[EMAIL PROTECTED]>Date: Mar 23, 2006 3:44 PM
Subject: Re: [Tinyos-help] tinyos-2.x how is the CC2420Config interface exposed to higher layers in tinyOS-2.xTo: [EMAIL PROTECTED]You need to explicitly wire to the CC2420PacketC interface in order to
get/set the transmit power for a specific packet. Once you've set thetransmission power, just send the packet and it will be sent with whatyou specified. The transmission power for that packet will stay the
same until you set it again. The default transmission power is fullpower (31), so if you've never called set() on a packet, it willdefault to that.I've included the relavant portion of the CC2420Packet interface so
that you can start writing some code.  /**   * Get transmission power setting for current packet.   *   * @param the message   */  async command uint8_t getPower( message_t* p_msg );
  /**   * Set transmission power for a given packet. Valid ranges are   * between 0 and 31.   *   * @param p_msg the message.   * @param power transmission power.   */  async command void setPower( message_t* p_msg, uint8_t power );
--Jonathan W. Hui[EMAIL PROTECTED]http://www.cs.berkeley.edu/~jwhui/On 3/23/06, Avinash Sridharan <
[EMAIL PROTECTED]> wrote:> Hi Jonathan,>   I guess it will take a while to get the CC2420Packet interface. Could you> describe to me meanwhile how can I use this interface ? Since currently I am
> just using the ActiveMessage and AMSender components. Do I need to> explicitly use the CC2420Packet component.>>  Thanks for all the help,>  regards,>>  Avinash>
> On 3/23/06, Jonathan Hui <[EMAIL PROTECTED]> wrote:> > Everything cc2420 related is in tos/chips/cc2420.> >> > --> > Jonathan W. Hui
> > [EMAIL PROTECTED]> > http://www.cs.berkeley.edu/~jwhui/> >> >> > On 3/23/06, Avinash Sridharan <
[EMAIL PROTECTED]> wrote:> > > Hi Jonathan,> > >   Where exactly can I find this interface ? under chips/cc2420 ? or> under
> > > micaz ? I just updated the CVS so not sure if I got your changes.> > >> > >  Thanks,> > >  Avinash> > >> > >> > > On 3/23/06, Jonathan Hui <
[EMAIL PROTECTED] > wrote:> > > > I've updated the tinyos-2.x cc2420 stack to support changing of> > > > transmission power. The 2.x method is different from 
1.x in that> > > > transmission power is specified on a per-packet basis using the> > > > CC2420Packet interface.> > > >> > > > Note: if you are on anonymous access with sourceforge, it may take up
> > > > to 24 hours to propagate the changes.> > > >> > > > --> > > > Jonathan W. Hui> > > > [EMAIL PROTECTED]
> > > > http://www.cs.berkeley.edu/~jwhui/> > > >> > > > On 3/23/06, Avinash Sridharan < 
[EMAIL PROTECTED]> wrote:> > > > > Hi All,> > > > >   I wanted to set the power of my radio dynamically (at runtime). I> > > figured> > > > > out that the 
CC2420Config.nc provides such an interface to set the> > > > > transmission power and it is implemented in CC2420ControlP.nc.> However I> > > am> > > > > not able to find any of the generic interfaces (that hide the
> hardware> > > > > specifics) in tinyOS-2.x that are are exposing the full> functionality of> > > > > CC2420Config.nc (that is the ability to set the tx power of the
> radios)> > > to> > > > > applications.> > > > >> > > > >Do I need to access the CC2420Control component directly to> perform> > > the
> > > > > above operation ?> > > > >> > > > >  Thanks,> > > > >  Avinash> > > > >> > > > > --> > > > > Phd Dept. of Electrical Engineering
> > > > > University of Southern California> > > > > http://www-scf.usc.edu/~asridhar> > > > > ___
> > > > > Tinyos-help mailing list> > > > > Tinyos-help@Millennium.Berkeley.EDU> > > > >> > >
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help> > > > >> > > > >
> > > > >> > > >> > >> > >> > >> > > --> > >> > > Phd Dept. of Electrical Engineering> > > University of Southern California
> > > http://www-scf.usc.edu/~asridhar> >>>>> -->> Phd Dept. of Electrical Engineering> University of Southern California
> http://www-scf.usc.edu/~asridhar-- Phd Dept. of Electrical EngineeringUniversity of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] tinyos-2.x how is the CC2420Config interface exposed to higher layers in tinyOS-2.x

2006-03-23 Thread Avinash Sridharan

Hi Jonathan,
 Where exactly can I find this interface ? under chips/cc2420 ? or
under micaz ? I just updated the CVS so not sure if I got your changes.

Thanks,
AvinashOn 3/23/06, Jonathan Hui <[EMAIL PROTECTED]> wrote:
I've updated the tinyos-2.x cc2420 stack to support changing oftransmission power. The 2.x method is different from 1.x in thattransmission power is specified on a per-packet basis using theCC2420Packet interface.
Note: if you are on anonymous access with sourceforge, it may take upto 24 hours to propagate the changes.--Jonathan W. Hui[EMAIL PROTECTED]
http://www.cs.berkeley.edu/~jwhui/On 3/23/06, Avinash Sridharan <[EMAIL PROTECTED]> wrote:> Hi All,>   I wanted to set the power of my radio dynamically (at runtime). I figured
> out that the CC2420Config.nc provides such an interface to set the> transmission power and it is implemented in CC2420ControlP.nc. However I am> not able to find any of the generic interfaces (that hide the hardware
> specifics) in tinyOS-2.x that are are exposing the full functionality of> CC2420Config.nc (that is the ability to set the tx power of the radios) to> applications.>>Do I need to access the CC2420Control component directly to perform the
> above operation ?>>  Thanks,>  Avinash>> --> Phd Dept. of Electrical Engineering> University of Southern California> 
http://www-scf.usc.edu/~asridhar> ___> Tinyos-help mailing list> Tinyos-help@Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help>>>
-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] tinyos-2.x how is the CC2420Config interface exposed to higher layers in tinyOS-2.x

2006-03-23 Thread Avinash Sridharan

Hi All,
 I wanted to set the power of my radio dynamically (at runtime). I
figured out that the CC2420Config.nc provides such an interface to set
the transmission power and it is implemented in CC2420ControlP.nc.
However I am not able to find any of the generic interfaces (that hide
the hardware specifics) in tinyOS-2.x that are are exposing the full
functionality of CC2420Config.nc (that is the ability to set the tx
power of the radios) to applications.

  Do I need to access the CC2420Control component directly to perform the above operation ?

Thanks,
Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] writting into EEPROM micaz's tinyos-2.x and setting radio power levels

2006-03-22 Thread Avinash Sridharan

Hi All,
 We have started using tinyos-2.x. There are not too many examples
around, so would be grateful if some one could post a few examples of
how to use the EEPROM on micaz's and also to set power levels on micaz
under tinyos-2.x.

Thanks and regards,
Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Re: your views of running TOSSIM with ~500 nodes

2006-03-10 Thread Avinash Sridharan

Hi Phil, That fix works, I am trying to push the simulation to around 990 nodes :) seems to be working. Will see how the results come out and will keep you posted on this.Thanks again for all the help,regards,
AvinashOn 3/10/06, Avinash Sridharan <[EMAIL PROTECTED]> wrote:
Hi Phil, Again thanks a lot. I think thats the behaviour I am observing. The minute I step beyond 100 the simulation segfaults at boot up. Will try the fix and get back to you.Thanks,
Avinash
On 3/10/06, Philip Levis <[EMAIL PROTECTED]> wrote:

On Mar 9, 2006, at 7:21 PM, Avinash Sridharan wrote:> Hi Phil,>>There's a bug in the beta that prevents you from simulating more than100 nodes. It's in tos/chips/atm128/sim/atm128hardware.h:
uint8_t atm128RegFile[100][0xa0];should beuint8_t atm128RegFile[TOSSIM_MAX_NODES][0xa0];I thought I had checked the fix into CVS, but it looks like it's notthere yet. I'll check it in today.
If you don't have this fix then the simulation segfaults prettyquickly. The way I saw it manifest was a node >100 tried to modifyits clock register and instead corrupted the memory for the loggingsystem, leading TOSSIM to think there were a bazillion output
channels for a dbg statement and segfaulting when it ran off the endof a length 0 array.Phil
-- Phd Dept. of Electrical EngineeringUniversity of Southern California
http://www-scf.usc.edu/~asridhar

-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Re: your views of running TOSSIM with ~500 nodes

2006-03-10 Thread Avinash Sridharan

Hi Phil, Again thanks a lot. I think thats the behaviour I am observing. The minute I step beyond 100 the simulation segfaults at boot up. Will try the fix and get back to you.Thanks,Avinash
On 3/10/06, Philip Levis <[EMAIL PROTECTED]> wrote:
On Mar 9, 2006, at 7:21 PM, Avinash Sridharan wrote:> Hi Phil,>>There's a bug in the beta that prevents you from simulating more than100 nodes. It's in tos/chips/atm128/sim/atm128hardware.h:
uint8_t atm128RegFile[100][0xa0];should beuint8_t atm128RegFile[TOSSIM_MAX_NODES][0xa0];I thought I had checked the fix into CVS, but it looks like it's notthere yet. I'll check it in today.
If you don't have this fix then the simulation segfaults prettyquickly. The way I saw it manifest was a node >100 tried to modifyits clock register and instead corrupted the memory for the loggingsystem, leading TOSSIM to think there were a bazillion output
channels for a dbg statement and segfaulting when it ran off the endof a length 0 array.Phil-- Phd Dept. of Electrical EngineeringUniversity of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Re: [Tinyos-devel] TinyOS 2.x node ID (TOSSIM)

2006-03-10 Thread Avinash Sridharan

Hi Phil, I was trying to debug the problem, I realised the problem was in my code and hence your changes work just fine. Due to a multitude of code changes I ended up reinitializing the node id's midway during simulation (this was a hack to get around the earlier bug) duh !!. Things are working fine now.
Thanks and regards,AvinashOn 3/9/06, Avinash Sridharan <[EMAIL PROTECTED]> wrote:
Hi Phil, I tried making the code changes you had suggested. I can't check out those specific files and didn't want a complete new source tree to play with, so went ahead and made the appropriate code changes. 
 But even now TOS_NODE_ID is always set to 0 ?? It does show the node id of the node properly. 
  I was printing out the TOS_NODE_ID in the boot section of my code ?-Avinash
On 3/9/06, Philip Levis <
[EMAIL PROTECTED]> wrote:
On Wed, 2006-03-08 at 23:51 -0800, Avinash Sridharan wrote:
> Hi,>  I am starting to use TinyOS 2.x. How do you I get the local address> in TinyOS -2.x. TOS_LOCAL_ADDRESS is not present should I be using> TOS_NODE_ID. The problem is that I am using TOSSIM in 
TinyOS-2.x and> in code I had used TOS_NODE_ID, but it doesn't get intitalized to the> node id. Since it keeps throwing the value of 1 for all nodes. I tried> TOS_AM_ADDRESS with the same results.

This is a bug. I've fixed it in CVS. It required two changes. The firstis in sim_tossim.c, where it sets TOS_NODE_ID when you switch nodes. Thesecond is in ActiveMessageAddressC, where it initializes addr to

TOS_NODE_ID. The modified functions:void sim_set_node(unsigned long node) __attribute__ ((C, spontaneous)) {  current_node = node;  TOS_NODE_ID = node;}  async command am_addr_t amAddress() {

if (!set) {  addr = TOS_NODE_ID;  set = TRUE;}return addr;  }Let me know if you have any other problems,Phil
-- 
Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar


-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Fwd: your views of running TOSSIM with ~500 nodes

Actually,  I was looking at TOSSIM-2.x which is a packet level simulator whose dynamics are quiet different from TOSSIM-1.x. Hence wanted to see if we can perform such scales of simulation with TOSSIM-2.x. TOSSIM-2.x also runs nesC code but the communication is at the packet level and hence our assumption was that it should not have the scalability drawbacks of 
TOSSIM-1.x.  -AvinashOn 3/9/06, MANJUNATH <[EMAIL PROTECTED]> wrote:
Hi,There is a paper by title "Issues Related to WSN Simulators", it
has answer to your questionsSince TOSSIM is a bit-level simulator aiming to provide highfidility using the full implementations of protocols (nativecode), there exists a well known tradeoff "Scaliability Vs
accuracy and performance".I think if you run simulations on higher end machines withabundant RAM, It may scale to large number of nodes...I am notsure whether TOSSIM supports PADS, if so multiprocessor enviroment
will help ypu outManjunathOn Thu, 9 Mar 2006, Avinash Sridharan wrote:> Hi Phil,>  Apologize for the empty mail before. The question I wanted to ask you with> regards to running 
TOSSIM-2.x with arpproximately 500 nodes (more is even> better). My simulation runs fine with around 100 nodes but anything beyond> that the simulation segfaults.>>  In order  to stress TOSSIM-2.x
 and remove any ambiguities, I tried running> the blink application for around 130 nodes and after booting up the> simulation simply hanged.>>  The application I am trying to simulate is a random walk. It works fine for
> 50 nodes. But apart from the nature of the application what was bothering me> was the fact that nodes are not able to boot up itself.>   The loop I am using to boot up the motes is as below, I hope I am not
> making a mistake with the booting up process:>> for i in range(0, NUM_SIM_NODES):> node = sim_obj.getNode(i);> node.bootAtTime(sim_obj.time() + i*1);> while True:
> sim_obj.runNextEvent();> if node.isOn() :> print "Commpleted booting node "+str(i)> break> #create links between nodes> sim_radio.setNoise(i, -105, 
3.0);> for j in range (0,NUM_SIM_NODES):> if (j != i ):> sim_radio.add(i, j, -50.0);>>>> Wanted to know your views on this.>> regards,
> Avinash>> -- Forwarded message --> From: Avinash Sridharan <[EMAIL PROTECTED]>> Date: Mar 9, 2006 7:21 PM
> Subject: your views of running TOSSIM with ~500 nodes> To: Philip Levis <[EMAIL PROTECTED]>> Cc: 
tinyos-help@millennium.berkeley.edu>> Hi Phil,>>> --> Phd Dept. of Electrical Engineering> University of Southern California> 
http://www-scf.usc.edu/~asridhar <http://www-scf.usc.edu/%7Easridhar>>>> --> Phd Dept. of Electrical Engineering> University of Southern California
> http://www-scf.usc.edu/~asridhar <http://www-scf.usc.edu/%7Easridhar>>> --> This message has been scanned for viruses and
> dangerous content by MailScanner, and is> believed to be clean.>>--This message has been scanned for viruses anddangerous content by MailScanner, and isbelieved to be clean.
-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Fwd: your views of running TOSSIM with ~500 nodes

Hi Phil, Apologize for the empty mail before. The question I
wanted to ask you with regards to running TOSSIM-2.x with
arpproximately 500 nodes (more is even better). My simulation runs fine
with around 100 nodes but anything beyond that the simulation
segfaults.
 In order  to stress TOSSIM-2.x and remove any
ambiguities, I tried running the blink application for around 130 nodes
and after booting up the simulation simply hanged. The
application I am trying to simulate is a random walk. It works fine for
50 nodes. But apart from the nature of the application what was
bothering me was the fact that nodes are not able to boot up itself.
  The loop I am using to boot up the motes is as below, I hope I am not making a mistake with the booting up process:
for i in range(0, NUM_SIM_NODES):
    node = sim_obj.getNode(i);
    node.bootAtTime(sim_obj.time() + i*1);
    while True:
    sim_obj.runNextEvent();
    if node.isOn() :
    print "Commpleted booting node "+str(i)
    break
    #create links between nodes
    sim_radio.setNoise(i, -105, 3.0);
    for j in range (0,NUM_SIM_NODES):
    if (j != i ):
    sim_radio.add(i, j, -50.0);
 Wanted to know your views on this.

regards,
Avinash-- Forwarded message ------From: 
Avinash Sridharan <[EMAIL PROTECTED]>Date: Mar 9, 2006 7:21 PM
Subject: your views of running TOSSIM with ~500 nodes
To: Philip Levis <[EMAIL PROTECTED]>Cc: 
tinyos-help@millennium.berkeley.edu
Hi Phil,-- Phd Dept. of Electrical EngineeringUniversity of Southern California

http://www-scf.usc.edu/~asridhar

-- Phd Dept. of Electrical EngineeringUniversity of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] your views of running TOSSIM with ~500 nodes

Hi Phil,-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Re: [Tinyos-devel] TinyOS 2.x node ID (TOSSIM)

Hi Phil, I tried making the code changes you had suggested. I can't check out those specific files and didn't want a complete new source tree to play with, so went ahead and made the appropriate code changes.  But even now TOS_NODE_ID is always set to 0 ?? It does show the node id of the node properly. 
  I was printing out the TOS_NODE_ID in the boot section of my code ?-AvinashOn 3/9/06, Philip Levis <
[EMAIL PROTECTED]> wrote:On Wed, 2006-03-08 at 23:51 -0800, Avinash Sridharan wrote:
> Hi,>  I am starting to use TinyOS 2.x. How do you I get the local address> in TinyOS -2.x. TOS_LOCAL_ADDRESS is not present should I be using> TOS_NODE_ID. The problem is that I am using TOSSIM in 
TinyOS-2.x and> in code I had used TOS_NODE_ID, but it doesn't get intitalized to the> node id. Since it keeps throwing the value of 1 for all nodes. I tried> TOS_AM_ADDRESS with the same results.
This is a bug. I've fixed it in CVS. It required two changes. The firstis in sim_tossim.c, where it sets TOS_NODE_ID when you switch nodes. Thesecond is in ActiveMessageAddressC, where it initializes addr to
TOS_NODE_ID. The modified functions:void sim_set_node(unsigned long node) __attribute__ ((C, spontaneous)) {  current_node = node;  TOS_NODE_ID = node;}  async command am_addr_t amAddress() {
if (!set) {  addr = TOS_NODE_ID;  set = TRUE;}return addr;  }Let me know if you have any other problems,Phil-- 
Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Re: [Tinyos-devel] TinyOS 2.x node ID (TOSSIM)

Thanks phil,  Will update the CVS and try it out.-AvinashOn 3/9/06, Philip Levis <[EMAIL PROTECTED]
> wrote:On Wed, 2006-03-08 at 23:51 -0800, Avinash Sridharan wrote:> Hi,
>  I am starting to use TinyOS 2.x. How do you I get the local address> in TinyOS -2.x. TOS_LOCAL_ADDRESS is not present should I be using> TOS_NODE_ID. The problem is that I am using TOSSIM in TinyOS-2.x
 and> in code I had used TOS_NODE_ID, but it doesn't get intitalized to the> node id. Since it keeps throwing the value of 1 for all nodes. I tried> TOS_AM_ADDRESS with the same results.This is a bug. I've fixed it in CVS. It required two changes. The first
is in sim_tossim.c, where it sets TOS_NODE_ID when you switch nodes. Thesecond is in ActiveMessageAddressC, where it initializes addr toTOS_NODE_ID. The modified functions:void sim_set_node(unsigned long node) __attribute__ ((C, spontaneous)) {
  current_node = node;  TOS_NODE_ID = node;}  async command am_addr_t amAddress() {if (!set) {  addr = TOS_NODE_ID;  set = TRUE;}return addr;  }Let me know if you have any other problems,
Phil-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] how are variables handled in TOSSIM

2006-03-08 Thread Avinash Sridharan

Hi Phil, I guess you meant that TOSSIM does handle the variables properly. The reason I was asking this question is that I have an existing piece of code that defines C type variables to maintain data structures in the implementation scope, and for slightly larger networks (~30 nodes), I was observing during simulation that some variables were getting overwritten by their default values. This could be a quirk in the code that I am trying to test out, but wanted to understand the dynamics of TOSSIM to be sure.
Thanks and regards,AvinashOn 3/8/06, Philip Levis <[EMAIL PROTECTED]> wrote:
On Mar 7, 2006, at 7:49 PM, Avinash Sridharan wrote:> Hi All,>  I have variables defined in an implementation section of the> module (that is these variables are present for the whole scope of
> the implementation. How does TOSSIM handle these variables ? I do> not have any timers in my code and it seems TOSSIM resets these> variables. This code works well in a real scenario since I have> tested them on micaz, but wanted to simulated a larger network on
> TOSSIM hence trying to simulate it on TOSSIM.>I don't understand what you're asking. If you define variablesoutside of a component (e.g., in C), then TOSSIM does not handle themproperly. It basically works by making a module variable:
module X {...}implementation {   uint8_t x;   ...}into an array:X$x[TOSSIM_MAX_NODES]then when you're node 43 you access element 43 of the array.TOSSIM also has an "init" call for returning all variables to the
boot state. This is so you can reboot motes in simulation. Normallythe boot sequence does this for you.Phil-- Phd Dept. of Electrical EngineeringUniversity of Southern California
http://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] how are variables handled in TOSSIM

2006-03-07 Thread Avinash Sridharan

Hi All, I have variables defined in an implementation section of the module (that is these variables are present for the whole scope of the implementation. How does TOSSIM handle these variables ? I do not have any timers in my code and it seems TOSSIM resets these variables. This code works well in a real scenario since I have tested them on micaz, but wanted to simulated a larger network on TOSSIM hence trying to simulate it on TOSSIM.
Thanks,Avinash-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] gdb not working with pc binaries tinyos-1.x

2006-03-07 Thread Avinash Sridharan

Hi, I was trying to debug my TOSSIM code, by running it under gdb. But even the blink application segfaults when calls the main function under TOSSIM. Is this a known problem. I am using TinyOS-1.1.15. The error is as seen below:
Starting program: /opt/tinyos-1.x/apps/Blink/build/pc/main.exe 1Program received signal SIGSEGV, Segmentation fault.0x610af064 in pthread_mutex::init () from /usr/bin/cygwin1.dll-Avinash
-- Phd Dept. of Electrical EngineeringUniversity of Southern Californiahttp://www-scf.usc.edu/~asridhar
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] call for resetting the EEPROM

2006-02-21 Thread Avinash Sridharan

Hi,
 Is there a call in the EEPROM API, which helps in resetting all
the entries to  say ?  I want to avoid going through the whole
EEPROM and writting  in each line.

-Avinash
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] javacomm-win32 not available on the Sun website

2006-02-14 Thread Avinash Sridharan

Thanks a lot Michael.

-AvinashOn 2/14/06, Michael Schippling <[EMAIL PROTECTED]> wrote:
I think it's on the TOS site(s) someplace,but I also put a copy on my site to makesure that I get sued for some kind ofIP infringement or other:
http://www.etantdonnes.com/TMP/javacomm20-win32.zipMSAvinash Sridharan wrote:> Hi All,>  I was trying to use the serial forwarder under cygwin, but I am unable> to get it working due to missing 
javax.comm package. The tinyOS website> says we need to download it from http://java.sun.com/products/javacomm/.> But at this location the only downloads available are for Solaris and
> Linux. They don't have any downloads for windows ?>>   Is this a common problem, is there any other location from where I can> get the setup files for javacomm ?> -Avinash>>
> >> ___> Tinyos-help mailing list> 
Tinyos-help@Millennium.Berkeley.EDU> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] javacomm-win32 not available on the Sun website

2006-02-14 Thread Avinash Sridharan

Hi All,
 I was trying to use the serial forwarder under cygwin, but I am
unable to get it working due to missing javax.comm package. The tinyOS
website says we need to download it from http://java.sun.com/products/javacomm/. But at this location the only downloads available are for Solaris and Linux. They don't have any downloads for windows ?


  Is this a common problem, is there any other location from where I can get the setup files for javacomm ?
-Avinash
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] trying to get Tinyos-2.x to work

2006-01-17 Thread Avinash Sridharan

Thanks philip, have started using the micaz sim options with make. Still a few issues. 

1> Have started using the tiny OS 2.0 developement branch. And since
the below question are aimed on issues pertaining to code from this
branch should I be posting on this list or the developers list ? 

2> Trying to make Blink work. As a first step I had to include quiet
a few directories to remove some of the compilation erros. Also the %T
tag doesn't work in the Makefile I had to explicityly put in $(TOSDIR)
to get it running.

3> Still having quiet a few compile errors :(. All the syntax errors
seem to be related to the use of the bool data type. Traditionally C
does not support the bool datatype, not sure if nesc1.2 does and hence do I have
to update the nesc-1.2 compiler by building it from source ?

Thanks for all the help,

regards,

AvinashOn 1/16/06, Philip Levis <[EMAIL PROTECTED]> wrote:
On Jan 16, 2006, at 9:04 AM, Avinash Sridharan wrote:> Hi All,>  Is the bool data type supported in nesc-1.2. I installed> tinyos-2.x and the required tools from the rpms provided on the> tinyos website but unfortunately when I try to compile 
Blink.nc as> make pc I am getting compilation errors.>>  The errors that I am getting are systanx errors in included> interfaces where the return for function prototypes are bool. When
> I change this to int it goes through fine.>> A more general question is there a problem with the pc.rules file> as well in the rpm's provided  (as in is this an old snapshot and> should I update to the latest), since I am having to make quiet a
> few changes to get it working. The problem is that it seems quite a> few directories such as system, interfaces and certain directories> under lib (timer etc) aren't included which leads to compilation
> errors.>>  I am trying to get tinyos-2.x running under FC4 with gcc 3.4.3There is no "pc" target in 2.x. We'll be sure to remove theassociated makefiles for the release. I apologize for the confusion.
There is a TOSSIM, but you compile it by using the "sim" option.E.g.: make micaz sim.Phil---"We shall not cease from explorationAnd the end of all our exploringWill be to arrive where we started
And know the place for the first time."- T. S. Eliot,  'Little Gidding'
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] trying to get Tinyos-2.x to work

2006-01-16 Thread Avinash Sridharan

Hi All,
 Is the bool data type supported in nesc-1.2. I installed
tinyos-2.x and the required tools from the rpms provided on the tinyos
website but unfortunately when I try to compile Blink.nc as make pc I
am getting compilation errors. 

 The errors that I am getting are systanx errors in included
interfaces where the return for function prototypes are bool. When I
change this to int it goes through fine. 

A more general question is there a problem with the pc.rules file as
well in the rpm's provided  (as in is this an old snapshot and
should I update to the latest), since I am having to make quiet a few
changes to get it working. The problem is that it seems quite a few
directories such as system, interfaces and certain directories under
lib (timer etc) aren't included which leads to compilation errors. 

 I am trying to get tinyos-2.x running under FC4 with gcc 3.4.3

Thanks,
Avinash
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Fwd: problems with compiling tinyos-2.x

Hi Phil,
 Thanks for the pointers. It helped !! The problem was that the
-board option in pc.rules (or for that matter avr.rules) had to be
changed --board and it tried compiling. But I am still running into
problems, now the compiler is throwing a lot of syntax errors so not
sure if I need to updated my source tree. I was compiling on a freshly
updated cvs tree. I tried compiling on the installed source tree
(mentioned on the tinyos website) with the same results

Here are the errors that I was getting 
mkdir -p build/pc
    compiling BlinkAppC to a pc binary
ncc -o build/pc/main.exe -g -O0 -pthread 
-fnesc-nido-tosnodes=1000 -fnesc-simulate -Wall -Wshadow
-DDEF_TOS_AM_GROUP=0x7d -Wnesc-all --target=pc
-fnesc-cfile=build/pc/app.c --board=micasb -I%T/lib/oski 
BlinkAppC.nc -lm
In component `BlinkAppC':
BlinkAppC.nc:45: component MainC not found
In file included from BlinkAppC.nc:45:
In C file:
BlinkC.nc:37: C file Timer not found
In component `BlinkC':
BlinkC.nc:41: syntax error before `TMilli'
BlinkC.nc:42: syntax error before `TMilli'
BlinkC.nc:43: syntax error before `TMilli'
BlinkC.nc:44: interface Leds not found
BlinkC.nc:45: interface Boot not found
BlinkC.nc:50: `booted' is not in interface `Boot'
BlinkC.nc: In function `Boot.booted':
BlinkC.nc:51: `Timer0' undeclared (first use in this function)
BlinkC.nc:51: (Each undeclared identifier is reported only once
BlinkC.nc:51: for each function it appears in.)
BlinkC.nc:52: `Timer1' undeclared (first use in this function)
BlinkC.nc:53: `Timer2' undeclared (first use in this function)
BlinkC.nc: At top level:
BlinkC.nc:57: unknown interface `Timer0'
BlinkC.nc: In function `Timer0.fired':
BlinkC.nc:58: interface has no command or event named `led0Toggle'
BlinkC.nc: At top level:
BlinkC.nc:62: unknown interface `Timer1'
BlinkC.nc: In function `Timer1.fired':
BlinkC.nc:63: interface has no command or event named `led1Toggle'
BlinkC.nc: At top level:
BlinkC.nc:67: unknown interface `Timer2'
BlinkC.nc: In function `Timer2.fired':
BlinkC.nc:68: interface has no command or event named `led2Toggle'
In component `BlinkAppC':
BlinkAppC.nc: At top level:
BlinkAppC.nc:45: component LedsC not found
BlinkAppC.nc:46: component OskiTimerMilliC not found
BlinkAppC.nc:46: component `OskiTimerMilliC' is not generic
BlinkAppC.nc:47: component OskiTimerMilliC not found
BlinkAppC.nc:47: component `OskiTimerMilliC' is not generic
BlinkAppC.nc:48: component OskiTimerMilliC not found
BlinkAppC.nc:48: component `OskiTimerMilliC' is not generic
BlinkAppC.nc:51: cannot find `Boot'
BlinkAppC.nc:52: cannot find `SoftwareInit'
BlinkAppC.nc:54: cannot find `Timer0'
BlinkAppC.nc:55: cannot find `Timer1'
BlinkAppC.nc:56: cannot find `Timer2'
BlinkAppC.nc:57: no match
make: *** [exe0] Error 1


One it seems the make is missing out a lot of inclues sush as
tos/system, tos/lib/timer and so on. Is there something I am missing ?

Thanks,
AvinashOn 1/15/06, Philip Levis <[EMAIL PROTECTED]> wrote:
On Jan 15, 2006, at 11:26 AM, Avinash Sridharan wrote:> Just to add some more info to the below problem I am having it> seems gcc 3.4 and above are sensitive to the order of the arguments> (atleast to the '-b') option I played around with gcc (I installed
> gcc 3.4.4 and tried using the -b option with the -v option and the> order matters). So my guess is nesC internally is calling gcc with> the specific target machine option -b and some how its not the
> first arugment ?>>  Is this something that we could look up in the nesc code ? Also I> am assuming with tinyos-2.x we have to use gcc-3.4.3 please correct> me here if I am wrong.
That's correct. You currently have to use 3.4.3, in that alldevelopment has been using 3.4.3.The place to look what options are being added:support/make/micaz.targetsupport/make/avr/avr.rulestos/platform/micaz/.platform
At what point is the -b option being passed? I don't think it'ssomething that nesC is doing directly, rather it's something that'sbeing introduced as part of some argument transformation (e.g., avr-gcc calls gcc with -b)?
Compiling with -v should give you a good printout of all of the stepsand their flags.Phil---"We shall not cease from explorationAnd the end of all our exploringWill be to arrive where we started
And know the place for the first time."- T. S. Eliot,  'Little Gidding'
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Fwd: problems with compiling tinyos-2.x

Just to add some more info to the below problem I am having it seems
gcc 3.4 and above are sensitive to the order of the arguments (atleast
to the '-b') option I played around with gcc (I installed gcc 3.4.4 and
tried using the -b option with the -v option and the order matters). So
my guess is nesC internally is calling gcc with the specific target
machine option -b and some how its not the first arugment ?

 Is this something that we could look up in the nesc code ? Also I
am assuming with tinyos-2.x we have to use gcc-3.4.3 please correct me
here if I am wrong.

regards,
Avinash-- Forwarded message --From: Avinash Sridharan <[EMAIL PROTECTED]
>Date: Jan 15, 2006 10:45 AMSubject: problems with compiling tinyos-2.xTo: tinyos-help@millennium.berkeley.edu.Hi All,
 I followed the instructions for upgrading from tinyos-1.x to
tinyos-2.x given on the tinyos.net home page. However after upgrading I
am having compilaiton issues. I tried compiling the blink applicaiton
and this is the error I got
 make micaz
mkdir -p build/micaz
    compiling BlinkAppC to a micaz binary
ncc -o build/micaz/main.exe -Os -finline-limit=10 -Wall -Wshadow
-DDEF_TOS_AM_GROUP=0x7d -Wnesc-all -target=micaz
-fnesc-cfile=build/micaz/app.c -board=micasb -I%T/lib/oski 
-I/opt/tinyos-2.x/tos/lib/CC2420Radio BlinkAppC.nc -lm
gcc: '-b' must come at the start of the command line
make: *** [exe0] Error 1


  The -b option suggests the we have to specify the target machine
as well (in this case avr I guess). I check the version of ncc that I
was using and it was nesc-1.2. I am doing the above compilation on FC4
which is using gcc 4.0 not sure if this is the issue ?

Thanks and regards,
Avinash


___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] problems with compiling tinyos-2.x

Hi All,
 I followed the instructions for upgrading from tinyos-1.x to
tinyos-2.x given on the tinyos.net home page. However after upgrading I
am having compilaiton issues. I tried compiling the blink applicaiton
and this is the error I got
 make micaz
mkdir -p build/micaz
    compiling BlinkAppC to a micaz binary
ncc -o build/micaz/main.exe -Os -finline-limit=10 -Wall -Wshadow
-DDEF_TOS_AM_GROUP=0x7d -Wnesc-all -target=micaz
-fnesc-cfile=build/micaz/app.c -board=micasb -I%T/lib/oski 
-I/opt/tinyos-2.x/tos/lib/CC2420Radio BlinkAppC.nc -lm
gcc: '-b' must come at the start of the command line
make: *** [exe0] Error 1


  The -b option suggests the we have to specify the target machine
as well (in this case avr I guess). I check the version of ncc that I
was using and it was nesc-1.2. I am doing the above compilation on FC4
which is using gcc 4.0 not sure if this is the issue ?

Thanks and regards,
Avinash
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] tinyos-2.x make problems