Re: [Tinyos-help] Tmote - Deluge rewrites node numbers for Trawler application (Delta)?

[Simon Willis]

Hi,

I have a feeling that Deluge is doing a similar thing with my 
application. My application is closely based on Surge. When I reprogram 
my nodes using Deluge they appear to be transmitting periodically, but 
they don't form a network. I suspect that the address of the nodes has 
changed, but I have not checked this yet. Deluge works fine for other 
programs such as Blink.


Thanks,

Simon

Val Zimmer wrote:

Hi,

Running the Delta code and the trawler application w/ a mix of Tmote 
Sky and Tmote Invent motes, we found that every time we reloaded one 
of the Images (e.g. reloaded Delta), the node numbers were set to #1, 
across the entire network, such that the Trawler application is no 
longer able to see the nodes.  (This could only be restored by taking 
each mote and physically reloading the Delta software (make tmote 
reinstall,3 - for example)).


Is this an artifact of the delta image - i.e. was the image originally 
written with the default #1 so that rebooting would cause this issue 
(and then the reinstall would be entirely separate), or is this 
something that would always happen?  If the latter, might this be 
fixed in the near future?

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



--
Simon WillisBE(CompSys)(Hons)-BSc   
PhD Candidate   Tel: (07) 47814865
Electrical & Computer Engineering   Fax: (07) 47815177
James Cook University   Mob: 0403653055
Townsville, QLD 4811Email: [EMAIL PROTECTED]
Web: http://eng.jcu.edu.au

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

Re: [Tinyos-help] EWMAMultiHopRouter

[Simon Willis]

I have seen the same thing. I found that the problem was that 
Surge_Reliable relies on acks. If it does not receive an ack it will try 
to send the packet again. I was using a different version of the MAC 
protocol (CC1000RadioIntM) that what Surge_Reliable is supposed to use. 
I think this caused the problem (not 100% sure), because my version was 
not using acks.. Have a look at the make file in Surge_reliable to see 
where it is getting the CC1000RadioIntM file from. Hopefully that will 
help you out.


Also, just out of interest I noticed that the version of CC1000RadioIntM 
that Surge_Reliable uses is actually an older version than the version 
in the /platform/mica2 directory.


Cheers,

Simon

Pablo Gil Montaño wrote:


Hi all,

I'm trying to use EWMAMultiHopRouter in 
contrib/xbow/tos/lib/ReliableRoute for reliable multi-hop routing. The 
problem is that I received several copies of the same packet in the 
base station (I have just 7 nodes working and I tipically receive more 
than 10 duplicate packets. I'm sure I'm not sending the same packet 
more than once (just by substituing EWMAMultiHopRouter with 
MultiHopRouter in tos/lib/Route works perfectly).


Regards,

Pablo Gil



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



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

Re: [Tinyos-help] MultiHopRouter(s)

[Simon Willis]

Mintroute is explained in this paper:
http://www.cs.berkeley.edu/~awoo/sensys_awoo03.pdf

I'm not sure what the differences are beteween the lib/Mintroute file 
and the xbow version. So far the only thing I have noticed is that the 
lib version has an estimate to route ratio of 10, whereas the xbow 
version has a ratio of 5.


Benjamin Madore wrote:

I've been working with the Multi-Hop Routing, and I have one burning question:

What is the difference in implementations?

I have looked at:
 xbow EWMA Multihop Router (ReliableRoute)
 MultiHop LEPSM (lib/Route)
 MultiHop LQI (lib/MultiHopLQI)
 MultiHopRouterM (lib/Route -- not wired in)
 MultiHop WMEWMA (lib/MintRoute)

The MultiHop document only mentions LEPSM. Several people have mentioned the
EWMA, but I have found it to appear hastily written. Is there a document
that explains what these are? A readme? Anything?

Which should I choose to base new code on?

  



--
Simon WillisBE(CompSys)(Hons)-BSc   
PhD Candidate   Tel: (07) 47814865
Electrical & Computer Engineering   Fax: (07) 47815177
James Cook University   Mob: 0403653055
Townsville, QLD 4811Email: [EMAIL PROTECTED]
Web: http://eng.jcu.edu.au

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

[Tinyos-help] {Spam?} Mintroute in contrib/xbow directory and Mintroute in tos/lib directory: What's the difference?

[Simon Willis]

Hi everyone,

I'm using Surge with Mintroute and have downloaded the xbow contrib 
files from their website. If I compile Surge to use the Mintroute 
implementation in the contrib/xbow directory I am able to use 
Surge-View.exe which is provided by xbow. However, if I compile Surge to 
use the newer Mintroute implementation in the tos/lib directory it does 
not work with Surge-View. What is the difference between these two 
implementations? I have it working with Moteview and using Surge-View is 
of secondary importance. Are there any improvements in the newer tos/lib 
implementation?



Thanks,

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

Re: [Tinyos-help] Fwd: TinyOS Wiring Diagrams

[Simon Willis]

Another way to do it is to download the TinyOS plugin for Eclipse from here:
http://www.dcg.ethz.ch/~rschuler/

It draws component diagrams as well and allows you to break down the 
components further to see how they are wired up internally.


Simon

Michael Schippling wrote:

I don't know what that diagram looks like, but, assuming you have
GraphViz setup as it should be, you can do "make  docs"
in any app directory and get a picture-to-puzzle-over like this:
http://www.etantdonnes.com/Motes/contrib.xbow.apps.Robot.Robot.nc.if.gif

In a fit of data hiding frenzy the output of the docs is put in:
../..doc/nesdoc/
MS

Bernd-Christian Renner wrote:

Hello list,

I would like to draw a Wiring/Configuration Diagram for a TinyOS 
application
and would be glad if somebody could tell me how I could do that. What 
I mean
is something like the graph in "The nesC Language: A holistic 
approach to

networked embedded sytems", page 5, figure 6.


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


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



--
Simon WillisBE(CompSys)(Hons)-BSc   
PhD Candidate   Tel: (07) 47814865
Electrical & Computer Engineering   Fax: (07) 47815177
James Cook University   Mob: 0403653055
Townsville, QLD 4811Email: [EMAIL PROTECTED]
Web: http://eng.jcu.edu.au

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

Re: {Spam?} [Tinyos-help] HELP on running surge-view

[Simon Willis]

Which version of Surge-view are you running? I believe there is one in 
the java tools directory and there is also an executable that you can 
download from Crossbow. I recently installed and ran the xbow version of 
Surge with the Surge-view executable from Crossbow.


Simon
TIAN YUXIANG(AARON) wrote:

Hi,
 
While I was trying the TinyOS Surge Program, I got following two errors:
 
1. java.lang.NullPointerException at 
net.tinyos.surge.PacketAnalyzer.FlowAnalyzer.clear
 
2.
receive error for net.tinyos.oscil.OscopeMsg (AM type 17):12 invalid 
length message received (too short)
receive error for net.tinyos.oscil.OscopeMsg (AM type 17):15 invalid 
length message received (too short)


I tried both TOSBase ,Surge, Surge_Reliable in apps and xbow folder. 
The remote mote could be seen on the surge interface, the problem is 
just the packets received are all invalid length, either too long or 
too short.
 
Any one please help me... Thank you very much in advance...



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


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

Re: [Tinyos-help] Bugs found in Deluge/TOSBoot

[Simon Willis]

Hi Mingze,

I found the same problem when I was trying to get Deluge to work on my 
Mica2-based nodes. I think that the pre-compiled binary for mica2 may 
not have been recompiled with the new version of TOSBootM.nc. I needed 
to have TOSBoot working ASAP and they way I got it working was to 
download an earlier version of TOSBootM.nc off CVS and then it worked.


Deluge seems to work fine with general problems, but I have a problem 
when I use Deluge to update my Surge-like program. All the nodes seem to 
reprogram themselves, but none of them talk. It's very odd. I've had to 
move on and get on with something else.


Cheers,

Simon
ZHANG Mingze wrote:


Hi all,

I was debugging Deluge on mica2dot for two days and finally found 
something wrong in Deluge/TOSBoot, hope anyone who has knowledge on 
this can confirm with me.


First, the Deluge/TOSBoot/build/mica2/main.ihex shipped in 1.1.15 rpm 
(both tinyos and linux) is alright, but 
Deluge/TOSBoot/build/mica2dot/main.ihex does not work.


Second, the Deluge/TOSBoot/TOSBootM.nc is not working for both mica2 & 
mica2dot (I am curious where the mica2/main.ihex comes from if this 
code is not working). I further debug into, and find this line is not 
working for mica2 and mica2dot,

if (intAddr != TOSBOOT_END)
  return ERROR;

the TOSBOOT_END is not defined anywhere for both mica2 and mica2dot. 
Actually the initial address of both mica2 and mica2dot is 0x,
(I can confirm this in the binary image written on External Flash, I 
have read them out and read line by line, the intial address is 
0x. This image on External Flash is right because mica2/main.ihex 
shipped with the rpm is able to reprogram the image without any problem),

so here the program should be,

if (intAddr != 0x)
  return ERROR;

Then, the problem is still not solved, I use LED count to count that 
there are exactly 90 loops in the real programming code, each loop 
256bytes of binary will be reprogrammed (except the last loop), the 
section length is 22982 for the BlinkDeluge application, 22982/256 is 
exactly 89.77 so I believe all codes from flash are correctly written 
to Program Flash. However, although the reprogramming succeeds, the 
reprogrammed program is not correct (for example for the 
BlinkApplication, the LED is not blinking after reprogram).


So I wonder where's anything else can be wrong in TOSBootM.nc. The 
thing I suspect is ProgramFlash.nc but I am not sure. Hope anyone can 
help out.


Really thanks for the patients to read through, and hope my findings 
can help somebody else who is also struggling here..


Anyway, is it possible that the Deluge team is able to provide me with 
the correct bootloader main.ihex for mica2dot too? If so, it will 
save  me a lot of time.


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



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

Re: [Tinyos-help] Debugging nesC code with the USB AVR JTAG ICE

[Simon Willis]

I have used it in TinyOS1.x. It took me a while to get it doing. I can't 
remember exactly what I had to do to get it to work. I have a feeling 
that I may have had to download a new version of avarice. The one that 
bundled with TinyOS1.x is a bit old and doesn't support the JTAGICEII. I 
don't know if the TinyOS2.x version supports it or not. I also had to 
add AVARICE_ARGS='-2 -j /dev/ttyS0' to the /etc/profile file to get it 
to work with the correct serial port. I think I had the same 
'/dev/avrjtag' error before I did this.


I hope this helps.

Simon

Jon Wyant wrote:
Hi.  Has anyone used the USB AVR JTAG ICE mk-II device for debugging 
TinyOS 2.x code?
 
I found the link for using the serial device on TinyOS 1.x code 
(http://www.tinyos.net/tinyos-1.x/doc/nesc/debugging.html), so I 
attempted to see if those directions would be similar enough to work.
 
I keep getting a "Failed to open /dev/avrjtag: No such file or 
directory" error when running ice-gdb. The "-j" switch doesn't seem to 
affect this in anyway. I have tried various options just to see if the 
error message would change, and it doesn't. I have installed AVR 
Studio and WinAVR. I know the device is working because I can read and 
program the fuses from AVR Studio just fine. I tried the ice-gdb file 
in the WinAVR\bin folder instead of the one that came with the Cygwin 
install, but still get the same error.
 
Also, I have been trying to compile a target file with extended coff 
debugging, that I could then open in AVR Studio, but have been un-able 
to get that part to work either. I have tried adding the "avr-objcopy 
--debugging -O coff-ext-avr " option to the "avr.rules" file, but 
I always get an "avr-objcopy: build/micaz/main.coff: Invalid bfd 
target" error. I tried the version of the avr-objcopy file from WinAVR 
tools (which has the coff-avr-patch), and I get the same error.
 
Any thoughts or suggestions would be greatly appreciated!
 
Thanks.
 
Jon
 



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



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

Re: {Spam?} [Tinyos-help] XSensorMTS300 compilation problem

[Simon Willis]

I had the same problem on my mica2-based nodes. My solution was to copy 
Voltage.nc into my platform directory and add included Voltage.nc at the 
top.


Simon
Ka.Selvaradjou wrote:

Hi,
I am trying to test XSensorMTS300, but getting the following error...

[EMAIL PROTECTED] XSensorMTS300]# make micaz
mkdir -p build/micaz
compiling TestSensor to a micaz binary
ncc -o build/micaz/main.exe -Os 
-I/opt/tinyos-1.x/contrib/xbow/tos/interfaces  
-I/opt/tinyos-1.x/contrib/xbow/tos/system  
-I/opt/tinyos-1.x/contrib/xbow/tos/platform/micaz 
-I/opt/tinyos-1.x/contrib/xbow/tos/lib 
-I/opt/tinyos-1.x/contrib/xbow/tos/sensorboards/mts310 
-finline-limit=10 -Wall -Wshadow -DDEF_TOS_AM_GROUP=125 -Wnesc-all 
-target=micaz -fnesc-cfile=build/micaz/app.c -board=mts310 
-DCC1K_DEFAULT_FREQ=RADIO_916BAND_CHANNEL_00 -DRADIO_XMIT_POWER=0xFF 
-DCC2420_TXPOWER=TXPOWER_MAX -DCC2420_DEF_CHANNEL=26 -I%T/lib/Deluge 
-DIDENT_PROGRAM_NAME=\"TestSensor\" -DIDENT_USER_ID=\"root\" 
-DIDENT_HOSTNAME=\"wdm.cs.iitm.ern\" -DIDENT_USER_HASH=0x5e79f256L 
-DIDENT_UNIX_TIME=0x458033b4L -DIDENT_UID_HASH=0x059d6a93L 
-I/opt/tinyos-1.x/tos/lib/CC2420Radio TestSensor.nc -lm
/opt/tinyos-1.x/tos/system/Voltage.nc:41: `TOS_ADC_VOLTAGE_PORT' 
undeclared here (not in a function)
/opt/tinyos-1.x/tos/platform/micaz/VoltageM.nc: In function 
`StdControl.start':
/opt/tinyos-1.x/tos/platform/micaz/VoltageM.nc:67: 
`TOS_ADC_VOLTAGE_PORT' undeclared (first use in this function)
/opt/tinyos-1.x/tos/platform/micaz/VoltageM.nc:67: (Each undeclared 
identifier is reported only once
/opt/tinyos-1.x/tos/platform/micaz/VoltageM.nc:67: for each function 
it appears in.)
/opt/tinyos-1.x/tos/platform/micaz/VoltageM.nc:68: 
`TOSH_ACTUAL_VOLTAGE_PORT' undeclared (first use in this function)

/opt/tinyos-1.x/tos/platform/mica2/ADCREFM.nc: In function `CalTask':
/opt/tinyos-1.x/tos/platform/mica2/ADCREFM.nc:94: interface has no 
command or event named `manualCalibrate'

/opt/tinyos-1.x/tos/platform/mica2/ADCREFM.nc: At top level:
/opt/tinyos-1.x/tos/platform/mica2/ADCREFM.nc:282: `manualCalibrate' 
is not in interface `ADCControl'
/opt/tinyos-1.x/tos/platform/mica2/ADCREFM.nc:293: `autoCalibrate' is 
not in interface `ADCControl'

/opt/tinyos-1.x/tos/system/Voltage.nc:41: constant expression expected
make: *** [exe0] Error 1
--

toscheck says tinyos is installed without error and I am able to 
comfortably compile other apps such as Blink, RfmToLed etc., without 
any problem.


What could be wrong?
I will appreciate your early reply in this regard.

Thanks,
Selvaraj

Have a burning question? Go to Yahoo! Answers 
 
and get answers from real people who know.



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



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

[Tinyos-help] Injecting surge using Deluge

[Simon Willis]

Hi everyone,

I am trying to program my nodes with Surge using Deluge. I have added 
the necessary Deluge statements into the Surge.nc file, recompiled it 
and injected it into the network of nodes that are running DelugeBasic. 
It appears that Surge is injected successfully and the nodes reboot. 
However, after this point no Surge data is forwarded to the serial port. 
I can see that the nodes are talking to each other over radio (I have a 
LED on the transmit line) and I assume this is Surge data (not deluge), 
but no data is received over the serial port. I am able to ping nodes 
with Deluge. If I program each node manually with Surge then it works 
fine. I have also tried taking out the Deluge statements in Surge.nc 
(Delugebasic is the golden image so you can get delugebasic back, by 
pressing reset three times) and it does not work.


Does anyone have any idea what could be the problem? My only thought is 
that maybe the node addresses are lost. These were set when I programmed 
Deluge basic. Does Surge use the same value?


Thanks,

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

Re: [Tinyos-help] Deluge mica2 reboot problem

[Simon Willis]

I thought I would post an update. I have been able to get Deluge working 
fine by downloading revision 1.1 of TOSBootM.nc and compiling TOSBoot 
using this file. The latest revision of TOSBootM.nc is v1.4, when I 
compile using this file I can inject a program and issue a reboot, but 
it will not reboot properly. I found that it fails in the programImage 
function at the following line, which apparently checks that the image 
starts on the correct boundary.


if (intAddr != TOSBOOT_END) {

 call ExtFlash.stopRead();

 return R_INVALID_IMAGE_ERROR;

   }


I found the following comment in CVS when revision 1.3 was added:

fail if the program image starts at the wrong address
(program too small or compiled for a different bootloader/revision)


Does this mean that I am compiling my program wrongly or something? I 
have updated all of the /lib/Deluge (and TOSBoot) directory from CVS. I 
compile my program using the following steps:

-Compile TOSBoot
-Compile and install DelugeBasic
-Compile by Blink test program
-Inject my program and try to reboot.

I am using Tinyos1.1.15 provided with the tinyos Eclipse plugin. The 
fact that my program originally worked using the pre-compiled mica2 
binary that was packed with tinyos1.1.15, may suggest that this was not 
updated in the release.


Thanks,

Simon


Simon Willis wrote:

Hi there,

I'm trying to get Deluge to work on my own platform that is similar to 
the mica2. So far I have managed to get it running by telling my 
makefile to install the TOSBoot image stored in the 
/Deluge/TOSBoot/build/mica2 directory. I have been able to install 2 
new images, issue a reboot and it changes images like it should.


I just updated the mica2 binary from CVS (apparently there was an 
update to ProgFlashM.nc by Jacob Sorber 6 months ago) and installed it 
on my node and Deluge will no longer reboot properly. I have 
recompiled DelugeBasic and my test program (Blink) and have injected 
them both again. When I issue a reboot command it goes through the 
usual count down sequence, but always reverts to the golden image. It 
is not giving the three flashes of the red LED which indicates a low 
battery, so it is not that problem. I also tried recompiling TOSBoot 
and it will not work with the new binary.


Can anyone help me out here? I'm thinking that may be something has 
changed with the make system, perhaps to do with the flash, but that's 
a guess.


Thanks,

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

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

[Tinyos-help] Deluge mica2 reboot problem

[Simon Willis]

Hi there,

I'm trying to get Deluge to work on my own platform that is similar to 
the mica2. So far I have managed to get it running by telling my 
makefile to install the TOSBoot image stored in the 
/Deluge/TOSBoot/build/mica2 directory. I have been able to install 2 new 
images, issue a reboot and it changes images like it should.


I just updated the mica2 binary from CVS (apparently there was an update 
to ProgFlashM.nc by Jacob Sorber 6 months ago) and installed it on my 
node and Deluge will no longer reboot properly. I have recompiled 
DelugeBasic and my test program (Blink) and have injected them both 
again. When I issue a reboot command it goes through the usual count 
down sequence, but always reverts to the golden image. It is not giving 
the three flashes of the red LED which indicates a low battery, so it is 
not that problem. I also tried recompiling TOSBoot and it will not work 
with the new binary.


Can anyone help me out here? I'm thinking that may be something has 
changed with the make system, perhaps to do with the flash, but that's a 
guess.


Thanks,

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

[Tinyos-help] Setting up TOSBoot with make system for new platform

[Simon Willis]

Hi Everyone,

I'm trying to get Deluge to work with my new platform which is based on 
the Mica2. I have manged to install DelugeBasic and upload programs, 
ping etc (as per the Deluge manual). However, I have discovered that 
make does not install TOSBoot like it does on the Mica2.


I am using the new make system and have a .target file in my contrib 
directory that seems to work fine. I have searched through all of the 
make files for mica2 and I can't work out how it is doing the TOSBoot 
part. Can anyone help me out here?


Thanks heaps,

Simon

--
Simon WillisBE(CompSys)(Hons)-BSc   
PhD Candidate   Tel: (07) 47814865
Electrical & Computer Engineering   Fax: (07) 47815177
James Cook University   Mob: 0403653055
Townsville, QLD 4811Email: [EMAIL PROTECTED]
Web: http://eng.jcu.edu.au

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

Re: {Spam?} [Tinyos-help] what is SQUELCH...... in cc1000??

[Simon Willis]

Have a look at the CC1000RadioIntM.nc file in /tos/platform/mica2. The 
squelch is continuously varied by measuring the signal strength when the 
radio is idle. The current squelch values is called usSquelchVal. This 
is calculated using a squelch table (usSquelchTable).


When transmitting the program waits a random delay time (sMacDelay). 
Everytime a byte is received from the radio an interrupt occurs. If this 
byte is rubbish and a transmit it pending then it decrements sMacDelay 
until it is 0. When this occurs then it tries to transmit by checking 
that the signal strength is low enough (less than squelch) before 
transmitting.


I hope this helps.

Simon

primalfear 69 wrote:

hello everybody..
 
why and for what is Squelch term or variable is used in CC1000?
i have a similar doubt in case of macdelay. (i guess mac delay 
is used in order to transmit another data when it has already sent 
one). if am wrong please correct me. and could anyone get me some help 
regarding the interrupts in general.
 
Regards
 
Primalfear



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



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

Re: [Tinyos-help] Fuse Help

[Simon Willis]

Perhaps the mica2dot is using the UART (if it has this ability like the 
mica2). Check the switch on the MIB510 is in the on position. This stops 
the mote from accessing the serial port.


Also, if you have a JTAGICE you could try to access the MCU fuses using 
AVR Studio.


Cheers,

Simon

[EMAIL PROTECTED] wrote:

The voltage levels are fine on the mote and programmer board. I have been using this serial cable 
for some time now with no problems. I had used the same command to try to read the fuses with no 
success (I also retried just then), i get the "programmer is not responding" error (with 
about every 3rd attempt giving "device is not responding correctly"). If the problem is 
not the fuses do you have any idea what else could be causing these errors?

Sam

- Original Message -
From: Simon Willis <[EMAIL PROTECTED]>
Date: Tuesday, August 22, 2006 3:00 pm
Subject: Re: [Tinyos-help] Fuse Help

  
I had similar problems with my own node, but that's because we 
designed 
it from scratch and the MCU fuses were set as they are from the 
factory. 
I think (I don't know this for certain) that the mica2 and mica2dot 
fuses might be preconfigured for that board, so you shouldn't have 
any 
problems and it seems that most people don't. The "programmer not 
responding" error is not the problem of the MCU, but the programmer 
board. Perhaps check the voltage of it and that you have the 
correct 
serial cable. In my installation of cygwin I found that it would 
fail if 
I specified the serial port as 'com1'. Instead I have to use 
/dev/ttyS0 
and it works fine.


To read fuses:
uisp -dprog=mib510 -dserial=/dev/ttyS0 -dpart=ATmega128 --rd_fuses

Cheers,

Simon

[EMAIL PROTECTED] wrote:


Hi,

I am having trouble programming a mica2dot mote using an mib510 
  

programming board. I get errors which alternate

between "programmer is not responding" and "device is not 
  

responding correctly" when I try to load code onto the mote.

>From reading the help lists I beleive this is a fuse problem, 
  

however, when I try to use a uisp command to read the fuse

values I get an error saying the "device is not responding 
  

correctly". Has anyone encountered this before? And if so, what


can be done to fix this problem?

Thanks,
Sam
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-
  

bin/mailman/listinfo/tinyos-help

  
  




--
Simon WillisBE(CompSys)(Hons)-BSc   
PhD Candidate   Tel: (07) 47814865
Electrical & Computer Engineering   Fax: (07) 47815177
James Cook University   Mob: 0403653055
Townsville, QLD 4811Email: [EMAIL PROTECTED]
Web: http://eng.jcu.edu.au

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

Re: [Tinyos-help] Fuse Help

[Simon Willis]

I had similar problems with my own node, but that's because we designed 
it from scratch and the MCU fuses were set as they are from the factory. 
I think (I don't know this for certain) that the mica2 and mica2dot 
fuses might be preconfigured for that board, so you shouldn't have any 
problems and it seems that most people don't. The "programmer not 
responding" error is not the problem of the MCU, but the programmer 
board. Perhaps check the voltage of it and that you have the correct 
serial cable. In my installation of cygwin I found that it would fail if 
I specified the serial port as 'com1'. Instead I have to use /dev/ttyS0 
and it works fine.


To read fuses:
uisp -dprog=mib510 -dserial=/dev/ttyS0 -dpart=ATmega128 --rd_fuses

Cheers,

Simon

[EMAIL PROTECTED] wrote:

Hi,

I am having trouble programming a mica2dot mote using an mib510 programming 
board. I get errors which alternate
between "programmer is not responding" and "device is not responding correctly" 
when I try to load code onto the mote.
>From reading the help lists I beleive this is a fuse problem, however, when I 
try to use a uisp command to read the fuse
values I get an error saying the "device is not responding correctly". Has 
anyone encountered this before? And if so, what
can be done to fix this problem?

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


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

Re: {Spam?} [Tinyos-help] TinyOS Eclipse Plugin

[Simon Willis]

Have you seen the installation guide:
http://www.dcg.ethz.ch/~rschuler/installation.htm

I followed this and had no problems.

antonio gonga wrote:


does any one knows how is the coorect form to setup TinyOS Eclipse 
Plugin?, I just tried lots of times and i'm getting the same error: 
"*cannot open TinyOS.prespective2*", and when I open the Wrapper Env, 
it Warns: Cannot Open Class:

please if any one knows feel free to answer back me.
 
thanks in advance



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



--
Simon WillisBE(CompSys)(Hons)-BSc   
PhD Candidate   Tel: (07) 47814865
Electrical & Computer Engineering   Fax: (07) 47815177
James Cook University   Mob: 0403653055
Townsville, QLD 4811Email: [EMAIL PROTECTED]
Web: http://eng.jcu.edu.au

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

Re: [Tinyos-help] Reading MCU regisgers with ice-gdb

[Simon Willis]

Hi Ram,

Thankyou very much for your reply. That works perfectly. It will make my 
debugging much easier.


Cheers,

Simon

Ram Kumar Rengaswamy wrote:

Hi,

AVR IO registers are memory mapped.
For e.g. TCCR0 register is at the address 0x53.
You can use view the contents of this IO register by creating a 
pointer to that address and dereferencing it.

Something like:  p/x *(uint8_t*)0x53
The memory addresses of the registers can be obtained from the AVR 
datasheet.


-Ram

On Aug 17, 2006, at 4:40 PM, Simon Willis wrote:


Hi,

I'm using a JTAGICE II and ice-gdb for debugging. Is there anyway to 
read the MCU registers when I hit a breakpoint? I know how to read 
the normal registers like r0,r1 etc, but I don't know how to access 
the peripheral registers like the timer status registers etc. Can 
anyone help?


Thanks,

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








--
Simon WillisBE(CompSys)(Hons)-BSc   
PhD Candidate   Tel: (07) 47814865
Electrical & Computer Engineering   Fax: (07) 47815177
James Cook University   Mob: 0403653055
Townsville, QLD 4811Email: [EMAIL PROTECTED]
Web: http://eng.jcu.edu.au

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

[Tinyos-help] Reading MCU regisgers with ice-gdb

[Simon Willis]

Hi,

I'm using a JTAGICE II and ice-gdb for debugging. Is there anyway to 
read the MCU registers when I hit a breakpoint? I know how to read the 
normal registers like r0,r1 etc, but I don't know how to access the 
peripheral registers like the timer status registers etc. Can anyone help?


Thanks,

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

Re: {Spam?} Re: [Tinyos-help] eclipse plugin make on rene2

[Simon Willis]

I have the same problem in Eclipse. I have altered the make environment 
for my own node using a similar process to you, except I didn't copy my 
.target file into the tools/make directory. I just set the TOSMAKE_PATH 
variable to contain the location of my own make directory in the contrib 
directory.


make works fine from the shell, but not with Eclipse. I suspect that the 
Eclipse plugin might be using the old make environment instead of the 
new one.


Simon

Firat TARAKTAS wrote:

1. have you created a rene2.target file in tools/make?
2. Modify tools/make/all.target file as PLATFORMS ?= mica mica2 
mica2dot telos telosb micaz pc rene2?

I wish they can solve
___
*F?rat TARAKTAS,** *

*GENETLAB BI.LGI. TEKNOLOJI.LERI. A.S,.*
Kay?s,dag(? Caddesi Kar Plaza D Blok Kat:3 34752
I.çerenköy / I.stanbul

Tel: +90 (216) 573 00 85 | 354
Fax:+90 (216) 469 85 07

[EMAIL PROTECTED] 
*www.genetlab.com
* * * 

- Original Message -

*From:* Sören Rinne 
*To:* tinyos-help@Millennium.Berkeley.EDU

*Sent:* Thursday, August 17, 2006 2:16 PM
*Subject:* [Tinyos-help] eclipse plugin make on rene2

Hi,

can anybody tell me, why "make" won't work for target "rene2" in
the eclipse plugin? There is a folder called "rene2" in
"tos\platform", but ...?

cheers
Soeren


___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU

https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help



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



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

Re: {Spam?} Re: [Tinyos-help] tinyViz running problems

[Simon Willis]

Fırat TARAKTAŞ
GENETLAB BİLGİ TEKNOLOJİLERİ A.Ş.
Kayışdağı Caddesi Kar Plaza D
Blok Kat:3 34752
İçerenköy / İstanbul
Tel: +90 (216) 573 00 85 | 354
Fax:+90 (216) 469 85 07
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> mailto:[EMAIL PROTECTED]>>
 www.genetlab.com
<http://www.genetlab.com>





___

Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
<mailto:Tinyos-help@Millennium.Berkeley.EDU>

    https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help









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



--
Simon WillisBE(CompSys)(Hons)-BSc   
PhD Candidate   Tel: (07) 47814865
Electrical & Computer Engineering   Fax: (07) 47815177
James Cook University   Mob: 0403653055
Townsville, QLD 4811Email: [EMAIL PROTECTED]
Web: http://eng.jcu.edu.au

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

[Tinyos-help] Timer debugging

[Simon Willis]

Hi everyone,

I'm trying to use Timer1 as a timer for my manchester encoder on my node 
which is based on the mica2. I am using HPLTimer1M.nc from the micaz and 
have modified it slightly for my application. Basically, the timer acts 
as a the clock for the SPI which outputs the manchester encoded bytes to 
the radio chip. I have found that it works fine at 9600bps, but when I 
try 19200bps it works for about 17 bytes and then the timer just cuts 
out. I am operating the timer in CTC (clear timer on compare) mode. I am 
using pin OC1C for output. The prescaler for the timer is set to /8, so 
the interval is set to 11 to get the correct output frequency.


I'm not sure where it's going wrong. My program is a very basic test 
program that basically starts the transceiver and then justs starts 
transmitting bytes which are manchester encoded before they are sent 
over the SPI. There is nowhere in my code that resets the clock, so 
perhaps the OS is doing something? I'm kind of stuck on what to check. I 
was thinking that maybe the manchester encoder cannot keep up, but I'm 
not sure how to check.


Does anyone have any ideas what might be causing the problem or anything 
I can check to work out where it's going wrong? I have a MIB510 and a 
JTAGICEII that I have been using with ice-gdb. Also, does anyone know 
how to check the registers of the MCU using ice-gdb?


Thanks,

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

Re: [Tinyos-help] Tinyos1.x,micaz mote,ATmega128,FLASH!!

[Simon Willis]

Have a look at tutorial 8. 
http://www.tinyos.net/tinyos-1.x/doc/tutorial/lesson8.html


It uses the logger component to perform datalogging into Flash. That 
should get you started.


I had problems last week using the Flash on mica2, because it was using 
the wrong PageEEPROM files. For some reason the compiler was getting the 
files from the /platform/mica directory instead of /lib/flash/AT45DB. 
This cause it to throw an error during compilation about PageEEPROM.  
I'm pretty new at TinyOS and couldn't work out how to fix it, so I just 
copied the necessary files from /lib/flash into the same directory as my 
program and it worked. I'd be interested to know if you have similar 
problems.


Simon

Munaretto, Daniel wrote:


Hi all,
i found some files in www.tinyos.net/tinyos-1.x/tos/  for using the FLASH memory. I 
transferred these files to my "FLASH" folder in tinyos-1.x/tos/lib  but now i 
don't know how to use them. Previously in this folder there were only ByteEEPROM.nc, 
ByteEEPROMC.nc, PageEEPROM.h, PageEEPROM.nc, PageEEPROMShare.nc.

My project needs more memory than the available RAM (only 4 Kbytes), so we 
think to write data on FLASH.

Does anyone know how to handle these files?  like BlockStorage.h, BlockRead.nc, 
BlockWrite.nc, FormatStorage.nc, Mount.nc, Storage.h, FlashWP.nc, 
StorageRemap.nc

Do i need other files?

Please, every help will be really appreciated!
Thanks very much,
cheers
Daniele

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



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

Re: {Spam?} [Tinyos-help] Writing to FLASH, which Components/Interfaces to use

[Simon Willis]

I also had some problems using Logger.LoggerWrite and Logger.LoggerRead. 
Using TinyOS1.1.15 it would give an error when I tried to build my app 
that said


`computeCrcContinue' is not in interface `PageEEPROM'

I am using a Mica2, but for some reason the compiler was using the files in 
tos/platform/mica instead of tos/Flash/AT45DB

My temporary fix was to copy the PageEEPROM files out of /Flash/AT45DB and put 
them in the same directory as the app.

This fixed the problem, but I need to work out how to fix the problem with 
make. Any ideas?

Simon

Lei Tang wrote:

Hi, Sean,

I had some problems when I was trying to write and read to/from flash 
on MICAz. But now it works very well. You need the component, Logger; 
and the interfaces are Logger.LoggerWrite and Logger.LoggerRead.


Look through the files in apps\SensorLightToLog, you will find them. 
If it still doesn't work, change the mote and try your luck.


regards,
Lei


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


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

Re: [Tinyos-help] uisp and mica2 programming problems

[Simon Willis]

I have now fixed the problem properly and I thought I would post it on 
this mailing list for future reference.


The simple fix was to change the low fuse to 0xFF. It was previously set 
at 0xFD which is what is stated in the fuse information on the xbow 
site. However, I noticed in a different Mica2 document that a screen 
shot of rd_fuses showed is was 0xFF. The difference here relates to the 
clock setting. According to page 37 of the ATMEGA128 datasheet OxFF is 
used for a XTAL with low rising power (start-up time from power save is 
16K CK and additional delay from reset of 65ms). OxFD is used for a 
ceramic resonator with fast rising power (start-up time from power save 
is 1K CK and additional delay from reset is 4.1ms).


This problem probably won't ever bother anyone with a purchased Mica2, 
but may catch out those people like me who are making a node from scratch.


Cheers,

Simon

Simon Willis wrote:

Some more news on this problem.

It is still occurring, but I can now get around it consistently. I 
also discovered that it will program the board with no problems if I 
change the high fuse to 0xD9 (uisp makes is 0xD8). In my last email I 
said that I was setting this fuse to 0x19, but it seems 0xD9 also 
works. The only difference this has from the uisp 0xD8 is that the 
BOOTRST vector is disabled. Does anyone have any idea what's going on 
here? I also discovered that writing 0xD8 to the high fuse will allow 
me to read the fuses reliably (it seems), but when I program it (with 
Blink for example) the program does nothing.


So here is how I program my boards:
-Write 0xD9 (or 0x19) to the high fuse several times: uisp 
-dprog=mib510 -dserial=/dev/ttyS0 -dpart=ATmega128 --write_fuse_h=0xD9
-Check the fuses: uisp -dprog=mib510 -dserial=/dev/ttyS0 
-dpart=ATmega128 --rd_fuses

-If the fuse has changed then continue
-Upload the program: make mica2 reinstall mib510,/dev/ttyS0

Does anyone have any ideas why it might be doing this or how I can fix 
it? Or even a few things I can do with the MIB510 to try and 
troubleshoot it?


I have tried reinstalling cygwin and the tinyos environment, but this 
did not fix it. I am using TinyOS1.1.15


Thanks again,

Simon

Simon Willis wrote:
I am having problems programming with uisp. I am using Blink for 
testing.


I have a MIB510 and a board that we designed that is based on the mica2.

Once I have programmed the ATMEGA128 I cannot reprogram it. It goes 
through all the correct actions, but the program doesn't seem to 
change (tested by changing the blinking LED) With a bit of playing 
around I discovered that I can get it to program after I change the 
fuse high byte to 0x98 (from 0xd8 set by uisp). This turns on the 
'enable JTAG' option (even though I don't have the JTAG plugged in) 
then it works. Another problem is that when I issue a 'rd-fuses' 
command it will quite often return all 0s (or give some other error 
message), also the wr_fuses_h command usually takes about 5 attempts 
until it does actually change the fuses (checked using rd_fuses). 
Once it has changed the fuse to 0x98 then rd_fuses will work reliably 
and I can upload my program. I have also tried other combinations for 
fuses (like 0x19) and it seems that whenever the 'enable JTAG' option 
is on it will work. Does anyone have any idea why this might be or 
what might be wrong here? I have been able to replicate this problem 
on 2 boards now (I have only built 2 so far).


Perhaps I should try changing the makefile so that uisp always 
enables JTAG, but this seems like a bit of a workaround problem, 
since normal mica2s seem to work OK.


Anothter note: It also seems that I can't program a fresh ATMEGA with 
uisp until I have plugged in a JTAG and changed the fuses to 0xfd (e) 
0x19 (h) 0xfe (l). Is this normal? I was thinking that perhaps this 
is done by Crossbow before the motes leave the factory.


Thanks for your help.

Simon




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

Re: [Tinyos-help] uisp and mica2 programming problems

[Simon Willis]

Some more news on this problem.

It is still occurring, but I can now get around it consistently. I also 
discovered that it will program the board with no problems if I change 
the high fuse to 0xD9 (uisp makes is 0xD8). In my last email I said that 
I was setting this fuse to 0x19, but it seems 0xD9 also works. The only 
difference this has from the uisp 0xD8 is that the BOOTRST vector is 
disabled. Does anyone have any idea what's going on here? I also 
discovered that writing 0xD8 to the high fuse will allow me to read the 
fuses reliably (it seems), but when I program it (with Blink for 
example) the program does nothing.


So here is how I program my boards:
-Write 0xD9 (or 0x19) to the high fuse several times: uisp -dprog=mib510 
-dserial=/dev/ttyS0 -dpart=ATmega128 --write_fuse_h=0xD9
-Check the fuses: uisp -dprog=mib510 -dserial=/dev/ttyS0 
-dpart=ATmega128 --rd_fuses

-If the fuse has changed then continue
-Upload the program: make mica2 reinstall mib510,/dev/ttyS0

Does anyone have any ideas why it might be doing this or how I can fix 
it? Or even a few things I can do with the MIB510 to try and 
troubleshoot it?


I have tried reinstalling cygwin and the tinyos environment, but this 
did not fix it. I am using TinyOS1.1.15


Thanks again,

Simon

Simon Willis wrote:

I am having problems programming with uisp. I am using Blink for testing.

I have a MIB510 and a board that we designed that is based on the mica2.

Once I have programmed the ATMEGA128 I cannot reprogram it. It goes 
through all the correct actions, but the program doesn't seem to 
change (tested by changing the blinking LED) With a bit of playing 
around I discovered that I can get it to program after I change the 
fuse high byte to 0x98 (from 0xd8 set by uisp). This turns on the 
'enable JTAG' option (even though I don't have the JTAG plugged in) 
then it works. Another problem is that when I issue a 'rd-fuses' 
command it will quite often return all 0s (or give some other error 
message), also the wr_fuses_h command usually takes about 5 attempts 
until it does actually change the fuses (checked using rd_fuses). Once 
it has changed the fuse to 0x98 then rd_fuses will work reliably and I 
can upload my program. I have also tried other combinations for fuses 
(like 0x19) and it seems that whenever the 'enable JTAG' option is on 
it will work. Does anyone have any idea why this might be or what 
might be wrong here? I have been able to replicate this problem on 2 
boards now (I have only built 2 so far).


Perhaps I should try changing the makefile so that uisp always enables 
JTAG, but this seems like a bit of a workaround problem, since normal 
mica2s seem to work OK.


Anothter note: It also seems that I can't program a fresh ATMEGA with 
uisp until I have plugged in a JTAG and changed the fuses to 0xfd (e) 
0x19 (h) 0xfe (l). Is this normal? I was thinking that perhaps this is 
done by Crossbow before the motes leave the factory.


Thanks for your help.

Simon



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

[Tinyos-help] Problems with MicaHWVerify

[Simon Willis]

I am having problems with MicaHWVerify.

I program it on my mote (based on Mica2) and nothing happens. The LEDs 
are supposed to start counting once it has retrieved the ID from the 
serial ID chip. I assumed that the problem was something to do with this.


To test it I put a Leds.redOn() in the StdControl.start() at the very 
start, before it calls HardwareId.read(). Surprisingly, nothing 
happened. So it seems like StdControl.start() is never getting called. I 
also placed Leds.redOn() in StdControl.init() and the LED turned on. So 
that's very strange.


I have tried other programs like IntToLeds and ReverseUART and they work 
fine.


I have tried two different PCBs and have tried programming with MIB510 
(uisp) or the JTAG (AVR Studio).


Is there any other (better?) way to test the serial ID and Flash?

Any ideas?

Thanks.

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

[Tinyos-help] uisp and mica2 programming problems

[Simon Willis]

I am having problems programming with uisp. I am using Blink for testing.

I have a MIB510 and a board that we designed that is based on the mica2.

Once I have programmed the ATMEGA128 I cannot reprogram it. It goes 
through all the correct actions, but the program doesn't seem to change 
(tested by changing the blinking LED) With a bit of playing around I 
discovered that I can get it to program after I change the fuse high 
byte to 0x98 (from 0xd8 set by uisp). This turns on the 'enable JTAG' 
option (even though I don't have the JTAG plugged in) then it works. 
Another problem is that when I issue a 'rd-fuses' command it will quite 
often return all 0s (or give some other error message), also the 
wr_fuses_h command usually takes about 5 attempts until it does actually 
change the fuses (checked using rd_fuses). Once it has changed the fuse 
to 0x98 then rd_fuses will work reliably and I can upload my program. I 
have also tried other combinations for fuses (like 0x19) and it seems 
that whenever the 'enable JTAG' option is on it will work. Does anyone 
have any idea why this might be or what might be wrong here? I have been 
able to replicate this problem on 2 boards now (I have only built 2 so far).


Perhaps I should try changing the makefile so that uisp always enables 
JTAG, but this seems like a bit of a workaround problem, since normal 
mica2s seem to work OK.


Anothter note: It also seems that I can't program a fresh ATMEGA with 
uisp until I have plugged in a JTAG and changed the fuses to 0xfd (e) 
0x19 (h) 0xfe (l). Is this normal? I was thinking that perhaps this is 
done by Crossbow before the motes leave the factory.


Thanks for your help.

Simon

--
Simon WillisBE(CompSys)(Hons)-BSc   
PhD Candidate   Tel: (07) 47814865
Electrical & Computer Engineering   Fax: (07) 47815177
James Cook University   Mob: 0403653055
Townsville, QLD 4811Email: [EMAIL PROTECTED]
Web: http://eng.jcu.edu.au

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

[Tinyos-help] Problems programming my Mote

[Simon Willis]

Hi everyone,

I'm trying to program my mote which I have designed and it based on the 
mica2. I have a MIB510 and JTAG ICE II. I've had quite a few problems 
with this board, but finally got it working, but now I have a few 
strange problems. Does anyone have any ideas on what I can try.


Current uisp is working and I am loading Blink on to the board and it 
all says it is fine, but nothing is happening. Also, it gives me the 
"broken wiring" error message if the JTAG is plugged into the board at 
the same time. When I turn the board on all of the LEDs light up and 
then they go off in sequence yellow-green-red. They also flash as I am 
programming. Is this normal? After that nothing happens. If I reset the 
board I get the same sequence. If I read the fuses with uisp I usually 
get all fuses as 0s, but sometimes they come up with different numbers. 
Usually fuse-e=ff, fuse_h=d8 and huse_l=fe


-Initially I could only program with the JTAG. I was using AVR studio 
and I could read fuses and program the board with Blink (which I 
compiled to a hex program as per instruction on xbow site). When I 
loaded Blink nothing happened...no sequency of lights or anything. The 
only thing I could get it to do was turn all leds on by editing 
stdcontrol.start


-Then I found some dry soler joints and got uisp going. Blink was 
working fine, but the JTAG stopped working. I thought that maybe the 
JTAG fuse had been disabled, so I wrote to the fuse to enable it and 
then it all stopped working.


-Now it's sort of programming except if the JTAG is plugged in it won't 
work.


Any ideas?

Thanks,

Simon

--
Simon WillisBE(CompSys)(Hons)-BSc   
PhD Candidate   Tel: (07) 47814865
Electrical & Computer Engineering   Fax: (07) 47815177
James Cook University   Mob: 0403653055
Townsville, QLD 4811Email: [EMAIL PROTECTED]
Web: http://eng.jcu.edu.au

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

[Tinyos-help] tinyos1.x or tinyos2.x?

[Simon Willis]

Hi everyone,

I'm about to commence my first programming in TinyOS. I am using TinyOS 
for a wireless sensor network that we have designed that is based on the 
Mica2. Basically, it has new radio hardware and will require the radio 
interface to be rewritten. We would like to test the new network with a 
routing protocol etc and I was thinking of using TinyOS 2 since it has 
the hardware abstraction architecture. The problem is that it doesn't 
seem to have much implemented yet (as far as routing protocols etc go).


Am I better off sticking with TinyOS 1 for the time being or starting my 
project in TinyOS 2?


Thanks,

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

Re: [Tinyos-help] Communicating with motes with Serial Port

[Simon Willis]

MAX232 / HIN232 are the RS232 line driver ICs. They are fairly easy to 
set up. Have a look at their data sheets.


Simon

Michael Schippling wrote:


all things are possible...haw.

Assuming you can attach wires to the Rx, Tx, and Gnd contacts
on the mote you should be able to connect them to some other logic
level serial device -- remember to cross them over Rx to Tx.

That said, _real_ RS232 works at +/-3v but the logic levels from the
motes are more on the order of 0 and +3v, so you need a level converter
if you want to plug straight into a PC or something. I recently found
some simple ones by Googling "serial level converter" I think.
The programmer board has a single chip MAXsomething-or-other that
does the job.

MS

Prasanna Ballal wrote:


Hi all,
 
Is there a way of communicating with the motes directly with the 
serial port without using the programmer board? All I need to do is 
communication and not programming.
 
Regards,
 
Prasanna Ballal.





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



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




--
Simon WillisBE(CompSys)(Hons)-BSc   
PhD Candidate   Tel: (07) 47814865
Electrical & Computer Engineering   Fax: (07) 47815177
James Cook University   Mob: 0403653055
Townsville, QLD 4811Email: [EMAIL PROTECTED]
Web: http://eng.jcu.edu.au

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