Re: [Tinyos-help] AM timing amongst CTP
The system will perform the arbitration, using a FIFO queue for AM sends. Generally speaking, you have an O(n^2) protocol, if each beacon will trigger O(n) CTP messages. It is very possible or likely that you are saturating the network. CTP is not intended for high throughput. What is the aggregate message rate you are seeing at the base station? Remember, these are slow, low-power radios. Phil On Sep 12, 2014, at 8:36 PM, Brad Goold brad_go...@dodo.com.au wrote: Hi, I'm a research student and I am using TelosB motes and TinyOS to perform a localisation task. I use the CTP protocol to route information back to a root node and then use the serial forwarder as a bridge between the WSN and a PC. I use a 'target node' to send simple AM's to the static nodes which recieve this AM, retrieve the RSSI information and then use the CTP to route the information back to the root. The problem I have is that I can only perform 1 to 2 beacons per second. The recieved packets at the PC are often missing a packet from a particular sensor. So my questions (of limited knowledge I may add) are: When sending simple AM's in conjunction with the CTP, do I need to do some sort of arbitration? Or is this included in the lower layers? Am I doing something really wrong? Any advice or direction is greatly appreciated, Regards, Brad -- Brad Goold Phone: +61 413 955 125 Email: brad_go...@dodo.com.au ___ 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] Time Synchronization in Micaz
The canonical approach for doing this is called FTSP (flooding time synchronization protocol). http://www.math.u-szeged.hu/tagok/mmaroti/okt/2010t/ftsp.pdf Take a look at tos/lib/ftsp. There is a sample app in apps/tests/TestFtsp. Phil On Aug 5, 2014, at 2:57 AM, Nemer14 g201206...@kfupm.edu.sa wrote: Any one has a code of any time synchronization protocol in WSN using Micaz? Best Regards. -- View this message in context: http://tinyos-help.10906.n7.nabble.com/Time-Synchronization-in-Micaz-tp24527.html Sent from the TinyOS - Help mailing list archive at Nabble.com. ___ 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] PppRouter (msp430-ld: region text is full) in Telosb
Alex,
It is not a nesC version problem. The issue is that the PppRouter code is too
big to fit on the micro controller.
Phil
On Jul 9, 2014, at 9:18 AM, Alex CP cpa9...@gmail.com wrote:
Dear Thomas.
Thanks for you answer.
I've commented these lines but error persists:
msp430-ld: region text is full (build/telosb/main.exe section .text)
msp430-ld: section .vectors [ffe0 - ] overlaps section .text
[4000 - 0001148f]
msp430-ld: build/telosb/main.exe: section .vectors lma 0xffe0 overlaps
previous sections
make: *** [exe0] Error 1
Probably is a problem of the nescc version?
root@a:/opt/tinyos-2.x.acp/apps/PppRouter# nescc --version
nescc: 1.3.5
gcc: gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
Thanks in advance for any help.
Yours faithfully,
Alex.
On Tue, Jul 8, 2014 at 4:52 AM, Thomas Pötsch t...@comnets.uni-bremen.de
wrote:
Hi Alex,
which checkout are you using?
If I remember correctly, then you have to comment the following lines in
PppRouterC.nc to get it working on TelosB:
// UDP shell on port 2000
// components UDPShellC;
// prints the routing table
// components RouteCmdC;
Viele Grüße,
Thomas
Hi all.
I'm trying to compile it:
root@a:/opt/tinyos-2.x/apps/PppRouter# make telosb blip
..
.
msp430-ld: region text is full (build/telosb/main.exe section .text)
msp430-ld: section .vectors [ffe0 - ] overlaps section .text
[4000 - 000119e9]
msp430-ld: build/telosb/main.exe: section .vectors lma 0xffe0 overlaps
previous sections
make: *** [exe0] Error 1
But appears errors of space in memory. I can't find the way improve this
problem.
Please someone know how fix it problem?
Thanks in advance.
Alex
On Sat, Jul 5, 2014 at 2:00 PM, tinyos-help-requ...@millennium.berkeley.edu
wrote:
Send Tinyos-help mailing list submissions to
tinyos-help@millennium.berkeley.edu
To subscribe or unsubscribe via the World Wide Web, visit
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
or, via email, send a message with subject or body 'help' to
tinyos-help-requ...@millennium.berkeley.edu
You can reach the person managing the list at
tinyos-help-ow...@millennium.berkeley.edu
When replying, please edit your Subject line so it is more specific
than Re: Contents of Tinyos-help digest...
Today's Topics:
1. TinyDDS middleware make micaz error (anas alroubaiy)
2. SHA1 error in tinyecc (Jisha Mary Jose)
--
Message: 1
Date: Sat, 5 Jul 2014 00:06:46 +0300
From: anas alroubaiy saba717...@hotmail.com
Subject: [Tinyos-help] TinyDDS middleware make micaz error
To: tinyos-help@millennium.berkeley.edu
tinyos-help@millennium.berkeley.edu
Message-ID: dub110-w1373e241c1d622bac37e1d2df...@phx.gbl
Content-Type: text/plain; charset=windows-1256
Hello all,
I am trying to do make micaz for TinyDDS middleware application. it works
fine
with make micaz sim, but when i try to do make micaz in tinyos 2.1.2,
ubuntu 12.04
this error has occurred:
from DDS.nc:49:
In component `DymoServiceC':
/home/ps3-279/tinyos-main/tos/lib/net/tymo/dymo/DymoServiceC.nc: At top
level:
/home/ps3-279/tinyos-main/tos/lib/net/tymo/dymo/DymoServiceC.nc:35:
`VOLUME_DYMODATA' undeclared here (not in a function)
/home/ps3-279/tinyos-main/tos/chips/at45db/At45dbStorageManagerC.nc:25:28:
error: StorageVolumes.h: No such file or directory
make: *** [exe0] Error 1
Should i searched for the StorageVolumes.h and add it manually?
Thanks in Advance
-- next part --
An HTML attachment was scrubbed...
URL:
https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/2014
0705/84cdc6f4/attachment.html
--
Message: 2
Date: Sat, 5 Jul 2014 14:23:32 +0530
From: Jisha Mary Jose jishamary1...@gmail.com
Subject: [Tinyos-help] SHA1 error in tinyecc
To: tinyos-help@millennium.berkeley.edu,
tinyos-help-requ...@millennium.berkeley.edu
Message-ID:
CADNVx9oa494qb4He33no15JPBXwC9_QVcccLNkm3pCVoCVx=
7...@mail.gmail.com
Content-Type: text/plain; charset=utf-8
Hi,
When I try to use the SHA1 function in tinyecc-2.0 IN TINYOS-2.1.2, i get
the following error:
IN the configuration file I give,
implementation {
components DisseminationC as App;
App.SHA1 - SHA1M;
}
Here SHA1.nc is the interface file and SHA1M.nc is the module file.
i get an error:
In component `DisseminationAppC':
DisseminationAppC.nc:19: expected component `SHA1', but got a component
DisseminationAppC.nc:31: cannot find `SHA1M'
HOW
Re: [Tinyos-help] TinyDB : where can I find it?
On Jul 17, 2014, at 9:33 AM, Cyril C ulrichcan...@yahoo.fr wrote: Thanks for your answer. So if TinyDB belongs to TinyOS 1, can I decently supposed that is it not longer supported ? Correct. Hasn't been supported for almost a decade now. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Is TinyOS slowly dying ????
On May 31, 2014, at 6:10 PM, Roadstar Runner redstripe...@gmail.com wrote: Andris, I understand that TinyOS is an all volunteer project and commend the time put in by the you and others. One of the aspects of TinyOS that attracted me to it was the enthusiasm and activity i saw on the forums. That seems to be on the decline now. I hope that it does not become a vicious cycle. That combined with the fact that the TinyOS tools are years old, do not bode well for the future of TinyOS. I have finally almost managed to get TinyOS working with gcc v4.9.0. Though i am a novice wrt gcc, I will be more than willing to contribute in any way to upgrading the toolchain. I will be testing the new version of gcc with a few test programs and will keep you updated as i go along Your problem is an avr-gcc problem, not a TinyOS one. Unfortunately it's a problem that's tricky to fix. TinyOS hasn't really been supported on Cygwin for a very long time; since the availability of free VM players, the recommended process for Windows has instead been to run Linux in a VM. Compiling compilers under Cygwin is tremendously difficult, TinyOS or not. It also sounds like you're not following the instructions that people *are* giving you. We're happy to help, but that's all we can do -- help. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] warning in FcfsResourceQueueC.nc after upgrading avr-gcc
The source code is not designed to be used with 4.9; this is why we package up particular compiler releases. I'm pretty sure this is a false positive warning. Sometimes we need to tweak code generation to suppress such warnings. If you could show the generated C that causes the warning, that would be helpful. But you've decided to venture into uncharted territory -- no-one has tested TinyOS with 4.9, and there might be bugs that the TinyOS code tickles (more common than you'd like with avr-gcc) and so your binaries aren't correct. Phil On Jun 8, 2014, at 7:05 PM, Roadstar Runner redstripe...@gmail.com wrote: I recently upgraded to avr-gcc 4.9.0 and am getting a few warnings in FcfsResourceQueueC.nc. I am not sure why gcc is complaining. /opt/tinyos-2.x/tos/system/FcfsResourceQueueC.nc:88:73: warning: array subscript is above array bounds [-Warray-bounds] resQ[qTail] = id; ___ 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] new avr toolchain
Andras, can we move this to tinyos-main? Running into a few issues. Phil On Jun 20, 2014, at 4:37 AM, András Bíró andras.b...@ucmote.com wrote: Hi Everyone, I'm finally done with updating the avr toolchain, and I'm happy to announce a beta release. Installation on debian/ubuntu/any dpkg based distro: #apt-get remove avr-tinyos-base #apt-get install avr-libc-tinyos-beta Revert to the old toolchain: #apt-get remove avr-tinyos-base #apt-get install avr-libc-tinyos There's no rpm yet, but if you need it, I could generate it on linux. However, I don't wan't to build the cygwin packages while we're testing it, since it's usually a pain to compile on cygwin. If you want to use it on windows, please use atmel's official 3.4.4 release binary What's new: GCC 4.8.1 (instead of 4.1.2) Binutils 2.24 (instead of 2.17) AVR-libc 1.8.0 (instead of 1.6.7, but since the old gcc, it barely know more than 1.4.7) Source: Atmel's pached AVR-GNU Toolchain v3.4.4 Buildscripts at $TOSROOT/packaging/avr-344-beta I'm using it for a while, didn't have any problem. Please test it, if you can. Please don't reply this email on the list, it's just an announcement. Public discussion is at github: https://github.com/tinyos/tinyos-main/issues/293 Best, Andras Biro ___ 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] TinyOS support for Atmel chips on newer ZigBit modules (ATZB)
On Apr 23, 2014, at 7:26 AM, Thomas Schmid thomas.sch...@gmail.com wrote: It really is all about writing drivers for those chips. The port for the SAM3U and SAM3S are pretty good, though they lack a little bit in low-power features (e.g. turning peripherals properly on and off). I'm definitely interested to hear what Cortex M chips people are using/want to use, to see if it's possible to do reasonable chip-independent implementations. I've poked around at the SAM3 code but haven't looked at other chip data sheets to have a sense of how much/what differs, if at all. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Interface for split-phase write operations
There isn't; the general intent is that interfaces are typed, so that you get compile-time checking. E.g., if you use a general Write interface, then someone could more easily connect components incorrectly. Take a look at CC2420Config, for example. It's a specific interface because its operations are CC2420 specific. There are general sensing interfaces because there are sensor-independent libraries one wants to be able to put on top of them, such as buffering, storage, etc. But control/configuration doesn't generally fall into this category. Phil On Apr 22, 2014, at 4:39 AM, Matthias May matthias@rwth-aachen.de wrote: Hello, is there a standard interface for split-phase write operations (a counterpart to the Read interface)? I can only find the Set interface for writing values backed by memory but I need to set configuration parameters in an external chip and I prefer using standardized interfaces. Regards, Matthias ___ 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] TinyOS support for Atmel chips on newer ZigBit modules (ATZB)
I'm very interested in incorporating support for the newer Atmel chips in the main tree. Cortex M3 is also a priority, but given the diversity of chips I want to take a look at the space and figure out which we should focus on. Phil On Apr 20, 2014, at 11:44 AM, Ugo Colesanti colesa...@dis.uniroma1.it wrote: On 04/20/2014 06:09 PM, Martin Cerveny wrote: Hello. Is there some progress or stable/final/tested code for Atmel newer RF chips on ZigBit (ATZB) modules ? Did someone check/test compatibility with previous chip generations ? Is there some TinyOS implementation with XMega CPU (ATxmegaxxx) ? And what about ARM Cortex-M0+ CPU (ATSAMR21xxx, https://code.google.com/p/tinyos-cortex/) ? We just bought an R21XplainedPro board, we are playing bit with it but with atmel studio only. There is almost no documentation (atmel sent us a very preliminary datasheet). We scheduled to work on a tinyos porting, but with very-low priority. The problem is that we are not familiar with cortex and with arm-gcc in general... if anyone wants to join... RF: - AT86RF233 - compatible with RF230 ? - Atmel module - http://www.atmel.com/tools/ATZB-RF-233-1-C.aspx Some references: - http://wiesel.ece.utah.edu/projects/10/ - git://wiesel.ece.utah.edu/tinyos/tinyos-prod.git (branch wiesel) - AT86RF212B - compatible with RF212 ? - Atmel module - http://www.atmel.com/tools/ATZB-RF-212B-0-U.aspx - Atmel module - http://www.atmel.com/tools/ATZB-RF-212B-0-CN.aspx CPURF: - ATmega256RFR2 - compatible with 128RFA1 ? - Atmel module - http://www.atmel.com/tools/ATZB-S1-256-3-0-U.aspx - Atmel module - http://www.atmel.com/tools/ATZB-S1-256-3-0-C.aspx We are very familiar with RFA1 (we have a custom board based on this chip) and we have a couple of RFR2 bought from dresden elektronik, we didn't had time to focus on RFR2 yet, but it is planned very soon. We can let you know on any updates about this topic (it seems there are few changes in transceiver and ADC modules, for the rest they seem the same). CPU+RF: - ATxmega256A3U + AT86RF233 - Atmel module - http://www.atmel.com/tools/ATZB-X0-256-3-0-C.aspx - ATxmega256A3U + AT86RF212B - Atmel module - http://www.atmel.com/tools/ATZB-X0-256-4-0-U.aspx - Atmel module - http://www.atmel.com/tools/ATZB-X0-256-4-0-CN.aspx Thanks for answers, Martin Cerveny ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Ugo Maria Colesanti Dipartimento di Ingegneria Informatica, Automatica e Gestionale Antonio Ruberti Sapienza Universita' di Roma Via Ariosto 25, II floor, room A221 00185, Rome http://wiserver.dis.uniroma1.it/cms/index.php/contacts/13-postdoc/4-ugo-colesanti Phone: +39 06 77274056 Fax:+39 06 77274002 ___ 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] Problem when installing TinyOS
Lei, I've encountered this problem too. I'm not sure why Eric's packages stopped passing verification. The simple workaround is to install them with --allow-unauthenticated. Phil On Apr 17, 2014, at 8:25 AM, Lei Chen lc...@york.ac.uk wrote: Dear everyone, I'm new here and I'm a PhD student in University of York. Currently, I'm experiencing difficulties when installing TinyOS in Ubuntu 12.04LTS. The problem is that the terminal shows me the error (The following signatures couldn't be verified because the public key is not vailable: NO_PUBKEY BD4DDD22F99BE531). I've followed the key installation procedure that Eric Decker listed in http://tinyprod.net/repos/debian/;. However, it still does't work. This is not the first time I install TinyOS in Ubuntu. Previous installation went smoothly without problem if I follow the guide. However, I tried several times recently and none of them work for me. May I ask for some help from you in this situation? Looking forward to hear any of you soon. Regards, Lei Chen Disclaimer: http://www.york.ac.uk/docs/disclaimer/email.htm ___ 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] TinyOS 2.1.3, packages, and repository
So it looks like tinyprod is down and won't be coming back up. I'm going to move TinyOS and its support packages (e.g., msp430-46) back to being hosted at tinyos.stanford.edu. In part, this means I'd like to package up version 2.1.3 of TinyOS. If anyone would like to help with the packaging and maintenance of the repository, please drop me a line (p...@cs.stanford.edu), I'd of course appreciate help. My plan is to start working on this in May and have a release ready by mid-June. I've started an issue on tinyos-main so we can come up with a to-do list of what to pull into the main repository (and issues to address) for 2.1.3 under that timeframe. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Im unable to install msp430-46 compiler
tinyos.stanford.edu now has the msp430-46 packages. deb http://tinyos.stanford.edu/tinyos/dists/ubuntu natty main Phil On Apr 14, 2014, at 11:57 PM, Antonio Linan ali...@zolertia.com wrote: To my knowledge the repository is broken, if you need only the compiler toolchain I can provide a link: http://sourceforge.net/projects/zolertia/files/Toolchain/ Cheers, --Antonio On Tue, Apr 15, 2014 at 4:04 AM, Erdélyi Ádám [Edöm] erdelyiadam.e...@gmail.com wrote: Hola Jorge, this is an English speaking mailing list to my best knowledge. Please act accordingly. Cheers, Adam On 2014.04.15. 1:19, Jorge Castro wrote: Hola. No puedo instalar el compilador msp430-46. Cada vez que trato de instalar desde los repositorios me aparece un error . Podrían darme alguna solución? Jorge. -- _ .. Att. Jorge Israel. ___ 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 -- -- Antonio Liñán Colina R+D Engineer @: ali...@advancare.com @: ali...@zolertia.com -- Advancare Ph.: +34 935 511 403 http://www.advancare.com http://www.zolertia.com http://zolertia.sourceforge.net http://webshop.zolertia.com ___ 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] Cryptic compile error with flag avr-studio-debug
(responded to this unicast, thought I would put it here too) It looks like the avr-studio-debug flag doesn't support code sizes greater than 65,535 bytes. I'm not exactly sure why. Phil On Apr 8, 2014, at 3:00 PM, Roadstar Runner redstripe...@gmail.com wrote: I have been compiling my program with the 'avr-studio-debug' flag so that i can use a JTAG to debug my software. Recently, even though my program compiles normally without the debug flag, it fails when i use the avr-studio-debug flag. I get a bunch of cryptic error message that reads like this /tmp/ccEjxlre.s:74677: Error: value of 65568 too large for field of 2 bytes at 26349 It seems that code i add, even modifying a local variable causes the compilation to fail. Here is my ROM/RAM size that compiles correctly with the debug flag. 68796 bytes in ROM 614 bytes in RAM Thanks ___ 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] Cryptic compile error with flag avr-studio-debug
This seems to be a basic avr-gcc problem: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087 It seems the general solution people are proposing involves rebuilding the compiler/tool chain so that dwarf debugging addresses are 2 bytes rather than 4. I am wondering whether newer avr-gcc releases solve this problem. Phil On Apr 10, 2014, at 10:30 AM, Roadstar Runner redstripe...@gmail.com wrote: Phil, Thanks once again. Is there an easy way for me to find a fix/workaround ? Lewis On Thu, Apr 10, 2014 at 12:13 PM, Philip Levis p...@cs.stanford.edu wrote: (responded to this unicast, thought I would put it here too) It looks like the avr-studio-debug flag doesn't support code sizes greater than 65,535 bytes. I'm not exactly sure why. Phil On Apr 8, 2014, at 3:00 PM, Roadstar Runner redstripe...@gmail.com wrote: I have been compiling my program with the 'avr-studio-debug' flag so that i can use a JTAG to debug my software. Recently, even though my program compiles normally without the debug flag, it fails when i use the avr-studio-debug flag. I get a bunch of cryptic error message that reads like this /tmp/ccEjxlre.s:74677: Error: value of 65568 too large for field of 2 bytes at 26349 It seems that code i add, even modifying a local variable causes the compilation to fail. Here is my ROM/RAM size that compiles correctly with the debug flag. 68796 bytes in ROM 614 bytes in RAM Thanks ___ 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] msp430-46 unable to install
I've put the msp430-46 packages up on tinyos.stanford.edu. The dummy packages still point at the old MSP430 versions. But if you install tinyos-2.1.2, tinyos-tools, msp430-46, nesc, you should be good. Phil On Apr 7, 2014, at 8:04 AM, Michiel Konstapel m.konsta...@sownet.nl wrote: Quick followup question, since Eric let me know that the tinyprod repo is indeed offline – where does one conveniently get a fresh TinyOS/MSP430 toolchain from at the moment? Build from source? TinyOS build instructions at http://tinyos.stanford.edu/tinyos-wiki/index.php/Installing_From_Sourcelook easy enough but I’m not sure about building mspgcc and I’d very much prefer one of the pre-built LTS versions. Cheers, Michiel From: tinyos-help-boun...@millennium.berkeley.edu [mailto:tinyos-help-boun...@millennium.berkeley.edu] On Behalf Of Michiel Konstapel Sent: Thursday, March 27, 2014 17:37 To: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] msp430-46 unable to install Is the TinyProd repository still broken? I just tried to install on a new machine (Ubuntu Server 13.10, 64 bit), which failed. In /etc/apt/sources.list, I have: deb http://tinyprod.net/repos/debian squeeze main deb http://tinyprod.net/repos/debian msp430-46 main Attempting to install: $ sudo apt-get install msp430-46 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: msp430-46 : Depends: msp430-binutils-46 but it is not installable Depends: msp430-gcc-46 but it is not installable Depends: msp430-libc-46 but it is not going to be installed Depends: msp430mcu-46 but it is not going to be installed Depends: msp430-gdb-46 but it is not installable E: Unable to correct problems, you have held broken packages. $ sudo apt-get install msp430-binutils-46 Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: gcc-4.8-base:i386 libc6:i386 libgcc1:i386 Suggested packages: glibc-doc:i386 locales:i386 The following NEW packages will be installed: gcc-4.8-base:i386 libc6:i386 libgcc1:i386 msp430-binutils-46:i386 0 upgraded, 4 newly installed, 0 to remove and 5 not upgraded. Need to get 27.9 MB/32.0 MB of archives. After this operation, 9821 kB of additional disk space will be used. Do you want to continue [Y/n]? y WARNING: The following packages cannot be authenticated! msp430-binutils-46 Install these packages without verification [y/N]? y Get:1 http://tinyprod.net/repos/debian/ msp430-46/main msp430-binutils-46 i386 2.21.1-LTS20120406 [27.9 MB] Fetched 1 B in 6s (0 B/s) Failed to fetch http://tinyprod.net/repos/debian/pool/main/m/msp430-binutils-46/msp430-binutils-46_2.21.1-LTS20120406_i386.deb Size mismatch E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? If this repo is offline, what’s the current alternative? Thanks, Michiel From: tinyos-help-boun...@millennium.berkeley.edu [mailto:tinyos-help-boun...@millennium.berkeley.edu] On Behalf Of Antonio Linan Sent: Tuesday, February 25, 2014 12:03 To: Vandana Bhasin Cc: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] msp430-46 unable to install See: http://tinyprod.net/debian-dev/README-46.html --Antonio On Tue, Feb 25, 2014 at 11:54 AM, Vandana Bhasin vandana.bha...@yahoo.com wrote: Hello, I am unable to install the msp430-gdb-46 package. A similar error message pops up for other msp packages apt-get install msp430-gdb-46 Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package msp430-gdb-46 Following instructions on github, unable to connect for keys also root@ubuntu:~# gpg --keyserver keyserver.ubuntu.com --recv-keys 34EC655A gpg: WARNING: unsafe ownership on configuration file `/home/vandanabhasin/.gnupg/gpg.conf' gpg: external program calls are disabled due to unsafe options file permissions gpg: keyserver communications error: general error gpg: keyserver receive failed: general error Can anybody please help resolve this issue? Thanks Vandana ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- -- Antonio Liñán Colina R+D Engineer @: ali...@advancare.com @: ali...@zolertia.com -- Advancare
Re: [Tinyos-help] msp430-46 unable to install
So you want to add deb http://tinyos.stanford.edu/tinyos/dists/ubuntu natty main Phil On Apr 7, 2014, at 8:04 AM, Michiel Konstapel m.konsta...@sownet.nl wrote: Quick followup question, since Eric let me know that the tinyprod repo is indeed offline – where does one conveniently get a fresh TinyOS/MSP430 toolchain from at the moment? Build from source? TinyOS build instructions at http://tinyos.stanford.edu/tinyos-wiki/index.php/Installing_From_Sourcelook easy enough but I’m not sure about building mspgcc and I’d very much prefer one of the pre-built LTS versions. Cheers, Michiel From: tinyos-help-boun...@millennium.berkeley.edu [mailto:tinyos-help-boun...@millennium.berkeley.edu] On Behalf Of Michiel Konstapel Sent: Thursday, March 27, 2014 17:37 To: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] msp430-46 unable to install Is the TinyProd repository still broken? I just tried to install on a new machine (Ubuntu Server 13.10, 64 bit), which failed. In /etc/apt/sources.list, I have: deb http://tinyprod.net/repos/debian squeeze main deb http://tinyprod.net/repos/debian msp430-46 main Attempting to install: $ sudo apt-get install msp430-46 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: msp430-46 : Depends: msp430-binutils-46 but it is not installable Depends: msp430-gcc-46 but it is not installable Depends: msp430-libc-46 but it is not going to be installed Depends: msp430mcu-46 but it is not going to be installed Depends: msp430-gdb-46 but it is not installable E: Unable to correct problems, you have held broken packages. $ sudo apt-get install msp430-binutils-46 Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: gcc-4.8-base:i386 libc6:i386 libgcc1:i386 Suggested packages: glibc-doc:i386 locales:i386 The following NEW packages will be installed: gcc-4.8-base:i386 libc6:i386 libgcc1:i386 msp430-binutils-46:i386 0 upgraded, 4 newly installed, 0 to remove and 5 not upgraded. Need to get 27.9 MB/32.0 MB of archives. After this operation, 9821 kB of additional disk space will be used. Do you want to continue [Y/n]? y WARNING: The following packages cannot be authenticated! msp430-binutils-46 Install these packages without verification [y/N]? y Get:1 http://tinyprod.net/repos/debian/ msp430-46/main msp430-binutils-46 i386 2.21.1-LTS20120406 [27.9 MB] Fetched 1 B in 6s (0 B/s) Failed to fetch http://tinyprod.net/repos/debian/pool/main/m/msp430-binutils-46/msp430-binutils-46_2.21.1-LTS20120406_i386.deb Size mismatch E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? If this repo is offline, what’s the current alternative? Thanks, Michiel From: tinyos-help-boun...@millennium.berkeley.edu [mailto:tinyos-help-boun...@millennium.berkeley.edu] On Behalf Of Antonio Linan Sent: Tuesday, February 25, 2014 12:03 To: Vandana Bhasin Cc: tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] msp430-46 unable to install See: http://tinyprod.net/debian-dev/README-46.html --Antonio On Tue, Feb 25, 2014 at 11:54 AM, Vandana Bhasin vandana.bha...@yahoo.com wrote: Hello, I am unable to install the msp430-gdb-46 package. A similar error message pops up for other msp packages apt-get install msp430-gdb-46 Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package msp430-gdb-46 Following instructions on github, unable to connect for keys also root@ubuntu:~# gpg --keyserver keyserver.ubuntu.com --recv-keys 34EC655A gpg: WARNING: unsafe ownership on configuration file `/home/vandanabhasin/.gnupg/gpg.conf' gpg: external program calls are disabled due to unsafe options file permissions gpg: keyserver communications error: general error gpg: keyserver receive failed: general error Can anybody please help resolve this issue? Thanks Vandana ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- -- Antonio Liñán Colina R+D Engineer @: ali...@advancare.com @: ali...@zolertia.com -- Advancare Ph.: +34 935 511 403 http://www.advancare.com http://www.zolertia.com http://zolertia.sourceforge.net
Re: [Tinyos-help] Tiny os and Contiki
Generally speaking, and I'm a bit biased, the TinyOS code is much more solid and efficient. But you're right that Contiki has a more active developer community. The TinyOS code that's there is rock solid, but our user-facing side could be better. Also, more active development on MCU and RFIC advances would be great. I'm interested in the comment that following the installation instructions doesn't work; I had a student start playing with TinyOS and he said he was startled at how trivial and easy it was to get up and running. Phil --- Philip Levis Associate Professor Computer Science and Electrical Engineering Stanford University http://csl.stanford.edu/~pal On Jan 9, 2014, at 8:52 AM, Rahav Dor (yahoo) rah...@yahoo.com wrote: I tend to agree with your comment, but leaving outside the kind of support requests you mentioned, I still have hopes for TinyOS. Right now it does not feel as a vibrant, active community. On top of that our public facing information is often incorrect or incomplete, just try to install it by following TinyOS web site and see where it would get you. I believe that our work products should be usable by others. With the potential of all-things-embedded, or Internet of Things, or whatever you want to call it, TinyOS will not be successful if we forget this. Rahav Dor On Thursday, January 9, 2014 9:12 AM, Saeid Yazdani sy.kal...@gmail.com wrote: TinyOS is not ment to have support. A researcher at least in the case of embedded systems or WSN PhD position should not need any support...I see many people here who are researchers and they don't know basic C programming. I agree that support is a good thing but people shouldn't relay on others to cut out the work for them. Kust y thoughts... On 9 Jan 2014 16:04, Rahav Dor (yahoo) rah...@yahoo.com wrote: You should also consider support. I've been using TinyOS for research purposes for a while and I can tell you that it seems like a dying product. Or at least one, that not too many people care about. It takes days if not longer to get a response on this forum. I do not know how Contiki is doing in this respect, but if this continues, the my current project is going to be the last on TinyOS. Rahav Dor ___ 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] TinyOS 2.x GDB dollar sign
The $ was originally used because it's a token that a C name can't have but which assembly can. The issue was that gcc's assembler is by default compiled to not support $, but you can enable it with a simple flag. But this meant we had to distribute our own version of the assembler. So we gravitated to __. Phil --- Philip Levis Associate Professor Computer Science and Electrical Engineering Stanford University http://csl.stanford.edu/~pal On Dec 23, 2013, at 5:52 PM, Eric Decker cire...@gmail.com wrote: On Mon, Dec 23, 2013 at 2:13 PM, Addisu Z. Taddese add...@isis.vanderbilt.edu wrote: I'm using TinyOS 2.1.2. I wasn't clear on how the dollar sign was used. I thought it was just a debugging convenience. One of the things that got confused was the debugger. anytime you had to type a nesc mangled symbol name you had to escape the $. It was a royal pain. We lobbied David to change it to __ Thanks for the help. On Mon, Dec 23, 2013 at 3:58 PM, Eric Decker cire...@gmail.com wrote: There is a way to do it but If you do a build with verbose you should see the switch that tells nesc to use __. You can do a search for that switch using grep and that will tell what files it is buried in. It hasn't been done that way in a long time. Using $ in symbol names caused lots of problems when we moved the compiler versions forward. That is why we went to __ (double under). Why are you using TinyOS 1? That has been supported in many moons. Current version is TinyOS 2.1.2 On Mon, Dec 23, 2013 at 1:27 PM, Addisu Z. Taddese add...@isis.vanderbilt.edu wrote: Hello, Looking at this website (http://www.tinyos.net/tinyos-1.x/doc/nesc/nesc-debugging.html), it looks like GDB, at one point, supported mapping nesC names to C names such that M$F maps to function F in module M so that one doesn't have to write M__F. When I try to do this with my copy of msp430-gdb (v 7.2), it comes back with a No symbol in current context error. Does anyone know how I can get this functionality back? Thanks, Addisu -- Addisu Z. Taddese Ph.D. Student Electrical Engineering and Computer Science Department Vanderbilt University ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Eric B. Decker Senior (over 50 :-) Researcher -- Addisu Z. Taddese Ph.D. Student Electrical Engineering and Computer Science Department Vanderbilt University -- Eric B. Decker Senior (over 50 :-) Researcher ___ 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] AMPacket.setType()
Eric, stop being a jerk. Lin Hai, your conclusion is correct: you cannot set the AM type above the AM layer, because when you call Send it fills in the value. The function is there because the AM layer uses it, and more generally, so that one could do something like call AMPacket.setType(m, X); … in another, later piece of code: call AMSend.send[AMPacket.type(m)](…) Phil --- Philip Levis Associate Professor Computer Science and Electrical Engineering Stanford University http://csl.stanford.edu/~pal On Dec 17, 2013, at 1:32 AM, Eric Decker cire...@gmail.com wrote: first, get a jtag and learn to single step the code. I suspect that you have wired a hard coded am_type at a higher level. You can call AMPacket.type but it will get over written later. However, that is just a guess. It is impossible to determine what is going on from the little bit of information you've provide. Seriously, what do you want from us? How about you think to your self what would help us help you. What code base are you working on? Better would be if you are based on github://github.com/tinyos/tinyos-main and fork so you have your own published copy. Then you could push your modifications up to your public tree. Then you could point us at the tree along with what particular application you were building and for what platform. Seriously, what did you expect us to do with the little bit of information you gave us above. Most folks would simply ignore you. Hopefully I'm teaching you how to fish. On Tue, Dec 17, 2013 at 12:45 AM, Lin Hai lin@whu.edu.cn wrote: Hi Guys, I am new to Tinyos. I am using AMSend.send(am_addr_t addr, message_t* msg, uint8_t len) to send packet to the destination. Before sending, I use l AMPacket.setType() to set type as follows: uint8_t AMID=3; call AMPacket.setType(m_msg, AMID); But it seems the type of the packet fails to be set to 3. on the destination: call AMPacket.type(msg) The results is 123 (using %d to print it) I checked the AMPacket component. It indicates that As the AM type is set as part * of sending with the AMSend interface, this command is not used * for sending packets. Does this mean that AMPacket.setType() function can not be used? So if I want to define different types of packet, how should I do? Thanks in advance Neil Lin ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Eric B. Decker Senior (over 50 :-) Researcher ___ 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] AMPacket.setType()
Eric, stop being a grinch. Lin Hai, your conclusion is correct: you cannot set the AM type above the AM layer, because when you call Send it fills in the value. The function is there because the AM layer uses it, and more generally, so that one could do something like call AMPacket.setType(m, X); … in another, later piece of code: call AMSend.send[AMPacket.type(m)](…) Phil --- Philip Levis Associate Professor Computer Science and Electrical Engineering Stanford University http://csl.stanford.edu/~pal On Dec 17, 2013, at 1:32 AM, Eric Decker cire...@gmail.com wrote: first, get a jtag and learn to single step the code. I suspect that you have wired a hard coded am_type at a higher level. You can call AMPacket.type but it will get over written later. However, that is just a guess. It is impossible to determine what is going on from the little bit of information you've provide. Seriously, what do you want from us? How about you think to your self what would help us help you. What code base are you working on? Better would be if you are based on github://github.com/tinyos/tinyos-main and fork so you have your own published copy. Then you could push your modifications up to your public tree. Then you could point us at the tree along with what particular application you were building and for what platform. Seriously, what did you expect us to do with the little bit of information you gave us above. Most folks would simply ignore you. Hopefully I'm teaching you how to fish. On Tue, Dec 17, 2013 at 12:45 AM, Lin Hai lin@whu.edu.cn wrote: Hi Guys, I am new to Tinyos. I am using AMSend.send(am_addr_t addr, message_t* msg, uint8_t len) to send packet to the destination. Before sending, I use l AMPacket.setType() to set type as follows: uint8_t AMID=3; call AMPacket.setType(m_msg, AMID); But it seems the type of the packet fails to be set to 3. on the destination: call AMPacket.type(msg) The results is 123 (using %d to print it) I checked the AMPacket component. It indicates that As the AM type is set as part * of sending with the AMSend interface, this command is not used * for sending packets. Does this mean that AMPacket.setType() function can not be used? So if I want to define different types of packet, how should I do? Thanks in advance Neil Lin ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Eric B. Decker Senior (over 50 :-) Researcher ___ 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] Assign value to an array NesC
There should be no difference between a C for loop and a nesC one: nesC is a C
dialect. I have no idea what your problem might be; I think that's people's
concern, that the bug is actually elsewhere for some reason. Could you provide
a full file?
Phil
---
Philip Levis
Associate Professor
Computer Science and Electrical Engineering
Stanford University
http://csl.stanford.edu/~pal
On Dec 1, 2013, at 12:50 PM, nivedita datta sweetniv...@gmail.com wrote:
uint8_t i;
uint8_t in[16] =
{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00};
for (i=0; i10; i++) {
in[i] = i; }
___
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 know the cause of send failure (using AMSend)
Generally speaking, for AM, returning FAIL on send because the radio isn't on, the packet is too long, or otherwise the call can't be completed. EBUSY Is when there's already a pending packet from that AMSenderC. Passing FAIL on sendDone can happen when any of the above FAIL conditions aren't detected until the packet is dequeued from the send queue. E.g., if the radio's on, you submit a packet, it succeeds, then the radio turns off, the layer signals sendDone with FAIL as a result_t. Phil --- Philip Levis Associate Professor Computer Science and Electrical Engineering Stanford University http://csl.stanford.edu/~pal On Nov 20, 2013, at 4:48 AM, adibsairi adib_sa...@fke.utm.my wrote: Thanks for the reply Eric. If I could not get that information form the layer that I am currently are, so, where could I get this information from in TinyOS? Is it available at the MAC layer? if yes, which function/file should I looked at? Thanks.. Adib -- View this message in context: http://tinyos-help.10906.n7.nabble.com/How-to-know-the-cause-of-send-failure-using-AMSend-tp23867p23869.html Sent from the TinyOS - Help mailing list archive at Nabble.com. ___ 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] understanding if statements in tinyos
Are you allocating the packet variable in your send function on the stack or in
the component? On the stack won't work.
Phil
---
Philip Levis
Associate Professor
Computer Science and Electrical Engineering
Stanford University
http://csl.stanford.edu/~pal
On Oct 30, 2013, at 12:23 PM, Alaios ala...@yahoo.com wrote:
Hi all,
I will need some help to further understand the tinyos fundamentals. I have
written some code (after finishing the mote to radio tutorial on the official
web site)
Part of this tutorial was to create a structure for the information I would
like to send.
typedef nx_struct WirelessStruct{
nx_uint16_t id;
nx_uint16_t LedsBits;
}WirelessPkt_t;
What I send s
WirelessPkt_t* msg = (WirelessPkt_t*)(call
Packet.getPayload(packet,sizeof(WirelessPkt_t)));
msg-id = 2;
msg-LedsBits = 2;
if (call AMSend.send(AM_BROADCAST_ADDR, packet,
sizeof(WirelessPkt_t))==SUCCESS)
{
isBusy==TRUE;
}
my send is succesful as the receiver part, as the leds turn on on the
receiver mote
WirelessPkt_t* incoming=(WirelessPkt_t*)payload; // cast payload to our data
type
uint16_t data= incoming-id;
uint16_t dataTwo =incoming-LedsBits;
if (data==2 ){
printf(I RECEIVED PACKAGE AND I AM: !%d!\n,TOS_NODE_ID);
printf(data is: !%d!\n,data);
}
if though I change the data==2 to the dataTwo==2 nothing happens on the
receiver part. Can someone try to see what might be the problem here?
I would like to thank you for your help
Regards
Alex
___
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] [Tinyos-devel] jni cross-compiling
Andras, can you repost this to the github issue tracker and move the discussion there? We're trying to converge on having one place for development information/updates. Thanks! Phil On May 5, 2013, at 11:53 AM, András Bíró wrote: Hi everyone, I merged the modifications. I also added cross-compiling on windows, packaging scripts for tinyos-tools and tinyos (and fixed the msp430 packaging scripts on cygwin, but it's not related). I also generated some unofficial packages: tinyos-tools and nesc for raspberry pi armhf: https://dl.dropboxusercontent.com/u/363226/munka/packages/UNOFFICIAL_nesc_1.3.4-tinyos_armhf_rpi.deb https://dl.dropboxusercontent.com/u/363226/munka/packages/UNOFFICIAL_tinyos-tools_1.4.3-20130505_armhf_rpi.deb and tinyos-tools for cygwin (including the 64 bit JNI libs for windows): https://dl.dropboxusercontent.com/u/363226/munka/packages/UNOFFICIAL_tinyos-tools-1.4.3-20130505.cygwin.i386.rpm I tested this on cygwin and linux, it would be great, if someone could test it on Darwin (OSX). Andris P.S.: I know this discussion should be on github, but since I started here, I wanted to close here. On Sat, Apr 27, 2013 at 3:35 AM, Philip Levis p...@cs.stanford.edu wrote: Fair enough -- I suppose that warning came from back when we were manually distributing/packaging things up and wanted to keep the number of packages down. E.g., RPMs rather than debs. Phil On Apr 24, 2013, at 11:29 PM, András Bíró wrote: I don't think it's necessary. It's much simpler (and in my opinion it's even nicer) to create platform dependent packages (actually, tinyos-tools is platform dependent since about v1.4.1) Andris On Wed, Apr 24, 2013 at 11:26 PM, Philip Levis p...@cs.stanford.edu wrote: +1, with one caveat, that it doesn't lead to bad RPMs/debs being built. Adding a flag which the package tools use would be fine. Phil On Apr 24, 2013, at 4:55 AM, András Bíró wrote: Hi everyone, If someone tries to compile tinyos-tools on linux, it will try to cross-compile the jni libs to i386 and x86_64, and if it doesn't succeed, there's a lot of warning like this: 64-bit libgetenv.so NOT GENERATED - DO NOT USE THIS RUN TO BUILD AN RPM Press return to continue Does anyone have a problem if I disable this? It doesn't make much sense to create cross-platform packages, and forcing the i386/x86_64 platforms makes it quite hard to compile tinyos-tools on ARM. I'm also planing to add cross compiling commands on windows, to make it possible to use the java sdk with windows x86_64 java. Andris ___ Tinyos-devel mailing list tinyos-de...@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel ___ Tinyos-devel mailing list tinyos-de...@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel ___ Tinyos-devel mailing list tinyos-de...@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] [Tinyos-devel] Issue regarding implementation of the Link Estimator
On Aug 14, 2012, at 4:02 PM, Adrian Dudau wrote: Hi everyone, I have stumbled upon the following issue while trying to port the TinyOs Link Estimator implementation onto a different platform. In the file LinkEstimatorP.nc, there is a NeighborTable structure that holds the up-to-date link quality information to all the neighbouring nodes. This table is parsed and the corresponding eetx value is returned when the module is asked the link quality of a specific node. My issue is the following: what happens when the connection with a neighbour disappears? As the corresponding RoutingTable seems to be updated only upon receiving a message from that node (by calling updateNeighborEntryIdx() on the corresponding entry), the link information seems to stick in the table and continue to be reported to the caller even when they are not connected anymore. It seems like a too obvious flaw, so I somehow expect that I'm missing something, though I can't see it at this moment. So I appreciate someone else's view on this :) This is more a question for -help, I'm moving it there. The link estimator doesn't assume a particular beacon rate; it might receive no packets because the node has an excessively long beacon timer. The assumption is that if a node starts sending packets to the dead destination, then none of them will be acked, and these failed transmissions will then update the link estimate. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Getting MSP430 error in tinyos-2.1.1
On Aug 27, 2011, at 3:46 AM, Richard Figura wrote: Hi, is there a solution for the problem described by Shravan Kulkarni yet? I am asking because I have exactly the same problem since ~2 weeks when I installed an update through the debian repositories. Like him, I also tried to reinstall TinyOS through the repositories without any success. The cause for the error-messages he described seems to be that there is no define within (at least my) TinyOS installation for: __msp430_have_port(PORTNUMBER) for any port, but these are required by: /opt/tinyos-2.1.1/tos/chips/msp430/pins/HplMsp430GeneralIOC However there are some defines for __MSP430_HAS_PORT(PORTNUMBER) which seems to be the replacement for __msp430_have_port On my second installation of TinyOS (not yet updated) I can compile for telosb. Other than my first installation it provides a file for mapping both defines mentioned above within: /usr/msp430/include/msp430/common.h So I guess something is wrong with the new packages of the debian repository. Best Regards Richard Figura Richard, I've been able to reproduce the problem; I'll see what I can do to take care of it ASAP. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Getting MSP430 error in tinyos-2.1.1
On Aug 27, 2011, at 3:46 AM, Richard Figura wrote: Hi, is there a solution for the problem described by Shravan Kulkarni yet? I am asking because I have exactly the same problem since ~2 weeks when I installed an update through the debian repositories. Like him, I also tried to reinstall TinyOS through the repositories without any success. If you point your package manager at http://tinyos.stanford.edu/tinyos/dists/ubuntu.old You should be able to get the old msp430 packages. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Getting MSP430 error in tinyos-2.1.1
On Aug 27, 2011, at 8:45 AM, Philip Levis wrote: On Aug 27, 2011, at 3:46 AM, Richard Figura wrote: Hi, is there a solution for the problem described by Shravan Kulkarni yet? I am asking because I have exactly the same problem since ~2 weeks when I installed an update through the debian repositories. Like him, I also tried to reinstall TinyOS through the repositories without any success. If you point your package manager at http://tinyos.stanford.edu/tinyos/dists/ubuntu.old You should be able to get the old msp430 packages. Unfortunately I'm about to leave for a week of no email contact. Hopefully this should be able to get things working for you until I return. When I'm back I'll work on setting up the repository more cleanly. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] [Tinyos-2-commits] [tinyos-main] r5696 committed - Removed hardware mutliply disable option: new msp430-gcc fixes.
On Aug 23, 2011, at 2:32 AM, Michiel Konstapel wrote: How badly will this break for people who update their TinyOS checkout, but not their compiler? Michiel Generally speaking, we try to tie the source tree to a version of the compiler. Over time, little idioms work in that are intended to avoid compiler bugs/issues. E.g., I know for the old msp430 there were a couple of segments of code that had to be rewritten because the compiler was generating incorrect output (e.g., a number wasn't being added). So going forward, there's absolutely no promise that any code will continue to work with the older compiler. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] [Tinyos-2-commits] [tinyos-main] r5696 committed - Removed hardware mutliply disable option: new msp430-gcc fixes.
On Aug 23, 2011, at 2:32 AM, Michiel Konstapel wrote: How badly will this break for people who update their TinyOS checkout, but not their compiler? Michiel Sorry, I didn't answer the original question. It means the code is likely to break badly. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] MSPGCC and telosb problem
On Aug 23, 2011, at 6:59 AM, Alfonso Martinez wrote: Hi! I have been working for some time with TinyOS 2.1.1 with telosb motes without any problem, but recently I have updated the MSP430 GCC using Synaptic in Ubuntu 10.10 and when now I try to compile for example Blink it gives me a lot of errors: /tmp/ccr4C49d.o: In function `__nesc_atomic_end': app.c:(.text+0x88): undefined reference to `__eint' /tmp/ccr4C49d.o: In function `__nesc_disable_interrupt': app.c:(.text+0x8e): undefined reference to `__dint' app.c:(.text+0x92): undefined reference to `__nop' /tmp/ccr4C49d.o: In function `__nesc_atomic_start': app.c:(.text+0x9a): undefined reference to `__read_status_register' /tmp/ccr4C49d.o: In function `main': app.c:(.text+0x5ce): undefined reference to `__BCSCTL1' app.c:(.text+0x5d2): undefined reference to `__BCSCTL2' app.c:(.text+0x5d8): undefined reference to `__TBCCTL0' app.c:(.text+0x5f4): undefined reference to `__BCSCTL1' app.c:(.text+0x5fe): undefined reference to `__BCSCTL1' app.c:(.text+0x602): undefined reference to `__DCOCTL' app.c:(.text+0x60e): undefined reference to `__TBR' app.c:(.text+0x614): undefined reference to `__TBCCR0' app.c:(.text+0x618): undefined reference to `__TBCCTL0' app.c:(.text+0x61c): undefined reference to `__TBCCTL0' app.c:(.text+0x624): undefined reference to `__TAR' app.c:(.text+0x65c): undefined reference to `__BCSCTL1' app.c:(.text+0x666): undefined reference to `__BCSCTL1' app.c:(.text+0x66a): undefined reference to `__DCOCTL' app.c:(.text+0x66e): undefined reference to `__BCSCTL1' app.c:(.text+0x67a): undefined reference to `__BCSCTL1' app.c:(.text+0x67e): undefined reference to `__BCSCTL2' app.c:(.text+0x686): undefined reference to `__TAR' app.c:(.text+0x690): undefined reference to `__TBR' app.c:(.text+0x6ba): undefined reference to `__P1SEL' app.c:(.text+0x6be): undefined reference to `__P2SEL' app.c:(.text+0x6c2): undefined reference to `__P3SEL' app.c:(.text+0x6c6): undefined reference to `__P4SEL' app.c:(.text+0x6ca): undefined reference to `__P5SEL' app.c:(.text+0x6ce): undefined reference to `__P6SEL' app.c:(.text+0x6d2): undefined reference to `__P1OUT' app.c:(.text+0x6d8): undefined reference to `__P1DIR' app.c:(.text+0x6de): undefined reference to `__P2OUT' app.c:(.text+0x6e4): undefined reference to `__P2DIR' app.c:(.text+0x6e8): undefined reference to `__P3OUT' app.c:(.text+0x6ee): undefined reference to `__P3DIR' app.c:(.text+0x6f4): undefined reference to `__P4OUT' app.c:(.text+0x6fa): undefined reference to `__P4DIR' app.c:(.text+0x6fe): undefined reference to `__P5OUT' app.c:(.text+0x702): undefined reference to `__P5DIR' app.c:(.text+0x706): undefined reference to `__P6OUT' app.c:(.text+0x70a): undefined reference to `__P6DIR' app.c:(.text+0x70e): undefined reference to `__P1IE' app.c:(.text+0x712): undefined reference to `__P2IE' app.c:(.text+0x716): undefined reference to `__TAR' app.c:(.text+0x71e): undefined reference to `__TAR' app.c:(.text+0x748): undefined reference to `__nop' app.c:(.text+0x74c): undefined reference to `__nop' app.c:(.text+0x852): undefined reference to `__eint' app.c:(.text+0x882): undefined reference to `__TACCTL0' app.c:(.text+0x88c): undefined reference to `__TACCTL1' app.c:(.text+0x898): undefined reference to `__TACCTL2' app.c:(.text+0x8a4): undefined reference to `__TACTL' app.c:(.text+0x8b4): undefined reference to `__ME1' app.c:(.text+0x8ba): undefined reference to `__U0TCTL' app.c:(.text+0x8c4): undefined reference to `__ME2' app.c:(.text+0x8ce): undefined reference to `__U1TCTL' collect2: ld devolvió el estado de salida 1 make: *** [exe0] Error 1 It looks like a problem with the register library, but I don't know how to fix it. I tried to download the last version of TinyOS doing svn checkout http://tinyos-main.googlecode.com/svn/trunk/ tinyos-2.x but it continues the same. Any ideas of how to fix it? Thanks in advance! Alfonso, 1) Which version of msp430-gcc and msp430-binutils are you using? Are they the updated TinyOS packages or something from another repository? 2) Can you give an example application that causes this error? E.g., tell me how to repeat it fully? Phil ___ 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 MSP430F2617 and TestSeri
On Aug 9, 2011, at 11:29 PM, Juan Verdu wrote: Hi, I created a mote using a MSP430F2617 microcontroller with libraries of MSP430X under TinyOS 2.1, which compiling with the msp430-gcc( version 3.2.3) of the mspgcc. I made several changes in Ubuntu and TinyOS operating systems. This mote the program through a USB port using BSL pins, I used the pins VCC, GND, RST #, TCK, and RX_BSL TX_BSL (P1.1 and P2.2) of the microcontroller. With this configuration using the tos-bsl I could program the micro with applications like Blink which makes it the right way. I've also tried to interrupt the execution by pressing a button and done right. When I run the application TestSerial not done correctly, I have another mote which made by me if it does well but not the last two motes and all hardware configuration are identical in all cases. In all the motes I have another USB port to run the application using the pins VCC, GND, TX_Uart0 and RX_Uart (Pins 29 and 40 of the MSP430F2617 64-pin). I have to indicate that the mote that works well all the time I tried it with Code Composer from Texas so do not know if some registers like those were modified . Using a tool like Siow (serial) I got the following results: Mote good: 7E 45 00 FF FF 00 00 08 00 89 00 09 00 00 00 00 00 00 81 91 7E ... Motes incorrect: FE C5 00 FF FF 00 00 08 00 09 00 08 00 00 00 00 00 00 E0 69 FE ... The speed with which I use is 115200 but I have also tried other speeds. I think it's a problem of synchronizing clocks using the UART USC but I'm not sure, Could someone help me? That sounds like a likely hypothesis, due to the distribution and form the bit errors take. Do you observe a lower bit error rate at slower speeds or does it stay the same? Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Dividing a CTP network
On Jul 20, 2011, at 7:29 PM, ranal fernando wrote: sorry for multiple mails. does anyone have any idea? at least about the feasibility of this? i thought of having some feedback from the community. Thanks. From: ranalferna...@live.com To: tinyos-help@millennium.berkeley.edu Date: Tue, 19 Jul 2011 19:48:29 -0400 Subject: [Tinyos-help] Dividing a CTP network Dear all, For my project i'm have to divide a ctp based network into two then connect them through an IP link. So the root will be in one part of the network. i'm going to send routing table information between the gateways using the IP link. Can you give me some suggestions about the feasibility of this? What type of a performance penalty will I have to pay for this? Why would you pay a performance penalty? I'm assuming that one node using the IP link will advertise itself as a child of the other (e.g., you model the IP link as a hop of low cost). To some degree, it's as if you set up another CTP tree whose root advertises a non-zero cost. The two major differences in behavior would stem from the fact that its cost is variable (so more loops are possible) and the CTP hysteresis value for link change being a constant (15) means high cost routes are more free to change next the next hop. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Permission denied on wiki documentation
On Jul 13, 2011, at 5:44 AM, Romain Bornet wrote: It is even worse than just the docs... Even the www.tinyos.net homepage is unreachable... Hope this will be fixed quickly. Regards Romain I'll take a look. This stuff is on a Berkeley server. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Path Loss Model for network topology in tossim
On Jul 1, 2011, at 9:31 PM, vinod kumar wrote: What are the sample values present in meyer-heavy.txt present in tos/lib/noise ?? Are they some sample gain values? In the topology.txt, the pattern is something like 1 2 -87 which mean signal sent by 1 , received by 2 with gain -87. meyer-heavy.txt are 1KHz samples taken of environmental interference. Please see: HyungJune Lee, Alberto Cerpa, and Philip Levis. Improving Wireless Simulation Through Noise Modeling. In Proceedings of the Sixth International Conference on Information Processing in Wireless Sensor Networks (IPSN), 2007. Are these values present inside topology.txt randomly generated? And the link is made between the nodes whose pattern is found inside this toplogy.txt as we have a link between '1' and '2' in the above case. But somebody told me that link is formed between nodes whose gain value is greater than some specific value. But the code below present in tutorial says that link is formed for all the patterns present in topology.txt file . f = open(topo.txt, r) lines = f.readlines() for line in lines: ... s = line.split() ... if (len(s) 0): ... print , s[0], , s[1], , s[2]; ... r.add(int(s[0]), int(s[1]), float(s[2])) The path loss equation is : Log-distance path loss model is formally expressed as: Path loss models are insufficient to model a wireless network for reasonable testing purposes. The topology files incorporate a path loss model as well as hardware covariance, based on Zuniga's work. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Stanford Ubuntu TinyOS Tools repo down
On May 6, 2011, at 8:30 PM, Eric Decker wrote: The Stanford repository has been down for at least two days. Not sure what is going on. Have tried to communicate with the folks in charge. In the meantime, a few of us have collaborated to bring up a mirror at John Hopkins. Try deb http://hinrg.cs.jhu.edu/tinyos karmic main Funny -- when I saw the original message I tested the repository myself and was able to access it with no problem, so assumed it was a momentary glitch. I admittedly tried only from a machine inside Stanford, but given the error message didn't think this should have changed anything. Sorry for the disruption. Eric -- your message on the 4th went into my -help folder (because of the subject line) which is why I didn't see it immediately. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP with Multiple Roots
On Mar 21, 2011, at 1:57 AM, wasif masood wrote: Hi all, Can someone tell me whether CTP can maintain multiple roots in its current implementation? BR, Wasif Masood Yes. A node will automatically choose to route towards the root that has the lowest cost path. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Reg:TOSSIM error
On Mar 21, 2011, at 2:27 AM, SHIVASANKAR GANESAN wrote: Hi While giving make micaz sim in TinyOS 2, It is showing error in tossim_wrap.cxx file. How to fix it. My error similar to http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg35373.html And How to check python version. python --version Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CC2420 bug: initial ACK transmission power not set correctly
On Mar 17, 2011, at 3:26 AM, tja...@mail.tu-berlin.de wrote:
Hello,
I think I have found a bug in the cc2420 stack concerning the
transmission power of the acknowledgements. Maybe someone can verify
it? I don?t know who is responsible for the stack at the moment. Is it
still David?
I am using the svn revision 5304 on the cc2420 folder.
In my setup a telosb node is continuously sending packets, requests an
ack and prints the rssi value of the ack. Another node is receiving
and prints out the rssi value of the received packet.
The problem occurs when I reduce the transmission power by setting
CFLAGS += -DCC2420_DEF_RFPOWER=1. The rssi of the acknowledgement
equals the transmission power of power level 31 and not the rssi of
the received packet.
It seems that the initial transmission power for the receiving node
was not set to DCC2420_DEF_RFPOWER. It looks like this should be done
by CC2420Control.Init.
For the maximum transmission power the rssi values of the ack and
received packet equals. The behavior occurs for SACK and HACK.
I found out, that I can fix the problem by the transmission of one
packet on the receiving node. It seems like after the SoftwareInit the
radio chip resets once more or the CC2420Config.sync() will never be
called to commit changes to TXCTRL.
Best regards,
Tobias
Some code snippets:
event void RadioControl.startDone(error_t err){
if (err == SUCCESS){
call CC2420Config.setAutoAck(1,0); //enable auto-sw-acks
call CC2420Config.sync();
}
else {
call RadioControl.start();
}
}
event void CC2420Config.syncDone(error_t error){
if (error == SUCCESS){
call Timer1.startPeriodic(600); //after 2s
}
else{
call CC2420Config.setAutoAck(1,0); //enable auto-sw-acks
call CC2420Config.sync();
}
}
event void Timer1.fired(){
am_addr_t dest = 1;
test_pkt_t* pkt = call
RadioSend.getPayload(radio_pkt,sizeof(test_pkt_t));
seqno++;
pkt-seqno = seqno;
call Acks.requestAck(radio_pkt);
call RadioSend.send(dest,radio_pkt,sizeof(test_pkt_t));
}
event void RadioSend.sendDone(message_t* msg, error_t err){
if (msg==radio_pkt err==SUCCESS){
if (call Acks.wasAcked(msg)){
printf(ACK received seqno:%u rssi:%02d\n \n,seqno, call
CC2420Packet.getRssi(msg)-45);
}
else {
printf(Packet LOST seqno:%u \n,seqno);
}
}
printfflush();
}
event message_t* RadioReceive.receive(message_t* msg, void*
payload, uint8_t len){
test_pkt_t* pkt = payload;
printf(RECEIVED seqno:%u rssi:%02d\n \n,pkt-seqno, call
CC2420Packet.getRssi(msg)-45);
printfflush();
return msg;
}
I've checked in a fix which I tested and updated the issue on Google Code. If
you could verify that the fix works for you I'll close the issue.
Phil
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CC2420 bug: initial ACK transmission power not set correctly
On Mar 17, 2011, at 3:26 AM, tja...@mail.tu-berlin.de wrote: Hello, I think I have found a bug in the cc2420 stack concerning the transmission power of the acknowledgements. Maybe someone can verify it? I don?t know who is responsible for the stack at the moment. Is it still David? I am using the svn revision 5304 on the cc2420 folder. In my setup a telosb node is continuously sending packets, requests an ack and prints the rssi value of the ack. Another node is receiving and prints out the rssi value of the received packet. The problem occurs when I reduce the transmission power by setting CFLAGS += -DCC2420_DEF_RFPOWER=1. The rssi of the acknowledgement equals the transmission power of power level 31 and not the rssi of the received packet. It seems that the initial transmission power for the receiving node was not set to DCC2420_DEF_RFPOWER. It looks like this should be done by CC2420Control.Init. For the maximum transmission power the rssi values of the ack and received packet equals. The behavior occurs for SACK and HACK. Can you enter this as an issue in Google Code? Thanks! Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Data-race detection
On Mar 17, 2011, at 12:18 PM, Francisco Sant'anna wrote:
Hello,
I cannot make nesC to detect potential race conditions in my programs.
For example, I can see in the compiler output the flag -Wnesc-data-race but
no data race is detected for following code snippet:
implementation
{
int my_global_var;
event void Boot.booted () {
call Timer.startPeriodic(10);
call AMControl.start();
}
event void Timer.fired () {
my_global_var = 1;
}
event void AMControl.startDone (error_t err) {
my_global_var = 1;
}
}
Am I missing something obvious here?
I am using TinyOS 2.1.1.
Yes. All of those events are synchronous code: they can't preempt one another.
So there's no way for there to be a data race.
Phil
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Timer failure related to program size
On Mar 18, 2011, at 10:08 AM, Joe Dvorak wrote: Hello, I ran into a problem where the timer fails to fire based on the size of variables defined in my program. The program has several timers and data arrays to store the results before transmitting. My program runs great with data arrays of a certain size, but an increase of just a few extra bytes causes the timers to stop working. There is no error while compiling. I have to download to the mote to test this behavior. With data arrays of 688 samples, the program runs normally. With data arrays of 692 samples, the program downloads, starts, and StdControl.init() and StdControl.start() both run. However, the timer that is started in these functions never fires and the mote does nothing further. To cause this behavior, I only change the length of the data arrays. I am using a micaz mote with an MDA300 sensorboard from Crossbow/Memsic for sampling. The program is based on the XSensorMDA300 program that is in the …/contrib/xbow/apps/XSensorMDA300 directory of Tinyos 1.1. The program is compiled for Tinyos 1.1. Size results for a working program: ROM: 19378 RAM: 4053 Size results for a non-working program: ROM: 19378 RAM: 4069 Any help or insight into the problem would be greatly appreciated. I would like to understand the issue better so I can determine the best way to work around the issue. The device has 4092 bytes of RAM. With the larger variables your programs writes to them is corrupting the stack, which shares that 4092 bytes with your data. Phil ___ 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 regulate the transmit power of a Sentilla JCreate Perk mote.
On Mar 16, 2011, at 9:30 AM, raffaele di bari wrote: Thanks Sergio, But I dont run the TinyOS. I use the Sentilla Jcreate APIs in Java... Raffaele Well, this is the tinyos-help list... Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] MicaZ Responses
On Mar 15, 2011, at 12:00 PM, Breno Guimarães wrote: Hi, I'm working with MicaZ motes on TinyOS 2.0.1. My application is simple. I have one mote sending a broadcast message and other two responding to the first whenever they receive any message. Therefore, the first mote receive two messages almost at the same time. When running on TOSSIM, I noticed that they respond exactly at the same time. As the first mote can't receive two messages at the same time, it drops one of the messages. I solved this problem by using a timer on each mote that acts as a clock. The clock frequency is calculated using the node ID number, so every mote respond with different times. That works very well on the simulation and there was no problem when I tried on real motes. But that seems a poor solution as it is made on software. My question is: Is there any hardware that avoid that kind of problem on micaz? If there isn't, is there any other better software solution? You're basically introducing time slots at a higher layer. That's a reasonable approach although it has limitations with respect to how many nodes it can support. Another approach is to just try retransmitting failed packets. The TinyOS MAC is such that if there are only 2 nodes it should not take more than a handful of retransmissions in the absolute worst case (unless you are sending very long packets). Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP timeout-related questions
On Mar 7, 2011, at 2:02 AM, David wrote: Hi there, I've started using CTP+LPL in a project (thanks for the earlier suggestion), and have a few questions about the network behavior when the basestation mote is offline/unavailable. (in this mail, I assume a very basic setup, where the motes can normally all reach the basestation directly over CTP). Also, I'm using the official TinyOS 2.1.1 release, installed from the deb files. Basically I have these queries: 1. CTP send timeout length: If you send a packet over CTP, but the basestation is off, the sent event never seems to fire (even with an error/timeout code). Or rather, sometimes it does, but not other times. Will the send eventually timeout, or will the mote eternally be in a trying to send state, without calling any event code in the app? If there is an eventual send timeout, then how long is it, and where can it be configured? There will be an eventual send timeout. But it might take a long, long time. With LPL, each packet transmission can take a while. And by default CTP can retransmit a packet up to 32 times. 2. Cancelling CTP send: If for instance you're trying to send data over CTP from sensors, but your data is out of date (basestation off for a long time), or your sensor changes it's mind about wanting to send - is there a way to cancel an existing in progress send? I don't see an interface for this. Would stopping and starting the radio, and the collect engines achieve the same thing? (at the moment: I'm assuming that if the mote has been offline for a long time, that the first received packet's sensor data should be ignored, due to likely being very out of date). Send has a cancel command. Take a look at the interface. 3. Updating the packet being sent. Alternately - if the CTP algorithm is taking a long time to send the packet (basestation is off for a long time), is it safe to update the not-yet-sent payload with newer details? (probably not safe, but just checking). No. It's probably already loaded in the radio, so changing it in memory won't matter. 4. Time for CTP network to re-establish. If the motes are unable to contact the basestation for a long time (eg: hours/days), but then later the basestation becomes available - then how long typically would it take for the network to re-establish, and for data to start coming through from the sensors? That is a great question: we've definitely tested starting a mote fresh, but if it was disconnected for a long time (the link was bad), it make take a while for the link estimate to come down to a point where the node might use it. It in part also depends on whether there are other nodes: the disconnected node might be creating routing loops, desperately searching for a route to the root. In that case it might take a while. This seems like a good test case to try sometime and make sure CTP handles well. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] about receiveMsg.receive() and send.sendDone()
On Mar 3, 2011, at 10:51 PM, xi xu wrote: hi, all I've been working on a problem under TOSSIM for a long time. I found that when I call Queuesend.send() and it did give a successful return of Queuesend.sendDone(), but sometimes the receive.receive() doesn't receive any packet it still give a succeesfull sendDone return. What could be the problem inside? Please read the documentation or check the mailing list archives. A SUCCESS on sendDone means the packet was sent successfully, not that it was received successfully. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] tmote sky power consumption
On Mar 1, 2011, at 2:58 PM, Bach wrote: Hello, I just did a simple experiment of the tmote sky, or telosB, to measure its current consumption when the radio transmission power is set at different level. I changed the makefile CFLASS += -DCC2420 DEF RFPOWER” to different value and did observe the change in communication range, which means the transmission power was changed. However, the total current consumptions were almost the same (both around 18mA). (The way I measure the current is by cascading a small resistor to the power supply (10 ohm). ) What is your sampling frequency? You might just be observing the receive power draw, which is independent of transmit power, or the sum of receive and transmit, with transmit being a very small fraction (spending most time in receive). Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] ip-driver issues in daemon mode
On Feb 26, 2011, at 10:45 AM, Harsha Chenji wrote: Hello all, I am trying to get ip-driver working in daemon mode on a router. However, when I issue the ./ip-driver command, the process always backgrounds itself. The token in a shell backgrounds a process. Only when I type fg does the process become active again. This happens on a PC also. That is usually how shells work. Has anyone gotten ip-driver to work successfully as a daemon? It should ideally not require an active console to do its work. There are tools to take programs and have them act as daemons: this is generally better than working that logic into every program. E.g., the daemon program. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] TinyOS Question
On Feb 14, 2011, at 2:56 AM, aca...@correo.ugr.es wrote: Good morning, I have problems when I try to make work the TestSerial (Lesson 4) I have the same error written in this link: https://www.millennium.berkeley.edu/pipermail/tinyos-help/2010-July/047030.html Please, would you tell me what is the manner to solve it? Thanks a lot. Greetings, Alejandro Cama. You have a java classpath problem: Java cannot find the necessary files. It's not possible to say how to fix it without knowing lots of details about your setup; I'd suggest figuring out how classpath works and then it should be easy for you to solve yourself. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP adaptive beaconing
On Feb 4, 2011, at 9:35 AM, Xiaohui Liu wrote: Hi, I think there is a mistake in my previous email, t should be within [currentInterval / 2, currentInterval], sorry about that. But I'm still not sure What tHasPassed means. Can anyone helps with that? Trickle picks a time t in the range of [tau/2,tau). The tHasPassed flag keeps track of whether Trickle is before or after this time t. This allows you to use one timer, set to t, then tau-t, rather than 2 times, for t and tau. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Conflict Between CC2420 Radio and I2C on Epic Platform
On Jan 31, 2011, at 2:15 PM, Brad Campbell wrote: SOLUTION: I figured out a method for making the I2C work after SPI has been used. I had to set the I2CTCTL register to 0x01 before configuring it properly. Here is my svn diff for the change: Can you add this as an issue on Google Code? Thanks! Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] TinyOS repository at sourceforge down.
Contrib is still hosted on Sourceforge, as they allow a project to have multiple licenses. Phil On Feb 1, 2011, at 6:19 PM, Eric Decker wrote: The CVS repository is deprecated. The current TinyOS 2.1.1 trunk is over at TinyOS Repo (Google Code via svn). It includes all the old code too. Do you really want the old repository? On Tue, Feb 1, 2011 at 3:12 AM, Declan Delaney declan.dela...@gmail.com wrote: Hi!! I cant see any previous mail on the list regarding this. The TinyOS repository at sourceforge seems to be down at the moment. http://tinyos.cvs.sourceforge.net/tinyos This is a recent issue as I was able to access on the 21st Jan. Does anyone know if there is specific reason why the repository is down, or is this some fault. Thanks, Dec ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Eric B. Decker Senior (over 50 :-) Researcher ___ 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] TinyOS repository at sourceforge down.
On Feb 2, 2011, at 1:44 AM, Declan Delaney wrote: Thanks guys, I was looking for Tinyos 2.1.0 for compatibility with some of the contrib work. Ive noticed that the contrib repo on google is empty: TinyOS-Contrib Repo. Is the sourceforge repo still maintained for contrib code, or will all new contributions be added to the Google Code contrib repo. Is the transferring of old contrib code a licence issue, or an issue of some other kind? Will old contrib code be transferred to Google Code also? Contrib is going to remain on sourceforge, for licensing reasons. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Howto use wait in tossim..
No -- as execution in TOSSIM is instantaneous (code runs infinitely fast) there is no way to have a busy wait. E.g., if you waited for 10s, then somehow the simulation would need to move forward 10 seconds even though lots of other things would happen in the meantime. This would require multithreading in the simulator. Phil On Feb 2, 2011, at 8:30 AM, Giuseppe Barbieri wrote: I did the following: ... interface BusyWaitTMilli,uint16_t; ... ... components new BusyWaitCounterC(TMilli, uint16_t); ... ... App.BusyWait-BusyWaitCounterC; BusyWaitCounterC.Counter-CounterMilli16C; ... But when I try to compile : make micaz sim : cannot find `CounterMilli16C' make: *** [sim-exe] Error 1 TinyOs 2.1.1 on Ubuntu 10.04 64bit I know that CounterMilli16C comes from msp4, but is there a way to use it in tossim? Giuseppe ___ 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] Compile Problem - Configuration File Being Ignored
On Jan 28, 2011, at 6:38 AM, Scott Corbin wrote: Hello, I am having a compiler problem that I’m hoping someone can shed some light on. I have a configuration file that doesn’t appear to be getting included in the build. This configuration file is in the same directory as a module file that is getting included in the build. I know the module is being included in the build because the compiler is complaining that some items are “not connected”. These “not connected” items have connections spelled out in the configuration file. I can create syntax errors in the configuration file that would normally cause the compiler to throw a fit, but not in this case. The names of the module and configuration files are HPLUSART1M.nc and HPLUSART1C.nc so they are valid file names (the compiler appears to ignore files with extensions it does not use such as .txt). These files do not exist anywhere else in the directory structure. Note, I am new to TinyOS and the XubunTOS development environment. Any idea what is going wrong? Thanks, Scott There are existing files with those names, and those existing files appear earlier in the search path? I.e., your files are being shadowed? Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Micaz smallest sending rate
On Jan 18, 2011, at 2:44 PM, Jimmy wrote: Hi, Currently I have a question of Micaz smallest sending rate. When I specified the packet size as 90 bytes and packet interval as 20 ms, I checked the received sequence id and found nearly only half of the transmitted packets were received. But when I decreased the packet size to 80 bytes, or increased packet interval to 25 ms, all packets were received. I was a little confused about this because I don't think the packet transmission was saturated at this stage. One explanation I can think of is maybe the Micaz hardware processing speed is not able to handle this much traffic. I wonder whether anybody else encountered similar situation as mine. Or what's your fastest sending rate when programming on Micaz. When I specified packet size as 20 bytes, the packet interval can be set as around 6ms. FYI, I use the timer function to trigger a packet transmission. Thanks for any suggestions. Jimmy, Have checked whether the send calls are failing (i.e., with 90 byte packets you call send again before sendDone is signaled)? I'd first check the sending side. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Installation on Debian from official .deb packages a mess?
On Jan 11, 2011, at 1:35 AM, Nicos Gollan wrote: Hi, First, there are file conflicts with distribution packages: * gcc-avr * avrdude * binutils-avr Those are required by some packages in the TinyOS repository, instead of the *-tinyos packages. So that requires quite a bit of manual interaction, and likely breaks things because you're now dealign with a mix of distribtion- and tos-packages. Can you send me (and Razvan cc'd), a more detailed report of the conflicts so we can sort them out? Turns out it was an issue with my own tinyos packages which had version 2.1.0-3 and thus superceded a bunch of packages from the repository. At least on Debian, TinyOS seems to run fine with the distribution packages of gcc-avr and binutils-avr by the way. Sorry for that :-/ Nicos No worries -- false positive alarms are better than things not working and nobody knowing. :) Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Installation on Debian from official .deb packages a mess?
On Jan 10, 2011, at 2:19 AM, Nicos Gollan wrote: Hi, I just went through the installation of 2.1.1 as described on the Wiki on a Debian system (tracking unstable). First, there are file conflicts with distribution packages: * gcc-avr * avrdude * binutils-avr Those are required by some packages in the TinyOS repository, instead of the *-tinyos packages. So that requires quite a bit of manual interaction, and likely breaks things because you're now dealign with a mix of distribtion- and tos-packages. Can you send me (and Razvan cc'd), a more detailed report of the conflicts so we can sort them out? Second, the provided nesc package does not provide an ncc binary. After trying to work around that by symlinking ncc-nescc, and sourcing the settings script, trying to run make micaz in the Blink app fails: ncc is provided by the tinyos tools package; it's a script that invokes the nesc compiler (nescc/nesc1) properly for TinyOS. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] regarding inyos
On Dec 24, 2010, at 2:56 AM, saran malar wrote: Hi. i am doing my project in tinyos. can anyone help in formation of tree for data gathering using tinyos.Please give me idea since i am starting from scratch..? http://sing.stanford.edu/gnawali/ctp/ Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP not reporting NET_C_FE_DST_MSG and NET_C_TREE_RCV_BEACON
On Nov 17, 2010, at 8:36 PM, Morten Tranberg Hansen wrote: I argue that the application, which is signaled receive from the ctp forwarding engine, should not necessarily have to tell anybody that it received this event, and hence CTP should debug the NET_C_FE_DST_MSG. In case the application, whichever one is used, decides to report the receive event (this is application dependent), one of the two reports is redundant. I just think its wrong to assume that all applications report the receive event signaled from the ctp forwarding engine. I feel like we're talking in circles, or completely misunderstanding each other. The application doesn't need to report the event. If a node is a root and receives a packet to forward, it signals receive(). Correspondingly, if you see a NET_C_FE_RCV_MSG event, and a node is a root, Receive.receive will be signaled. For a root, you would always see RCV_MSG log message followed by the receive event log message. Or is your concern the max payload length test? Whether or not this reaches an application (the app has wired to the particular receive event ID) is a wholly separate concern. E.g., it could be that the application does not handle that CTP data type. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP not reporting NET_C_FE_DST_MSG and NET_C_TREE_RCV_BEACON
On Nov 17, 2010, at 4:45 PM, Morten Tranberg Hansen wrote: Hi Om, I've always wondered why CTP does not report arrived messages and received beacons. Over time I've found these events very useful when debugging CTP. Is there a reason for not reporting these events? If not, see proposed changes below. It does not log receive() for data messages because the event is redundant: if the node is a root and receives a data packet, it signals receive(). It does not log received beacons because, in dense networks, received beacon events can overload the logging system's throughput and lead to lots of lost log messages. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP not reporting NET_C_FE_DST_MSG and NET_C_TREE_RCV_BEACON
On Nov 17, 2010, at 5:34 PM, Morten Tranberg Hansen wrote: Thats what I thought were the arguments. Personally I like to debug CTP independent of the application, and hence find the arrived event useful, Why is the current logic for receive() dependent on the application? and for debugging purposes and less dense networks I still argue that the receive beacon is useful. Maybe these could be added optionally with an ifdef? Generally, we try to avoid ifdefs: Om, what do you think? Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP not reporting NET_C_FE_DST_MSG and NET_C_TREE_RCV_BEACON
On Nov 17, 2010, at 6:38 PM, Morten Tranberg Hansen wrote: On Thu, Nov 18, 2010 at 12:00 PM, Philip Levis p...@cs.stanford.edu wrote: Why is the current logic for receive() dependent on the application? The application would either have to send the NET_C_FE_DST_MSG event through the CollectionDebug interface or report the reception of a data packet in some other way. With the first choice a processing script for collection debug messages would only need to worry about the predefined collection debug message types, and not some arbitrary data message. I guess this is why I'm confused. If a root node receives a packet for forwarding, it signals reception. Therefore, if a root node receives a packet for forwarding, you implicitly know it signaled receive(). In terms of the log, you'd always see the two paired together, and so the latter is redundant. Or is there a case I'm missing? Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP: ETX values vs. LPL wake-up interval
I don't think this quite answers my question: it was whether, on using setLocalWakeupInterval(), you see a change in PRR on simple AM transmissions. I.e., is this a general link layer issue, or an interaction between the link layer and CTP? My guess is that it is the former, but evidence would help. Phil On Nov 16, 2010, at 9:55 PM, Manjunath Doddavenkatappa wrote: Dear Sir, The problem and its cause can be summarized as follows. In the case of CTP, I guess it is required to set LPL variables (local and remote sleep intervals) from the Makefile. Otherwise, I guess no preamble is sent before transmitting routing beacons thus resulting in unexpected behavior. Instead of defining LPL variables in the Makefile, I was using LowPowerListeniing interface to set LPL variables from the application. The interface allows to set local sleep interval, and remote wake-up interval for only the data packets that I send from the application and this does not have any effect on beacon transmission. As you suggested, I tested without CTP, program works without any problems in both the cases of on setting LPL variables from the Makefile and application. As no routing beacons are involved, behavior is independent of the location from where I set LPL variables. Please correct me if my understanding is wrong. Further, what is the reason for not having the LPL to use default preamble length for outgoing packets based on local sleep interval (that is set using the command setLocalWakeupInterval()). I understand that the command setRemoteWakeupInterval allows to handle different sleep intervals. But is is typical to have different schedules for different nodes ? and moreover, this requires every forwarder to know the sleep interval of its next hop. Thanking you, D. Manjunath *** On Mon, 15 Nov 2010, Philip Levis wrote: On Nov 7, 2010, at 3:40 AM, Manjunath Doddavenkatappa wrote: Dear Dr. Gnawali, Sorry to get back to you so late, we had a paper deadline. Everything works fine if I set LPL variables from the Makefile as in TestNetworkLpl. Problems arise only on trying to set LPL variables from the program using setLocalWakeupInterval(). Just to verify in the later case, I retrived sleep interval value using getLocalWakeupInterval(), the returned value is consistent with what I set it to. Manjunath D Here's a simpler question: outside of CTP, is there a relationship between the LPL interval and a link's packet reception ratio? I.e., if you send unicast LPL messages to a destination, do you see that increasing the LPL interval decreases the PRR? Note that CTP is often going to be using borderline links that are near the SNR/PRR threshold. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] LinkLayerModel (TinyOS2 TOSSIM)
On Nov 16, 2010, at 9:29 AM, Pedro Nunes wrote: I'm facing this same problem. Does anyone have a solution for this (i.e. a configuration file for MICAz nodes)? Thank you in advance. Regards, Pedro Nunes TOSSIM is intended mostly as a debugging tool, not a tool for evaluation. Results purely from TOSSIM without validation on real networks are basically useless, and I think it's good to keep it that way. Let's not revisit the wireless ns2 research mistakes of the past decade. There are enough large, publicly available testbeds out there that there's no excuse for not using one. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] [Info] A complete Imote2 installation programming guide on Ubuntu
Given that docs.tinyos.net is a wiki, it might be helpful to put your web page up there: this means it will persist after you graduate from Purdue. Phil On Oct 25, 2010, at 9:54 AM, Paul Joonhwa Shin wrote: Hello, I am a PhD student at Purdue. I just want to contribute to this community with my hands-on experience for imote2 installation programming. After struggling a month or so, I could finally set up all environments for Imote2 programming on Ubuntu 10.04. Although I found more than ten web pages, describing their successful configuration and installation procedures, they are missing some problem cases that I encountered. So I made a web page that contains my experience and my own procedures that worked on Ubuntu 10.04. Of course, most of them are from other existing sources but I also include things that I have never found on the web including this community. In addition, I just collected useful resources from other web pages. So you could browse almost all available sources on a single page. I of course put where they are from. I hope it would be useful for newbies like whom I was. Paul's Guide: http://web.ics.purdue.edu/~paulshin/research_Imote2.html Thanks, Paul Joonhwa Shin -- -- Paul J. Shin (Joonhwa Shin) Graduate Research Assistant Robot Vision Lab School of Electrical and Computer Engineering Purdue University Those who are wise will shine like the brightness of the heavens, and those who lead many to righteousness like the stars for ever and ever. - DAN 12:3 == ___ 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] CTP: ETX values vs. LPL wake-up interval
On Nov 7, 2010, at 3:40 AM, Manjunath Doddavenkatappa wrote: Dear Dr. Gnawali, Sorry to get back to you so late, we had a paper deadline. Everything works fine if I set LPL variables from the Makefile as in TestNetworkLpl. Problems arise only on trying to set LPL variables from the program using setLocalWakeupInterval(). Just to verify in the later case, I retrived sleep interval value using getLocalWakeupInterval(), the returned value is consistent with what I set it to. Manjunath D Here's a simpler question: outside of CTP, is there a relationship between the LPL interval and a link's packet reception ratio? I.e., if you send unicast LPL messages to a destination, do you see that increasing the LPL interval decreases the PRR? Note that CTP is often going to be using borderline links that are near the SNR/PRR threshold. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP neighbor eviction procedure
On Nov 1, 2010, at 2:03 PM, Omprakash Gnawali wrote: On Mon, Nov 1, 2010 at 2:52 AM, wasif masood rwmas...@gmail.com wrote: Yes, I think it would be troublesome if one neighbor completely vanishes from the vicinity of a node because in that case node will always be transmitting 3 byte additional overhead in terms of the reverse link neighbour quality. Good point! If you want to fix that, you should expire the entry after a certain number of maximum Trickle intervals. I don't know how big of a problem this is so I am not convinced yet if we should make this change. In a network with sufficient density, the dead neighbor should be replace by a not-dead one. So the question is whether the (tiny) energy savings are worth the increase in code size to handle this edge case. My guess is no. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP: CtpForwardingEngineP component error
On Nov 1, 2010, at 6:46 PM, Dongyu Yang wrote:
Hello!
The return value is EBUSY. The AM layer do not promise signal
AMSend.sendDone
event, if the return value is not SUCCESS when call AMSend.send().
Because in the component AMQueueImplP, when call Send.send() it may
return
EBUSY in two place, as show below:
generic module AMQueueImplP(int numClients) @safe() {
provides interface Send[uint8_t client];
uses{
interface AMSend[am_id_t id];
interface AMPacket;
interface Packet;
}
}implementation {
..
command error_t Send.send[uint8_t clientId](message_t* msg, uint8_t
len) {
if (clientId = numClients) {
return FAIL;
}
if (queue[clientId].msg != NULL) {
return EBUSY; //
.(1)
}
dbg(AMQueue, AMQueue: request to send from %hhu (%p): passed
checks\n, clientId, msg);
queue[clientId].msg = msg;
call Packet.setPayloadLength(msg, len);
if (current = numClients) { // queue empty
error_t err;
am_id_t amId = call AMPacket.type(msg);
am_addr_t dest = call AMPacket.destination(msg);
dbg(AMQueue, %s: request to send from %hhu (%p): queue
empty\n, __FUNCTION__, clientId, msg);
current = clientId;
err = call AMSend.send[amId](dest, msg,
len);//.(2)
if (err != SUCCESS) {
dbg(AMQueue, %s: underlying send failed.\n,
__FUNCTION__);
current = numClients;
queue[clientId].msg = NULL;
}
return err;
}
else {
dbg(AMQueue, AMQueue: request to send from %hhu (%p):
queue not empty\n, clientId, msg);
}
return SUCCESS;
}
..
}
If the EBUSY is returned from (1), it is OK, and the Send.sendDone event
will be
signaled for the client who call it later; but if the EBUSY is returned from
(2), the
problem arise, it do not signal the Send.sendDone event for the client who
call it, but
it will only signal the Send.sendDone event for another client whose AM ID is
different
from the current client later.
I find this phenomenon arises when the EBUSY value return from (2). So it
may be
the component AMQueueImplP have some problem, it can not guarantee the same
semantic for the EBUSY.
Best regards!
Except that EBUSY should never be returned in this case. EBUSY is only for when
the AM layer is already sending a packet. If you're getting an EBUSY in (2),
this implies a component is *not* going through the AM queue and instead
directly accessing the active message layer: this breaks the queue's semantics
and implementation.
Can you determine why the active message layer is returning EBUSY?
Phil
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] TinyOS vs Contiki
On Nov 15, 2010, at 10:45 AM, Jose Araujo wrote: Hi, There is a course going on at KTH, sweden on Sensor Networks given by Adam Dunkels, Luca Mottola and Olaf Landsiedel, with some good info on the OSs for WSNs. In my opinion, if you plan to do hardware implementations with the motes use TinyOS since the documentation for TinyOS is much nicer. Contiki as a fantastic simulator that TinyOS doesnt have. http://www.ee.kth.se/~oland/teaching/wsn2010/index.html I saw Adam demo Cooja at SenSys this year, showing how it can take mote binaries (including TinyOS). It definitely seemed like a super-useful tool. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Damaged IEEE 802.15.4 header in TinyOS 2.x
On Oct 20, 2010, at 12:41 PM, Jan Bauer wrote: Hi all, since I've updated my TinyOS version from 2.1.1 to the newest SVN version, I've got problems with decoding transmitted packets in wireshark (using the Jackdaw RZUSBStick). For example, I've captured these two Drip/Deluge-Hello-Packets below. The first was sent from a TelosB mote running TinyOS 2.1.1 and the second from the same mote running the current version of TinyOS. 1) IEEE Header: | Payload| IEEE FCS Flags SN PANID DA SA | AMType Drip/Deluge Hello | 4188 01 2200 beef | 3f60 de00 | a7ef 2) IEEE Header: | Payload| IEEE FCS Flags SN PANID | | 4100 01 2200 | 3fff beef 0060 de00 | e478 As far as I know, the second byte 00 of the IEEE flags in TinyOS 2.x is not consistent with the IEEE 802.15.4 standard. Besides, this byten is the reason of interpreting all bytes between PANID and FCS as payload. But there are more inconsistencies. Any ideas what's wrong here? It looks like there were some checkins to CC2420CsmaP.nc which, among other things, don't always compile. I'll try to take a look. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Damaged IEEE 802.15.4 header in TinyOS 2.x
Stephen, I think you broke CC2420CsmaP.nc on r5174. In particular, the setting of the FCF. Can you please check that it still works with regular AM packets. Also, the current code is such that if you compile with HW security support it won't compile. Phil On Oct 20, 2010, at 12:41 PM, Jan Bauer wrote: Hi all, since I've updated my TinyOS version from 2.1.1 to the newest SVN version, I've got problems with decoding transmitted packets in wireshark (using the Jackdaw RZUSBStick). For example, I've captured these two Drip/Deluge-Hello-Packets below. The first was sent from a TelosB mote running TinyOS 2.1.1 and the second from the same mote running the current version of TinyOS. 1) IEEE Header: | Payload| IEEE FCS Flags SN PANID DA SA | AMType Drip/Deluge Hello | 4188 01 2200 beef | 3f60 de00 | a7ef 2) IEEE Header: | Payload| IEEE FCS Flags SN PANID | | 4100 01 2200 | 3fff beef 0060 de00 | e478 As far as I know, the second byte 00 of the IEEE flags in TinyOS 2.x is not consistent with the IEEE 802.15.4 standard. Besides, this byte is the reason of interpreting all bytes between PANID and FCS as payload. But there are more inconsistencies. Any ideas what's wrong here? Thanks in advance! Best regards, Jan ___ 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] SerialP problems under heavy load....
On Oct 14, 2010, at 9:44 AM, Philip Levis wrote:
On Sep 19, 2010, at 1:27 AM, Eric Decker wrote:
I'm pretty sure the following is a problem under heavy receive loads on the
serial link. This is especially true for high baud rates that have
interarrival character times that are quite small.
Eric,
Can you test that this patch works:
===
--- SerialP.nc(revision 5198)
+++ SerialP.nc(working copy)
@@ -445,9 +445,15 @@
if (isDelimeter) { /* handle end of frame */
if (rxByteCnt = 2) {
if (rx_current_crc() == rxCRC) {
+ rxInit();
+ call SerialFrameComm.resetReceive();
+ if (offPending) {
+ rxState = RXSTATE_INACTIVE;
+ testOff();
+ }
signal ReceiveBytePacket.endPacket(SUCCESS);
ack_queue_push(rxSeqno);
- goto nosync;
+ goto done;
}
else {
goto nosync;
I tested a slight modification of this bug fix under high RX and TX load. It
seems to hold up. I've checked it in. If others could let me know if there are
any problems, I'd appreciate it.
Phil
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] SerialP problems under heavy load....
On Sep 19, 2010, at 1:27 AM, Eric Decker wrote:
I'm pretty sure the following is a problem under heavy receive loads on the
serial link. This is especially true for high baud rates that have
interarrival character times that are quite small.
Eric,
Can you test that this patch works:
===
--- SerialP.nc (revision 5198)
+++ SerialP.nc (working copy)
@@ -445,9 +445,15 @@
if (isDelimeter) { /* handle end of frame */
if (rxByteCnt = 2) {
if (rx_current_crc() == rxCRC) {
+ rxInit();
+ call SerialFrameComm.resetReceive();
+ if (offPending) {
+ rxState = RXSTATE_INACTIVE;
+ testOff();
+ }
signal ReceiveBytePacket.endPacket(SUCCESS);
ack_queue_push(rxSeqno);
- goto nosync;
+ goto done;
}
else {
goto nosync;
Phil
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] [Tinyos-devel] CTP broken and ACK delay
On Oct 8, 2010, at 7:58 AM, Fabrice Dossin wrote: Hi, I am using iris motes in the same kind of load. When load is going higher I see this kind of things. I am not sure it is linked but I also have infinite loop into the ctp tree and it never recovers from it. I can see data and beacon datagram from the node from the loop but I never see any beacon from the other nodes. Also the byte next to the 0x70 or 0x71 byte is always 0x00 like if the P bit was never activated. Should the P bit be activated so that the other node know they have to send a beacon ? They should also respond to broadcasted beacon like this one ? 15:39:05 'r' 1496976736 4955 35 [ 0x61 0x88 0xf1 0x22 0x00 0xff 0xff 0x09 0x00 0x3f 0x70 0x05 0x5a 0x00 0x00 ] 51 255 Do you think that the channel capacity could lead to such behavior (loops in CTP) ? The channel should be so occupied that the mote never sends beacon ? Which algorithm should we use instead of CTP ? Is there an existing one implemented into TinyOS ? Kind regards, Fabrice Dossin Fabrice, The easiest way to let Om and me take a look is to send a link to a packet trace. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Is there any documentation that describes the serial packet ack mechanism?
On Sep 18, 2010, at 7:35 PM, Eric Decker wrote:
I'm sure this is pretty old but
I'm currently debugging a serial protocol problem. I'm sending a well formed
Serial AM packet to my mote but for some reason it is getting
dropped by dispatch. The AM type isn't being seen correctly (dispatch seems
to be looking at the wrong byte). I've probably got something
wired wrong.
But in the course of looking at the Serial driver (SerialP.nc), I noticed the
following:
bool valid_rx_proto(uint8_t proto){
switch (proto){
case SERIAL_PROTO_PACKET_ACK:
return TRUE;
case SERIAL_PROTO_ACK:
case SERIAL_PROTO_PACKET_NOACK:
default:
return FALSE;
}
}
Is there anything that describes the protocol for serial acking in more
detail?
eric
TEP 113 is probably the best resource. There were a lot of discussions back in
2004-6, I think, particularly with respect to high throughput. Ben Greenstein
ran a lot of profiling tests to see where the bottlenecks where. Sometime in
2007? Razvan examined the issue of incoming packets being dropped due to high
interrupt load (for Deluge) and so introduced a bit of delay on serial tools to
give the mote side a bit of wiggle room. These discussions were all on the
mailing lists.
Phil
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] SerialP problems under heavy load....
On Sep 19, 2010, at 1:27 AM, Eric Decker wrote: Under heavy loads and just the right circumstances this can cause an in use receive slot to become unlocked causing a packet loss. The unlocked slot will get used for a new incoming packet. The packet contained in the slot's msg buffer will be lost and the msg buffer reused for the new incoming packet. Can you walk me through the code execution that causes this to happen? endPacket(SUCCESS) causes a buffer swap in SerialDispatcherP. Is the issue when both buffers are locked in SerialDispatcherP? I.e., buffer A is locked buffer A completes, remains locked buffer B is locked buffer B completes, nosync unlocks A before it is ready? I guess this suggests that there are really three states: unlocked, in-progress, and complete. nosync should unlock an in-progress buffer but not a complete one. But it would be really helpful if you could write down the exact code execution that makes this happen. For a task to be delayed for so long is, well, pretty long... Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] parametrized interfaces : an array of timers
On Sep 15, 2010, at 5:03 AM, Michiel Konstapel wrote:
I have some troubles implementing a parametrized interface of Timers.
I
have used the code snippets from Software design Patterns for
Tinyos
from Gay et al. and some hints online and from this mailing list.
I am
attaching the complete code (it is basically the Blink application
with
an array of 3 timers). When compiling, the error is:
In component `BlinkC':
BlinkC.nc: In function `Boot.booted':
BlinkC.nc:51: Timers.startPeriodic not connected
BlinkC.nc:52: Timers.startPeriodic not connected
BlinkC.nc:53: Timers.startPeriodic not connected
make: *** [exe0] Error 1
I found a hint on this mailing list from Phil Lewis that I need a
default implementation for the event, but this hint leads to yet
another compilation error, saying:
In file included from BlinkAppC.nc:45:
In component `BlinkC':
BlinkC.nc:61: `fired' is defined, not used, in this component
BlinkC.nc:61: (default implementations are only for used commands or
events)
BlinkC.nc:61: conflicting types for `Timers.fired'
BlinkC.nc:56: previous declaration of `Timers.fired'
make: *** [exe0] Error 1
You're close - you don't need a default implementation for the event,
but for the startPeriodic command, because the compiler can't or
doesn't
check you won't call startPeriodic() on a timer number that you didn't
connect (since you only wire up 0, 1 and 2, and you might call
Timers.startPeriodic[42] somewhere).
If you add:
default command void Timers.startPeriodic[uint8_t id](uint32_t
dt) {}
to BlinkC, it should work.
Correct. A component needs defaults for functions it invokes that
might not be wired.
Phil
___
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 add contributions?
On Sep 15, 2010, at 6:17 AM, Stefano Abbate wrote: Dear Colleagues, I have Master's student in Computer Engineering which has developed a module in TinyOS 2.x to measure the Energy Consumption and generally, the activity of a Tmote-Sky/TelosB node. He would be happy to make his work available to everyone and to extend it to other platforms. Can you please suggest me how to do it? Best regards, Stefano Abbate http://docs.tinyos.net/index.php/Contributing_Code_to_TinyOS Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Multichannel Oscilloscope for Tinyos2? [including PRE-PATCH]
On Sep 13, 2010, at 11:56 PM, Roger Larsson wrote: Hi, I am in need of a multichannel oscilloscope application for Tinyos2 (I have read that there was such an application included in Boomerang - but I can't find it available on the net) In an attempt to learn Tinyos I have enhanced the included Oscilloscope application, 80% works... I suspect that the remaining 20% will take 80% of my time to polish up (mostly in the Java application) So now is the time to ask - does anyone have finished code in their drawer? PS Why isn't it possible to use the SENSOR_ARRAY approach? (really a question for tinyos-devel) Keeping this on -help. Sorry -- I haven't been able to keep up with -help the past few weeks. Can you describe the SENSOR_ARRAY approach? Are you basically talking about having a single function call invoke many operations, then spool in the split-phase results based on an identifier? Something like: call Sensors.read() event Sensor.readDone[i](x) data[i] = x Or am I completely misunderstanding the issue? Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] AODV implementation
On Aug 27, 2010, at 6:05 AM, rupesh vishwakarma wrote: Hi, I am trying to implement AODV protocol for multihop networking in telos B if any one have sample code or method then do help Don't. AODV is ten years old and no-one uses for a good reason. It's academic in the worst sense of the word: overly tread intellectual history that is irrelevant. At the very least, try DYMO. Or take a look at RPL. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] topology generation
On Sep 6, 2010, at 8:23 AM, mojtaba raznahan wrote: This is my problem too!! fix the transmission range of each node to 40m only Any help would be appreciated. On Mon, Sep 6, 2010 at 12:37 AM, avinash chaurasia avinash.aviank2...@gmail.com wrote: hello all, I have to generate topology such that, there are nine grids in a rectangle and each grid contains 100 nodes distributed in random fashion if i do it randomly, then i have to do it for 900 nodes. please help me. also i dont understand how to calculate db in order to fix the transmission range of each node to 40m only. thanks in advance. Thanks Avinash Kumar Chaurasia Department of Computer Science IIT Kanpur, India Wireless radios don't behave in this way. Any results you obtain from such a network has no relevance to reality and is purely of theoretical interest; so why not just use a much simpler simulator or programming model than TinyOS? Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] TinyOS questions
On Aug 23, 2010, at 11:47 AM, surfma...@gmx.at wrote:
Hello,
After reading a TinyOS tutorial I have 4 remaining questions:
1.) Why do you need the = operator for wiring?
Does the configuration as well as the module provide and use
interfaces?
Why is the provides interface Leds; outside of the implementation?
configuration LedsC {
provides interface Leds;
}
implementation {
components LedsP, PlatformLedsC;
Leds = LedsP.Leds;
LedsP.Init - PlatformLedsC.Init;
LedsP.Led0 - PlatformLedsC.Led0;
LedsP.Led1 - PlatformLedsC.Led1;
LedsP.Led2 - PlatformLedsC.Led2;
}
2.) What is auto-wiring?
4.) Commands and events are synchronous by default?
The execution of an event can't be interrupted by a task or another
event because they are sync
by default? If the commands or events as aync, they can be
interrupted by a task?
Please take a look at the TinyOS programming guide.
Phil
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP simulation
On Aug 24, 2010, at 8:19 PM, Omprakash Gnawali wrote: On Tue, Aug 24, 2010 at 3:21 PM, wasif masood rwmas...@gmail.com wrote: the only random values in test.py are related to bootuo time and I don't how this value is going to effect the outcome. Those random values might change the order in which nodes come up and start sending messages. That can change the tree. You might also want to look at the random values in TOSSIM. The files are in tos/lib/tossim. Correct -- message order will change what the resulting tree is (it affects cache insertion/removal policies). You can set TOSSIM's random seed if you want a repeatable run. The operating assumption is that if you run the same simulation twice you're doing separate trials. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Dissemination Protocols Comparison
The DIP paper explains Drip; Drip allocates a separate Trickle timer per item. Phil On Aug 22, 2010, at 11:08 AM, Paul Gildea wrote: Hello, I'm looking to compare the dissemation protocols provided with tinyos, DIP, DHV, DRIP. i have papers n DIP and DHV to read, is there any good documentation on Drip? thanks, -- Paul ___ 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] Simple Time Sync
You can't really in this case: other parts of the system (eg timers) depend on the value's progression. Two options: 1) Run FTSP 2) Store the observed difference between transmitter and receiver time at the receiver, use this as an offset. Note the issues with drift. Phil (sent from a phone) On Aug 21, 2010, at 11:43 AM, JC de Dios jc.ded...@ieee.org wrote: Hello, I am trying to implement a simple time synchronization by sending the current time of a periodic timer from a master node using command getNow() of the Timer interface. Is it possible that the slave nodes set this value as the current time of their periodic timer? I imagine having motes that have blinking LEDs at the same time (not that precise) while booting at different times. What command and interface can I use to overwrite the current time of a timer? Thanks for your help. - JC de Dios ___ 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] is there a struct definition rule?
On Aug 20, 2010, at 7:22 AM, Xiaohui Liu wrote: Actually, I'm trying to change 4 bit link estimation (4bitle) to estimate some link delay related information. At the beginning, 4bitle is working fine. However, after I add the blue fields (nothing else), 4bitle seems to malfunction. Hope this helps clarify my question. You need to be more precise. Malfunction is not helpful when it comes to debugging. Sorry to say this, but you're going about debugging this all wrong. You're confusing a symptom (when you change the structure) with a diagnosis (what's going wrong in the program). This kind of debugging is just throwing darts in the dark: it doesn't get you to the bottom of the problem. There are two possibilities: 1) More likely: there is a memory access bug in your code. When you change the structure definition, the compiler places the differently sized structure in a different place in memory. E.g., next to the memory with the bug. One way to help diagnose this is to examine what variables are near the structure in the two different executables (nm, objdump, etc.). 2) Much less likely: there is a compiler bug on access to the structure. The way to diagnose this is to look at the generated assembly. Effective diagnosis requires, in both cases, a clear understanding of what the memory access error is and how it manifests. Regardless, chances are this bug has nothing to do with nesC, and is really just a low-level C bug. That is, unless nesc1 is doing something weird (very unlikely). You can check this by looking at app.c. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] is there a struct definition rule?
On Aug 19, 2010, at 8:57 PM, Xiaohui Liu wrote:
Hi,
The following appears in my header file.
enum {
SWS = 15,
NUM_OF_QUANTILES = 4,
LINK_MARKER_COUNTS = 11,
};
typedef struct neighbor_table_entry {
am_addr_t ll_addr;
uint8_t lastseq;
uint8_t rcvcnt;
uint8_t failcnt;
uint8_t flags;
uint8_t inage;
uint8_t inquality;
uint16_t eetx;
uint8_t data_success;
uint8_t data_total;
} neighbor_table_entry_t;
Till now, everything works as expected. However, after the blue part is
appended to the structure definition to the following, which is the only
change to my program, it's not working anymore. Then I append the red part
and it goes back to normal. Can anyone help me understand what is going on? I
guess this may be related to alignment and order issue. I've encountered
several problems so far and every time I have to randomly change the order of
some fields or add some padding bytes till it's working. Is there a rule
regarding how a structure must be defined in TinyOS? Thanks.
There are no special rules. Chances are you have a memory access bug in your
program somewhere; adding the padding leads the compiler to place the structure
differently, such that you don't see the bug manifest.
Phil
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Multicast Protocol
On Aug 18, 2010, at 5:49 PM, sadun silva wrote: Dear all, Is there an implementation of a multicast protocol in TOS2? Thanks in advance silva ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help Use Trickle: http://tools.ietf.org/html/draft-hui-6man-trickle-mcast-00 You can use either Drip, DIP, or DHV. net2 current recommends you use DHV except for some really narrow edge cases. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] calling AMSend.send?
On Aug 17, 2010, at 1:42 AM, Hamidreza Ghafghazi wrote: dear all, Is it possible to call AMSend.send in the event void Receive.receive or not? Yes, but you need to be careful with message pointers. Be sure that you don't return the same message_t* that you pass to AMSend. Otherwise the radio stack might start using your transmit buffer as a receive buffer, leading to corrupted or incorrect packets being sent. If not, Is it possible to call a timer inside event void Receive.receive as an event in order to send the modified received data? You can do this as well. Actually I want to receive some data and modify it and send it again to the other node immediately and I am looking for a solution. that would be so great if anybody could give me a hint. Take a look at tos/lib/net/lqi/LqiForwardingEngineP.nc:SubReceive.receive; it can call mForward, which can call forward, which can call SubSend. This forwarding engine is simpler than CTP's, so it's a bit easier to follow the call chain. Note that if the message is a broadcast, you want to avoid forwarding immediately: many nodes will all broadcast in unison, which can be terrible for collisions. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Send to UART and Radio at a time
This looks like TinyOS 1.x; in 1.x you can't send to the radio and serial port
simultaneously. In 2.x you can.
Phil
On Aug 16, 2010, at 8:45 AM, Xavi Colomer wrote:
Hello,
I need to send to UART and Radio at a time, but only one of SendMsg calls
works... What is the problem? Parameterized interfaces solves the problem?
MyApp.nc
[...]
MyAppM.SendMsg - Comm.SendMsg[AM_XSXMSG]; //AM_XSXMSG=0
MyAppM.UARTMsg - Comm.SendMsg[AM_XSYMSG];//AM_XSYMSG=1
[...]
MyAppM.nc
[...]
uses {
interface Timer;
interface Leds;
interface ReceiveMsg;
interface SendMsg;
interface SendMsg as UARTMsg;
}
[...]
void task SendFlag()
{
atomic sending_packet = TRUE;
if (call SendMsg[AM_XSXMSG].send(port,sizeof(XDataMsg),msg_buffer) !=
SUCCESS)
sending_packet = FALSE;
return;
}
void task SendData()
{
atomic sending_packet = TRUE;
if (call UARTMsg.send(TOS_UART_ADDR,sizeof(YDataMsg),msg_buffer2) !=
SUCCESS)
sending_packet = FALSE;
return;
}
Sorry for my bad english, and thanks in advance.
Xavi
___
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] Tossim questions
On Aug 15, 2010, at 11:07 AM, Sergio Campamá wrote: Hello, I am trying to understand how Tossim works in order to make some changes in the simulation engine, specifically to incorporate new processors and try different wireless channel models. Is there any documentation from when MicaZ was implemented in Tossim, or the function flow from the python interpreter to where the noise is added to the packet? Also, does someone know where the SimMote.nc is compiled into? I know sim_mote.h is compiled with the SWIG wrapper, but I'm having trouble following where the NesC implementation is compiled into. There isn't any special documentation for this, as it's not *too* many lines of code. The component you probably care about is CpmModelC; it's what actually computes whether a packet should be received, based on signal strength, mote interference, and external interference. External interference/noise samples are taken from a statistical model implemented in sim_noise.c. If you have more precise questions I can try to point you in the right direction. To be honest, the best way to learn the code might be to just run TOSSIM inside gdb and walk through what happens. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Tossim questions
On Aug 15, 2010, at 6:23 PM, Sergio Campamá wrote: Thank you Philip, hadn't occurred to me to use gdb. I'll try to produce better questions after I study TOSSIM some more. I've managed to follow some function calls but the link between NesC and C, as in sim_mote.h, are a little more difficult to understand. Ah -- yeah, there's a bunch of layers of indirection in order to simplify SWIG support. The problem is we basically need python to be able to call nesC. The top-level interface to the simulator is C++; SWIG takes these objects and generates python bindings for them, which allows you to control TOSSIM from python. The C++ objects call C functions. These C functions are implemented in nesC files, and can therefore call nesC components through commands/events as needed. For example, Tossim.i has the Mote class, with the function bootAtTime(). So you can call this from python. Calling it invokes the C function sim_mote_set_start_time(). This C function is implemented in SimMoteP.nc. It's convenient to have functionality like this implemented in components because then compiling for TOSSIM automatically scales the functionality up to many motes (i.e., when you access a component variable, it indexes into an array based on what the current node is). Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] question regarding CTP
On Aug 10, 2010, at 10:50 PM, Manjunath Doddavenkatappa wrote: Just a guess, Before asking the routing layer whether a new route to a neighbor is promising, the estimator asks physical layer whether the white bit of the incoming packet (from the sender of the new link) is set. Only if the white bit is set then estimator proceeds. Since the set white bit already indicates that local link is good (may be interpreted as ETX=1), it may not be required to verify the local ETX values of the existing neighbors. Please correct me if I am wrong. Manjunath D Sort of -- please refer to the 4-bit link estimation paper. Normally, when the estimator first learns about a neighbor, it waits before making communication with that neighbor available (actually putting it into the link table as an active link). The reason is simple: after receiving only one packet, the estimator can't provide a good estimate, and so making the link active might cause a protocol to choose a very very poor link. The white bit circumvents this initial estimation phase. The white bit indicates that there's a high probability that the underlying link is high quality; this allows the link estimator to skip the initial estimation and make the link immediately available for the routing layer to use. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Wiring Statements
On Jul 16, 2010, at 9:30 AM, Shang Lin Chua wrote: Hi all, i've got a question regarding wiring statements. For example, end point1 - end point2 (equivalent to end point2 - end point 1) basically means user(end point 1) is wired to provider (end point 2). can anyone tell me what does end point1 = end point2 mean? i've looked around there's no clear definition I'm thoroughly confused. thank you very much ___ Take a look at the TinyOS programming manual (http://csl.stanford.edu/~pal/pubs/tos-programming-web.pdf), section 4.1.2. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] 8ms for packet to reach CC2420ReceiveC(receiver) from CC2420TransmitC(sender)
On Jul 12, 2010, at 7:28 PM, Obaid Salikeen wrote: Hi, I am using the most lowest component for sending i.e CC2420transmitC, and CC2420ReceiveC. Problem is that it is taking too long to send and receive a message with just 2 bytes payload and 21byte header (CC2420_SIZE). It is taking 8ms, so if a sender has send a packet, ACK will be received in 16ms. I thought cc2420Transmit was the lowest component, and that it should right away send the packet without any delay. I set the radio backoff values to 0, and disabled CCA, but still it takes too long. please if some body know then do share that why it takes so long,,,what it there between CC2420TransmitC and Radio that increase the transmit time ? The theoretical transmission delay that i calculated is 0.736 Milli second i.e 736micro seconds, but in reality its taking more then 8ms which is strange. CSMA backoff. The TinyOS MAC picks an initial backoff in the range of 0-10ms. Including transmission time, packet load time, etc., this means that the average send/sendDone latency is ~7ms. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] `TOSH_DATA_LENGTH' undeclared (first use in this function)
On Jul 7, 2010, at 3:30 PM, Yi Tang wrote: Hi all! I'm trying to analyse some Routing Protocols in TinyOS 1.x. For the Analysing i need to test compiled C Code. As i tried to compile e.g. tinyos-1.x/tos/lib/Route/MultiHopEngineM.nc i get this error: Why? These protocols are old, have well known problems, and are far from state of the art. The last 1.x update was five years ago! Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Segmentation fault in TOSSIM
On Jun 29, 2010, at 7:25 AM, harsh...@cse.iitk.ac.in wrote: Hi, I have been trying to run a clustering protocol in tinyos2. I have written some code for some part of the protocol. But whenever I run the code on TOSSIM, it runs for a few events and then a Segmentation fault is flagged and simulation stops abruptly. I tried removing the noise model part(i.e. commenting out the following in python script): --code begins-- for i in range(0,numNodes): print Creating noise model for ,i; t.getNode(i).createNoiseModel() --code ends then the code runs and terminates smoothly but it is of not much use as none of the sent messages are received. I really need to simulate the protocol. Any suggestions would be greatly appreciated. I'd suggest running it in gdb to find out what's causing the segfault. Chances are you are not initializing the noise model correctly. Take a look through the archives: similar problems come up occasionally. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] call UartPacket.clear() in Base Station
On Jun 7, 2010, at 12:21 AM, Xiaohui Liu wrote: Hi all, Why is it necessary to call UartPacket.clear(msg) in uartSendTask() task of BaseStationP? I don't see why uart message header has to be reset to be all zero, which is exactly what UartPacket.clear() does. Thanks. Because that message buffer might have been used for other things; rather than leave pre-set bits, they should be cleared. This is less of an issue for a UART message than for, say, a 802.15.4 message. Miklos led a discussion on this a few years ago. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
