Re: [Tinyos-help] make deluge support mica2
Hello :
2008/6/3 Razvan Musaloiu-E. [EMAIL PROTECTED]:
Hi!
I just found a MPR400CB and I and was able to successfully run the burn
script from the tinyos-2.x/apps/tests/deluge/Blink.
that is to say you have modify the deluge to make it support deluge
including th burn script ? what is the way ? are there some differences
with mine ? are there some errors in my modifications , Razvan ME ?
I used a MIB520 so the command I used was:
./burn /dev/ttyUSB0 /dev/ttyUSB1 micaz
Both the injection and the reboot worked fine.
i also can injection on the basestation mote . but when i use the reboot
command (-r) , it does not load the image i specify to the internal flash
and just reboot .
what about yours ? does it can reboot from the specified image ?
I only have one of these motes so I cannot do any other test than this. :-(
You have helped me so much , i really thank you very mcch !!
Does any one try it ? i want to know the your result . thank you very much
!!
--
Razvan ME
On Tue, 3 Jun 2008, jiwen zhang wrote:
Hello all :
can someone give me an answer to my questions (as follows)? thank you
very much !!!
2008/6/1 jiwen zhang [EMAIL PROTECTED]:
Hello all :
because i have many mica2 motes , and few micaz motes , so i want to
modify the deluge to make it support mica2 .
some operations i have done :
1 . go to /opt/tinyos-2.x/tos/lib/TOSBOOT , create a folder named mica2
,
copy all the files in the directory TOSBOOT/micaz to TOSBOOT/mica2.
2 . modify the file hardware.h in TOSBOOT/mica2 . add the sentences at
about lines 101? :
TOSH_ASSIGN_PIN(BAT_MON, A, 5);
TOSH_ASSIGN_PIN(THERM_PWR, A, 7);
chage the value of VOLTAGE_PORT to 7 . (i refer to tinyos-1.15) , i
think it should be 30 .
3. modify the file VoltageC.nc
at the start of command Voltage.okToProgram() , add the sentences : (i
refer to tinyos-1.15)
TOSH_MAKE_BAT_MON_OUTPUT();
TOSH_SET_BAT_MON_PIN();
4 . modify the Makefile in the directory TOSBOOT/ , add the sentences
(after about lines 54 ?):
ifeq ($(MAKECMDGOALS),mica2)
CFLAGS += -DTOSBOOT_START=0x1f000 -DTOSBOOT_END=0x2
CFLAGS += -Wl,--section-start=.text=0x1f000
CFLAGS += -Iat45db -Iavr -Imica2 -Ilib
CFLAGS += -I../net/Deluge
endif
5 . modify the files TOSBootM.nc in /TOSBOOT/ ,
BlockStorageManagerC.nc and BlockStorageManagerP.nc in
lib/Deluge/BlockStorageManager/ , DelugePageTransfer.h in lib/Deluge/ .
the mothod is easy , for example :
at the lines : defined(PLATFORM_MICAZ) || defined(PLATFORM_IRIS)
change it into : defined(PLATFORM_MICAZ) || defined(PLATFORM_MICA2) ||
defined(PLATFORM_IRIS)
6 . go to /opt/tinyos-2.x/tos/lib/net/Deluge/extra , copy the files
NetProgC.nc and NetProgM.nc in extra/iris to extra/mica2 .
7 . /opt/tinyos-2.x/support/make, modify the file bnp.extra , add the
sentences at about line29 ?:
ifeq ($(TARGETS),mica2)
CFLAGS += -I$(DELUGE_EXTRA)/mica2 -I$(DELUGE_EXTRA)/micaz
-I$(DELUGE_EXTRA)/avr -I$(DELUGE_EXTRA)
BOOTLOADER ?= $(TOSBOOT_DIR)/mica2/main.ihex
AVR_FUSE_H ?= 0xda
endif
8 . modify the files tos-deluge in /usr/local/bin ? and
/opt/tinyos/tools/tinyos/misc at about line38 ? :
chage :
BAUDRATES = {'micaz': 57600,
'telosb': 115200,
'iris': 57600}
into :
BAUDRATES = {'micaz': 57600,
'mica2': 57600,
'telosb': 115200,
'iris': 57600}
that is all .
Do i still have something to modify or there are something wrong i have
modified ?
i have tested the result , there is something deviant :
1 . i test the basestion node (/opt/tinyos-2.x/tests/deluge/blink ,
CFLAGS=--DDELUGE_BASESTATION make mica2 ), I can ping it and inject a
new
image , but when i use the command to reboot it from the image i have
installed (section 1) , it reboots but does not load the image from
senction
1 .
2 . i test network programme . i use two mica2 motes , one is the
basestion
, the other is non-basestation . after i use the command -dr , i find
the
green led of non-basestation blinks .( i have tested with micaz , it is a
right action it should have . ) i have thought it is ok . but after a
long
time (about more than 30 minutes ) , the mote still blink the green led .
i
don't know why .
can anyone give me some suggestions ?
thank you very much !!
zhang jiwen
--
zhang jiwen
--
zhang jiwen
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] time synchronization
Hello all : i see some files in chips/rf230 , i see some words like TimeSyncPacket , so i think maybe the time synchronization is implementated in rf230 , am i right ? if yes , i want to know which arithmetic does it use ? maybe there are a corresponding paper , can someone give me a reference ? thank you very much !! -- zhang jiwen ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] ERROR: MAKE TELOSB
I did not modify anything, I just installed the Xubuntos version from CD. This behavior is really odd, because make micaz actually works, but when I type make telosb I get that error. As you said, strace make telosb gives tons and tons of output, but what shall I figure out from it? Thanks. Date: Mon, 2 Jun 2008 22:31:34 -0700 From: [EMAIL PROTECTED] To: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] ERROR: MAKE TELOSB From what I can tell, your path looks fine. The execution path lookup is actually (usually) handled as part of a system call... have you modified the Makefile in anyway? (Maybe assigning to PATH?) What does an strace reveal? You can try `strace make telosb` or `strace contents of the long line starting with ncc` There will be tons and tons of output so you should log it. You may have to install the appropriate package to get the strace utility. Couldn't execute may also mean msp430-gcc failed to start for some other reason (such as bad dynamic linking). On Mon, Jun 2, 2008 at 2:16 PM, Michael Schippling [EMAIL PROTECTED] wrote: I'm cc'ing this back to the whole help list because: A) I'm clueless B) We would like to keep a record of the above... NCC obviously uses some other nefarious method to find the executable, so maybe someone who understands such things can comment. MS Marco Belleschi wrote: Thanks for your interest. This is what I get when I type the following commands: $ which msp430-gcc /opt/msp430/bin/msp430-gcc $ msp430-gcc --version msp430-gcc (GCC) 3.2.3 $ echo $PATH /opt/msp430/bin:/usr/local/sbin:/usr/local/bin: /usr/sbin:/usr/bin:/sbin:/bin:/usr/games Unluckily, these commands do not give to me any clue and I get stuck. Thanks in advance for your help Date: Mon, 2 Jun 2008 11:05:38 -0600 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] ERROR: MAKE TELOSB See if you can find the missing executable. On my Widows T1 system its: /opt/msp430/bin/msp430-gcc.exe If it exists then some PATH or other thing is not pointing to it correctly. MS Marco Belleschi wrote: Dear all, I installed tinyos 2.0.2 using the Xubuntos live CD. Everything seems to work, but when I make telosb I get the following error: /opt/tinyos-2.x/apps/BlinkSingle$ make telosb mkdir -p build/telosb compiling BlinkAppC to a telosb binary ncc -o build/telosb/main.exe -Os -O -mdisable-hwmul -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x7d -Wnesc-all -target=telosb -fnesc-cfile=build/telosb/app.c -board= -DIDENT_PROGRAM_NAME=\BlinkAppC\ -DIDENT_USER_ID=\root\ -DIDENT_HOSTNAME=\marco-Xubuntos\ -DIDENT_USER_HASH=0x401d86ebL -DIDENT_UNIX_TIME=0x4843d015L -DIDENT_UID_HASH=0x222da1f9L BlinkAppC.nc -lm Couldn't execute msp430-gcc make: *** [exe0] Error 2 Any hint would be great. Thanks in advance! Discover the new Windows Vista Learn more! http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help Get news, entertainment and everything you care about at Live.com. Check it out! http://www.live.com/getstarted.aspx ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help _ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Problem with the iris mote and avrdude
The problem is that your avr compilers are too old. You need to be using 4.1.2 or above. Kevin On Fri, May 30, 2008 at 2:00 AM, Xavier PATRIS [EMAIL PROTECTED] wrote: Hello everybody, I need assistance with avrdude. I work with TinyOS 2.0.2 on Ubuntu 8.04. Avrdude is installed form the the rpm package (http://www.isis.vanderbilt.edu/projects/NEST/tinyos-2.x-iris/tools/release/external-tools/linux/avrdude-5.4-1.i386.rpm) witch Alien. All my TinyOS files are up-to-date and checked out from CVS and it works fine with the MICA2 and MICAz motes. When I try to flash an IRIS mote with my MIB520 board (make iris install mib520,/dev/ttyUSB0/), I get the following error : mkdir -p build/iris compiling BlinkAppC to a iris binary ncc -o build/iris/main.exe -Os -Wall -Wshadow -Wnesc-all -target=iris -fnesc-cfile=build/iris/app.c -board=micasb -DIDENT_PROGRAM_NAME=\BlinkAppC\ -DIDENT_USER_ID=\wcg\ -DIDENT_HOSTNAME=\wcg-laptop\ -DIDENT_USER_HASH=0xda66ccefL -DIDENT_UNIX_TIME=0x483fb3beL -DIDENT_UID_HASH=0x0a90f557L -fnesc-dump=wiring -fnesc-dump='interfaces(!abstract())' -fnesc-dump='referenced(interfacedefs, components)' -fnesc-dumpfile=build/iris/wiring-check.xml BlinkAppC.nc -lm compiled BlinkAppC to build/iris/main.exe 2230 bytes in ROM 51 bytes in RAM avr-objcopy --output-target=srec build/iris/main.exe build/iris/main.srec avr-objcopy --output-target=ihex build/iris/main.exe build/iris/main.ihex writing TOS image cp build/iris/main.srec build/iris/main.srec.out installing iris binary using mib510 uisp -dprog=mib510 -dserial=/dev/ttyUSB0 --wr_fuse_h=0xd9 -pm1281 -U efuse:w:0xff:m --erase --upload if=build/iris/main.srec.out No part specified, supported devices are: AT90S4414 AT90S2313 AT90S1200 AT90S2323 AT90S2343 AT90S2333 AT90S4433 AT90S4434 AT90S8515 AT90S8535 AT90S8534 ATmega8515 ATmega8535 ATtiny11 ATtiny12 ATtiny15 ATtiny22 ATtiny26 ATtiny28 ATmega8 ATmega323 ATmega32 ATmega161 ATmega163 ATmega16 ATmega162 ATmega169 ATmega103 ATmega128 It's look like that the make command tries to flash the IRIS mote with uisp rather than avrdude. Does somebody have an idea to fix the problem ? Thanks for your time. Kind, -- Xavier PATRIS Research Engineer OPERA Department Université Libre de Bruxelles Av. F. Roosevelt 50 (CP 165/51) 1050 Bruxelles Belgium tel: +32 2 650 30 87 e-mail: [EMAIL PROTECTED] ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- ~Kevin ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] RAM size memory
Eric, thank you for your answers! But, maybe you can clarify something more. You have told me that the compiler doesn´t control the memory size, it only counts bytes, but... how can the compiler know if it is out of memory or not?If the compiler knows that it is out of memory I think that it has to know something about limits for memory size... Sorry if I am insisted on this doubt but I am trying to know how the compiler works... I have found some files (msp430x16x.h...) where the interrupt vectors, flags, SFR...are defined for every model for msp430 family, but I din´t find any information related to limits for memory size. We are trying to compile a profile, but we think that we don´t have enough memory because when we make it, an error message appears, it has been reported before ...build/tmote/main.exe: section vectors lma 0xffe0 overlaps previous sections... I have read about this , and people has solved this problem removing some components, we know that the component that is increasing the memory size is Deluge component, but we need it and we can´t remove it...so I have read about doing a fake platform that could give us information about how much memory we need. (we are thinking about choosing a micro with higher ram memory but we need more information about memory requirements) http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg03045.html Do you know how can I do that? how can I define a fake platform with other memory size limits and the same hardware characteritics? I am reading about Deluge and TSync components in order to know if we can remove something more, or we need to get a higher RAM memory. Thank you very much for your help. Graci ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] MTS 420
This is my fault. I'll add you in right now. Kevin On Tue, Jun 3, 2008 at 12:32 AM, Aurélien Francillon [EMAIL PROTECTED] wrote: Philip Levis a écrit : On Jan 7, 2008, at 2:22 AM, Aurélien Francillon wrote: Le Sunday 06 January 2008 20:50:19 Kevin Klues, vous avez écrit : This is great news. Let us know if you would like to do your development work as part of a tinyos-2.x contrib project. Hi, a port to tinyos-2.x has been done by someone here (incl GPS driver) , we plan to upload it to the contrib soon ... That would be excellent. Phil Hi Phil, I have been sending a request on 10/05 and again on 26/05 at the caretakers' address: [EMAIL PROTECTED] I had no answer yet ? I'm sending my request to the wrong place ? I feel like I'm just ignored because someone else is working on it and pushed it's implementation to the contrib repository ? There is probably room for more than one experimental implementation ... Cheers Aurélien ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- ~Kevin ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] cricket listener send tracking data wirelessly to another listener
Hi, friends is it possible for cricket listener to send tracking data to another listener wirelessly instead of using serial port to ipaq or laptop. thanks in advanced ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] CTP and snooping (very short qt)
Hi, I whould like to verify if CTP routing protocol uses snooped packet information to update its neighbour table entries? Thank you __ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités http://mail.yahoo.fr Yahoo! Mail ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] MTS 420
On Jun 3, 2008, at 12:32 AM, Aurélien Francillon wrote: Philip Levis a écrit : On Jan 7, 2008, at 2:22 AM, Aurélien Francillon wrote: Le Sunday 06 January 2008 20:50:19 Kevin Klues, vous avez écrit : This is great news. Let us know if you would like to do your development work as part of a tinyos-2.x contrib project. Hi, a port to tinyos-2.x has been done by someone here (incl GPS driver) , we plan to upload it to the contrib soon ... That would be excellent. Phil Hi Phil, I have been sending a request on 10/05 and again on 26/05 at the caretakers' address: [EMAIL PROTECTED] I had no answer yet ? I'm sending my request to the wrong place ? I feel like I'm just ignored because someone else is working on it and pushed it's implementation to the contrib repository ? There is probably room for more than one experimental implementation ... Hm -- I'll ask the contrib czars (Kevin Klues and Martin Leopold). Kevin is out this week, so it might be until next week. Contrib doesn't apply admission control like you describe. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] DELAY_AFTER_RECEIVE in CC2420 Low Power Listening
Hi Jongkeun - Good observation. Sending an RTS / CTS to stop transmissions from other nodes is a good idea. I have two initial concerns about this approach, but maybe it should be studied a little more to confirm or deny these: 1) I'm concerned about the dependency on the link-layer to prevent phy-layer collisions, especially when we're dealing with such low power and somewhat long transmission distances that cause packets to be easily corrupted. 2) I'm concerned about the excess transmissions taking place to get a single packet through, and the impact on reliability and energy savings. 802.11's virtual sensing approach, from what I understand, works well especially because the transmission rates are high and the transmitters have access to mains power. In this case, getting a single packet through with an RTS / CTS requires at least 3 packets to be exchanged: RTS / CTS / Data. Transmissions are typically the largest energy consumer of any operation on the node. If one of those packets gets dropped, it will have to be retransmitted. Other nodes will also have to back off somehow to prevent collision if they miss the CTS packet, which brings us back down to PHY-layer collision avoidance. If you don't want to rely on the radio hardware to prevent collisions (and save energy by leaving the radio off), I think you'd be talking more about a TDMA solution. This is totally possible, but requires accurate clock management and synchronization between nodes. The RF230 implementation is pioneering some really nice synchronization protocols that would make something like that more possible, at least across homogeneous platforms. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jongkeun Na Sent: Monday, June 02, 2008 9:29 PM To: David Moss Cc: tinyos-help@millennium.berkeley.edu Subject: Re: DELAY_AFTER_RECEIVE in CC2420 Low Power Listening It sounds like a sort of virtual carrier sensing. How about introducing a thing like NAV of 802.11 for a packetized wake-up transmission as a general approach? do you think it is worth to introduce such a virutal carrier sensing mechansim for LPL based sensor networks? if so, is it possible to implement it without an aid of radio H/W? Thanks, Jongkeun On Fri, May 30, 2008 at 9:17 AM, David Moss [EMAIL PROTECTED] wrote: Yes, in fact, this is what I'm implementing on the CC1100 and CC2500 radio stacks. The trick is getting the transmit branch of the radio stack to hold off for awhile if a packet was recently received. This allows one node to completely dominate the channel while it sends back-to-back packets with acknowledgment gaps in between. Packet delivery and acknowledgment success rate goes up, collisions go down, and energy efficiency goes way up. So far, this seems to work very reliable on my desk. I have yet to test it outside or in a real network, where any number of issues may come into play. -David _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jongkeun Na Sent: Thursday, May 29, 2008 7:24 PM To: David Moss Cc: tinyos-help@millennium.berkeley.edu Subject: Re: DELAY_AFTER_RECEIVE in CC2420 Low Power Listening Thank you David for your detailed explanation. I fully agree with you regarding safety and robustness for applications. One more question, looking at the initial backoff (0x4) and congestion backoff (0x3) applied in the packetized wake-up transmission, I'm wondering there is any theory in choosing those backoff constants. What's the backoff strategy? intentionally to allow multiple wake-up transmissions mixed at the same time. What if we allows only one wake-up transmission at a time in medium by treating separately the first packet and the following resended packets in the packet train, i.e. the standard backoff is applied for the first packet and almost 0 backoff is used for the resended packets. Do you have any history or experience? Thanks, Jongkeun On Thu, May 29, 2008 at 8:54 AM, David Moss [EMAIL PROTECTED] wrote: Hi Jongkeun, The DELAY_AFTER_RECEIVE is not the length of a CCA receive check. The receive check is currently implemented through polling the CCA pin a number of times in PowerCycleP. This polling method will be transformed into an alarm/interrupt receive check for greater accuracy and efficiency, as soon as someone has time to do it. The goal of the receive check is to be as short as possible, and is the length of the time between packets in a packetized wake up transmission strategy. I've had these receive check perform reliably at 5 ms or less, but the current implementation makes the receive check last ~11 ms for reliability across everyone's systems and platforms. Only after activity is detected - either by transmitting a packet or receiving a packet - does the radio remain on for the time defined by DELAY_AFTER_RECEIVE, which is currently 100 ms. You'll notice the DELAY_AFTER_RECEIVE is
Re: [Tinyos-help] make deluge support mica2
Hi!
On Tue, 3 Jun 2008, jiwen zhang wrote:
Hello :
2008/6/3 Razvan Musaloiu-E. [EMAIL PROTECTED]:
Hi!
I just found a MPR400CB and I and was able to successfully run the burn
script from the tinyos-2.x/apps/tests/deluge/Blink.
that is to say you have modify the deluge to make it support deluge
including th burn script ? what is the way ? are there some differences
with mine ? are there some errors in my modifications , Razvan ME ?
I run exactly the latest version from CVS. I used micaz which means the
radio part will not work but otherwise the Mica2 is very similar with
MicaZ.
I used a MIB520 so the command I used was:
./burn /dev/ttyUSB0 /dev/ttyUSB1 micaz
Both the injection and the reboot worked fine.
What happens if you run the above command on an unmodified tree?
i also can injection on the basestation mote . but when i use the reboot
command (-r) , it does not load the image i specify to the internal flash
and just reboot .
what about yours ? does it can reboot from the specified image ?
The reboot using -r worked properly because the burn script is using it. I
also tested it manually and it worked fine.
All the best!
Razvan ME
I only have one of these motes so I cannot do any other test than this. :-(
You have helped me so much , i really thank you very mcch !!
Does any one try it ? i want to know the your result . thank you very much
!!
--
Razvan ME
On Tue, 3 Jun 2008, jiwen zhang wrote:
Hello all :
can someone give me an answer to my questions (as follows)? thank you
very much !!!
2008/6/1 jiwen zhang [EMAIL PROTECTED]:
Hello all :
because i have many mica2 motes , and few micaz motes , so i want to
modify the deluge to make it support mica2 .
some operations i have done :
1 . go to /opt/tinyos-2.x/tos/lib/TOSBOOT , create a folder named mica2,
copy all the files in the directory TOSBOOT/micaz to TOSBOOT/mica2.
2 . modify the file hardware.h in TOSBOOT/mica2 . add the sentences at
about lines 101? :
TOSH_ASSIGN_PIN(BAT_MON, A, 5);
TOSH_ASSIGN_PIN(THERM_PWR, A, 7);
chage the value of VOLTAGE_PORT to 7 . (i refer to tinyos-1.15) , i
think it should be 30 .
3. modify the file VoltageC.nc
at the start of command Voltage.okToProgram() , add the sentences : (i
refer to tinyos-1.15)
TOSH_MAKE_BAT_MON_OUTPUT();
TOSH_SET_BAT_MON_PIN();
4 . modify the Makefile in the directory TOSBOOT/ , add the sentences
(after about lines 54 ?):
ifeq ($(MAKECMDGOALS),mica2)
CFLAGS += -DTOSBOOT_START=0x1f000 -DTOSBOOT_END=0x2
CFLAGS += -Wl,--section-start=.text=0x1f000
CFLAGS += -Iat45db -Iavr -Imica2 -Ilib
CFLAGS += -I../net/Deluge
endif
5 . modify the files TOSBootM.nc in /TOSBOOT/ ,
BlockStorageManagerC.nc and BlockStorageManagerP.nc in
lib/Deluge/BlockStorageManager/ , DelugePageTransfer.h in lib/Deluge/ .
the mothod is easy , for example :
at the lines : defined(PLATFORM_MICAZ) || defined(PLATFORM_IRIS)
change it into : defined(PLATFORM_MICAZ) || defined(PLATFORM_MICA2) ||
defined(PLATFORM_IRIS)
6 . go to /opt/tinyos-2.x/tos/lib/net/Deluge/extra , copy the files
NetProgC.nc and NetProgM.nc in extra/iris to extra/mica2 .
7 . /opt/tinyos-2.x/support/make, modify the file bnp.extra , add the
sentences at about line29 ?:
ifeq ($(TARGETS),mica2)
CFLAGS += -I$(DELUGE_EXTRA)/mica2 -I$(DELUGE_EXTRA)/micaz
-I$(DELUGE_EXTRA)/avr -I$(DELUGE_EXTRA)
BOOTLOADER ?= $(TOSBOOT_DIR)/mica2/main.ihex
AVR_FUSE_H ?= 0xda
endif
8 . modify the files tos-deluge in /usr/local/bin ? and
/opt/tinyos/tools/tinyos/misc at about line38 ? :
chage :
BAUDRATES = {'micaz': 57600,
'telosb': 115200,
'iris': 57600}
into :
BAUDRATES = {'micaz': 57600,
'mica2': 57600,
'telosb': 115200,
'iris': 57600}
that is all .
Do i still have something to modify or there are something wrong i have
modified ?
i have tested the result , there is something deviant :
1 . i test the basestion node (/opt/tinyos-2.x/tests/deluge/blink ,
CFLAGS=--DDELUGE_BASESTATION make mica2 ), I can ping it and inject a new
image , but when i use the command to reboot it from the image i have
installed (section 1) , it reboots but does not load the image from
senction
1 .
2 . i test network programme . i use two mica2 motes , one is the basestion
, the other is non-basestation . after i use the command -dr , i find the
green led of non-basestation blinks .( i have tested with micaz , it is a
right action it should have . ) i have thought it is ok . but after a
long
time (about more than 30 minutes ) , the mote still blink the green led . i
don't know why .
can anyone give me some suggestions ?
thank you very much !!
zhang jiwen
--
zhang jiwen
--
zhang jiwen
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
Re: [Tinyos-help] time synchronization
Hello all : 2008/6/3 Miklos Maroti [EMAIL PROTECTED]: Hi Zhang, Hello all : i see some files in chips/rf230 , i see some words like TimeSyncPacket , so i think maybe the time synchronization is implementated in rf230 , am i right ? Yes. The PacketTimeStamp interface is used to access the transmit or receive time of the packet. If you want to embed a time stamp inside the packet then you need to use the TimeSyncAMSend and TimeSyncPacket interfaces of the SimSyncSend component. i understand , when use the TimeSyncAMSend interface to send a packet , it also performs sender-receiver time synchronization besides send the packet. but i still have some puzzles . if the sender and receiver are turned on all the time and sleep periodically , there is no need of time synchronzation and the information of time have no significance to the motes. am i right ? what is the aim when you implement the driver ? do you want to use it for lowpowerlistening ? because the current implementation of lowpower listening is asynchronous , not synchronous (the sender know when the receiver wake up , and there is no need to send the wake up packet before send the useful data ) . i see the lpl of rf230 has been implemented , which kind does it belong to ? do it use time synchronization in implementation of LPL ? if yes , i want to know which arithmetic does it use ? What do you mean? The time resolution is currently 1 millisecond (continnuous) and 1 microsecond (stops of the mote stops). i think you have implemented the time synchronization , so i want to know the arithmetic of time synchronization you use . Do you know which implementation of time synchronization suppose rf230 ? maybe there are a corresponding paper , can someone give me a reference ? Not yet. a TEP is coming out soon. You should have no problem using the components I pointed out. The interface files have the necessary documentations. is rf230 supposed by CTP ? Best, Miklos -- zhang jiwen ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] time synchronization
Hi Zhang, Yes. The PacketTimeStamp interface is used to access the transmit or receive time of the packet. If you want to embed a time stamp inside the packet then you need to use the TimeSyncAMSend and TimeSyncPacket interfaces of the SimSyncSend component. i understand , when use the TimeSyncAMSend interface to send a packet , it also performs sender-receiver time synchronization besides send the packet. but i still have some puzzles . if the sender and receiver are turned on all the time and sleep periodically , there is no need of time synchronzation and the information of time have no significance to the motes. am i right No. The TimsSyncAMSend is a time synchronization primitive and has nothing to do with asynchronous LPL. If you want to establish synchronized global time across all motes (regardless if you use LPL or not) to be able to correlate external events, then you need time synchronization. Please read the Flooding Time Synchronization Protocol paper. ? what is the aim when you implement the driver ? do you want to use it for lowpowerlistening ? because the current implementation of lowpower listening is asynchronous , not synchronous (the sender know when the receiver wake up , and there is no need to send the wake up packet before send the useful data ) . i see the lpl of rf230 has been implemented , which kind does it belong to ? do it use time synchronization in implementation of LPL ? No, they are completely independent. i think you have implemented the time synchronization , so i want to know the arithmetic of time synchronization you use . Do you know which implementation of time synchronization suppose rf230 ? What do you mean by arithmetic of time synchronization? By the way, only the sender-receiver time synchronization primitive is implemented. FTSP will be ported to use this primitive. Not yet. a TEP is coming out soon. You should have no problem using the components I pointed out. The interface files have the necessary documentations. is rf230 supposed by CTP ? What is CTP? Best, Miklos ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] avr-gcc on Mac -- not only for Mac users
Hi, I'm trying to compile for micaz on PPC Mac (Tiger), and I have the standard problem which was already described here. Unforunately, I couldn't find a satisfactory answer in this mailing list, and nowhere else. I installed TinyOS using recent instructions by Kevin Klues with precompiled binaries for msp430 (this works fine) and avr: http://klueska.doesntexist.com/installing_tinyos2.html The famous error goes here: --- spiderman:~/src/tinyos-2.x/apps/Blink zina$ make micaz mkdir -p build/micaz compiling BlinkAppC to a micaz binary ncc -o build/micaz/main.exe -Os -Wall -Wshadow -Wnesc-all - target=micaz -fnesc-cfile=build/micaz/app.c -board=micasb - DDEFINED_TOS_AM_GROUP=0x22 --param max-inline-insns-single=10 - DIDENT_APPNAME=\BlinkAppC\ -DIDENT_USERNAME=\zina\ - DIDENT_HOSTNAME=\spiderman.infor\ -DIDENT_USERHASH=0x9bf9b498L - DIDENT_TIMESTAMP=0x484569aeL -DIDENT_UIDHASH=0x1f02a009L -fnesc- dump=wiring -fnesc-dump='interfaces(!abstract())' -fnesc- dump='referenced(interfacedefs, components)' -fnesc-dumpfile=build/ micaz/wiring-check.xml BlinkAppC.nc -lm avr-gcc: error trying to exec 'cc1': execvp: No such file or directory commandline: failed to preprocess /stow/repository/nesc-1.2.9/lib/ ncc/nesc_nx.h avr-gcc: error trying to exec 'cc1': execvp: No such file or directory commandline: failed to preprocess /Users/zina/src/tinyos-2.x/tos/ system/tos.h avr-gcc: error trying to exec 'cc1': execvp: No such file or directory commandline: failed to preprocess /Users/zina/src/tinyos-2.x/tos/ system/TinySchedulerC.nc commandline: Scheduler `TinySchedulerC' has no scheduling interface named `TaskBasic' avr-gcc: error trying to exec 'cc1': execvp: No such file or directory commandline: failed to preprocess BlinkAppC.nc make: *** [exe0] Error 1 - I checked that I have only one avr-gcc on my system, then deleted it and reinstalled (this is what Kevin recommended when this question was posted previously). No effect. At first glance, avr-gcc cannot find the program called cc1. However: $ avr-gcc -print-prog-name=cc1 /stow/repository/avr-tinyos/bin/../libexec/gcc/avr/4.1.2/cc1 To compare: $ msp430-gcc -print-prog-name=cc1 /stow/bin/../lib/gcc-lib/msp430/3.2.3/cc1 It can be seen that msp430-gcc was built using gcc 3.2.3, but avr-gcc uses gcc 4.1.2. The only solution I could think of was to try and build avr-gcc using gcc 3.2.3. However, before I go to such trouble, I would like to hear what you think of this idea, and probably you can suggest something else (even if you are not a Mac user). Cheers Zinaida -- Zinaida Benenson http://pi1.informatik.uni-mannheim.de University of Mannheim A 5,6 68159 Mannheim Germany Room B 138 Phone +49 621 181 2556 Fax +49 621 181 3577 [EMAIL PROTECTED] ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Question about adding component in the MultihopLEPSM
Hello Dr.Levis, I am working on modifying a clustering protocol which is implemented in the Surge application. I figured that the routing used is MultiHopLEPSM. I want to calculate the distance of the node from the base station (i.e node 0) and use it as one of the parameter for clustering. There are two ways that I think of implementing it: 1.Give the location of the nodes ahead ,so from there the distance can be calculated using Euclidean equation. Can I do that ,in that case I think I should be writing a module in MultiHopLEPSM. 2.Secondly I thought of giving the input of coordinates in Neighbortbl.But so far I understood the entries of Neighbortbl is updated from the packets received from the neighboring nodes by snooping. In that case I thought of declaring my own packet structure (as CC1000 radio can have it's own packet structure). And giving the two field for coordinates of the node. Can you please correct me if I'm going in the wrong way? Or this is not at all possible? I am working on this for last few months and couldn't get a possible solution. Regards Nirupama Barua ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Question about adding component in the MultihopLEPSM
Finding distances (localization) between motes is problematic, at best. Assuming each node is in a (known) static location you impose another requirement on the WSN. It doesn't really matter if motes know this up-front (e.g. program time) or are told OTA (over-the-air) later. For OTA it may be beneficial to implement your own distribution protocol along-side. (It becomes more complicated when you try to merge everything into one, KISS.) Or maybe a Dissemination protocol or Deluge could help. Another approach may simply be to use some metric of link quality to implement your protocol. In the end, link-quality (aggregated with delay, power, throughput, etc.) is what counts when getting messages from A to B... On Tue, Jun 3, 2008 at 11:03 AM, [EMAIL PROTECTED] wrote: Hello Dr.Levis, I am working on modifying a clustering protocol which is implemented in the Surge application. I figured that the routing used is MultiHopLEPSM. I want to calculate the distance of the node from the base station (i.e node 0) and use it as one of the parameter for clustering. There are two ways that I think of implementing it: 1.Give the location of the nodes ahead ,so from there the distance can be calculated using Euclidean equation. Can I do that ,in that case I think I should be writing a module in MultiHopLEPSM. 2.Secondly I thought of giving the input of coordinates in Neighbortbl.But so far I understood the entries of Neighbortbl is updated from the packets received from the neighboring nodes by snooping. In that case I thought of declaring my own packet structure (as CC1000 radio can have it's own packet structure). And giving the two field for coordinates of the node. Can you please correct me if I'm going in the wrong way? Or this is not at all possible? I am working on this for last few months and couldn't get a possible solution. Regards Nirupama Barua ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] how to use ParameterInituint16_t
No, it looks problematic in general. 1) Don't wire the component twice. This will just make things confusing. 2) The generate_random() function initializes a seed and then gets a random number from that seed. Remember that PRNGs generate the -same sequence- for the same seed (and the seed is being set each time!). This is essentially making the random generator non-random (it is entirely based off of the current 'counter'.) 3) Furthermore, the variable name 'counter' sounds suspicious. See point #2 and below. Just set the seed at mote initialization (and maybe *adjust* periodically from a random source). To get many different sequences the seeds MUST COVER the entire seed-space (2**32). You can find many examples (some really bad) on how older programs (most notably C and Perl?) set the seed based on some function of system time. Usually this involves extra math to attempt to get a better coverage of the seed-space. All that being said, the first thing I would ensure is that -the seeds you are providing- are as 'random' as you think. In this implementation the inputs directly determines the 'random' (see above) output. Without the re-seeding you would simple get another pseudo-random number NEXT in the sequence based off of the seed. HTH, Paul Thank you for your reply, I just want to confirm with you if the code you saw in my message to set the seed and then generate a random number is actually correct? What did you mean by correctly applied when you said: I would ensure an adequate seed is actually being generated and correctly applied. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Compile warnings
I don't have any better ideas but... if you are going to use a
standard prefix, maybe:
safe$tmpLen.
It indicates more magic to me.
Although, I'd rather have the warnings left in than use a filter.
Another option may be to use macros.
#ifdef SAFE
#define DEFSAFE(a) a
#else
#define DEFSAFE(a)
#end
void foo() {
DEFSAFE(int tempLen);
...
}
(okay, maybe this wasn't the best example)
On Tue, Jun 3, 2008 at 9:19 AM, John Regehr [EMAIL PROTECTED] wrote:
The unused variable warnings are a side effect of our Safe TinyOS
patches. Creating safe code sometimes requires introducing temporaries
that are in fact unused when you compile code in unsafe (i.e. default)
mode. The nature of these temporary values is such that they will not
cause a smart compiler to generate worse object code.
Anyway we're aware of the warnings and want to get rid of them. One way
would be to adopt a naming convention for them (e.g. safeTmpLen or
similar) and then filter out warnings about those variables. That is kind
of gross. I'm open to suggestions.
John Regehr
On Tue, 3 Jun 2008, David wrote:
Hi list.
I'm using the latest tinyos2.x CVS, and recently I've been getting a
lot of compilation warnings like this:
=OUTPUT=
[EMAIL
PROTECTED]:~/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/apps/tests/deluge/Blink$
make telosb
mkdir -p build/telosb
compiling BlinkAppC to a telosb binary
ncc -o build/telosb/main.exe -Os -O -mdisable-hwmul -Wall -Wshadow
-Wnesc-all -target=telosb -fnesc-cfile=build/telosb/app.c -board=
-DDEFINED_TOS_AM_GROUP=0x22 -Ibuild/telosb -DDELUGE
-I/home/david/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/tos/lib/net
-I/home/david/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/tos/lib/net/drip
-I/home/david/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/tos/lib/net/Deluge
-I/home/david/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/tos/lib/net/Deluge/FlashVolumeManager
-I/home/david/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/tos/lib/net/Deluge/BlockStorageManager
-I/home/david/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/tos/lib/net/Deluge/extra
-I/home/david/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/tos/lib/net/Deluge/extra/msp430
-I/home/david/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/tos/lib/net/Deluge/extra/telos
-I/home/david/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/tos/lib/net/Deluge/extra/telosb
-Wl,--section-start=.text=0x4a00,--defsym=_reset_vector__=0x4000
-DIDENT_APPNAME=\BlinkAppC\ -DIDENT_USERNAME=\david\
-DIDENT_HOSTNAME=\lnxdavid\ -DIDENT_USERHASH=0xb4cd1e4cL
-DIDENT_TIMESTAMP=0x484505f6L -DIDENT_UIDHASH=0x9b3be594L
BlinkAppC.nc -lm
/home/david/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/tos/chips/cc2420/lpl/DummyLplC.nc:39:2:
warning: #warning *** LOW POWER COMMUNICATIONS DISABLED ***
/home/david/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/tos/chips/msp430/adc12/Msp430Adc12ImplP.nc:66:2:
warning: #warning Accessing TimerA for ADC12
/home/david/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveP.nc:
In function `CC2420ReceiveP$receiveDone_task$runTask':
/home/david/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveP.nc:329:
warning: unused variable `tmpLen'
/home/david/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveP.nc:
In function `CC2420ReceiveP$RXFIFO$readDone':
/home/david/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveP.nc:198:
warning: unused variable `tmpLen'
/home/david/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/tos/chips/cc2420/transmit/CC2420TransmitP.nc:
In function `CC2420TransmitP$loadTXFIFO':
/home/david/dev/internet/tinyos/tinyos2/git_checkout/tinyos-2.x/tos/chips/cc2420/transmit/CC2420TransmitP.nc:658:
warning: unused variable `tmpLen'
compiled BlinkAppC to build/telosb/main.exe
31506 bytes in ROM
960 bytes in RAM
msp430-objcopy --output-target=ihex build/telosb/main.exe
build/telosb/main.ihex
writing TOS image
Is this normal?
David.
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Atmel RF230
Hi all, I currently looking to integrate the RF230 transceiver from Atmel in one of my design and I just wonder if someone have something to tell about it. Is the chip follow the spec given by Atmel (sensitivity, timing, etc)? Is there a lot of bugs with the chips? How can it be compare to TI c2420 or Freescale MC1319x? In fact, I'm interested by all little thing you can have experienced with it and that are not documented ;) Thanks, Fred ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] avr-gcc on Mac -- not only for Mac users
Those error messages seem to indicate the standard C library headers can't be found. Ensure C_INCLUDE_PATH contains the standard header path and/or use -Ipath_to_standard_headers These errors go hand-hand in hand with what you have described about different target (layout) environments. That should get you up. Hopefully. HTH, Paul ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Atmel RF230
Hi Fred, Crossbow's IRIS Mote already uses RF230 transceiver and is supported under MoteWorks and TinyOS 2.x. You can find product details at http://www.xbow.com/Products/productdetails.aspx?sid=264 I hope that helps, Giri From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frederic Beaulieu Sent: Tuesday, June 03, 2008 12:00 PM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] Atmel RF230 Hi all, I currently looking to integrate the RF230 transceiver from Atmel in one of my design and I just wonder if someone have something to tell about it. Is the chip follow the spec given by Atmel (sensitivity, timing, etc)? Is there a lot of bugs with the chips? How can it be compare to TI c2420 or Freescale MC1319x? In fact, I'm interested by all little thing you can have experienced with it and that are not documented ;) Thanks, Fred ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] MTS 420
Philip Levis a écrit : ... Hm -- I'll ask the contrib czars (Kevin Klues and Martin Leopold). Kevin is out this week, so it might be until next week. Contrib doesn't apply admission control like you describe. Phil Hi, Kevin just opened the mts4x0 contrib for me (thanks Kevin), sorry for the tone of the previous mail. I understand the fact that people can are busy and so ... I was just disappointed by the fact that some work was done in double... cheers Aurélien ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Atmel RF230
Thanks for your input! When you are talking about the new chip revision, do you talk about the rf231??? Can you be more explicit about the several errors and lack of configuration options of the automatic modes? Thanks again, Fred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Miklos Maroti Sent: Tuesday, June 03, 2008 3:44 PM To: Frederic Beaulieu Cc: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] Atmel RF230 Hi Fred, I currently looking to integrate the RF230 transceiver from Atmel in one of my design and I just wonder if someone have something to tell about it. Is the chip follow the spec given by Atmel (sensitivity, timing, etc)? I cannot verify the sensitivity, but the published timings to control the state machine of the radio chip is correct. Is there a lot of bugs with the chips? The basic operation mode works as advertised. The automatic mode had several errors and lack of configuration options that prevented the tinyos 2.x driver to use that mode. Nonetheless, the basic mode is perfectly appropriate to do everything at least as good as the cc2420 driver does. We can send a (software generated) acknowledgement frame in less than 200 microsecond. The chip has a new revision and corrects most of the early problems of the first revision. However I did not investigate if the automatic mode would be useful. Also, the original revision does not have an automatic CRC check for the received packets in the basic mode, this is corrected in the new revision. I have observed that under very rare circumstances (in a 1 microsecond window), that the chip can get stuck between the receive state and transmit state. If you switch to PLL_ON state and a message arrives just then, then the chip does not switch to RX_BUSY but stays in PLL_ON. When I initiate the transmission with the SLP_TR pin, but then the chip does not goes to BUSY_TX but stays in PLL_ON and I suspect that the TRX_END interrupt correspond to the received message and not the transmitted message. This can be detected if you verify that the chip goes to BUSY_TX. Everything goes back to normal with the RX_ON command. How can it be compare to TI c2420 or Freescale MC1319x? I cannot really compare. I think the programming interface of the chip is simpler than that of the CC2420. In fact, I'm interested by all little thing you can have experienced with it and that are not documented ;) Look at the RF230 code in the tinyos 2.x tree, you can learn stuff there, but pretty much it works as it supposed to work if you used it correctly. Miklos ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Compile warnings
Thanks Paul, the CPP idea is perhaps a bit less ugly than filtering the compiler output :). John ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] something wrong happened in CC1000 driver in tinyos-2.x tree of cvs version
I looked into this a little bit and it seems like this bug was
introduced when we put code that sets the white bit in the metadata.
The problem is in packetReceiveDone(), we are checking if the radio is
in RECEIVED_STATE before setting it to RECEIVED_STATE. The radio would
be in RX_STATE and discard the packet. Here is the relevant code
snippet:
void enterReceivedState() {
radioState = RECEIVED_STATE;
}
void packetReceiveDone() {
message_t* pBuf;
uint16_t snr;
atomic {
if (radioState != RECEIVED_STATE) {
return;
}
post signalPacketReceived();
enterReceivedState();
}
Phil, you own this code so you should decide how to fix this problem.
BTW, I did not get the out of bound error that John found - maybe I
did not run the test long enough...
Thanks.
- om_p
On Mon, Jun 2, 2008 at 4:03 PM, John Regehr [EMAIL PROTECTED] wrote:
Ok, we found some mica2s and put Oscilloscope on them after hacking
CC1000SendReceiveP.nc to check for count going out of bounds. It is
definitely going out of bounds at line 501.
John
On Sun, 1 Jun 2008, John Regehr wrote:
We think we have found a problem in the CC1000 receive-side code that is
perhaps related to the behavior described here.
The suspected culprit is at line 501 of CC1000SendReceiveP.nc which looks
like this:
((uint8_t *)rxBufPtr)[count++] = nextByte;
We think that count is going out of bounds, leading to RAM corruption.
To test this, introduce some code just before this line that is something
like
if (count=sizeof(message_t)) { ... blink LEDs in infinite loop ... }
Confirmation that this check fails (or not) would be useful to us.
We'd do this ourselves but we seem to have very few mica2s sitting
around.
The root problem may be a failure to clear count at an appropriate time.
John
On Sun, 1 Jun 2008, Philip Levis wrote:
On May 30, 2008, at 1:22 PM, Dima Kogan wrote:
I can confirm this. My CC1000-based motes work fine with the 2.0.2
release but crash with the latest cvs. I run a modified BlinkToRadio
to test, with one node only transmitting and the other node only
receiving. The transmitting node works ok. The receiving node seems
to crash. As a test, I turn on an LED in Boot.booted() and don't
turn it off in any part of the code. This LED blinks or turns off at
various times on the transmitted node, which indicates that the mote
is
rebooting. ALso, the first packet from the transmitter is always
received properly, with the erroneous behavior starting with the
second
packet.
There have only been a few small changes to the CC1000 stack; the
first was that it actually checks for CRCs, the second was the
inclusion of support for 4 bit link estimation.
Om, you were going to run some tests on mica2dots, right? Can you see
if you encounter this problem?
Phil
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] something wrong happened in CC1000 driver in tinyos-2.x tree of cvs version
David Gay committed a fix a few minutes ago and things seem to be working now. BTW, I did not get the out of bound error that John found - maybe I did not run the test long enough... Odd-- I believe we saw it almost immediately. Anyway, should be a non-issue now. Thanks, John ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] make deluge support mica2
Hello all :
2008/6/3 Razvan Musaloiu-E. [EMAIL PROTECTED]:
Hi!
On Tue, 3 Jun 2008, jiwen zhang wrote:
Hello :
2008/6/3 Razvan Musaloiu-E. [EMAIL PROTECTED]:
Hi!
I just found a MPR400CB and I and was able to successfully run the burn
script from the tinyos-2.x/apps/tests/deluge/Blink.
that is to say you have modify the deluge to make it support deluge
including th burn script ? what is the way ? are there some differences
with mine ? are there some errors in my modifications , Razvan ME ?
I run exactly the latest version from CVS. I used micaz which means the
radio part will not work but otherwise the Mica2 is very similar with MicaZ.
i understand what you do . i also test like you and my mica2 mote work well
too as it should be . i don't change too muh , why after modification
according to the mothod present in the email before , the mica2 can not
reboot from specified image ? it puzzle me .
I used a MIB520 so the command I used was:
./burn /dev/ttyUSB0 /dev/ttyUSB1 micaz
Both the injection and the reboot worked fine.
What happens if you run the above command on an unmodified tree?
the mica2 mote work well if it is an basestation on an unmodified tree .
i also can injection on the basestation mote . but when i use the reboot
command (-r) , it does not load the image i specify to the internal flash
and just reboot .
what about yours ? does it can reboot from the specified image ?
The reboot using -r worked properly because the burn script is using it. I
also tested it manually and it worked fine.
when i use the -r on the modified tree , the mica2 mote just reboot and can
load the specified image . so i use the command -i to load an image to the
section 0 , and test it manually , it can reboot and can load the image from
section 0 .
can you see where the problem is , Razvan ME ?
can you modify the tree according to the mothod i have said and check where
the problem is ? maybe we can make deluge support mica2 mote , if the
basestation mote work well , i can test the network programme , i have some
mica2 motes .
thank you very much for your help !!
All the best!
Razvan ME
I only have one of these motes so I cannot do any other test than this.
:-(
You have helped me so much , i really thank you very mcch !!
Does any one try it ? i want to know the your result . thank you very much
!!
--
Razvan ME
On Tue, 3 Jun 2008, jiwen zhang wrote:
Hello all :
can someone give me an answer to my questions (as follows)? thank you
very much !!!
2008/6/1 jiwen zhang [EMAIL PROTECTED]:
Hello all :
because i have many mica2 motes , and few micaz motes , so i want to
modify the deluge to make it support mica2 .
some operations i have done :
1 . go to /opt/tinyos-2.x/tos/lib/TOSBOOT , create a folder named
mica2,
copy all the files in the directory TOSBOOT/micaz to TOSBOOT/mica2.
2 . modify the file hardware.h in TOSBOOT/mica2 . add the sentences at
about lines 101? :
TOSH_ASSIGN_PIN(BAT_MON, A, 5);
TOSH_ASSIGN_PIN(THERM_PWR, A, 7);
chage the value of VOLTAGE_PORT to 7 . (i refer to tinyos-1.15) , i
think it should be 30 .
3. modify the file VoltageC.nc
at the start of command Voltage.okToProgram() , add the sentences : (i
refer to tinyos-1.15)
TOSH_MAKE_BAT_MON_OUTPUT();
TOSH_SET_BAT_MON_PIN();
4 . modify the Makefile in the directory TOSBOOT/ , add the sentences
(after about lines 54 ?):
ifeq ($(MAKECMDGOALS),mica2)
CFLAGS += -DTOSBOOT_START=0x1f000 -DTOSBOOT_END=0x2
CFLAGS += -Wl,--section-start=.text=0x1f000
CFLAGS += -Iat45db -Iavr -Imica2 -Ilib
CFLAGS += -I../net/Deluge
endif
5 . modify the files TOSBootM.nc in /TOSBOOT/ ,
BlockStorageManagerC.nc and BlockStorageManagerP.nc in
lib/Deluge/BlockStorageManager/ , DelugePageTransfer.h in lib/Deluge/ .
the mothod is easy , for example :
at the lines : defined(PLATFORM_MICAZ) || defined(PLATFORM_IRIS)
change it into : defined(PLATFORM_MICAZ) || defined(PLATFORM_MICA2) ||
defined(PLATFORM_IRIS)
6 . go to /opt/tinyos-2.x/tos/lib/net/Deluge/extra , copy the files
NetProgC.nc and NetProgM.nc in extra/iris to extra/mica2 .
7 . /opt/tinyos-2.x/support/make, modify the file bnp.extra , add the
sentences at about line29 ?:
ifeq ($(TARGETS),mica2)
CFLAGS += -I$(DELUGE_EXTRA)/mica2 -I$(DELUGE_EXTRA)/micaz
-I$(DELUGE_EXTRA)/avr -I$(DELUGE_EXTRA)
BOOTLOADER ?= $(TOSBOOT_DIR)/mica2/main.ihex
AVR_FUSE_H ?= 0xda
endif
8 . modify the files tos-deluge in /usr/local/bin ? and
/opt/tinyos/tools/tinyos/misc at about line38 ? :
chage :
BAUDRATES = {'micaz': 57600,
'telosb': 115200,
'iris': 57600}
into :
BAUDRATES = {'micaz': 57600,
'mica2': 57600,
'telosb': 115200,
'iris': 57600}
that is all .
Do i still have something to modify or there are something wrong i have
modified ?
i have tested
Re: [Tinyos-help] RSSI values of mica2
Hi, Thanks MS.I took for granted vref=3V and proceeded.With max.Tx power(5dBm) I get RSSI(dBm)=-48dBm with ADC=0x0015 and with min.Tx.power= -20dBm ,I get RSSI(dBm) as -90dBm with ADC =0x0133. Regards, Kishore On Tue, Jun 3, 2008 at 10:57 PM, Michael Schippling [EMAIL PROTECTED] wrote: The actual Vref on the mica2 is the battery voltage. I forget where the ADCREFM thing comes from... MS ram kishore wrote: Hi, I receive RSSI values( uint16_t type) using Msg-strength feild .At maximum power, I get RSSI(ADC) value as 0x0015.Given in /tos/platform/mica2/ADCREFM.nc file(attached) is the following formula: ADC = (Vport*1024) / Vref; Where Vref =1.23V as in ADCREFM file.I find Vport using above equation for 0x0015(integer=21) and substitute in RSSI(dBm) = -50 * Vport -45.5 ; I get -46.2612 dBm which is wrong actually.I use tinyos1.1.10.I posted this problem several times all in vain.Please help me out.I am going out of head.Please. Thanking you, Kishore ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
