Dear all.
I am running a very simple test applications where
40 nodes are broadcasting packets every 10 sec,
and a BaseStation node is listening to those packets.
And I am receiving far less packets in t2, compared to t1,
for (what I believe to be) the same application.
So I was wondering
I've lost my Boomerang 2.0.4 install CD and www.moteiv.com has disappeared.
If anyone has a zip of this installation please post a link so that I can
download it.
Thanks a zillion,
David
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
Hello all.
I try to built an application to receive in the computer data from analog to
digital converts (ADC0 and ADC1) in the tmote sky expansion port. Also I
wish to change the sample time (to read the ADCs) the remote node from the
computer.
All con TinyOS 2.
I have node with
Hi
is there a quick and concise way to check whether the radio is on/active
when using low power listening? For example, if I wanted to shut the radio
off fully (AMControl.stop()) but only if I was certain LPL was not in the
middle of detecting energy or receiving a packet and had initiated or
Hello.
I'm a telecommunications engineering degree student from Barcelona (Spain).
I'm working with tinyos-2.x under Linux. I have a question executing the
RssiToSerial application. As you would can know, RssiToSerial shows by console
strings like the following:
answer to my own question, for future reference, problem is due to the
change of TinyOS application, mainly message format.
sorry to everyone. :-)
regards;
Peizhao
Peizhao Hu wrote:
Hi All,
I have a strange problem with my Java program and TinyOS application. I
have two application
I'm working on time synchronization with tmote sky motes and TinyOS2.
I'm using a poller that sends a PollPacket every X milliseconds and a
set of clients that timestamp the arrival time of the PollPacket.
I found that the 16 timestamp in the time field of the Metadata are
somethimes incorrect (
RECEIVE CHECK / RADIO POWER:
In 2.0.2 (and possibly earlier versions) the PowerCycleC configuration
provides two State interfaces:
interface State as SplitControlState;
interface State as RadioPowerState;
The State enumerator, which should actually be located in a header file and
not the
Here's one possible explanation: the CSMA backoff changed between T1 and T2.
In T1, the CSMA backoff wasn't very fair, allowing one transmitter to
possibly hog the channel. The CSMA congestion and initial backoffs were
flipped in T2, making the initial backoff longer and the congestion backoff
I haven't done much work with the timestamps in the CC2420 apart from
Jonathan's original implementation, nor have I used it enough to have
experienced any type of erratic behavior. Is the issue here that the 16-bit
timestamp rolls over to 0 periodically? Would a 32-bit timestamp be better?
You may have to take this application as an example and convert it to
provide the information you're looking for. This app's original intention
was to give you a warm fuzzy feeling about RSSI coming out of the CC2420.
Page 49 of the CC2420 data sheet offers more information about RSSI and
I think he is talking about a shorter range and not lower
throughput. He says whenever he sends a broadcast packet, fewer nodes
receive that broadcast pkt in T2 than in T1.
- om_p
Here's one possible explanation: the CSMA backoff changed between T1 and T2.
In T1, the CSMA backoff wasn't
On Oct 30, 2007, at 12:33 AM, Jeongyeup Paek wrote:
Dear all.
I am running a very simple test applications where
40 nodes are broadcasting packets every 10 sec,
and a BaseStation node is listening to those packets.
And I am receiving far less packets in t2, compared to t1,
for (what I believe
1 packet every 10 seconds.
Thank you
- jpaek
Philip Levis wrote:
On Oct 30, 2007, at 12:33 AM, Jeongyeup Paek wrote:
Dear all.
I am running a very simple test applications where
40 nodes are broadcasting packets every 10 sec,
and a BaseStation node is listening to those packets.
And I
Yes... though the scenario is reversed.
When all nodes are sending broadcasts, and one basestation is receiving,
that base station is receiving packets from *less number of nodes*.
thanks
- jpaek
Omprakash Gnawali wrote:
I think he is talking about a shorter range and not lower
throughput.
[tos2, micaz]
When using low power listening if I wish to send two packets over the radio,
it is there a special way in which I can make sure they will both be sent
after the same preamble such that all receiving motes that caught preamble
in front of the first message also received the
Hi again - sorry, one more quick question...
If I initiated a tinyOS program using setLocalSleepInterval(2000), and then
subsequently issued the following set of commands after 250 ms:
setLocalSleepInterval()
***
Please
Very Sorry - hit the wrong button! Full message follows:
Hi again - sorry, one more quick question...
If I initiated a tinyOS program using setLocalSleepInterval(2000), and then
subsequently issued the following set of commands after 4250 ms:
setLocalSleepInterval( 0 )
setLocalSleepInterval( 500
About the scenario: If a packet is received by many nodes, a node will
have received packets from many nodes.
- om_p
Yes... though the scenario is reversed.
When all nodes are sending broadcasts, and one basestation is receiving,
that base station is receiving packets from *less number of
Hi,
first of all thak you.
I have a question :
I created a file under C:\jennic\cygwin\etc\profile.d named tinyos.sh when
I installed TinyOS. My question is :
if I just add the Variable NESC_MACHINE to the containt of this file, is it
sufficient to use env in my .platform file ?
the containt of
It might be ok, but it makes more sense to put it in the .platform
file since you may be compiling for different processors at different
times. You should probably jsut follow the example from how they do
it in /tinyos-2.x/tos/platforms/intelmote2/.platform
Kevin
On Oct 30, 2007 11:28 AM, mejda
I have apparently confused myself with new code...
I'm just starting to do useful work with Boomerang and Tmote sky.
I believe this means TOS1.1.15 plus now-defunct Moteiv addons.
Running the CountUart demo, I get this data stream from Listen:
04 00 00 00 00 00 7E 00 04 7D 00 1C 00 01
If you get a sendDone() event and call your next send() event quickly
(within tens of milliseconds) then both radios will still be awake and you
will be communicating at 100% throughput. Both radios will remain active as
long as there is useful communication taking place. In this manner,
multiple
Which version of the SF are you using? We face the same problems when
using the C-based SF, after switching it to the Java version all
problems were resolved.
Tiago
Ariel Mauricio Nunez Gomez wrote:
Thanks Amit.
Maybe your packet size is too big.try to reduce it below
36
Hi Dima,
I saw your response about the warning Send.sendDone' called asynchronously
from the maillist of tinyos help. But I don't quite understand what you mean
by add the async keyword to all the components that use the interface
Send? Isn't async can only be placed in front of an event? What
Hi all,
I have a wireless sensor development kit from www.jennic.com
Do you know if a port of TinyOS exists for Jennic's boards ?
If not I am trying to estimate how much of an effort is that in order to
attempt to do it.
They have a simple scheduler called BOS (Basic Operating System), which is
You are using T1 right?
In T1, the TOS_Msg struct does not use nx types.
So, all TOS_Msg header fields (e.g. addr) are
in host format, which will be little endian in Tmote sky.
Although I haven't seen CountUart demo, probably
their payload is using a nx struct with nx_uint16_t fields.
Then
Yes, I'm using T1. And yes the CountMsg uses nx_ types,
and the telos/AM.h header in T1.1.15 does not.
So is the big-endian nx_*int* thing a default behavior
across all platforms? Do you know in what TOS version
this started? And can you point me to relevant doc?
I have to assume that this was
It doesn't look like you have libc installed for your compiler.
Kevin
On Oct 30, 2007 3:20 PM, mejda chouaieb [EMAIL PROTECTED] wrote:
Hello,
I'm trying to complie Null for my new Platforme isense but I have these
problems, can someone help me to fix these errors ?
Well, I don't know exactly who and when this started...
but yes, it is a default-like thing across all platforms.
It is dependent on 'nesC' rather than 'tinyos',
and I think people started to use it since tinyos-1.2 (not 1.1.15).
MoteIV/Boomerang used it, and it became a standard thing in T2
They've been in use since about May of 2005 and were introduced as
part of nesC 1.2.
http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2005-May/000884.html
Anything compiled with nesC 1.2 can use them, anything with older
versions of nesC will have compile time errors. They've are used
Thanks for the detailed explanation.
But just one thing... doesn't atmega128 use little endian?
Did something happen behind the scene even before
nx types were introduced?
I thought all mica, mica2, micaz, telosb, tmote,
intel-processor PC's, and stargates used little endian.
I've experienced
Sorry, you're right, atmeaga128 is little endian as well. The reason
the network types (or more appropriate -- platform independent types)
are needed is because the msp430 expects all tw-byte variables to be
word aligned (can only start at even addresses), while the atmega
allows them to be byte
33 matches
Mail list logo
