[Tinyos-help] How to display sensor data using Moteview

[Dhivya G]

Hai,
   I am using crossbow Professional kit consisting of Micaz motes,MIB520
programming board and MTS400 sensor board. I want to know whether I have to
program Micaz mote to collect data from sensor using Moteview.If so how I
have to program Micaz mote.

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

[Tinyos-help] error making Blink application

[Calvin Bebermeyer]

Unfortunately, I have had troubles getting TinyOS 2 to correctly run.

I am getting this error:

mkdir -p build/micaz

compiling BlinkAppC to a micaz binary

ncc -o 
build/micaz/main.exe -Os -finline-limit=10 -Wall -Wshadow -Wnesc-all 
-target=micaz 
 -fnesc-cfile=build/micaz/app.c -board=micasb 
-DIDENT_PROGRAM_NAME=\"BlinkAppC\" 
 -DIDENT_USER_ID=\"calvin\" -DIDENT_HOSTNAME=\"amd64\" 
-DIDENT_USER_HASH=0x5dd41d5bL 
 -DIDENT_UNIX_TIME=0x47fc474cL -DIDENT_UID_HASH=0xf3703cd8L -fnesc-dump=wiring 
 -fnesc-dump='interfaces(!abstract())' -fnesc-dump='referenced(interfacedefs, 
components)' -fnesc-dumpfile=build/micaz/wiring-check.xml BlinkAppC.nc -lm

In file included from /opt/tinyos-2.x/tos/system/TinySchedulerC.nc:41:

In component `McuSleepC':

/opt/tinyos-2.x/tos/chips/atm128/McuSleepC.nc: In function `McuSleep.sleep':

/opt/tinyos-2.x/tos/chips/atm128/McuSleepC.nc:102: implicit declaration of 
function `pgm_read_byte'

make: *** [exe0] Error 1



I have found some reference to an include problem referring to pgmspace.h 
being able to fix this problem but I am not certain how to "include" this 
file into the program.



thanks for your assistance,

Calvin





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

Re: [Tinyos-help] Collection: Loosing Connection to a Node

[Omprakash Gnawali]

On Mon, Apr 7, 2008 at 10:21 PM, Bulut ERSAVAS <[EMAIL PROTECTED]> wrote:
> Omprakash,
>
> We increased the root beacon interval by adjusting the constants in CtpP.nc
> passed to CtpRoutingEngineP:
>
>  components new CtpRoutingEngineP(TREE_ROUTING_TABLE_SIZE, 10, 1024) as
> Router;

This should work but in the last few weeks we have found some other
reasons (loop, pull, etc) why there might be more beacons than you
think. The fix should be available in the CVS in about a week.


> In either case, I am afraid that the problem will not be reproduced. Is
> there any other way to snoop the beacons? I remember earlier emails in
> tinyos-help about snooping. Would placing a TelosB with a proper program
> help in this case?

You should use the BaseStation application to snoop the packets sent
by the "disconnected" mote. If that does not yield any clues, you can
redirect the debug messages to the radio instead of the serial
interface. For this, you need to wire UARTDebugSenderP to send using
the radio.

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

Re: [Tinyos-help] link metric

[renjie huang]

Thanks, Dr Phlip.

On 4/8/08, Philip Levis <[EMAIL PROTECTED]> wrote:
>
>
> On Apr 8, 2008, at 4:30 PM, renjie huang wrote:
>
> > Hi
> > Can someone share with me experience of what routing metric is better
> > when data rate is high?
> >
> > Currently I am using MultihopLQI. When the data rate is low, it works
> > well and topology is more stable. But when data rate is high, topology
> > changes very often. It may be due to interfence from concurrent
> > transmission.
> >
> > Using SNR as link indicator may also has the same problem. Can someone
> > give me any advice on this? I don't know whether TinyOS2 introduces some new
> > link metric.
> >
>
> Rodrigo, Om, Kyle and I (members of net2) published a paper on the topic
> last year:
>
> Rodrigo Fonseca, Omprakash Gnawali, Kyle Jamieson, and Philip Levis
> "Four-Bit Wireless Link Estimation." In Proceedings of the Sixth Workshop
> on Hot Topics in Networks (HotNets VI), 2007.
>
> The short answer: using information from the physical, link, and network
> layers is superior than staying at a single layer. The paper describes how
> CTP's link estimator works, although the parameters (alpha value) have
> changed since its publication.
>
> Phil
>



-- 
Renjie Huang
Sensorweb Research Laboratory
http://sensorweb.vancouver.wsu.edu/
Washington State University
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] link metric

[Philip Levis]

On Apr 8, 2008, at 4:30 PM, renjie huang wrote:
> Hi
> Can someone share with me experience of what routing metric is  
> better when data rate is high?
>
> Currently I am using MultihopLQI. When the data rate is low, it  
> works well and topology is more stable. But when data rate is high,  
> topology changes very often. It may be due to interfence from  
> concurrent transmission.
>
> Using SNR as link indicator may also has the same problem. Can  
> someone give me any advice on this? I don't know whether TinyOS2  
> introduces some new link metric.

Rodrigo, Om, Kyle and I (members of net2) published a paper on the  
topic last year:

Rodrigo Fonseca, Omprakash Gnawali, Kyle Jamieson, and Philip Levis
"Four-Bit Wireless Link Estimation." In Proceedings of the Sixth  
Workshop on Hot Topics in Networks (HotNets VI), 2007.

The short answer: using information from the physical, link, and  
network layers is superior than staying at a single layer. The paper  
describes how CTP's link estimator works, although the parameters  
(alpha value) have changed since its publication.

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

[Tinyos-help] link metric

[renjie huang]

Hi
Can someone share with me experience of what routing metric is better when
data rate is high?

Currently I am using MultihopLQI. When the data rate is low, it works well
and topology is more stable. But when data rate is high, topology changes
very often. It may be due to interfence from concurrent transmission.

Using SNR as link indicator may also has the same problem. Can someone give
me any advice on this? I don't know whether TinyOS2 introduces some new link
metric.
-- 
Renjie Huang
Sensorweb Research Laboratory
http://sensorweb.vancouver.wsu.edu/
Washington State University
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Error compiling Oscilloscope with IRIS mote

[Janos Sallai]

Eva,

 

Based on the compiler output you sent, you don't have the most recent CVS tree:

 

> /opt/tinyos-2.x/tos/interfaces/Packet.nc:108: previous declaration of 
> `Packet.getPayload'

 

Packet.getPayload should be on line 115 in the most recent version. It used to 
be on line 108 last December - probably this is the version you have. 

 

Please check out the whole T2 tree, not just the IRIS related folders.

 

Janos

 

From: Philip Levis [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 08, 2008 3:36 PM
To: Janos Sallai; Miklos Maroti
Subject: Fwd: [Tinyos-help] Error compiling Oscilloscope with IRIS mote

 

 


Begin forwarded message:





From: "Eva Maria Garcia" <[EMAIL PROTECTED]>

Date: April 8, 2008 11:21:59 AM PDT

To: 

Subject: [Tinyos-help] Error compiling Oscilloscope with IRIS mote

 

Hi everyone,

 

I'm working with IRIS motes on TinyOS 2.0.2 with the latest CVS tree. When I 
try to compile the Oscilloscope application, I encountered a series of compile 
errors. The compile information is listed at the end of this email.

 

Any idea?

 

Regards,

Eva

 

 

 

Compiling OscilloscopeAppC to a iris binary

ncc -o build/iris/main.exe -Os -Wall -Wshadow -Wnesc-all -target=iris 
-fnesc-cfile=build/iris/app.c -board=micasb 
-DIDENT_PROGRAM_NAME=\"OscilloscopeApp\" -DIDENT_USER_ID=\"xubuntos\" 
-DIDENT_HOSTNAME=\"xubuntos-tinyos\" -DIDENT_USER_HASH=0x00f95284L 
-DIDENT_UNIX_TIME=0x47fbb64dL -DIDENT_UID_HASH=0x747002abL -fnesc-dump=wiring 
-fnesc-dump='interfaces(!abstract())' -fnesc-dump='referenced(interfacedefs, 
components)' -fnesc-dumpfile=build/iris/wiring-check.xml OscilloscopeAppC.nc -lm

In file included from /opt/tinyos-2.x/tos/chips/rf230/DefaultPacketC.nc:45,

 from /opt/tinyos-2.x/tos/chips/rf230/DefaultMacC.nc:49,

 from /opt/tinyos-2.x/tos/platforms/iris/ActiveMessageC.nc:45,

 from OscilloscopeAppC.nc:22:

In component `DefaultPacketP':

/opt/tinyos-2.x/tos/chips/rf230/DefaultPacketP.nc:92: conflicting types for 
`Packet.getPayload'

/opt/tinyos-2.x/tos/interfaces/Packet.nc:108: previous declaration of 
`Packet.getPayload'

In file included from /opt/tinyos-2.x/tos/chips/rf230/DefaultMacC.nc:68,

 from /opt/tinyos-2.x/tos/platforms/iris/ActiveMessageC.nc:45,

 from OscilloscopeAppC.nc:22:

In component `ActiveMessageLayerC':

/opt/tinyos-2.x/tos/chips/rf230/ActiveMessageLayerC.nc:81: conflicting types 
for `AMSend.getPayload'

/opt/tinyos-2.x/tos/interfaces/AMSend.nc:125: previous declaration of 
`AMSend.getPayload'

/opt/tinyos-2.x/tos/chips/rf230/ActiveMessageLayerC.nc: In function 
`AMSend.getPayload':

/opt/tinyos-2.x/tos/chips/rf230/ActiveMessageLayerC.nc:82: too many arguments 
to function `SubSend.getPayload'

/opt/tinyos-2.x/tos/chips/rf230/ActiveMessageLayerC.nc: At top level:

/opt/tinyos-2.x/tos/chips/rf230/ActiveMessageLayerC.nc:41: 
`Snoop.payloadLength' not implemented

/opt/tinyos-2.x/tos/chips/rf230/ActiveMessageLayerC.nc:41: `Snoop.getPayload' 
not implemented

/opt/tinyos-2.x/tos/chips/rf230/ActiveMessageLayerC.nc:41: 
`Receive.payloadLength' not implemented

/opt/tinyos-2.x/tos/chips/rf230/ActiveMessageLayerC.nc:41: `Receive.getPayload' 
not implemented

In file included from /opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerC.nc:44,

 from /opt/tinyos-2.x/tos/chips/rf230/DefaultMacC.nc:69,

 from /opt/tinyos-2.x/tos/platforms/iris/ActiveMessageC.nc:45,

 from OscilloscopeAppC.nc:22:

In component `MessageBufferLayerP':

/opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerP.nc:230: conflicting types 
for `Send.getPayload'

/opt/tinyos-2.x/tos/interfaces/Send.nc:114: previous declaration of 
`Send.getPayload'

/opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerP.nc: In function 
`Send.getPayload':

/opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerP.nc:231: warning: passing 
argument 2 of `Packet.getPayload' makes pointer from integer without a cast

/opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerP.nc: In function 
`deliverTask.runTask':

/opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerP.nc:283: warning: passing 
argument 2 of `Packet.getPayload' makes pointer from integer without a cast

/opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerP.nc: At top level:

/opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerP.nc:48: 
`Receive.payloadLength' not implemented

/opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerP.nc:48: `Receive.getPayload' 
not implemented

In file included from /opt/tinyos-2.x/tos/chips/rf230/UniqueLayerC.nc:43,

 from /opt/tinyos-2.x/tos/chips/rf230/DefaultMacC.nc:70,

 from /opt/tinyos-2.x/tos/platforms/iris/ActiveMessageC.nc:45,

 from OscilloscopeAppC.nc:22:

In component `UniqueLayerP':

/opt/tinyos-2.x/tos/chips/rf230/UniqueLayerP.nc:80: conflicting types for 
`Send.getPayload'

/opt/tinyos-2.x/tos/interfaces/Send.nc:114: previous declaration of 
`Send.getPaylo

[Tinyos-help] [tinyos-help] imote2 toolchain for tos-1.x

[Ian Freeman]

I'm having some difficulties getting tinyos-1.x to work with imote2.

I exactly followed the instructions at 
http://www.eecs.harvard.edu/~konrad/projects/imote2Camera/IMote2-Installation-Instructions.html 
and after some fiddling with source files in beta/platform I got it to 
compile up to the point in the attached shell output (tos1build.txt). Patch 
file attached; to be run as `patch -p0 /opt/tinyos-1.x/beta/platform.


I have no modifications to $TOSDIR different than the cvs version.

Compiling Blink for another platform such as micaz of course works. Is there 
something I'm missing to get rid of these nesC errors at the end of the 
build output?


My environment particulars:
#uname -a
Linux xubuntu-tos 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 
GNU/Linux


#xscale-elf-gcc -v
Reading specs from /usr/local/lib/gcc/xscale-elf/3.4.4/specs
Configured with: 
../configure --target=xscale-elf --prefix=/usr/local --with-gnu-as --with-gnu-ld 
--enable-languages=c

Thread model: single
gcc version 3.4.4

Thank you. 

make imote2
mkdir -p build/imote2
xscale-elf-as -mcpu=iwmmxt -mfpu=softfpa -defsym BOOTLOADER=1 
/opt/tinyos-1.x/tos/platform/pxa27x/../imote2/flash.s 
/opt/tinyos-1.x/tos/platform/pxa27x/../imote2/binarymover.s 
/opt/tinyos-1.x/tos/platform/pxa27x/barecrt.s 
/opt/tinyos-1.x/tos/platform/pxa27x/mmu_table.s 
/opt/tinyos-1.x/tos/platform/pxa27x/util.s  -o build/imote2/asms.o

cd /opt/tinyos-1.x/tos/platform/pxa27x/lib; make;
make[1]: Entering directory `/opt/tinyos-1.x/beta/platform/pxa27x/lib'
xscale-elf-gcc -g -O2 -Wall -I/opt/tinyos-1.x/tos/platform/pxa27x 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/DSP 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/   -c -o bufferManagement.o 
bufferManagement.c

In file included from bufferManagement.c:2:
assert.h:8: warning: `C' attribute directive ignored
In file included from bufferManagement.c:4:
systemUtil.h:28: warning: `C' attribute directive ignored
systemUtil.h:28: warning: `spontaneous' attribute directive ignored
xscale-elf-gcc -g -O2 -Wall -I/opt/tinyos-1.x/tos/platform/pxa27x 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/DSP 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/   -c -o downsample.o 
downsample.c
xscale-elf-gcc -g -O2 -Wall -I/opt/tinyos-1.x/tos/platform/pxa27x 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/DSP 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/   -c -o frequency.o 
frequency.c
xscale-elf-gcc -g -O2 -Wall -I/opt/tinyos-1.x/tos/platform/pxa27x 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/DSP 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/   -c -o paramtask.o 
paramtask.c

In file included from paramtask.c:4:
systemUtil.h:28: warning: `C' attribute directive ignored
systemUtil.h:28: warning: `spontaneous' attribute directive ignored
xscale-elf-gcc -g -O2 -Wall -I/opt/tinyos-1.x/tos/platform/pxa27x 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/DSP 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/   -c -o profile.o profile.c
xscale-elf-gcc -g -O2 -Wall -I/opt/tinyos-1.x/tos/platform/pxa27x 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/DSP 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/   -c -o queue.o queue.c
xscale-elf-gcc -g -O2 -Wall -I/opt/tinyos-1.x/tos/platform/pxa27x 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/DSP 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/   -c -o systemUtil.o 
systemUtil.c

In file included from systemUtil.c:2:
systemUtil.h:28: warning: `C' attribute directive ignored
systemUtil.h:28: warning: `spontaneous' attribute directive ignored
xscale-elf-gcc -g -O2 -Wall -I/opt/tinyos-1.x/tos/platform/pxa27x 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/DSP 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/   -c -o utils.o utils.c
xscale-elf-gcc -g -O2 -Wall -I/opt/tinyos-1.x/tos/platform/pxa27x 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/DSP 
-I/opt/tinyos-1.x/tos/platform/pxa27x/lib/   -c -o wmmx.o wmmx.c
xscale-elf-ar  -rvs libimote2.a bufferManagement.o downsample.o 
frequency.o paramtask.o profile.o queue.o systemUtil.o utils.o wmmx.o

r - bufferManagement.o
r - downsample.o
r - frequency.o
r - paramtask.o
r - profile.o
r - queue.o
r - systemUtil.o
r - utils.o
r - wmmx.o
make[1]: Leaving directory `/opt/tinyos-1.x/beta/platform/pxa27x/lib'
   compiling Blink to a imote2 binary
ncc -o build/imote2/main.exe -O1 -g 
-I/opt/tinyos-1.x/tos/lib/CC2420Radio -I/opt/tinyos-1.x/tos/lib/Flash 
-DAUTO_BATTERY_MONITORING=1 -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x7d 
-Wnesc-all -target=imote2 -fnesc-cfile=build/imote2/app.c -board= 
-DBOOTLOADER -DIDENT_PROGRAM_NAME=\"Blink\" 
-DIDENT_USER_ID=\"ifreeman\" -DIDENT_HOSTNAME=\"xubuntu-tos\" 
-DIDENT_USER_HASH=0xb3e68d44L -DIDENT_UNIX_TIME=0x47fb40bdL 
-DIDENT_UID_HASH=0x8728271aL Blink.nc -lm build/imote2/asms.o 
/opt/tinyos-1.x/tos/platform/pxa27x/lib/libimote2.a

In file included from /opt/tinyos-1.x/tos/system/Main.nc:49,
from Blink.nc:42:
In component `PotC':
/opt/tinyos-1.x/tos/system/PotC.nc:90: component HPLPotC not found
/opt/tinyos-1.x/tos/system/PotC.nc:93: no match
In file included from 

Re: [Tinyos-help] Package for Freescale HCS08 and MC1319x

[Frederic Beaulieu]

The HCS08 seems to be used with the Telos platform a few years ago.
Anybody having the conversion script for CodeWarrior and/or chip package?


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frederic Beaulieu
Sent: Tuesday, April 08, 2008 1:53 PM
To: (tinyos-help@millennium.berkeley.edu)
Subject: [Tinyos-help] Package for Freescale HCS08 and MC1319x

Hi all,

Anybody know if there is somewhere a package for interfacing Freescale HCS08 
MCU and MC1319x transceiver?
If not, I will probably create it. Let me know if someone interested!

.:Fred

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

Re: [Tinyos-help] OscilloscopeRF writes data slow

[Michael Schippling]

I'm cc'ing this back to the help list to keep a record of my mistakes...

Yes, TOS 1.1.10 is the version where "they" supported micaz and put an
almost invisible clamp at 3ms in the Timer setting. 3ms should be way
shorter than you need in your application, but it doesn't work below that.

As I usually say, everything is (im)possible with software. To the extent
that you will be modifying .nc files you will need to do nesC coding,
however changing a value in the Timer and doing a range comparison is
basic C, so it shouldn't be too hard. Meaning: no config file mods.

mica2's can send about 25 messages/sec so the minimum cycle is about
40 or 50 ms. That's why I suggested the range discriminator. Do your
samples as fast as you can and then check them for some kind of on-off
change and only send a message when that happens. The Oscope program
aggregates a bunch of samples before sending so you'll probably want
to change that behavior as well.

It's a great adventure...

MS



Matthew Melucci wrote:
> Thank you for your response. I am new to this stuff. First what is
> T1.1.10? Is that the tinyos version? Also how can you find the message
> transmit time? And one more question. With the Oscilloscope the data
> is constantly changing. Even with the laser pointed at it. It never
> stays constant but it does still stay in a certain area. Will the
> discriminator still work for that? And will all this involve doing
> nesC coding? Thank you so much for the response!!
> 
> On Tue, Apr 8, 2008 at 1:47 PM, Michael Schippling <[EMAIL PROTECTED]> wrote:
>> Look for this in OscilloscopeM.nc::start():
>> call Timer.start(TIMER_REPEAT, 125);
>>
>> The 125 argument is the number of "binary milli-seconds" to wait
>> between sample cycles. If you are using >= T1.1.10 the minimum
>> value for this is 3. However if you run that fast you will overrun
>> the message transmit time, so you probably want to put a discriminator
>> on the sampled data and only send a message when it changes.
>>
>> MS
>>
>> Matthew Melucci wrote:
>>>
>>>
>>> Is there a way to speed up how fast it gets data and writes it? I use
>>> mica2 and use Listen > output to write to a file. I have an app I
>>> wrote that tracks people entering and exiting through an area. I point
>>> a laser at the sensor and if it gets cut from someone walking through
>>> it and breaking it I record it. But the problem is it only works if
>>> they break the beam for so long. A quick break isn't recorded. Is
>>> there a way to fix this? Thanks!!!
>>> ___
>>> Tinyos-help mailing list
>>> Tinyos-help@millennium.berkeley.edu
>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>>
>> --
>> Platform: WinXP/Cygwin
>> TinyOS version: 1.x, Boomerang
>> Programmer: MIB510
>> Device(s): Mica2, MicaZ, Tmote
>> Sensor board: homebrew
>>
>>

-- 
Platform: WinXP/Cygwin
TinyOS version: 1.x, Boomerang
Programmer: MIB510
Device(s): Mica2, MicaZ, Tmote
Sensor board: homebrew

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

Re: [Tinyos-help] [tinyos-help] help plz multihopLEPSM

[Omprakash Gnawali]

I suggest looking at CTP in TinyOS 2.x - the code there has more
comments, there are more documents describing the protocol, and the
code borrows some parts from the TinyOS 1.x routing protocols you
mention.

- om_p

On Tue, Apr 8, 2008 at 8:33 AM, dima . <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
>
> hello all , plz i need the best help i can get
>
>
>
>  i am working on impelemting a rounting algorithm and i am trying to
> understand the multihopeRoute so i could change in it ino my algorithm
> called DSAP am I on the right way to do this ???
>
>
>
> could anyone help me to find the answer about these questions??
>
>
>
> -in multihopLEPSM :
>
>
>
>
>
>
>
> -what the difference in  Origin address and Source address in the AM message
> and there's already in the TOS_Msg  struncture  the field  addr (address)?
>
>
>
> -why do I need the flags?  NBRFLAG_VALID, NBRFALG_NEW , NBRFLAG_EST_INIT …?
>
>
>
> -what the difference between a forwarded packet and an originated one?
>
>
>
> -what's the use for The struct RPEstEntry, sortEntry ?
>
>
>
> -the struct RoutePacket and its  fields "EstEntries" and "RPestEntry
> estlist[1]"  are used for what ?
>
>
>
> -what is the meaning of evicting a "previous entry" and "evicts the parent "
> in  this sentence??
>
> "
>
> Get neighbor table entry corresponding to the given address.
>
>* If current entry doesn't exist, then create one, possibly
>
>* evicting a previous entry.
>
>* XXX - what if it evicts the parent???
>
>
>
>
>
> -what does the function sortByReceiveEstFcn do ?
>
>
>
> -when do I need to update the neighbor table?
>
>
>
> -what does the function SendRouteTask () do ?
>
> i didnt understand its impelentation espacillay the lines in RED
>
> _  task void SendRouteTask() {
>
> TOS_MHopMsg *pMHMsg = (TOS_MHopMsg *) &routeMsg.data[0];
>
> RoutePacket *pRP = (RoutePacket *)&pMHMsg->data[0];
>
> struct SortEntry sortTbl[ROUTE_TABLE_SIZE];
>
> uint8_t length = offsetof(TOS_MHopMsg,data) +
> offsetof(RoutePacket,estList);
>
> uint8_t maxEstEntries;
>
> uint8_t i,j;
>
>
>
> if (gfSendRouteBusy) {
>
>   return;
>
> }
>
>
>
> dbg(DBG_ROUTE,"MultiHopLEPSM Sending route update msg.\n");
>
>
>
> maxEstEntries = TOSH_DATA_LENGTH - length;
>
> maxEstEntries = maxEstEntries / sizeof(RPEstEntry);
>
>
>
> for (i = 0,j = 0;i < ROUTE_TABLE_SIZE; i++) {
>
>   if (NeighborTbl[i].flags & NBRFLAG_VALID) {
>
> sortTbl[j].id = NeighborTbl[i].id;
>
> sortTbl[j].receiveEst = NeighborTbl[i].receiveEst;
>
> j++;
>
>   }
>
> }
>
> qsort (sortTbl,j,sizeof(struct SortEntry),sortByReceiveEstFcn);
>
>
>
>.
>
> .}
>
>
>
> thanx alot and best wishes for all
>
>
>
> DIMA
>
>
>
> 
> Connect to the next generation of MSN Messenger  Get it now!
> ___
>  Tinyos-help mailing list
>  Tinyos-help@millennium.berkeley.edu
>  https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>

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

[Tinyos-help] Error compiling Oscilloscope with IRIS mote

[Eva Maria Garcia]

Hi everyone,

 

I’m working with IRIS motes on TinyOS 2.0.2 with the latest CVS tree. When I
try to compile the Oscilloscope application, I encountered a series of
compile errors. The compile information is listed at the end of this email.

 

Any idea?

 

Regards,

Eva

 

 

 

Compiling OscilloscopeAppC to a iris binary

ncc -o build/iris/main.exe -Os -Wall -Wshadow -Wnesc-all -target=iris
-fnesc-cfile=build/iris/app.c -board=micasb
-DIDENT_PROGRAM_NAME=\"OscilloscopeApp\" -DIDENT_USER_ID=\"xubuntos\"
-DIDENT_HOSTNAME=\"xubuntos-tinyos\" -DIDENT_USER_HASH=0x00f95284L
-DIDENT_UNIX_TIME=0x47fbb64dL -DIDENT_UID_HASH=0x747002abL
-fnesc-dump=wiring -fnesc-dump='interfaces(!abstract())'
-fnesc-dump='referenced(interfacedefs, components)'
-fnesc-dumpfile=build/iris/wiring-check.xml OscilloscopeAppC.nc -lm 

In file included from /opt/tinyos-2.x/tos/chips/rf230/DefaultPacketC.nc:45,

 from /opt/tinyos-2.x/tos/chips/rf230/DefaultMacC.nc:49,

 from
/opt/tinyos-2.x/tos/platforms/iris/ActiveMessageC.nc:45,

 from OscilloscopeAppC.nc:22:

In component `DefaultPacketP':

/opt/tinyos-2.x/tos/chips/rf230/DefaultPacketP.nc:92: conflicting types for
`Packet.getPayload'

/opt/tinyos-2.x/tos/interfaces/Packet.nc:108: previous declaration of
`Packet.getPayload'

In file included from /opt/tinyos-2.x/tos/chips/rf230/DefaultMacC.nc:68,

 from
/opt/tinyos-2.x/tos/platforms/iris/ActiveMessageC.nc:45,

 from OscilloscopeAppC.nc:22:

In component `ActiveMessageLayerC':

/opt/tinyos-2.x/tos/chips/rf230/ActiveMessageLayerC.nc:81: conflicting types
for `AMSend.getPayload'

/opt/tinyos-2.x/tos/interfaces/AMSend.nc:125: previous declaration of
`AMSend.getPayload'

/opt/tinyos-2.x/tos/chips/rf230/ActiveMessageLayerC.nc: In function
`AMSend.getPayload':

/opt/tinyos-2.x/tos/chips/rf230/ActiveMessageLayerC.nc:82: too many
arguments to function `SubSend.getPayload'

/opt/tinyos-2.x/tos/chips/rf230/ActiveMessageLayerC.nc: At top level:

/opt/tinyos-2.x/tos/chips/rf230/ActiveMessageLayerC.nc:41:
`Snoop.payloadLength' not implemented

/opt/tinyos-2.x/tos/chips/rf230/ActiveMessageLayerC.nc:41:
`Snoop.getPayload' not implemented

/opt/tinyos-2.x/tos/chips/rf230/ActiveMessageLayerC.nc:41:
`Receive.payloadLength' not implemented

/opt/tinyos-2.x/tos/chips/rf230/ActiveMessageLayerC.nc:41:
`Receive.getPayload' not implemented

In file included from
/opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerC.nc:44,

 from /opt/tinyos-2.x/tos/chips/rf230/DefaultMacC.nc:69,

 from
/opt/tinyos-2.x/tos/platforms/iris/ActiveMessageC.nc:45,

 from OscilloscopeAppC.nc:22:

In component `MessageBufferLayerP':

/opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerP.nc:230: conflicting
types for `Send.getPayload'

/opt/tinyos-2.x/tos/interfaces/Send.nc:114: previous declaration of
`Send.getPayload'

/opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerP.nc: In function
`Send.getPayload':

/opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerP.nc:231: warning: passing
argument 2 of `Packet.getPayload' makes pointer from integer without a cast

/opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerP.nc: In function
`deliverTask.runTask':

/opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerP.nc:283: warning: passing
argument 2 of `Packet.getPayload' makes pointer from integer without a cast

/opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerP.nc: At top level:

/opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerP.nc:48:
`Receive.payloadLength' not implemented

/opt/tinyos-2.x/tos/chips/rf230/MessageBufferLayerP.nc:48:
`Receive.getPayload' not implemented

In file included from /opt/tinyos-2.x/tos/chips/rf230/UniqueLayerC.nc:43,

 from /opt/tinyos-2.x/tos/chips/rf230/DefaultMacC.nc:70,

 from
/opt/tinyos-2.x/tos/platforms/iris/ActiveMessageC.nc:45,

 from OscilloscopeAppC.nc:22:

In component `UniqueLayerP':

/opt/tinyos-2.x/tos/chips/rf230/UniqueLayerP.nc:80: conflicting types for
`Send.getPayload'

/opt/tinyos-2.x/tos/interfaces/Send.nc:114: previous declaration of
`Send.getPayload'

/opt/tinyos-2.x/tos/chips/rf230/UniqueLayerP.nc: In function
`Send.getPayload':

/opt/tinyos-2.x/tos/chips/rf230/UniqueLayerP.nc:81: too many arguments to
function `SubSend.getPayload'

make: *** [exe0] Error 1

 

 

 


cid:image001.gif@01C7372E.BEA5F900

 Departmento de 
 Sistemas Informáticos


Eva María García
Profesora Asociada
  [EMAIL PROTECTED]

Teléfono: +34 967 599 200 (ext. 2495)
Dirección:
Escuela Politécnica Superior de Albacete
Campus Universitario
Avenida de España s/n 
02071 – Albacete (ESPAÑA)
Web:   www.uclm.es

 

 

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

[Tinyos-help] Package for Freescale HCS08 and MC1319x

[Frederic Beaulieu]

Hi all,

Anybody know if there is somewhere a package for interfacing Freescale HCS08 
MCU and MC1319x transceiver?
If not, I will probably create it. Let me know if someone interested!

.:Fred

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

Re: [Tinyos-help] OscilloscopeRF writes data slow

[Michael Schippling]

Look for this in OscilloscopeM.nc::start():
  call Timer.start(TIMER_REPEAT, 125);

The 125 argument is the number of "binary milli-seconds" to wait
between sample cycles. If you are using >= T1.1.10 the minimum
value for this is 3. However if you run that fast you will overrun
the message transmit time, so you probably want to put a discriminator
on the sampled data and only send a message when it changes.

MS

Matthew Melucci wrote:
> Is there a way to speed up how fast it gets data and writes it? I use
> mica2 and use Listen > output to write to a file. I have an app I
> wrote that tracks people entering and exiting through an area. I point
> a laser at the sensor and if it gets cut from someone walking through
> it and breaking it I record it. But the problem is it only works if
> they break the beam for so long. A quick break isn't recorded. Is
> there a way to fix this? Thanks!!!
> ___
> Tinyos-help mailing list
> Tinyos-help@millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

-- 
Platform: WinXP/Cygwin
TinyOS version: 1.x, Boomerang
Programmer: MIB510
Device(s): Mica2, MicaZ, Tmote
Sensor board: homebrew

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

Re: [Tinyos-help] Resource.reserve returns EBUSY forever after some time

[Kevin Klues]

Hmmm, yes, there were some changes to interface semantics for some
fairly important interfaces (like Receive!) between 2.0.2 and the CVS
head.   While the changes are somewhat minimal (i.e. you have to add a
particular parameter to some interfaces, and change the value you pass
to others), code written for 2.0.2 will not compile immediately after
updating to cvs.  If you don't want to go through this process (which
you might eventually anyway if you ever plan on upgrading to newer
version of TinyOS in the future), then just checking out a new
tos/chips/msp430/adc12 directory  might be your best bet.

Kevin

On Tue, Apr 8, 2008 at 8:51 AM, Eric Keller <[EMAIL PROTECTED]> wrote:
> If I update to the CVS version from TinyOS-2.0.2, does that affect my
>  toolset and code?
>  Should I just check out the ADC12 directory?
>  Eric
>
>
>
>  On Mon, Apr 7, 2008 at 6:07 AM, Jan Hauer <[EMAIL PROTECTED]> wrote:
>  > I reproduced Sandip's problem and tracked it down to a bug in the ADC
>  >  HAL (the overflow interrupt was not handled properly). This is now
>  >  fixed in CVS as well as the bug reported some time ago about the
>  >  ReadStream not working with a "usPeriod" parameter > 0x.
>  >
>  >  Jan
>  >
>  >
>  >
>  >  On Sat, Mar 29, 2008 at 5:21 PM, Jan Hauer <[EMAIL PROTECTED]> wrote:
>  >  >
>  >  > >  > You should make sure that you don't call Resource.request() while
>  >  >  >  > you're still owner. You could do it by keeping state in some 
> module
>  >  >  >  > variable, but you could also do it through "if (!call
>  >  >  >  > Resource.isOwner()) call Resource.request();" in your 
> Timer.fired().
>  >  >  >  > Note that this means, that your samples might not be taken at 
> regular
>  >  >  >  > intervals (you lose a sample when isOwner() returns FALSE)
>  >  >  >
>  >  >  >
>  >  >  >  That's not right. It should be valid to request while owner: this
>  >  >  >  enqueues a request, which will be serviced (after possibly others)
>  >  >  >  once release() is called. TEP 108 is very clear on this.
>  >  >
>  >  >  Of course you can request while you're already owner and the first
>  >  >  time you do it, it will succeed (will queue the request). I was trying
>  >  >  to find a quick solution for the given problem, not giving a general
>  >  >  rule, maybe that was not clear.
>  >  >  There is a known potential race condition if  you call release after
>  >  >  you've requested but before you've gotten the granted() event (see
>  >  >  @note in Resource.nc). Looking at the code snippet this should not
>  >  >  happen, but then the snippet is not the real code
>  >  >  (MultiChannel.dataReady is async) - Sandip, can you please post the
>  >  >  exact code you're running?
>  >  >
>  >  >  Jan
>  >  >
>  >  ___
>  >  Tinyos-help mailing list
>  >  Tinyos-help@millennium.berkeley.edu
>  >  https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>  >
>  ___
>  Tinyos-help mailing list
>  Tinyos-help@millennium.berkeley.edu
>  https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>



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

[Tinyos-help] Broken link in website

[Dimas Abreu Dutra]

Hello,

in the TinyOS website,
http://www.tinyos.net/scoop/special/working_groupsthe TEP 3 link
points to
http://www.tinyos.net/tinyos-2.x/doc/html/tep3.txt which does not exist. The
correct link should be http://www.tinyos.net/tinyos-2.x/doc/html/tep3.html .

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

Re: [Tinyos-help] tos install jni cygwin

[Ittipong Khemapech]

Hi,

Take a look at this:
http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2007-November/029359.html

Hope it helps.

Ittipong

On 08/04/2008, Jack Travis <[EMAIL PROTECTED]> wrote:
>
> Hi, anybody ever got this error
>
> $ tos-install-jni
> Installing 32-bit Java JNI code in /cygdrive/c/Program
> Files/Java/jdk1.5.0_15/jre/bin ...
> install: cannot stat `/usr/lib/tinyos/*-32.dll': No such file or directory
>
> (There is effectivly no /usr/lib/tinyos/ dir and copying /lib/tinyos/ to
> that location did not solve it.
>
> the locate is OK
> $ tos-locate-jre --jni
> /cygdrive/c/Program Files/Java/jdk1.5.0_15/jre/bin
>
> Thanks
> Jack T
>
> ___
> Tinyos-help mailing list
> Tinyos-help@millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] OscilloscopeRF writes data slow

[Matthew Melucci]

Is there a way to speed up how fast it gets data and writes it? I use
mica2 and use Listen > output to write to a file. I have an app I
wrote that tracks people entering and exiting through an area. I point
a laser at the sensor and if it gets cut from someone walking through
it and breaking it I record it. But the problem is it only works if
they break the beam for so long. A quick break isn't recorded. Is
there a way to fix this? Thanks!!!
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] tos install jni cygwin

[Jack Travis]

Forget last question got it renaming the toscomm.dll to toscomm-32.dll
and copying the directory to `/usr/lib/tinyos/
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] [Tinyos-devel] Fwd: About java toolchain for T2 andmessage source

[Dimas Abreu Dutra]

Great! The message.getSerialPacket()  solves the problem of getting the
source and even other issues like getting the group the message sender
belongs to. An interface redesign will, with no doubt, cause older programs
to stop working, so I believe that the current solution offers the best
compromise.

~Dimas~

On 4/6/08, David Moss <[EMAIL PROTECTED]> wrote:
>
> This isn't the first time we have discussed this issue.  Although I think
> the interface is not ideal as it exists right now, a patch has already
> been
> implemented that allows a developer to access the source address without
> the
> need to change the interface and break existing code.
>
> All packet information, including everything in the packet's header, is
> available in the SerialPacket that the Message was created from.  The fix
> that was implemented months ago allows you to access the original
> SerialPacket from the Message you received. From the SerialPacket, you can
> access that source address and any other header information you want.
> i.e...
>
> public void messageReceived(int to, Message message) {
>   int source = message.getSerialPacket().get_header_src();
>   //...
> }
>
> If an interface change is in store, maybe the solution is to provide a
> Message and its original SerialPacket so you can access whatever you want,
> and not limit things to just the source or destination address.  A
> completely and painful redesign might allow all the information to be
> accessed directly through the Message.
>
> public void messageReceived(Message message, SerialPacket packet) {
>   int source = packet.get_header_src();
> }
>
> You can get at anything you want to as the code exists now, and that is
> probably be a better solution than changing the interface and causing code
> management problems throughout the community.  A new major revision of
> TinyOS will be able to get away with safely fixing that interface, if
> there's consensus to do so.
>
> -moss
>
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Writing to the serial port

[antonio gonga]

Hey all,
I'm trying to create a Packet analyzer in nesc/tinyos like Whireshark. I 
started by modifying the BaseStation. My first approach was to resize the 
messages at the BS so that a timestamp and other relevant packet header fields 
could be inserted into the payload. This allows the Java parser to decode any 
type of fields in the incoming message. I also use a configuration file(XML) 
that indicates the position and size of some fields in the incoming array of 
bytes.
 
The process of resizing seems to consume so much time because it creates an 
additional packet, so I decide to relay the data traffic as the BaseStation 
does, and to send an addicional packet containing the timestamp and other 
header fields for each received packet. In both cases I use a circular buffer 
as the input buffer. It does not work as I expect it to work. The problem seems 
to be in the part sending to the serial port.
My question is: What´s the maximum number of packets can I send to the serial 
Interface? I'm testing the sniffer with a sensor sending data as fast as it 
can, but It seems that the Sniffer does not handle all the incoming packets. I 
do store them into an input buffer, but the speed of sending to the serial port 
seems to be the main issue.
 
Is it possible to use or write directly to the serial port from a nesc App 
without using the serialActiveMessageC component?
I'm thinking to embed a C code into a nesC app, so that I could access directly 
to the UART, and send the packet as sequence of bytes as It arrives.
 
Thanks in Advance.
-Antonio
 
 
_
Connect to the next generation of MSN Messenger 
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] (no subject)

[Razvan Musaloiu-E.]

Hi!

On Tue, 8 Apr 2008, subhash nemani wrote:

> hi
> how can i measure the supply voltage(battery) of the tmote, without using
> any of the  ADC ports because for all the ADC ports sensors are connected,
>
> is there any software command to directly get the supply voltage of tmote???

The VoltageC component from tos/platforms/telosb doesn't use any external 
ports. This is what you are looking for?

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

[Tinyos-help] tos install jni cygwin

[Jack Travis]

Hi, anybody ever got this error

$ tos-install-jni
Installing 32-bit Java JNI code in /cygdrive/c/Program
Files/Java/jdk1.5.0_15/jre/bin ...
install: cannot stat `/usr/lib/tinyos/*-32.dll': No such file or directory

(There is effectivly no /usr/lib/tinyos/ dir and copying /lib/tinyos/ to
that location did not solve it.

the locate is OK
$ tos-locate-jre --jni
/cygdrive/c/Program Files/Java/jdk1.5.0_15/jre/bin

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

Re: [Tinyos-help] Resource.reserve returns EBUSY forever after some time

[Eric Keller]

If I update to the CVS version from TinyOS-2.0.2, does that affect my
toolset and code?
Should I just check out the ADC12 directory?
Eric

On Mon, Apr 7, 2008 at 6:07 AM, Jan Hauer <[EMAIL PROTECTED]> wrote:
> I reproduced Sandip's problem and tracked it down to a bug in the ADC
>  HAL (the overflow interrupt was not handled properly). This is now
>  fixed in CVS as well as the bug reported some time ago about the
>  ReadStream not working with a "usPeriod" parameter > 0x.
>
>  Jan
>
>
>
>  On Sat, Mar 29, 2008 at 5:21 PM, Jan Hauer <[EMAIL PROTECTED]> wrote:
>  >
>  > >  > You should make sure that you don't call Resource.request() while
>  >  >  > you're still owner. You could do it by keeping state in some module
>  >  >  > variable, but you could also do it through "if (!call
>  >  >  > Resource.isOwner()) call Resource.request();" in your Timer.fired().
>  >  >  > Note that this means, that your samples might not be taken at regular
>  >  >  > intervals (you lose a sample when isOwner() returns FALSE)
>  >  >
>  >  >
>  >  >  That's not right. It should be valid to request while owner: this
>  >  >  enqueues a request, which will be serviced (after possibly others)
>  >  >  once release() is called. TEP 108 is very clear on this.
>  >
>  >  Of course you can request while you're already owner and the first
>  >  time you do it, it will succeed (will queue the request). I was trying
>  >  to find a quick solution for the given problem, not giving a general
>  >  rule, maybe that was not clear.
>  >  There is a known potential race condition if  you call release after
>  >  you've requested but before you've gotten the granted() event (see
>  >  @note in Resource.nc). Looking at the code snippet this should not
>  >  happen, but then the snippet is not the real code
>  >  (MultiChannel.dataReady is async) - Sandip, can you please post the
>  >  exact code you're running?
>  >
>  >  Jan
>  >
>  ___
>  Tinyos-help mailing list
>  Tinyos-help@millennium.berkeley.edu
>  https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] [tinyos-help] help plz multihopLEPSM

[dima .]

 
 
hello all , plz i need the best help i can get 
 
 i am working on impelemting a rounting algorithm and i am trying to understand 
the multihopeRoute so i could change in it ino my algorithm called DSAP am I on 
the right way to do this ???
 
could anyone help me to find the answer about these questions??
 
-in multihopLEPSM :
 
 
 
-what the difference in  Origin address and Source address in the AM message 
and there's already in the TOS_Msg  struncture  the field  addr (address)?
 
-why do I need the flags?  NBRFLAG_VALID, NBRFALG_NEW , NBRFLAG_EST_INIT …?
 
-what the difference between a forwarded packet and an originated one?
 
-what's the use for The struct RPEstEntry, sortEntry ?
 
-the struct RoutePacket and its  fields "EstEntries" and "RPestEntry  
estlist[1]"  are used for what ?
 
-what is the meaning of evicting a "previous entry" and "evicts the parent " in 
 this sentence??
"
Get neighbor table entry corresponding to the given address.
   * If current entry doesn't exist, then create one, possibly
   * evicting a previous entry. 
   * XXX - what if it evicts the parent???
 
 
-what does the function sortByReceiveEstFcn do ?
 
-when do I need to update the neighbor table?
 
-what does the function SendRouteTask () do ?
i didnt understand its impelentation espacillay the lines in RED
_  task void SendRouteTask() {
TOS_MHopMsg *pMHMsg = (TOS_MHopMsg *) &routeMsg.data[0];
RoutePacket *pRP = (RoutePacket *)&pMHMsg->data[0];
struct SortEntry sortTbl[ROUTE_TABLE_SIZE];
uint8_t length = offsetof(TOS_MHopMsg,data) + offsetof(RoutePacket,estList);
uint8_t maxEstEntries;
uint8_t i,j;
 
if (gfSendRouteBusy) {
  return;
}
 
dbg(DBG_ROUTE,"MultiHopLEPSM Sending route update msg.\n");
 
maxEstEntries = TOSH_DATA_LENGTH - length;
maxEstEntries = maxEstEntries / sizeof(RPEstEntry);
 
for (i = 0,j = 0;i < ROUTE_TABLE_SIZE; i++) {
  if (NeighborTbl[i].flags & NBRFLAG_VALID) {
sortTbl[j].id = NeighborTbl[i].id;
sortTbl[j].receiveEst = NeighborTbl[i].receiveEst;
j++;
  }
}
qsort (sortTbl,j,sizeof(struct SortEntry),sortByReceiveEstFcn);
 
   .
.}
 
thanx alot and best wishes for all
 
DIMA
 
_
Connect to the next generation of MSN Messenger 
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Resource.reserve returns EBUSY forever after some time

[John Griessen]

Kevin Klues wrote:
> Awesome. :)
> 
> Kevin
> 
> On Mon, Apr 7, 2008 at 3:07 AM, Jan Hauer <[EMAIL PROTECTED]> wrote:
>> I reproduced Sandip's problem and tracked it down to a bug in the ADC
>>  HAL (the overflow interrupt was not handled properly). 

Great!

John G

-- 
Ecosensory   Austin TX
tinyOS devel on:  ubuntu Linux;   tinyOS v2.0.2;   telosb ecosens1
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Minimizing RAM consmption

[Alban Hessler]

Another tweak that we used in our project is to have a central message
pool (using the Pool interface). That way, not each component declares
his own buffer for the messages, but it's only done once at one place.
But then you have to handle the possibility that there is no buffer
available -> slighly increases the program memory and complexity.

Also, if an array is representing a constant, uses the constant key
word in front of the declaration. For mica family (AVR) programs, you
have to use a macro call (PROGMEM or something like that) in addition
to constant..

Alban

2008/4/8, Michiel Konstapel <[EMAIL PROTECTED]>:
>
>
>
> Tweak your TOSH_DATA_LENGTH to be just big enough for your payloads so you
> don't waste memory on packet buffers.
>  Michiel
>
>
>  -Original Message-
>  From: [EMAIL PROTECTED] on
> behalf of Flavio Pompermaier
>  Sent: Tue 4/8/2008 10:52 AM
>  To: Tinyos
>  Subject: [Tinyos-help] Minimizing RAM  consmption
>
>  Hi,
>  I would like to know if there's any document reporting all possible
> enhancements focused in minimizing RAM consumption on Tmotes.
>  And why components variables are stored in RAM whereas function local
> variable are stored in ROM?? Shouldn't be the viceversa?
>
>  Some suggestions I found for RAM consumption minimizing are:
>  - use enum for constants instead of variables
>  - avoiding signalling from command/events
> -  do not use enum variables
>  others?
>
>  Thanks,
>  Flavio
>
>
>
>
>Inviato da Yahoo! Mail.
>  La casella di posta intelligente.
>  http://it.docs.yahoo.com/mail/overview/index.html
>
>
>
>
> ___
>  Tinyos-help mailing list
>  Tinyos-help@millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] Software multiplication: problems on TelosB

[Alban Hessler]

Hi,

 We have been running into a weird bug with the Telos motes, using
msp-gcc 3.2.3 .

 We are using for a node election protocol the random generator of
tinyOS, RandomMlcg. (We also tried RandomLfsr, the problem remains).
 The motes will crash (hang) after the second call to random. In our
code, we call 32-operations at two different places (random and
distance calculation). We tried several work-arounds and here are the
symptoms:

 - Running the code on Micaz, the mote does not crash and the protocol
works fine.
 - As well, the protocol runs fine on TOSSIM.
 - If we comment out the call to the random generator, or the other
32-bits multiplication (distance computation, see below), the mote
does not crash.
 - If we replace the sèpeudo random generator code with a simple one (e.g.
  return seed++), the mote does not crash.
  - In other pieces of code we have, using the random generator will
lead, as far as we observed, to no crash. So the crash is apparently
specific to the code we have.

And to add some mystery:

 - Using the HW multiplier of the Telosb (by changing the compiler
flags), the code runs perfectly fine.
 Although, we do not like this solution, as it is said that mspgcc can
generate buggy binary with the HW multiplier. (and therefore is
disabled by default in the tinyOS toolchain)

 We believe, that under certain conditions, the code generation for
the multiplication is buggy. Although, the call to the random
generator, and the call to the distance calculation are sequential, so
we do not understand yet why they conflict.

Here are a snippet of the two methods involving 32 bits operations
(See RandomMlcg in tos/system)

 void calculateRefCoords(uint16_t p_epochNum, location_t* p_refCoord)
  {
  atomic
  {
call SeedInit.init(p_epochNum);
p_refCoord->x = (call
 ReferencePointGenerator.rand16() % (AREA_SIZE / PARTS_NUM));
p_refCoord->y = (call
 ReferencePointGenerator.rand16() % (AREA_SIZE / PARTS_NUM));
  }
 }

 distance calculation:
 uint32_t Distance(location_t p_locA, location_t p_locB)
  {
  uint32_t xDiff = p_locA.x < p_locB.x ? p_locB.x -
 p_locA.x : p_locA.x - p_locB.x;
  uint32_t yDiff = p_locA.y < p_locB.y ? p_locB.y -
 p_locA.y : p_locA.y - p_locB.y;

  return yDiff * yDiff + xDiff * xDiff;
  }

The two methods are called, as said before sequentially. location_t is
a struct with two uint16_t elements. As stated previously, if we
invoke only one of the two methods, the mote will not crash.. I
haven't been looking in the assembly code yet.

Has anyone experienced something like that?

Thank you in advance for the help,

Alban

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

Re: [Tinyos-help] Problems with ACKs in TinyOS 2.0.2

[Juan Antonio López Riquelme]

Hello David and Kevin,

More thanks. It is ok. I had BaseStation reciving packets every minute for two 
hours and it does not lose anything message.

Now, the next step, low power listening.

A greeting,

Juan Antonio.
  - Original Message - 
  From: David Moss 
  To: 'Juan Antonio López Riquelme' ; tinyos-help@millennium.berkeley.edu 
  Sent: Monday, April 07, 2008 11:10 PM
  Subject: RE: [Tinyos-help] Problems with ACKs in TinyOS 2.0.2


  Hi Juan -

   

  According to your BaseStation makefile, you are disabling acknowledgments at 
the base station. This would cause PacketLink to fail because PacketLink 
requires the destination node to send back an acknowledgment.  Remove the 
CC2420_NO_ACKNOWLEDGMENTS line from the BaseStation Makefile and recompile.

   

  -David

   

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

Re: [Tinyos-help] Minimizing RAM consmption

[Michiel Konstapel]

Tweak your TOSH_DATA_LENGTH to be just big enough for your payloads so you 
don't waste memory on packet buffers.
Michiel

-Original Message-
From: [EMAIL PROTECTED] on behalf of Flavio Pompermaier
Sent: Tue 4/8/2008 10:52 AM
To: Tinyos
Subject: [Tinyos-help] Minimizing RAM  consmption
 
Hi,
I would like to know if there's any document reporting all possible 
enhancements focused in minimizing RAM consumption on Tmotes.
And why components variables are stored in RAM whereas function local variable 
are stored in ROM?? Shouldn't be the viceversa?

Some suggestions I found for RAM consumption minimizing are:
- use enum for constants instead of variables
- avoiding signalling from command/events
   -  do not use enum variables
others?

Thanks,
Flavio




  Inviato da Yahoo! Mail. 
La casella di posta intelligente.
http://it.docs.yahoo.com/mail/overview/index.html

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

[Tinyos-help] Minimizing RAM consmption

[Flavio Pompermaier]

Hi,
I would like to know if there's any document reporting all possible 
enhancements focused in minimizing RAM consumption on Tmotes.
And why components variables are stored in RAM whereas function local variable 
are stored in ROM?? Shouldn't be the viceversa?

Some suggestions I found for RAM consumption minimizing are:
- use enum for constants instead of variables
- avoiding signalling from command/events
   -  do not use enum variables
others?

Thanks,
Flavio




  Inviato da Yahoo! Mail. 
La casella di posta intelligente.
http://it.docs.yahoo.com/mail/overview/index.html___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Problems with ACKs in TinyOS 2.0.2

[Flavio Pompermaier]

I was also thinking that the CC2420_NO_ACKNOWLEDGMENTS flags was wrong, but I 
have another question about another flag:
CC2420_HW_ACKNOWLEDGEMENTS

What happens in this case? What is the difference with software acks?




  Inviato da Yahoo! Mail. 
La casella di posta intelligente.
http://it.docs.yahoo.com/mail/overview/index.html___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

[Tinyos-help] (no subject)

[subhash nemani]

hi
how can i measure the supply voltage(battery) of the tmote, without using
any of the  ADC ports because for all the ADC ports sensors are connected,

is there any software command to directly get the supply voltage of tmote???

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