Re: [Tinyos-help] NesC and TinyOS

2006-06-13 Thread David Gay

On 6/13/06, Adam <[EMAIL PROTECTED]> wrote:

In the following common seeing code segment, I notice someone add 'atomic'
before 'm_data = data;' (such as OscilloscopeRF), someone does not (such as
Delta from Moteiv). Since another 'dataReady' interupt could come before
task sendData is excuted, it seems to me the first 'atomic' is not necessary
-- even if you have, the 'm_data' will be changed before sendData excuted.

Further more, if 'msg' will be modified here only, I even think the second
'atomic' is not necessary. Since one task will not preempt another task. In
other words, another post sendData will not excute until the current
sendData finish.

async event result_t ADC.dataReady(uint16_t data) {
atomic m_data = data;
post sendData();
return SUCCESS;
  }

 task void sendData() {
.
atomic msg->data = m_data; // assume msg will be modified here only
 }

It seems to me that 'atomic' is useful only if there are a set of variables
- you want to keep the integrity of the variable set.


There is no guarantee that the write of a single variable is atomic.
In fact, on many mote platforms, reads or writes of anything larger
than a single variable are not atomic. So in the code above, a
dataReady interrupt at the wrong time could give a rather weird value
in m_data (assuming it is 16-bits it could get one byte from one
reading, and one byte from the next).

Also, if you write

 x = x+1

there's only one variable. But you still get a data-race even if it is
a single byte. In fact, this is the classic example of a data-race...

Some people skip the atomic because either:
- they are more worried at the code size/execution time overhead of
atomic than the potential data race
- they know that the data-race won't occur for some other reason.
E.g., if I'm sampling once every 5 minutes, then there isn't going to
be a race on m_data (or if there is, there's clearly a very large
other problem ;-))

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


RE: [Tinyos-help] NesC and TinyOS

2006-06-13 Thread Adam
Thanks a lot. 

In the following common seeing code segment, I notice someone add 'atomic'
before 'm_data = data;' (such as OscilloscopeRF), someone does not (such as
Delta from Moteiv). Since another 'dataReady' interupt could come before
task sendData is excuted, it seems to me the first 'atomic' is not necessary
-- even if you have, the 'm_data' will be changed before sendData excuted. 

Further more, if 'msg' will be modified here only, I even think the second
'atomic' is not necessary. Since one task will not preempt another task. In
other words, another post sendData will not excute until the current
sendData finish.

async event result_t ADC.dataReady(uint16_t data) {
atomic m_data = data;
post sendData();
return SUCCESS;
  }

 task void sendData() {
.
atomic msg->data = m_data; // assume msg will be modified here only  
 }  

It seems to me that 'atomic' is useful only if there are a set of variables
- you want to keep the integrity of the variable set.

Please give a quick a comment, I got confused with this quite a while ... 

-Original Message-
From: David Gay [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 13, 2006 11:00 AM
To: Adam
Cc: tinyos-help@millennium.berkeley.edu
Subject: Re: [Tinyos-help] NesC and TinyOS

On 6/13/06, Adam <[EMAIL PROTECTED]> wrote:
> Page 39 Listing 4.24 in the Phil's manual says differently... I wish 
> what you said is correct - easier to manage. Please clarify. Thanks.

You're misinterpreting the text there. As Phil said in his answer, Listing
4.24 is an example of an optimisation where allowing async code to interrupt
an atomic statement would have no detectable effects. But in cases where the
effects would be detectable (i.e., if there is any shared state between the
atomic statement and anything that interrupts it), such an optimisation
would be illegal. It's all quite moot because we don't attempt to do such
optimisations at this point.

David Gay

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


Re: [Tinyos-help] RSSI

2006-06-13 Thread Keyan Mahadevan
A follow up question - is there any way I would be able to access the RSSI values in TOSSIM. 
Thanks
KnOn 6/13/06, Philip Levis <[EMAIL PROTECTED]> wrote:
On Jun 13, 2006, at 12:15 PM, Keyan Mahadevan wrote:> I saw a few people talking about getting RSSI values. RSSI value> seems to be zero when I use TOSSIM on a PC. Is that normal?Yes; TOSSIM in 1.x
 doesn't model RF signal strength. (2.x does, butit does not yet make it accessible to applications).Phil
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


[Tinyos-help] Cannot compile TOSSIM 2.0!!

2006-06-13 Thread Luis E. Palafox-Maestre
Hi,

I recently upgraded to TinyOS 2, and I'm having trouble compiling
for TOSSIM 2, this is what I get:


$ make micaz sim
mkdir -p build/micaz
  placing object files in build/micaz
  writing XML schema to app.xml
  compiling BlinkAppC to object file sim.o
ncc -c -fPIC -o build/micaz/sim.o -g -O0 -tossim -fnesc-nido-tosnodes=1000
-fnes
c-simulate -fnesc-nido-motenumber=sim_node\(\)   -finline-limit=10 -Wall
-Ws
hadow -DDEF_TOS_AM_GROUP=0x7d -Wnesc-all -target=micaz
-fnesc-cfile=build/micaz/
app.c -board=micasb  -Wno-nesc-data-race BlinkAppC.nc
-fnesc-dump=components -
fnesc-dump=variables -fnesc-dump=constants -fnesc-dump=typedefs
-fnesc-dump=inte
rfacedefs -fnesc-dump=tags -fnesc-dumpfile=app.xml
In file included from C:/cygwin/opt/tinyos-2.x/tos/lib/tossim/sim_mac.c:34,
 from C:/cygwin/opt/tinyos-2.x/tos/lib/tossim/tos.h:90:
C:/cygwin/opt/tinyos-2.x/tos/lib/tossim/sim_gain.c:14: warning: declaration
of `
link' shadows global declaration
/usr/include/sys/unistd.h:97: warning: location of shadowed declaration
C:/cygwin/opt/tinyos-2.x/tos/lib/tossim/sim_gain.c:20: warning: declaration
of `
link' shadows global declaration
/usr/include/sys/unistd.h:97: warning: location of shadowed declaration
C:/cygwin/opt/tinyos-2.x/tos/lib/tossim/sim_gain.c: In function
`sim_gain_alloca
te_link':
C:/cygwin/opt/tinyos-2.x/tos/lib/tossim/sim_gain.c:134: warning: declaration
of
`link' shadows global declaration
/usr/include/sys/unistd.h:97: warning: location of shadowed declaration
C:/cygwin/opt/tinyos-2.x/tos/lib/tossim/sim_gain.c: At top level:
C:/cygwin/opt/tinyos-2.x/tos/lib/tossim/sim_gain.c:141: warning: declaration
of
`link' shadows global declaration
/usr/include/sys/unistd.h:97: warning: location of shadowed declaration
In file included from
C:/cygwin/opt/tinyos-2.x/tos/chips/atm128/timer/sim/HplAtm
128Timer0AsyncC.nc:53,
 from
C:/cygwin/opt/tinyos-2.x/tos/platforms/mica/AlarmCounterMi
lliP.nc:30,
 from
C:/cygwin/opt/tinyos-2.x/tos/platforms/mica/sim/HilTimerMi
lliC.nc:41,
 from C:/cygwin/opt/tinyos-2.x/tos/system/TimerMilliP.nc:41,
 from C:/cygwin/opt/tinyos-2.x/tos/system/TimerMilliC.nc:40,
 from BlinkAppC.nc:46:
In component `HplAtm128Counter0C':
C:/cygwin/opt/tinyos-2.x/tos/chips/atm128/timer/sim/HplAtm128Counter0C.nc:
In fu
nction `timer0_overflow_handle':
C:/cygwin/opt/tinyos-2.x/tos/chips/atm128/timer/sim/HplAtm128Counter0C.nc:31
1: w
arning: declaration of `time' shadows global declaration
/usr/include/time.h:49: warning: location of shadowed declaration
In file included from
C:/cygwin/opt/tinyos-2.x/tos/chips/atm128/timer/sim/HplAtm
128Timer0AsyncC.nc:58,
 from
C:/cygwin/opt/tinyos-2.x/tos/platforms/mica/AlarmCounterMi
lliP.nc:30,
 from
C:/cygwin/opt/tinyos-2.x/tos/platforms/mica/sim/HilTimerMi
lliC.nc:41,
 from C:/cygwin/opt/tinyos-2.x/tos/system/TimerMilliP.nc:41,
 from C:/cygwin/opt/tinyos-2.x/tos/system/TimerMilliC.nc:40,
 from BlinkAppC.nc:46:
In component `HplAtm128CompareC':
C:/cygwin/opt/tinyos-2.x/tos/chips/atm128/timer/sim/HplAtm128CompareC.nc: In
fun
ction `timer0_compare_handle':
C:/cygwin/opt/tinyos-2.x/tos/chips/atm128/timer/sim/HplAtm128CompareC.nc:195
: wa
rning: declaration of `time' shadows global declaration
/usr/include/time.h:49: warning: location of shadowed declaration
cc1: warning: -fPIC ignored for target (all code is position independent)


.
.
.
.

And afterward everything fails! :-)

Thanks in advance,


Luis Enrique Palafox-Maestre


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


Re: [Tinyos-help] RSSI

2006-06-13 Thread Philip Levis

On Jun 13, 2006, at 12:15 PM, Keyan Mahadevan wrote:

I saw a few people talking about getting RSSI values. RSSI value  
seems to be zero when I use TOSSIM on a PC. Is that normal?


Yes; TOSSIM in 1.x doesn't model RF signal strength. (2.x does, but  
it does not yet make it accessible to applications).


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


[Tinyos-help] RSSI

2006-06-13 Thread Keyan Mahadevan
I saw a few people talking about getting RSSI values. RSSI value seems to be zero when I use TOSSIM on a PC. Is that normal?
Thanks
Kn
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] Tmote Sky ACK

2006-06-13 Thread Joe Polastre

On 6/13/06, Adam <[EMAIL PROTECTED]> wrote:

The easiest thing is to use GenericCom, you can enable ACk by call
enableACK() command. For SP, maybe it is a good stuff, but it will take many
efforts to understand the mechanism, since there is no good documentation on
that -- the SP paper is high level, not much help to programming.


This is completely not true.  The paper describes the interfaces and
their semantics.  The documentation in Boomerang provides detailed
nesdoc information on every interface and its uses.  There is also a
sample SP protocol called NetSync.  You will find that SP is
documented more than any other library in the tinyos-1.x tree.

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


[Tinyos-help] Crash while programming TelosB

2006-06-13 Thread Meng Jiang
Has anyone every had the problem of computer crashing during programming of TelosB?
I have a Sony Vaio S260 Laptop, and am running WindowsXP. I have TinyOS V 1.1.15.
I dont' have any serial ports on my laptop so I had to use the USB to Serial Emulator from Telos..
So the mote is always assigned to either COM14 or COM15, programs compiles ok and the computer
will also locate the mote using motelist. However, whenever I try to program the devices, my computer
always crashes after it says "found mote". Anyone saw this problem before?
 
Thanks.
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] Tmote Sky ACK

2006-06-13 Thread Philip Levis

On Jun 13, 2006, at 9:34 AM, Adam wrote:

The easiest thing is to use GenericCom, you can enable ACk by call  
enableACK() command. For SP, maybe it is a good stuff, but it will  
take many efforts to understand the mechanism, since there is no  
good documentation on that -- the SP paper is high level, not much  
help to programming.




One note: the Boomerang SP implementation uses a different ACK  
mechanism than the 1.x and 2.x CC2420 TinyOS stacks. The TinyOS  
stacks use hardware-generated ACKs. This has the nice property that  
they are timed precisely but the drawback that you can't snoop on  
unicast messages. SP sends ACKs from software; the drawback (and I've  
observed this happen) is that you can get false positives: since you  
sacrifice the precise timing, the software stack sometimes ACKs  
packets that it shouldn't. The benefit is that SP can snoop on  
unicast messages.


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


Re: [Tinyos-help] NesC and TinyOS

2006-06-13 Thread David Gay

On 6/13/06, Adam <[EMAIL PROTECTED]> wrote:

Page 39 Listing 4.24 in the Phil's manual says differently... I wish what
you said is correct - easier to manage. Please clarify. Thanks.


You're misinterpreting the text there. As Phil said in his answer,
Listing 4.24 is an example of an optimisation where allowing async
code to interrupt an atomic statement would have no detectable
effects. But in cases where the effects would be detectable (i.e., if
there is any shared state between the atomic statement and anything
that interrupts it), such an optimisation would be illegal. It's all
quite moot because we don't attempt to do such optimisations at this
point.

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


Re: [Tinyos-help] NesC and TinyOS

2006-06-13 Thread Philip Levis

On Jun 13, 2006, at 10:41 AM, David Gay wrote:


-- Forwarded message --
From: David Gay <[EMAIL PROTECTED]>
Date: Jun 13, 2006 10:41 AM
Subject: Re: [Tinyos-help] NesC and TinyOS
To: Adam <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]


On 6/13/06, Adam <[EMAIL PROTECTED]> wrote:

(1)
void foo()
{
c = d;
}
 ..
atomic
{
a = b;
foo();
}
...

First question is: does atomic protect the variable in both side.  
In this

example, are all variables (a,b,c,d) protected? Or just a and c are
protected.


All variables are protected. Atomic statements are defined to be
"serialisable", i.e., you can assume nothing else happens during the
execution of an atomic statement (and, in fact, they are simply
implemented by disabling interrupts...).


Another question is, since async event can still interrupt the atomic
section (as you mention in the manual).


Async events cannot interrupt atomic statements.


I think the confusion comes from the distinction between the  
semantics of atomic (the theory) and what TinyOS does to achieve  
these semantics (the practice).


David's first statement (serialisability) is how  atomic behaves  
semantically. As atomic sections are defined to be serializable, then  
code in atomic section cannot be interrupted by code that modifies  
anything which might alter its result: it must behave as if there  
were no preemption, but rather a completely serial execution order.


In practice, the way TinyOS/nesC achieves this is to globally disable  
interrupts.  However, if it were running on more complex hardware  
(e.g., with interrupt priority level disabling) then it *could* do  
something more complex without violating its semantic requirements.  
As the manual goes into, two atomic interrupts that never touch each  
other could *in theory* preempt one another. In practice, however,  
they do not.


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


Fwd: [Tinyos-help] NesC and TinyOS

2006-06-13 Thread David Gay

-- Forwarded message --
From: David Gay <[EMAIL PROTECTED]>
Date: Jun 13, 2006 10:41 AM
Subject: Re: [Tinyos-help] NesC and TinyOS
To: Adam <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]


On 6/13/06, Adam <[EMAIL PROTECTED]> wrote:

(1)
void foo()
{
c = d;
}
 ..
atomic
{
a = b;
foo();
}
...

First question is: does atomic protect the variable in both side. In this
example, are all variables (a,b,c,d) protected? Or just a and c are
protected.


All variables are protected. Atomic statements are defined to be
"serialisable", i.e., you can assume nothing else happens during the
execution of an atomic statement (and, in fact, they are simply
implemented by disabling interrupts...).


Another question is, since async event can still interrupt the atomic
section (as you mention in the manual).


Async events cannot interrupt atomic statements.

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


RE: [Tinyos-help] NesC and TinyOS

2006-06-13 Thread Adam
Phil, I have read your TinyOS programming manual, and still have some doubt
regarding the data race conditions:

(1) 
void foo()
{
c = d;
}
 ..
atomic 
{
a = b;
foo();
}
...

First question is: does atomic protect the variable in both side. In this
example, are all variables (a,b,c,d) protected? Or just a and c are
protected.

Another question is, since async event can still interrupt the atomic
section (as you mention in the manual). Assume the following async event
comes after 'a=b' assignment:  async event result_t ADC.dataReady(uint16_t
data) { a = data;}. What will happen?  What would  the excution order be?

(2) I notice many sample program does something like this:

 async event result_t ADC.dataReady(uint16_t data) {
m_data = data;
post sendData();
return SUCCESS;
  }

 task void sendData() {
.
atomic dmsg->data = m_data; // assume dmsg will be modified here only
 }
 what's the usage of atomic here? Since task will not preempt itself. On the
other hand, the async event can preempt the task at any time (e.g., another
dataReady event comes before task sendData excutes). It seems to me there is
no difference whether there is atomic or not.

I notice some code like Oscope added atomic in dataReady, does it make
difference?

Thanks.



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Philip
Levis
Sent: Tuesday, June 13, 2006 9:01 AM
To: Andres Aberasturi
Cc: tinyos-help@Millennium.Berkeley.EDU
Subject: Re: [Tinyos-help] NesC and TinyOS

On Jun 12, 2006, at 7:29 AM, Andres Aberasturi wrote:

>
> Hi all,
>
> We have been working with TinyOs and NesC some few months, but we 
> still have some doubts. We want to ask you the following three
> questions:
>
> 1.- In some places, we have read that events can call commands, post 
> tasks and signal other events. Also, we have read that commands can 
> call lower level commands. Then, a command cannot post a task? or 
> signal an event? is it right? We thought command can do it.

The only operation that issues a warning is when an async function calls a
sync function. For simplicity, sync functions are only safe to call when the
root of the call graph is a task. Async functions can also have interrupt
handlers are their root.

In practice, it is bad practice to signal an event (signal ) inside a
command. There is nothing that prevents you from doing so, however. It is
bad practice because it can easily lead to infinite call loops. For example:

call Foo.send();
event void Foo.sendDone();


commmand void Foo.send() {
   signal Foo.sendDone();
}

The TinyOS programming manual goes into detail on this and other good/ bad
programming practices.


>
> 2.- We have read that there are two level scheduling: events and  
> tasks. We know TinyOs scheduler manages tasks which are posted, so  
> does TinyOs scheduler manage events? or are events managed like  
> commands?

The distinction is sync/async. The term "event" was overloaded in the  
original TinyOS paper to mean both "callback" and "interrupt." The  
command/event distinction means the former, the task/event  
distinction means the latter. The nesC paper and the TinyOS  
programming guide are good resources for learning about the details.


>
> 3.- If you have a task posted, could you post the same task other  
> time? We mean if we have a task in the task qeue, could we post the  
> same task again? Perhaps it is a simple question, but we think it  
> is possible that if the task is in the task qeue, we couldn't post  
> it again.
>

This depends on what version of  TinyOS you're using. In 1.x, a  
single task can have multiple outstanding posts in the task queue. In  
2.x, a task can only have one outstanding post. This latter behavior  
turns out to have a lot of nice isolation and fairness properties.  
TEP 106 has a good discussion of the tradeoffs.

Phil
___
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] make pc docs

2006-06-13 Thread Mikael Ifversen

Hello,
make pc docs, produces the errors below, any help is appreciated, thanks 
Mikael


$ make pc docs
  Making documentation for Blink on pc
nesdoc /opt/tinyos-1.x/doc/nesdoc/pc -topdir="/home/TekMan" -topdir=/ 
-fnesc-is-
app  -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 -
DIDENT_PROGRAM_NAME=\"Blink\" -DIDENT_USER_ID=\"TekMan\" 
-DIDENT_HOSTNAME=\"mikm
o-a24523d52\" -DIDENT_USER_HASH=0x4d8680c1L 
-DIDENT_UNIX_TIME=0x448e98c5L -DIDEN

T_UID_HASH=0x23de3a57L Blink.nc
nesc1: warning: invalid data in info.idx - ignoring remainder of file

Error: c:\program files\ucb\att\graphviz\bin\dot.exe: can't open 
Files.UCB.cygwi

n.opt.tinyos-1.x.apps.Blink.Blink.nc.if.gif
Error: c:\program files\ucb\att\graphviz\bin\dot.exe: can't open 
cygdrive.c.Prog

ram
Error: c:\program files\ucb\att\graphviz\bin\dot.exe: can't open 
Files.UCB.cygwi

n.opt.tinyos-1.x.apps.Blink.Blink.nc.if.dot
Error: c:\program files\ucb\att\graphviz\bin\dot.exe: can't open 
Files.UCB.cygwi

n.opt.tinyos-1.x.apps.Blink.Blink.nc.if.cmap
Error: c:\program files\ucb\att\graphviz\bin\dot.exe: can't open 
cygdrive.c.Prog

ram
Error: c:\program files\ucb\att\graphviz\bin\dot.exe: can't open 
Files.UCB.cygwi

n.opt.tinyos-1.x.apps.Blink.Blink.nc.if.dot
assertion "infile" failed: file "unparse.c", line 187
make: *** [docs_] Error 1


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


Re: [Tinyos-help] Sampling Noise level

2006-06-13 Thread Philip Levis

On Jun 12, 2006, at 7:38 PM, Sean Casey wrote:


Hi everyone,

Is there a way to sample the noise in a given environment?  I was  
interested in having a mote (mica2) just monitor the noise level,  
and not send or receive any packets.  I checked the archives and I  
couldn't find anything on this, so if anyone had any ideas or could  
point me in the right direction, I'd appreciate it.



In 1.x, take a look at

CC1000RadioC.nc

This is the line you care about:

  CC1000RadioM.RSSIADC -> ADCC.ADC[TOS_ADC_CC_RSSI_PORT];

RSSI is basically measuring the voltage coming in; this is what the  
radio stack uses to estimate the noise floor.


In 2.x, take a look at:

HplCC1000C.nc and HplCC1000P.nc

The resource management mechanisms in 2.x mean that sampling the ADC  
is a little more complicated. You request access, when it is granted,  
you then sample. The complicated part is that the ADC automatically  
reconfigures itself to the settings you need to take your sample when  
it is granted to you. You see this in the two lines:


  components new AdcReadClientC() as RssiChannel;

  RssiChannel.Atm128AdcConfig -> HplCC1000P;

The ADC requests what channel, voltage reference, etc., it should use  
by calling the HplCC1000P.RssiConfig interface.


Phil



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


Re: [Tinyos-help] MAC protocols in genealogy of tinyos protocols

2006-06-13 Thread Philip Levis

On Jun 12, 2006, at 2:10 PM, Adam wrote:


Thanks again, Philip.  May I ask you another question: in genealogy of
tinyos protocols, what MAC protocols are used in each platform by  
default?
Several people asked this question in the forum, but no one give an  
accurate

answer.


The default TinyOS MAC has always been CSMA-based. There was no  
proper name for the early MACs: they were just CSMA with randomized  
backoff over a fixed interval. Initial backoff was usually larger  
than contention backoff. So something like this:


tx() {
  backoff in range A-B
}

backoff() {
  if channel busy
backoff in range a-b
  else
send packet
}

More recent mica2/CC1000 (in 1.x and 2.x) stacks have BMAC, which is  
basically just a CSMA MAC that allows you to adjust constants, such  
as your backoff intervals. BMAC also supports low power listening  
(LPL), so low-power operation.


The CC2420 stacks (in 1.x and 2.x) also support some BMAC operations,  
such as backoff interval control, but they do not support LPL.


Phil







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


Re: [Tinyos-help] Help with simulators

2006-06-13 Thread Philip Levis

On Jun 12, 2006, at 8:41 AM, Aditya Bhave wrote:



Hello all,

Does any one know of a good simulator (preferably on a Windows  
based PC) that one can use to develop applications using the motes.  
I do not have access to the actual hardware and would like to work  
on projects with simulations. TOSSIM and TinyViz are completely non- 
intuitive and not documented.




For TOSSIM documentation, I'd recommend:

1) The TOSSIM tutorial (for how to use it)
2) The TOSSIM manual (for more details on its features)
3) The TOSSIM paper (for how it works)

That being said, TOSSIM does require that you write TinyOS/nesC code.  
On the other hand, with a few exceptions mostly having to do with  
interrupt handling, TOSSIM is a pretty reasonable (but not perfect)  
TinyOS simulator.


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


Re: [Tinyos-help] NesC and TinyOS

2006-06-13 Thread Philip Levis

On Jun 12, 2006, at 7:29 AM, Andres Aberasturi wrote:



Hi all,

We have been working with TinyOs and NesC some few months, but we  
still have some doubts. We want to ask you the following three  
questions:


1.- In some places, we have read that events can call commands,  
post tasks and signal other events. Also, we have read that  
commands can call lower level commands. Then, a command cannot post  
a task? or signal an event? is it right? We thought command can do it.


The only operation that issues a warning is when an async function  
calls a sync function. For simplicity, sync functions are only safe  
to call when the root of the call graph is a task. Async functions  
can also have interrupt handlers are their root.


In practice, it is bad practice to signal an event (signal )  
inside a command. There is nothing that prevents you from doing so,  
however. It is bad practice because it can easily lead to infinite  
call loops. For example:


call Foo.send();
event void Foo.sendDone();


commmand void Foo.send() {
  signal Foo.sendDone();
}

The TinyOS programming manual goes into detail on this and other good/ 
bad programming practices.





2.- We have read that there are two level scheduling: events and  
tasks. We know TinyOs scheduler manages tasks which are posted, so  
does TinyOs scheduler manage events? or are events managed like  
commands?


The distinction is sync/async. The term "event" was overloaded in the  
original TinyOS paper to mean both "callback" and "interrupt." The  
command/event distinction means the former, the task/event  
distinction means the latter. The nesC paper and the TinyOS  
programming guide are good resources for learning about the details.





3.- If you have a task posted, could you post the same task other  
time? We mean if we have a task in the task qeue, could we post the  
same task again? Perhaps it is a simple question, but we think it  
is possible that if the task is in the task qeue, we couldn't post  
it again.




This depends on what version of  TinyOS you're using. In 1.x, a  
single task can have multiple outstanding posts in the task queue. In  
2.x, a task can only have one outstanding post. This latter behavior  
turns out to have a lot of nice isolation and fairness properties.  
TEP 106 has a good discussion of the tradeoffs.


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


Re: [Tinyos-help] using the hardware multiplier on msp430 for FFT

2006-06-13 Thread Philip Levis

On Jun 11, 2006, at 9:41 AM, Matthew J Whelan wrote:

I don't think there is an interface, but using the hardware  
multiplier is a rather easy task to figure out.  I haven't used it  
for FFT, but I have implemented digital filtering without any  
issues.  You should check out the TI application note on the  
hardware multiplier for info on how to use it and source code for  
FFT calculations:


http://focus.ti.com/lit/an/slaa042/slaa042.pdf



When compiling for MSP430 platforms, the TinyOS build chain tells gcc  
to not use the multiply instruction. There's nothing wrong with the  
instruction; rather, gcc has some bugs when generating code that uses  
it. Therefore, I'd guess that assembly hacking would work fine, but  
trying to do it through C will run into issues.


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


RE: [Tinyos-help] Tmote Sky ACK

2006-06-13 Thread Adam



The easiest thing is to use GenericCom, you can enable ACk 
by call enableACK() command. For SP, maybe it is a good stuff, but it will take 
many efforts to understand the mechanism, since there is no good documentation 
on that -- the SP paper is high level, not much help to 
programming.


From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of 
giovanni gambaSent: Monday, June 12, 2006 4:53 PMTo: 
tinyos-helpSubject: [Tinyos-help] Tmote Sky ACK
Hi all,does anybody knows how can i use ACKED tx and rx on Tmote 
Sky MOTES?Is it possible to set it up at runtime, like the rf power or the 
rf channel (i think using the CC2420ControlM module)?And another thing... 
does every trasmission use the SP components?Can i modify parameters at this 
level or it's better not?Thank you very muchGiovanni
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


[Tinyos-help] is possible with TinyViz?

2006-06-13 Thread Munaretto, Daniel
Hi all,
 i'd like to work with packages bigger than 29 bytes. So i modified in AM.h 
TOSH_DATA_LENGTH (but no more of 100 bytes, cause there are many warnings 
showed by the compiler).
 
So the question is:
 does anyone know how to see in TinyViz all the data bytes? cause by default 
you can see only 29 bytes with "debug messages". If and where there is 
something that has to be modified, please advise me!
 
Thanks for your availability,
cheers
Daniele

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


Re: [Tinyos-help] Tmote Sky ACK

2006-06-13 Thread Joe Polastre

SP has an option to request reliability, which will let you know if
the packet was acknowledged or not.  Please see the SPSend interface
documentation in /opt/moteiv/doc/nesdoc or read the SP paper at
www.polastre.com/pubs.html

-Joe

On 6/12/06, giovanni gamba <[EMAIL PROTECTED]> wrote:

Hi all,
 does anybody knows how can i use ACKED tx and rx on Tmote Sky MOTES?
 Is it possible to set it up at runtime, like the rf power or the rf channel
(i think using the CC2420ControlM module)?
 And another thing... does every trasmission use the SP components?Can i
modify parameters at this level or it's better not?
 Thank you very much
 Giovanni

___
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


Re: [Tinyos-help] RSSI_VAL

2006-06-13 Thread Andres Aberasturi

Hi,

I have an application that copies the "msg->strength" and saving it in an 
uint8_t data:


uint8_t msg->data[4]=msg->strength

then with my own xlisten, I visualize the "strength".

Thanks for your attention,

Andrés



From: "Hui KANG" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [Tinyos-help] RSSI_VAL
Date: Tue, 13 Jun 2006 09:52:01 -0500 (CDT)


Which tool did you use to see the value, listen or others?
Thanks.

Hui Kang

On 6/13/2006, "Andres Aberasturi" <[EMAIL PROTECTED]> wrote:

>Hi all,
>
>I am working with the localization of micaz motes (with the 1.1.7version 
of

>TinyOS), and for it, I need to know the RSSI value messured.
>
>At this moment, I am able to read the value, and see that when I separate
>the motes, this value dicreases. But which are the unit of this value ? 
How

>can I do the conversion?
>
>The datasheet of CC2420 gives me this formula to obtain the power in dBm:
>
>P=RSSI_VAL+RSSI_OFFSET
>
>RSSI_OFFSET is -45dBm, so, RSSI_VAL must be in dB if I want to obtain the
>power in dBm. Can anyone explain me how can I convert my data read to
>RSSI_VAL in dB?
>
>Thank you in advance,
>
>Andrés
>
>_
>Descubre la descarga digital con MSN Music. Más de un millón de 
canciones.

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


_
Acepta el reto MSN Premium: Correos más divertidos con fotos y textos 
increíbles en MSN Premium. Descárgalo y pruébalo 2 meses gratis. 
http://join.msn.com?XAPID=1697&DI=1055&HL=Footer_mailsenviados_correosmasdivertidos


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


Re: [Tinyos-help] RSSI_VAL

2006-06-13 Thread Matthew J Whelan
Take the RSSI value, which is an 8-bit SIGNED integer.  This is RSSI_VAL and is in units of dBm.  Subtract 45 dBm from this value.  That is the approximate received signal strength. Matt   [EMAIL PROTECTED] wrote: -To: tinyos-help@Millennium.Berkeley.EDUFrom: "Andres Aberasturi" <[EMAIL PROTECTED]>Sent by: [EMAIL PROTECTED]Date: 06/13/2006 10:44AMSubject: [Tinyos-help] RSSI_VALHi all,I am working with the localization of micaz motes (with the 1.1.7version of TinyOS), and for it, I need to know the RSSI value messured.At this moment, I am able to read the value, and see that when I separate the motes, this value dicreases. But which are the unit of this value ? How can I do the conversion?The datasheet of CC2420 gives me this formula to obtain the power in dBm:P=RSSI_VAL+RSSI_OFFSETRSSI_OFFSET is -45dBm, so, RSSI_VAL must be in dB if I want to obtain the power in dBm. Can anyone explain me how can I convert my data read to RSSI_VAL in dB?Thank you in advance,Andrés_Descubre la descarga digital con MSN Music. Más de un millón de canciones. http://music.msn.es/___Tinyos-help mailing listTinyos-help@Millennium.Berkeley.EDUhttps://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] RSSI_VAL

2006-06-13 Thread Andres Aberasturi

Hi all,

I am working with the localization of micaz motes (with the 1.1.7version of 
TinyOS), and for it, I need to know the RSSI value messured.


At this moment, I am able to read the value, and see that when I separate 
the motes, this value dicreases. But which are the unit of this value ? How 
can I do the conversion?


The datasheet of CC2420 gives me this formula to obtain the power in dBm:

P=RSSI_VAL+RSSI_OFFSET

RSSI_OFFSET is -45dBm, so, RSSI_VAL must be in dB if I want to obtain the 
power in dBm. Can anyone explain me how can I convert my data read to 
RSSI_VAL in dB?


Thank you in advance,

Andrés

_
Descubre la descarga digital con MSN Music. Más de un millón de canciones. 
http://music.msn.es/


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


Re: [Tinyos-help] Sampling Noise level

2006-06-13 Thread Matthew J Whelan
Sean, I am assuming that you want to sample the noise in the RF frequency band.  You can use the RSSI signal from the CC1000 radio chip to get a good idea of what the noise level is at.  This signal is a current output that is connected to gnd across a resistor (and capacitor for filtering), so that the mote can sample the signal as a voltage.  You may want to checkout the CC1000 datasheet as well as whatever xbow says about it.  Simply sample this channel (as far as you can) to record the signal level as measured by the radio chip.  What I have done to gauge the noise (using Tmote Sky motes) is to read the RSSI register from the CC2420 (not an analog signal) and then send the data to a host computer across the UART.  Performing this simple testing outdoors and indoors makes it clear very quickly why the radios tend to perform better outdoors. Regards,Matt[EMAIL PROTECTED] wrote: -To: tinyos-help@Millennium.Berkeley.EDUFrom: Sean Casey <[EMAIL PROTECTED]>Sent by: [EMAIL PROTECTED]Date: 06/12/2006 10:38PMSubject: [Tinyos-help] Sampling Noise levelHi everyone,Is there a way to sample the noise in a given environment?  I was interested in having a mote (mica2) just monitor the noise level, and not send or receive any packets.  I checked the archives and I couldn't find anything on this, so if anyone had any ideas or could point me in the right direction, I'd appreciate it.Thanks,Sean___Tinyos-help mailing listTinyos-help@Millennium.Berkeley.EDUhttps://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