llivolts.
IMP###
Refer CC1000 datasheet for the o/p specifications of the RSSI pin.
5.) The formula for calculating the values in dBm are
V_rssi (volts) = V_batt (volts) * adcCounts / 1024.0;
RSSI_dBm = -50.0 * V_rssi - 45.5; // for CC1000 at 915 MHz!
where adcCounts is the 16 b
First a couple suggestionsupgrade to a later version of TOS1.x,
say something over .7 and use the defines in the
contrib/xbow/apps/MakeXbowlocal file (or just do your development
in the xbow tree, otherwise the CC1000 will not work very well
(in my experience...).
Also setPower() may not have
I think you are asking what wires to connect to what, is that right?
You need to tie the power grounds of the two systems together
and then run the signal output from the sensor to the tmote's
ADC input.
MS
Chen Bleed wrote:
> Hello, all
>
> I am a rookie of mote world. Now I have a tmote sky
As far as I know moteIF is pretty much it in Java. You can use it
to connect directly to the serial port on the MIBs, etal. If you
want to slim things down, look at Packetizer.java where most of
the rubber meets the road. Also there are examples in C in the tools
tree, and C# seems to be possible
Did deeper into DemoSensor. First of course you have to figure out
which one and where it is...I don't (yet) have a tmote dev environment,
but for the Mica's it's in tos/sensorboards/micasb/DemoSensorC.nc
What you will find is that it is a dimly veiled layer over an ADC input,
which, IMHO, just o
Assuming you already have .../tinyos-*/tools/java in your CLASSPATH,
there's probably nothing more you can do to help.
It seems that the no arg constructor Message() is private in
tools/java/net/tinyos/message/Message.java, and bean-like systems
usually use those constructors as the default insta
Well, yeah...But doesn't every platform also have the "raw" ADC implementation
which provides exactly the same interface, with a (well, to my low-level mind)
more straightforward connection to the external world? Admittedly there are
some 'tricks' that need to be performed to get, e.g., the micasb
Read up on GenericComm.
But briefly, in a header file you assign arbitrary 16 bit message
identifiers and their associated data structures:
/** Message types
**/
enum
{
// Status Reply to Host (Send)
AM_ROBOSTATUSMSG = 10,// normal robot status
AM_ROBODATAMSG = 11, // dum
I think you need to wire the Timer StdControl:
Main.StdControl -> TimerC;
Yong, Chee Yeew wrote:
Hello all,
I am having a bit of a problem wiring parameterised interfaces. The program
is as below.
I keep getting the error:
"MyTimers.start() not connected".
I am not sure why it is comp
See my code bolus for an example using mica's and T1:
http://www.etantdonnes.com/Motes/robocode.tar.gz
I'm not sure what you mean by "typecast at TOSBase",
it should pretty much be a transparent pass-through.
Perhaps you are not calculating CRCs correctly or have
the wrong total message lengt
I believe that "they" changed the message structure slightly in T2
so as to be incompatible with any previous host software...Look
into the equivalent of types/AM.h to see what needs to be modified.
MS
Hristo Bojkov wrote:
Hello tinyOS coders,
I am new to TinyOS2. I have used TinyOS 1.1 for 6
--Original Message-----
From: Michael Schippling [mailto:[EMAIL PROTECTED]
Sent: 31 July 2007 18:57
To: Yong, Chee Yeew
Cc: tinyos-help@Millennium.Berkeley.EDU
Subject: Re: [Tinyos-help] Wiring parameterised interfaces
I think you need to wire the Timer StdControl:
Main.StdControl ->
TimerC uses Timer/Counter1 which is 16 bits, so that's a theoretical max.
But you would have to go look at the code, or experiment, to see if there's
more headroom eaten up by data munging...
MS
Siirtola Harri wrote:
I'll need vry long measurement intervals for my application. What's
the ma
Well, look at the micasb version. It wraps Photo (or Temp, I never remember)
which further wraps ADC (which does actually do something in-between...).
I'm going to assume that the telosb internal voltage sensor is implemented
as some kind of ADC as well. The basic pattern is:
// in some m
That looks like it should work. You do know that there is another
yellowToggle() call in the standard TOSBase, right? Maybe they are
competing with each other...
Also by printing out messages, does this mean you are running a
simulator? Perhaps you can debug in and look at what's actually
happeni
I agree...since you need a proxy of some kind on a PCish host,
I would put parsing and encoding software there instead of pushing
it all the way out to the sensors. Appropriate Technology and all...
MS
J. Ryan Stinnett wrote:
As I said, the largest packet would be about 256 bytes, but the standa
0x7d,
};
So I know I've miss something, but for now I am not able to see where is the
problem.
HB
---Original Message---
From: Michael Schippling
Date: 01.08.2007 г. 19:59:19
To: Hristo Bojkov
Cc: Tinyos-help@Millennium.Berkeley.EDU
Subject: Re: [Tinyos-help] HDLC pr
You are right about
typedef struct { int16_t var; } MateValueVariable;
being functionally equivalent to
typedef int16_t MateValueVariable;
However the usage would be a bit different.
For the first you would do:
MateValueVariable x;
x.val = NNN;
and the second:
MateValueVariabl
That code looks correct to me. Start by sending to BCAST addr
just in case you have a moteID mismatch. Also check that you
have the right xmit frequency and power defines. Have you
even gotten a radio message to work, like with one of the
demo apps? The apps/MicaHWVerify program tests radio connec
On the issue of not filtering by moteID...
T1 GenericComm on micas does, and your mod of send is correct.
However I've heard tales of that not happening on this list,
but I don't remember what combination of modules and platforms
were at issue. You could try a search and see if anything turns up.
M
Do what somebody just someone else to do...
printenv > env.txt
and send us the env.txt file (it should be plain-text
and not too long, so just copy and paste it into the email).
To set a PATH variable do something like this:
export PATH="/cygdrive/c/JAVA/j2sdk1.4.2_04/bin:\
/usr/local/bin:/
With a little Internot sleuthing I think I found "stargate" at:
http://www.xbow.com/Products/productdetails.aspx?sid=229
I believe it is an alternate base-station approach. Assuming
that you are running the HWVerify on a separate host, you
probably need to use an IP address instead of serial.
es verry well. so if someone
can give me some links or doc it will be verry nice, because i'm new in
tinyos world ;-)
Thank you all
----- Message d'origine
De : Michael Schippling <[EMAIL PROTECTED]>
À : mejda chouaieb <[EMAIL PROTECTED]>
Cc : tinyos-help@Millennium.Berk
e a solution to this.
Thanks,
Bharath
On 8/4/07, * Michael Schippling* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
With a little Internot sleuthing I think I found "stargate" at:
http://www.xbow.com/Products/productdetails.aspx?sid=229
I be
First your measured voltage should be between 0 and 3 volts
(the mica battery voltage). If it's some kind of proportional
thing it's actually a good idea to use the mica batteries to
power it because they are used as the ADC reference.
Then pick an available ADC input. Here's a pin list I made ye
It means that no interrupts are serviced until they are enabled again.
You probably don't miss any, unless you overrun due to blocking for too long.
See my last breathless post on this:
https://mail.millennium.berkeley.edu/pipermail/tinyos-help/2007-July/027039.html
and search for "interrupt" on t
ind of interrupt are generated for
several times? I am not sure, if I understand correctly, MSP430 have a
register for each kind of interrupt. If more than one interrupts of
the same type are generated, will some be lost?
On 8/7/07, Michael Schippling <[EMAIL PROTECTED]> wrote:
It means that no int
There's an example of reading PortC in:
http://www.etantdonnes.com/Motes/AVR128timers.zip
MS
Caloy Diaz wrote:
Hi, may I ask if any of you know how to read a whole port of the Atmel
microcontroller in Mica 2 with just one instruction? All I could read
now is just one pin at a time, say TOSH_
In T1 you can look for the various AM.h files to get the TOS_Msg structure.
For instance the mica2 and UART use tos/types/AM.h, whereas the micaz
radio uses: tos/platform/micaz/AM.h (and yes, you pretty much just have
to know which one to look at...although adding a -v to the ncc command
will give
If you are using TOS1.x, the description you have is of the
micaz (and I think tmote) RADIO structure. But, depending on
the settings of the host receiver, Listen.java is probably
giving you data in a structure that looks like tos/types/AM.h
-- which matches the UART (and mica2) message.
There is
g etc?
Regards,
Adi
On 8/8/07, *Michael Schippling* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
In T1 you can look for the various AM.h files to get the TOS_Msg
structure.
For instance the mica2 and UART use tos/types/AM.h, whereas the micaz
radio uses: t
See this for message decoding tips:
http://www.octavetech.com/pubs/TB5-01%20Deciphering%20TinyOS%20Serial%20Packets.pdf
The A100 values are your samples, in little-endian so the value is 0x00A1.
They are awfully stable (don't change) so I suspect that you are not really
sampling anything. Look in
At first glance it looks to me that there is some confusion of "channel"
and "moteID", or actually non-confusion as I don't see where the moteID
gets used, in the net/tinyos/oscope/GraphPanel.java method oscopeReceived().
A quick way to see if it'll work would be to change the channel number
in ea
Is BaseStation supposed to be sending something back?
Make sure there are messages being sent from the mote someplace.
And also check the silly-slide-switch on the MIB, I believe it
should be in the OFF position.
MS
Sumesh Philip wrote:
I'm trying to carry out tutorial 4 using a mib510 programme
Much too practical and useful. I don't see how it could catch on...
MS
Platform: WinXP/Cygwin
TinyOS version: 1.x, Boomerang
Programmer: MIB510
Device(s): Mica2, MicaZ, Tmote
Sensor board: homebrew
Siirtola Harri wrote:
Hi,
Could it be a good idea to make a signature that contains complete
pla
at it says. However if you are getting
the same ID from different motes you probably didn't install different
IDs when you downloaded. Do something like this: make X install.N
where X is your platform and N is the ID to use on that mote.
MS
Alessandro Turella wrote:
Michael Schippling ha scr
are surely many wrong/incompelte
things there...
2007/8/10, Michael Schippling <[EMAIL PROTECTED]>:
Much too practical and useful. I don't see how it could catch on...
MS
Platform: WinXP/Cygwin
TinyOS version: 1.x, Boomerang
Programmer: MIB510
Device(s): Mica2, MicaZ, Tmote
Senso
Surge
application 34 byte packet some times. Surge do send the 22 byte packet.
What does this packet signify and can any one tell me the packet format?
Regards,
Adi
On 8/9/07, *Michael Schippling* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
It is all, of course, a m
The LEDs should blink on the TOSBase mote if it is getting/sending radio
messages. I would try using Listen or ListenRaw to see if anything
is coming through when the LEDs flash. If no TOSBase flashing, check your
radio freq and power settings during compile. Especially on mica2, the
power is set
You'll have to go look at the schematics, or horrorssearch whatever
doc there is...to see if it's the same paradigm as the mica's. On Mica2,Z
the Voltage reading is coming from a fixed-value-ref where the ADC ref
is the actual battery voltage. So as the battery droops the fixed-ref
seems to in
Assuming you have a graphviz installed, it's probably a newer version
so you can ignore those messages. Try "type dot" and if it shows anything
you're probably OK.
You _could_ fix the CLASSPATH warnings by adding those elements
in one of the bash startup files. Or better, they should probably
be
send() returns fail when it is still working on a message
(and for reasons...), so this may indicate that you are
trying to send too fast. That's the original point of the
pending state variable, so make sure you have that logic
worked out correctly.
MS
Ittipong Khemapech wrote:
Hi Urs,
Thank
I'm cc'ing this back to the help list where someone may be able to...
From this is seems that your sensor is not working, perhaps not wired
or powered correctly. But I would first start with a simple radio
message transmission, like CntToRfm, to make sure that you have
connectivity. Then I would
You don't seem to have the TOSComm package installed correctly.
Look for instructions online or in the manuals.
MS
Iyad tumar wrote:
Hi i still face the same problem, to make
communication between PC and the telosB and i still
get this message
" Exception in thread "main"
java.lang.NoClassDefF
You may be using the wrong (older) version of Java,
or worse, compiling with one version and running with another.
I suspect that TOS requires 1.5++. "type java" and/or "which javac"
may provide clues.
I hate GUI's...
MS
sergio mena doce wrote:
Hi to all.
We are two students of the Technical
The micaZ's (and other 2420 radio motes) run at approx the same frequency
as 802.11b -- your favorite wireless networking wavelength. So any antenna
that works for wireless will work for 2420's. The connector is an MMCX,
which is _really_ painful to assemble, but it comes standard on some antennas
First thing is I wouldn't install java in "Program Files" because the
space in the dirname will just become more and more problematic.
Second, you probably do not have a PATH correctly set to your Java
installation, you should not have to make those symbolic links. This
may be the result of the P_
Yes, you have to use globals to pass arguments to tasks, so do something
like this and set the values in your async function before posting the task:
uint16_t *buf;
uint16_t buflen;
task void SendReadingsTask1() { ... }
You can't guarantee order of task execution, but y
It's entirely possible that moteIF doesn't throw any Exceptions.
You will probably have to dig through it's code to see, but for
the most part the compiler should whine if they exist and are not
caught. Or was the question about how to use try-catch itself?
MS
ZhuoHao Sum wrote:
Hi,
I'm worki
This is something I have never figured out how to do correctly
so I can only toss some ideas your way...maybe looking at the
cygwin.com site will help.
What you seem to want to do is to run a cygwin bash script from
an MSDOGS command shell, right?
The first place to look is reading the bash manu
If you are formatting the send string yourself you are probably
bound to do something wrong. Usually the CRC calculation, but
it could be anything...If you are using Java, look at the
Packetizer.java class to do the heavy lifting. You can see an
example of sending and receiving in my (old) code bo
Loosing 2% is not too bad actually, but under your ideal conditions
you should be doing better. Your surmise about send contention is
probably correct, but the only way I know to fix it is to implement
some kind of ACK-retry mechanism.
MS
Wojciech Czylok wrote:
Hello,
we are working on a resea
nks
Amrit
On 9/7/07, *Michael Schippling* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
This is something I have never figured out how to do correctly
so I can only toss some ideas your way...maybe looking at the
cygwin.com <http://cygwin.com> s
Please send questions to the TOS help list.
For everything you can do with the cygwin bash shell type: man bash
To set an envvar you can do this:
export MAKERULES=/some/file/name
MS
Bo Xu wrote:
Dear Sir:
Do you know how to set the environment variable MAKERULE?
Thank you so much!
I think what you need to do is have separate names for each ADC 'channel'
and call their getData()'s in sequence, something like this:
in the Config file:
ProjectOtherM.ADCx -> ADCC.ADC[TOS_ADC_SENSORX_PORT];
ProjectOtherM.ADCy -> ADCC.ADC[TOS_ADC_SENSORY_PORT];
ProjectOtherM.ADCz -> ADCC.
hmm, you _should_ only get one done per message send,
meaning one from the UART and one from the radio.
Using GenericComm, you need to sequence the sends such
that only one is active at a time. What I have done is
fire off the serial send from the done of the radio send.
If that doesn't work for y
Are we sure that the antennas are for the right wavelength?
By "linksys" I guess you mean a dongle from an 802.11b,g
router? Do they have the same connector as your Tmote?
And are the connectors seated well?
Also, you're sure you disabled the internal antenna?
I think there's a capacitor that nee
You have made a pointer, but it doesn't point to anything...
or more preciesely it is probably initialized to 0, so it
points to the bottom of memory. Since there isn't any mem
management (to speak of) the easiest thing is to create
your array directly:
uint16_t dataArr[SOMEsmallSIZE];
O
Make sure you have selected the same frequency defines for
both devices in the relevant makefiles. E.g., I have:
PFLAGS += -DCC1K_DEF_FREQ=91670
CFLAGS += -DRADIO_XMIT_POWER=0xFF
Note that the 'regular' apps/Makelocal doesn't set any power
level for mica2's, so that might be a proble
what is the value of
SomeSmallSize...
I can go the other way around by specifying a large value but I am
afraid that I may overflow the memory so is there a way to compute the
available memory?
Islam Hegazy
- Original Message - From: "Michael Schippling" <[EMAIL PROTECTED]>
At the end of my T1 "make mica2" I get:
compiled Robot to build/mica2/main.exe
15998 bytes in ROM
568 bytes in RAM
MS
Islam Hegazy wrote:
How can I compute the RAM usage at the end of compilation then?
Islam
- Original Message ----- From: "Mic
In general, any variable you define inside the implemenation
braces, but outside of a function, is "global" to the whole
module. Since tasks don't get arguments on their stack you
must use globals like this to pass data. So one fix for your
problem would be to copy buf and buflen to other 'global'
Sorry
fire-off means call ADCy.getData();
This will start the second (Y) conversion.
Then in ADCy.dataReady() call ADCz.getData();
to start the Z conversion. In ADCz.dataReady()
you could chain back to ADCx.getData() or leave
it to your timer to start the next set.
MS
Chen Bleed wrote:
It
hmmm, I don't use TOSSIM but it's possible that they made the
assumption that node 0 is the base-station (usually running
"TOSBase") and that other nodes would talk to the PC through
that one. In a 'real' mote system that would be the general
case, although you _can_ assign any ID to the mote in t
radio to the
basestation (node 0), and then towards the PC for displaying. But now, I
want to remove the debug from the radio.
I don't understand, so is it possible to receive packets from other nodes ?
Please explain. Thank you.
Ray
On 9/16/07, *Michael Schippling* <[EMAIL PROTECTED]
&
If you are using rpm to install you can try the --nodeps option.
Also I believe graphviz is only used for some documentation
generation so it shouldn't hang up development...well...any
more than the rest of the missing documentation...
MS
hamsa jega wrote:
Hi,
Thank you for your reply. I went
I might point out that the TOS toolchain does work on Widows XP
and there has been some chatter about Vista on this list. You
can search back and see if anything useful transpired, and look
at tinyos.net for various platform distributions. Otherwise I'm
pretty much at the beginning of the just-use
nfo is not
required always.
On 9/16/07, *Michael Schippling* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Perhaps I'm missing the point...you are using:
-comm [EMAIL PROTECTED]
which, I think, means you are talking to a simulator
rather than a
I you are using TOS1.x look at apps/SimpleCmd for an example
of sending data to a mote. I believe the host side java demo
that runs this is in tools/java/net/tinyos/tools/BcastInject.java
T2 probably has something similar.
MS
Leonardo wrote:
hy guy... i wanna write data by uart from pc to sens
Perhaps Urs's advice has helped the initial problem but I would
recommend that you just skip the SF processes and go directly to the
serial ports. You could start a java thread to wait on each port and
deliver the data for whatever processing you wish...
Anyway there is indication in the T1 tools
I think the complaint is simply that you have 'global'
and a local stack variables with the same name.
I'd just change this:
async event void a2d12ch.dataReady(uint16_t *buffer, uint16_t bufferlen)
to something like this:
async event void a2d12ch.dataReady(uint16_t *b, uint16_t bl)
However, yo
I don't think MOTECOM is significant to downloading programs,
only 'listening' to data messages. I believe the tmote system
has some magic for determining what USB port to use for downloads.
You might try reviewing the setup info in the tmote manual,
I remember there being some way to explicitly r
ng you have a separate problem. Config or otherwise.
On 9/18/07, Michael Schippling <[EMAIL PROTECTED]> wrote:
Perhaps Urs's advice has helped the initial problem but I would
recommend that you just skip the SF processes and go directly to the
serial ports. You could start a java threa
, all the names themselves are arbitrary as long as the
types map to each other.
MS
John Griessen wrote:
Michael Schippling wrote:
I think the complaint is simply that you have 'global'
and a local stack variables with the same name.
I'd just change this:
async event void a2d12ch.d
further with advice. But
one thing I would worry about is how long values are valid in your
buffer. If you start another conversion set before you gobble
up the results of the last one, you may get mixed results. In
that case making a copy would be indicated.
MS
John Griessen wrote:
Michael Sc
in T1 it's the macro: TOS_LOCAL_ADDRESS
but I think "they" changed the name in T2
so do a little googling.
MS
[EMAIL PROTECTED] wrote:
Hi ,
I wanna get a nodeId,for being clear I'm not talking about the
AM type or AM address of a node,but the id which is associated
to a node during the install
The Blink demo app ought do ya then.
MS
Chan kenniel wrote:
Thanks Philip, I have found that too, actually since I am kind of rush
for the project, so I would appreciate if there's any simple way
for me to learn wiring of nesC programming, I don't have enough time to
read the whole tutorial, t
In T1 there are some host side C programs in tools/src
Also search back on this list. I believe the thing that
is missing is the CRC calculation for sending messages,
and I know I've seen reports of this being hacked in
various non-Java languages.
MS
Chan kenniel wrote:
Dear all,
I have modifi
Does 'regular' printf() guarantee that now?
I remember having to do fflush() if I really wanted to see something.
MS
Philip Levis wrote:
On Sep 21, 2007, at 4:21 PM, Kevin Klues wrote:
I'm not sure I understand your concern. How is it different than
printf(3)?
When your printf returns,
t would be nice to not have to wire it (I think it
would be nice to not have to wire...well...anything...but that's just me).
But maybe we could have a null implementation to use to wire-it-out?
MS
Philip Levis wrote:
On Sep 21, 2007, at 5:56 PM, Michael Schippling wrote:
Does 'regular&
I can't swear that that specific code works, but what it is trying to do
is extract the received signal strength from each message and stick it
into a, maybe, unused byte of the message packet before resending it
over the UART. If you look for "strength" in the file you sent you
will see this in R
I did find this when googling "TOS_Msg length is invalid"
http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2005-July/010467.html
but I think it's more relevant to micaz/2 issues.
If ListenRaw works for you, you may be able to see the actual messages and
decode where it's going wrong. Or
Check that your CLASSPATH points to the tos tools. Mine is:
export CLASSPATH=".;C:/cygwin/opt/tinyos-1.1.7/tools/java/classes"
but it might be just .../java, or you may have a jar file.
MS
Ferry Cialis wrote:
Hi,
I'm trying out Lesson 4 for tinyos-2.x on Mote-PC serial communication.
I've t
Quite some time ago I tried to characterize speed and reliability
and came up with about 100 default sized messages/sec for the micaz.
However, there is some question that this might have been limited by
the serial port speed so it's to be taken with a grain...
My report is here: http://www.etant
You can of course add antennas of various kinds. The mica2's have
the advantage of being in the RFID freq range so there are some
standard things available. I found some in the digikey catalog.
MS
Jacob Sorber wrote:
Radio range will depend on how close to the ground you are. The range
you are
I write Q&D message classes to print what I want
and plug them into lightweight things like Listen.
Too many years of hexdumps, I guess...
MS
John W. Barron wrote:
With all the PrintF questions, I was wondering... How does everyone view
their data. If I send a Message_t to serail what are my op
In my cursory experience, the 'Zs seem to be more reliable
but also more environment sensitive. The higher the freq the
more line-o-sight it becomes. And 2.4G is an absorption band
for water...on the other hand there are more cheap antenna
options because it matches up with WiFi.
MS
Tony Han wr
My USB converter loaded a driver as COM3 which maps to /dev/ttyS2
in later versions of cygwin. You can see the port assignment
in the "Device Manager" under (on XP at least)
ControlPanel-AdminTools-ComputerManagement
Look for Ports. I found that the port number changed depending
on which USB i
I stared here:
http://www.tinyos.net/tinyos-2.x/doc/html/install-tinyos.html
and got to this:
http://www.graphviz.org/Download..php
hopefully that's what you need.
MS
Bo Zhang wrote:
Can anyone let me know how to install Graphviz on Cygwin?
Thanks in advance
Bo
Since the data[] array is bytes, only one byte (the LSB) is assigned.
One quick fix it is to do two assignments, knowing that everybody
expects multi-byte data to be in little-endian order:
data[2] = strength & 0xff;
data[3] = strength >> 8;
MS
RamKishore wrote:
Hi Mich
The COMx syntax is, unfortunately, only useful with older cygwin
versions that 'came with' TOS pre 1.1.10(or 11?). In some uses
with some newer versions "they" started using the nNIX /dev syntax.
I am purposely vague about the "somes" because I don't remember if
download and message comm are fello
e[1]: Leaving directory
`/cygdrive/c/tinyos/cygwin/opt/tinyos-1.x/apps/TOSBas
e'
make: *** [install.0] Error 2
May I know where did I go wrong?
Best regards,
U-Wei
On 9/27/07, *Michael Schippling* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
The COMx syntax
Most likely you have not calculated the CRC correctly...
danielw just sent a message about how to do this in T2:
http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2007-September/028109.html
MS
Roberto wrote:
I forgot an important (in my opinion) detail:
at the mica side, I would like rec
Boy, that's a tough one...I'm not entirely sure without looking up all
the chips but I think when powered by the USB it goes sorta like this:
page 3 top-left "USB Interface"
U22 pin 4 -- power from host -- becomes U_VCC
U25 TC55RP33 -- does some magic to make -- P_DVCC
page 3 top-right "Mote Pow
Error: No such file or directory
-> /dev/ttys7
make[1]: *** [reinstall.0] Error 1
make[1]: Leaving directory
`/cygdrive/c/tinyos/cygwin/opt/tinyos-1.x/apps/TOSBas
e'
make: *** [install.0] Error 2
May I know where did I go wrong?
t produces
3.3V. That voltage goes through the diode so that the USB side of the
mote is not reverse-powered when the mote runs on batteries and the
mote is disconnected from USB.
Cheers,
Rob
On 9/27/07, Michael Schippling <[EMAIL PROTECTED]> wrote:
Boy, that's a tough one...I'm
darn...I thought:
--
"The truth shall set you free"
Was quite relevant to the Subject: line...
MS
Bernardo Avila Pires wrote:
Greetings
I am sorry for having sent the empty e-mail.
Is there any way to simulate different components in TOSSIM? I've
tried to mask the components
nk when powered through USB. Why is that so?
Best Regards,
Xi
2007/9/27, Michael Schippling <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
Boy, that's a tough one...I'm not entirely sure without looking up all
the chips but I think when powered by the USB it
It's binary. Hyperterm want's ASCII...
MS
Dimuthu Jayasingha wrote:
Hello.
I am using mica2 mote platform and I need to access the serial data
coming from mote.
When I use "Listen" provided in the tinyos tools I can clearly see the
packet.
But when I access the the serial through hyper term
I believe you have it right. Except I'd have to go analyze the controller's
manuals to see if there is a notion of interrupt priority -- more likely
any enabled int can preempt a TOSH_INTERRUPT(). I think the A,B_EVENTS()
will execute in the interrupt context from whence they were called. So
in
1 - 100 of 1470 matches
Mail list logo
