On Mar 9, 2008, at 9:28 PM, Dhananjay Singh wrote:
Dear Friends,
I am Dhananjay Singh from India but now a days i am doing my
research work at in Ubiquitous Sensor Laboratory, Dongseo
University Busan Korea
Friends, i am working on ip-based Wirelesss Sensor Networks so i
have to need
Hi om_p,
I have the same doubt, so I set the basestation ID to -1 for trasparent
bridging (could I send a custumized ACK??) and ID= 0 for packets generator,
and I have added a check in Send.send (CC2420CsmaP.nc,
if( call AMPacket.address() != -1)
header-src = call AMPacket.address(); )
Domenico,
The iris (atm1281) timer code should work out of the box on the atm2560.
The two MCUs are mostly identical with respect to timers/counters.
Janos
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Domenico Arenga
Sent: Thursday, March 06, 2008 5:09 AM
To:
You're right, but fixing it didn't help so I dug deeper and found that
the ReadStream implementation on the MSP430 is broken.
Bugger.
So even if I set the usecond period correctly in my program to a large
value, it gets truncated in this function call. For some reason, GCC
does not
You are right the value received from the cc2420 is the average correlation
and not LQI, by the way, do you know why it is commonly called LQI ?
In my understanding this correlation value is the average correlation value
of the first eight symbols, we get the correlation of each symbol at the
Hi every body,
When I executed Surge application with export DBG=route, I found that misd=0
all the time although I defined a lossy.nss File
Please how could I evaluate Surge application.
I need your help.
Regards
Funofnet
I thought that when the timer goes off, a hardware interrupt
is generated which causes the currently executing task to be
preempted, then the timer.fired event runs and when finished,
the preempted task will resume.
Not exactly. You're right that when the timer goes off, a hardware
interrupt
is
What you want to use is an alarm instead of a timer. Take a look at
TEP 102 to learn about the distinction.
http://www.tinyos.net/tinyos-2.x/doc/html/tep102.html
Timers are basically built on top of Alarms. The fired event of the
Alarm simply posting a task that signals the Timer.fired()
I've now checked in the README file in the LowPowerSensing application
directory. Not sure why it got lost, but I generated a new one from
scratch this afternoon. let me know if you find anything confusing or
if you think there is anythign missing that would help in the clarity
of reading it or
Hi,
After being through the code in OscilloscopeC.nc, I've found that 65535 is
set by the Read.readDone() event in case of unsuccessful data read.
My current guess in that I might not activate the temp sensor correctly.
Please give me some suggestions.
Thanks,
Ittipong
PS
I also change
Hi,
Thanks for your reply. I'm doing 'make tmote' and then installing it on the
invent (make tmote install). I've got no errors.
It works well if I don't modify the Oscilloscope (using the DemoSensorC()
interface).
Ittipong
On 27/02/2008, Kevin Klues [EMAIL PROTECTED] wrote:
I'm not sure
I also tried using TestSerialBandwidth. I commented out the code in
TestSerial.java which sends packets to mote. Thus, I'm only sending
packets to the PC from mote.
Using the as fast as possible mode, I can send packets at the rate
of approx 100Hz in the direction mote to PC. What limits the rate
Hi Ian.
You're right about the README file, its not there and I can't seem to
find it anywhere :) I know I created it at the time I checked the app
in, but somehow it must have gotten lost in the shuffle somehow. I
'll see about writing a new one when I get some time soon. For now
though, what
seamlessly in any version of TinyOS.
Giri
--
*From:* Nikhil Singhal [mailto:[EMAIL PROTECTED]
*Sent:* Friday, February 15, 2008 8:55 PM
*To:* Giri Baleri
*Cc:* tinyos-help@millennium.berkeley.edu; Siirtola Harri
*Subject:* Re: [Tinyos-help] re: GPS module of MTS420
I've just had the same problem and manage to cobble up a fix.
1. Set up environment variables correctly in your .bashrc script
# TOSROOT MUST be defined before it is referenced
export TOSROOT=/opt/tinyos-2.x
export TOSDIR=$TOSROOT/tos
export MAKERULES=$TOSROOT/support/make/Makerules
export
@millennium.berkeley.edu; Siirtola Harri
Subject: Re: [Tinyos-help] re: GPS module of MTS420 not working
Thanks! I do have the new MTS420CC board. I downloaded the drivers from
the link you sent. I have a question though: Do I need to load the
/opt/tinyos-1.x/contrib/xbow/apps/XSensorMTS400 app or the
/opt/tinyos-1.x
Philip Levis:
On Feb 15, 2008, at 1:45 AM, Jan Hauer wrote:
If you don't have separate arbiters for the ADC and the DAC how can
you ever allow them to perform operations in parallel? And this sort
of cascading through multiple levels of arbitration happens all the
time. Think about how
On Feb 15, 2008, at 10:48 AM, Andreas Koepke wrote:
Philip Levis:
On Feb 15, 2008, at 1:45 AM, Jan Hauer wrote:
If you don't have separate arbiters for the ADC and the DAC how can
you ever allow them to perform operations in parallel? And
this sort
of cascading through multiple levels of
On Feb 15, 2008 7:59 PM, Kevin Klues [EMAIL PROTECTED] wrote:
Thats fine, but I think the point is that if the ADC reading you are
about to take needs to use the refernece voltage, access should NOT be
granted to the ADC until access to the reference voltage has been
granted. If you use VCC,
I don't really like the idea of having two arbiters (one for ADC and
one for DAC) and in addition another one for RefVolt, because that
would force (some) clients to make two successful requests before they
can actually start their operations. We have never really discussed
this, but resource
If you don't have separate arbiters for the ADC and the DAC how can
you ever allow them to perform operations in parallel? And this sort
of cascading through multiple levels of arbitration happens all the
time. Think about how the flash drivers on telos work. There is
arbitration to the flash
Hi all
In my previous message, I had mentioned that I was using XListen with a
CrossBow MTS420 mote and wasn't getting any output on the screen. As it
turns out, my sensor board was faulty. I'm using another one now, and I get
readings from all the other sensors, but nothing from the GPS. I have
If you don't have separate arbiters for the ADC and the DAC how can
you ever allow them to perform operations in parallel? And this sort
of cascading through multiple levels of arbitration happens all the
time. Think about how the flash drivers on telos work. There is
arbitration to
Why would you ever allow AdcClient2 to successfully be granted the ADC
before it was granted the RefVolt? You would need to make sure that
it had access to the refvolt before signaling a granted for the ADC
woudn't you?
Kevin
On Fri, Feb 15, 2008 at 1:45 AM, Jan Hauer [EMAIL PROTECTED] wrote:
Why would you ever allow AdcClient2 to successfully be granted the ADC
before it was granted the RefVolt? You would need to make sure that
it had access to the refvolt before signaling a granted for the ADC
woudn't you?
If we have separate ADC, DAC and RefVolt components/arbitration then
@millennium.berkeley.edu
Subject: [Tinyos-help] re: GPS module of MTS420 not working
Hi all
In my previous message, I had mentioned that I was using XListen with a
CrossBow MTS420 mote and wasn't getting any output on the screen. As it
turns out, my sensor board was faulty. I'm using another one now
@millennium.berkeley.edu
*Subject:* [Tinyos-help] re: GPS module of MTS420 not working
Hi all
In my previous message, I had mentioned that I was using XListen with a
CrossBow MTS420 mote and wasn't getting any output on the screen. As it
turns out, my sensor board was faulty. I'm using another one now, and I get
There are separate apps XMTS400, XMTS410, XMTS420. Shouldn't you use the
latter?
From: Nikhil Singhal [mailto:[EMAIL PROTECTED]
Sent: Friday, February 15, 2008 1:04 PM
To: Siirtola Harri
Cc: tinyos-help@millennium.berkeley.edu
Subject: Re: [Tinyos-help] re: GPS
Sure I guess I was just assuming the wrapper approach then
Kevin
On Fri, Feb 15, 2008 at 2:33 AM, Jan Hauer [EMAIL PROTECTED] wrote:
Why would you ever allow AdcClient2 to successfully be granted the ADC
before it was granted the RefVolt? You would need to make sure that
it had
that helps,
Giri
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nikhil
Singhal
Sent: Friday, February 15, 2008 3:04 AM
To: Siirtola Harri
Cc: tinyos-help@millennium.berkeley.edu
Subject: Re: [Tinyos-help] re: GPS module of MTS420 not working
It seems
On Feb 15, 2008, at 1:45 AM, Jan Hauer wrote:
If you don't have separate arbiters for the ADC and the DAC how can
you ever allow them to perform operations in parallel? And this
sort
of cascading through multiple levels of arbitration happens all the
time. Think about how the flash
Thats fine, but I think the point is that if the ADC reading you are
about to take needs to use the refernece voltage, access should NOT be
granted to the ADC until access to the reference voltage has been
granted. If you use VCC, you don't need to wait for this. The
information about which
?
--
*From:* Nikhil Singhal [mailto:[EMAIL PROTECTED]
*Sent:* Friday, February 15, 2008 1:04 PM
*To:* Siirtola Harri
*Cc:* tinyos-help@millennium.berkeley.edu
*Subject:* Re: [Tinyos-help] re: GPS module of MTS420 not working
It seems like I am getting all
that helps,
Giri
--
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Nikhil Singhal
*Sent:* Friday, February 15, 2008 3:04 AM
*To:* Siirtola Harri
*Cc:* tinyos-help@millennium.berkeley.edu
*Subject:* Re: [Tinyos-help] re: GPS module of MTS420
Currently Msp430RefVoltArbiterImplP intercept the requests of ADC
clients to the Resource interface, it is not really arbitrating access
itself. If the DAC needs access to the RefVolt component too, then we
might need a real arbiter for the RefVolt component that is
independent of the actual ADC
Jan,
In the latter approach you outlined, where they share the same arbiter, if we
assume that the ADC and DAC require the same reference voltage, would they
still not be able to run in parallel?
Here's one scenario which might be common to a lot of sensing apps: An app uses
RefVolt via
In the latter approach you outlined, where they share the same arbiter, if
we assume that the ADC and DAC require the same reference voltage, would
they still not be able to run in parallel?
By parallel I meant at the same time: in the second approach if two
components would request to use the
I like Sandip's idea to create an arbiter that reserves use of refvolt to the
first
process that asks, but also responds to queries about the refvolt value.
Do arbiters as they are now allow for keeping a queue of asking routines
satisfied
with a resource with no breaks?
Would a shared
What we really need I think is a way of allowing the reference voltage
component have multiple owners simultaneously. Most components that
provide the Resource interface are used to grant exclusive access to a
device that is used to perform some operation. The reference voltage
component is a
Αλέξανδρος Καραγιάννης wrote:
Hello everyone,
Before i describe my case i'd like to express a big THANK YOU for the
help that this list provides to those people trying to deal and
experiment on WSN and Tinyos-NesC.
Moving now to the problem. I was using in Tinyos-1.x the oscilloscope
Sandip Bapat wrote:
a DAC module would either have to wire to Msp430RefVoltArbiterP (in which case
it also has to provide the
AdcConfigure interface) or be expected to provide wiring for these interfaces.
This is fine for apps that just want to use the DAC and not ADC but what if
both are
The access to the refvolt generator has to be properly arbitrated between
the ADC and the DAC. Pins, timers, etc. are all potential shared resource
between the two. Jan, who is responsible for the msp430 ADC stack, is at a
project meeting and probably has not read the thread. Please get in touch
Another strange thing:
I'm comparing my code with the app.c file which contains the parsed code.
The line
temp=((chosen[j]=temp) || inconsistent[j] || (j == heldout));
where temp is an integer, is parsed in
temp = (chosen[j] = temp || inconsistent[j]) || j == heldout;
which is different from the
I use TOS 2.0
2008/2/9, AIGroup [EMAIL PROTECTED]:
Another strange thing:
I'm comparing my code with the app.c file which contains the parsed code.
The line
temp=((chosen[j]=temp) || inconsistent[j] || (j == heldout));
where temp is an integer, is parsed in
temp = (chosen[j] = temp ||
I fully agree, and the question is not philosophical. The TinyOS HAA
defines two well-defined taping points for the application into the driver
code: the HAL and the HIL level. Consequently, the public interfaces at both
the HAL and the HIL level have to be documented and accepted through the TEP
One of the interesting aspects of NesC is that it doesn't enforce any
specific kind of encapsulation of interfaces. That is, an application
component can poke through the various layers below it to get at an
interface provided by a deeper underlying component. In this case you
propose to
I think each documentary TEP refers to the release version number so
even if the interfaces get added to the head of the CVS, I don't see
that as a problem. In theory, such interface change will be discussed
when a new TEP is written to document a new release. This brings up
another point - when
Here you go. If you want to measure the RSSI noise floor use CC1000RssiP.
Also, this code is for T2, but for tinyos 1.x it is very similar.**
~Dimas~
== code ==
#include message.h //Unnecessary if using the send or receive interfaces.
//Put this inside your module
uint16_t
On Feb 7, 2008 4:43 AM, Adriano Pasquali [EMAIL PROTECTED] wrote:
Hi,
portTerminal is a terminal like Hiperterminal of Windows. I don't believe
that there are collision because sniffer display only my frame on channel
26. I believe that there is a memory problem or sincronization of
Matt and Phil -
This is meant to serve only as a private interface within the CC2420 stack
right now, not an interface provided by the ActiveMessage façade. After
all, once the interface is provided by ActiveMessage, it is no longer a
private CC2420-specific interface.
This is absolutely not a
On Feb 7, 2008, at 6:00 AM, David Moss wrote:
Matt and Phil -
This is meant to serve only as a private interface within the
CC2420 stack
right now, not an interface provided by the ActiveMessage façade.
After
all, once the interface is provided by ActiveMessage, it is no
longer a
While I like this idea, are we going through a TEP vetting process
before adding new calls in the radio stack interface? I could think of
a lot of things that one might want to add to the CC2420 radio stack
but I thought the idea of the TEP process was to air these ideas
through feature
On Feb 6, 2008, at 2:10 PM, Matt Welsh wrote:
While I like this idea, are we going through a TEP vetting process
before adding new calls in the radio stack interface? I could think
of a lot of things that one might want to add to the CC2420 radio
stack but I thought the idea of the TEP
On Jan 31, 2008 6:17 AM, AIGroup [EMAIL PROTECTED] wrote:
OK! now it works, but only in simulation!!!
I tried to edit my makefile but without success!
add
BUILD_EXTRA_DEPS = Hello.o
to the Makefile (it's a magic variable listing things that should be
built before the main executable)
David Gay
I believed...
include directive works well. I have problem to edit the Makefile in order
to compile also the C file.
2008/1/30, AIGroup [EMAIL PROTECTED]:
Hi all.
I would like to include some routines in my nesC code as follows
(considering the BlinkApp for example):
/* nesC code*/
#include works fine, but, as in C, it's just textual inclusion (it
really is nothing complicated ;-)). So it's all as if you just wrote:
module ...
implementation
{
#ifndef C_CODE
#define C_CODE
void Hello();
#endif
event void Boot.booted()
{
call Timer0.startPeriodic( 250 );
I believed...
I'm using TinyOS 2.0.
I tried to compile and use these statements in my code:
int *x;
x=(int *)(malloc(sizeof(int)));
*x=4;
dbg(BlinkC, Timer 0 fired @ %s.\nContenuto di x = %d\n,
sim_time_string(), *x);
and all works well!
So...why using malloc() is dangerous? (as I
Hi,
Malloc might work in a simulation environment, but it does not work on
the physical motes. So if you want to program real hardware you'll have
to find a way to avoid malloc.
Cheers,
Urs
AIGroup wrote:
I believed...
I'm using TinyOS 2.0.
I tried to compile and use these statements in
On Jan 29, 2008, at 2:49 AM, AIGroup wrote:
I believed...
I'm using TinyOS 2.0.
I tried to compile and use these statements in my code:
int *x;
x=(int *)(malloc(sizeof(int)));
*x=4;
dbg(BlinkC, Timer 0 fired @ %s.\nContenuto di x = %d\n,
sim_time_string(), *x);
and all
Malloc actually should work on the mote hardware if you want to try
it. Whiel its use is discouraged, there is technically nothing
preventing you from using it.
Kevin
On Jan 29, 2008 3:52 AM, Urs Hunkeler [EMAIL PROTECTED] wrote:
Hi,
Malloc might work in a simulation environment, but it does
Perhaps you should use the PoolC component which provides similar
functionalities but is safer. It works with pre-allocation.
~Dimas~
2008/1/29, Philip Levis [EMAIL PROTECTED]:
On Jan 29, 2008, at 2:49 AM, AIGroup wrote:
I believed...
I'm using TinyOS 2.0.
I tried to compile and use
On Jan 29, 2008 11:36 AM, Philip Levis [EMAIL PROTECTED] wrote:
On Jan 29, 2008, at 2:49 AM, AIGroup wrote:
I believed...
I'm using TinyOS 2.0.
I tried to compile and use these statements in my code:
int *x;
x=(int *)(malloc(sizeof(int)));
*x=4;
dbg(BlinkC, Timer 0
Here is what the received placket looks like when running Listen
00 00 01 00 22 08
On Jan 21, 2008 6:05 PM, Ian Welch [EMAIL PROTECTED] wrote:
I just updated my TOS Source tree. When I run my program the received
message at the base station (2.0 beta) placed the length in the AM type
field
Coalton Bennett cb322 at cornell.edu writes:
Hello All,
For any skilled Crossbow users who are familiar with Xserve
I have a question about viewing the output from the
mote(s). I am going through some of the tutorials that come
with the software package and I am currently
Please ignore my previous question. Because it works now...
Faisal Aslam wrote:
Hi,
This question is not related to tinyOS but about using uisp in cygwin
and Window XP.
I am sorry for asking off topic question but I really need your help
and AVRfreaks does not allow me to register. Do not
Also, we are using iMote2 for our project. The following page
also contains a lot of tips related to tinyos environment setup for
iMote2:
http://sensorweb.vancouver.wsu.edu/wiki/index.php/Tinyos#Install_Imote2_in_tinyos-1.x
Our lab have one PhD RA opening. See
hi
By using this program i am not able to send the packets through
multihop
what could be the problem???
plzzz help me in this regard
extADC1_3phrmsM.nC
Description: Cdf file
___
Tinyos-help mailing list
Hi Rodolfo,
As far as see, you do not forward the packets received from Base station
to the serial port. This is the reason why you can not connect to the
port 2390. I think your command should look like this:
java avrora/Main -platform=mica2 -report-seconds -monitors=packet,leds,*serial*
Hi Rodolfo,
As far as I see, you do not forward the packets received from Base
station to the serial port. This is the reason why you can not connect
to the port 2390. I think your command should look like this:
java avrora/Main -platform=mica2 -report-seconds -monitors=packet,leds,*serial*
hi
i have installed SimpleCmd in one mote with id as 1 and in the basestation
i dumped the TOSBase
by giving the commands such as led_on,led_off
java net.tinyos.tools.BcastInject.led_on
it is giving message like
sending payload 1 1 0 0 0 0 0 0 0
[EMAIL PROTECTED]:resynchronising and
I am using tinyos 2.0.2 in TOSSIM.
2008/1/4, DAE HEE KIM [EMAIL PROTECTED]:
Hi...
I want to change noise level after simulation started. How can I do that
in python script?
Surely, before simulation starts, I set noise by using following python
script (the same as the tutorial 11)
I am using tinyos 2.0.2 in TOSSIM.
2008/1/4, DAE HEE KIM [EMAIL PROTECTED]:
Hi.
I also want to change gain value after simulation started.
I set gain value by using linkgain.out file when simulation starts.
What I want to know is to change the gain value that was set at the first
time.
Hum... I found out following function
:
sim_gain_set_noise_floor(10, -30, 5);
:
So, I tried upper function, but it seems not work.
anyone help me ?
2008/1/4, DAE HEE KIM [EMAIL PROTECTED]:
Can I use setNoise() ?
...
r = t.radio()
r.setNoise(1, -30, 5)
...
I tried but, It seems to not
Can I use setNoise() ?
...
r = t.radio()
r.setNoise(1, -30, 5)
...
I tried but, It seems to not work.
Are there any way to see change of noise ?
Please help me
2008/1/4, DAE HEE KIM [EMAIL PROTECTED]:
I am using tinyos 2.0.2 in TOSSIM.
2008/1/4, DAE HEE KIM [EMAIL PROTECTED]:
Hi,
I was getting same problem when I change over to tinyOs-2.x. The problem is you
have to load nesC version 1.2.8b or nesc-1.2.9 if you are having nesc-1.2.8a.
Then Set the env variable as:
export TOSROOT=/opt/tinyos-2.x
export TOSDIR=/opt/tinyos-2.x/tod
export
hi
i have written applications to sense data and transmit to the
basestation(mote connected to personal computer) successfully
but i don't know how to send the data or a signal(such as output a high
signal on DAC0 in the tmote with moteid X) from the basestation( mote
connected to personal
We revised a piece of code in at45db and update at45db driver from B to
D version.
In tinyos-2.x/tos/platforms/mica2/chips/at45db/HplAt45dbIOP.nc, waitIdle()
function ought to be revised as follows:
command void HplAt45dbByte.waitIdle() {
// Setup interrupt on rising edge of flash in
Great work, that took care of it! Thanks for the quick response.
- Ryan
Razvan Musaloiu-E. wrote:
Hi!
There was a bug the way the CRC computation was handled for at45db which
prevented the new image checks we put Deluge T2 from running properly.
Can you try the latest CVS and see if it
Hi!
There was a bug the way the CRC computation was handled for at45db which
prevented the new image checks we put Deluge T2 from running properly.
Can you try the latest CVS and see if it works well now?
Note: I noticed one strange case. It's like this: I inject an image, I
erase it and
On Dec 20, 2007, at 2:04 PM, Baozhi Chen wrote:
I looked at the tutorial documents of Tinyos 2.0.2. The propagation
model we can use is large-scale propagation loss model but not
small-scale propagation model such as Rayleigh fading. Has anyone
done anything in modeling small-scale
I guarantee that it will be worth it. TOS2 is fundamentally more
robust, flexible, and sound going forward. The learning tools and
examples are coming into place. Hanging on to TinyOS1.x dusty desk at
this point would surely be penny wise pound foolish.
Philip Levis wrote:
On Dec 16,
] [mailto:tinyos-help-
[EMAIL PROTECTED] On Behalf Of Hristo Bojkov
Sent: woensdag 19 december 2007 14:01
To: Tinyos-help
Subject: [Tinyos-help] Re: Is uint16_t a unsigned int type?
Sorry. Ignore my last mail. I didn't catch that it is complaining not
for the type of the variable, rather
On Dec 17, 2007 12:39 AM, Michael Schippling [EMAIL PROTECTED] wrote:
In my humble, humbling, and limited experience with academically
driven software, upgrading to the new-improved version of something
generally exposes one to the Latest Software Engineering Paradigms,
since such software is
Michael Schippling wrote:
In my humble, humbling, and limited experience with academically
driven software, upgrading to the new-improved version of something
generally exposes one to the Latest Software Engineering Paradigms,
since such software is generally developed by grad-students who
On Dec 16, 2007, at 3:39 PM, Michael Schippling wrote:
So, aside from applying my rusty hermeneutic skills to the TEPS,
is there someplace I can find a good description of the advantages
of re-experiencing the TOS learning cliff under T2?
Excellent...thank you...
A couple questions...
One of my projects relies on ATMEGA Timers13 for PWM output and
time capture. Have these been preempted by internals or can I
still use them with impunity?
The same project also uses PortC and all the ADC's, round robin
sampling on a 1ms Timer[]
static building: meaning a link phase so you can include
regular 'C' code without hoop-jumping? or...?
thx
MS
John Griessen wrote:
Michael Schippling wrote:
In my humble, humbling, and limited experience with academically
driven software, upgrading to the new-improved version of something
Great papers...have these been in stealth mode or did I just miss
the announcement? Are they linked in to the new improved TOSdoc wiki?
MS
Vlado Handziski wrote:
...
I would not say that the relation between T2 and T1 can be characterized
by
On Dec 16, 2007 10:05 PM, Chad Metcalf [EMAIL PROTECTED] wrote:
On Dec 16, 2007 12:34 PM, Kevin Klues [EMAIL PROTECTED] wrote:
My solution to all this would be to try and convince everyone to switch
over to tinyos-2.x, but I realize that some people are reluctant to do so
right away.
In my humble, humbling, and limited experience with academically
driven software, upgrading to the new-improved version of something
generally exposes one to the Latest Software Engineering Paradigms,
since such software is generally developed by grad-students who
need thesis topics, without
Hi Roman,
First of all, thanks for your help.
Today with Tektronic tds3052 and a Agilent 34401A 6 1/2 digit multimeter, I can
measure the various LPM modes with success.
With Null application,
Mode Active - 1.63 mA
LPM0 - 0.151 mA
LPM1 - 0.150 mA
LPM2 - 25 uA
LPM3 - 6 uA
LPM4 - 4 uA
With a
Hi all,
I have the same prob with Vijayant. When I call make
micaz sim then it can only generate the latest object
that I declared. I mean in Vijayant's case only the
RadioCountData.py, .java, .class were created. I
havent figure out why it happens like that.
Right now, my solution is typing
CAn anyone reply please ? :)
-Vijayant
On Dec 13, 2007 9:27 PM, Vijayant Bhatnagar [EMAIL PROTECTED]
wrote:
hi,
Can anyone give me hint on implementing link reliability. I found out that
there is a mechanism by which we can know whether a packet was sent or not.
I was able to implement
An updated power trace can be found at
http://tik42x.ethz.ch:8080/buildresults/t2-null?tab=power-charts
although there are some distrubances in the measurement, one can
clearly see, that the null app uses almost no energy.
Oh, those are really rather nifty :-)
Are those traces automatically
Tanks for your help Roman.
I will try this week again, set pState in MCUSleepC.nc, and then measured the
current.
Tanks again
Miguel Silva
-Mensagem original-
De: Roman Lim [mailto:[EMAIL PROTECTED]
Enviada: ter 12/11/2007 9:44
Para: migueltsilva
Cc: tinyos-help@Millennium.Berkeley.EDU
I was using the dual setup so my cygwin installation was from the 1.1.11
autoinstaller and I'd used the upgrade instructions for 2.0.
When I unistalled and tried to reinstall from the autoinstaller, it gave the
same fork_copy errors and the installation was not successful so I finally gave
up
Hi Miguel
I'd suggest you use the latest tinyos-2.x from cvs repository. There was
a bug that lacked some current in sleep mode (see
http://tinyos.cvs.sourceforge.net/tinyos/tinyos-2.x/tos/platforms/telosb/MotePlatformC.nc?revision=1.3view=markup).
An updated power trace can be found at
Joe,
The MICAz type neoMOTE has been in production for Energy Saving Co.
XMesh runtime is intalled for multi-hop WSN , collecting micro climate
data AND actuates HVAC/refregirators in supermarket.
System test was completed in Q1 of '07 and some 1+ shipped
since Q2 and continuing. Qtty in
I am somehow debugging this problem :
Basically i have two structs like :
typedef nx_struct radio_count_msg {
nx_uint16_t type;
nx_uint16_t data1;
nx_uint16_t data2;
} radio_count_msg_t;
typedef nx_struct radio_count_data {
nx_uint16_t type;
nx_uint16_t data;
} radio_count_data_t;
it seems that there is some problem with our makefile. can anyone help us
please ?
Regards,
Vijayant
On Dec 8, 2007 4:56 AM, Vijayant Bhatnagar [EMAIL PROTECTED]
wrote:
I am somehow debugging this problem :
Basically i have two structs like :
typedef nx_struct radio_count_msg {
201 - 300 of 965 matches
Mail list logo
