Re: [Tinyos-help] Strange error about type definition
So how could I store in my code a radio struct? Should I construct another one
regular struct and retrieve data from the payload?
Why it is so?
On Feb 13, 2008 3:23 PM, Flavio Pompermaier [EMAIL PROTECTED] wrote:
Hi to all,
I have a very problem in defining a message types to send over the radio!
I want to make they endianess-indipendent so I use the nx_ suffix with
structures and basic types.
However, when I compile my application I get errors like the following:
'DataMsg' defined as wrong kind of tag.
Did you bychance previously declare (not define) struct DataMsg
somewhere (e.g. used 'struct DataMsg *p' somewhere)? If so, you've
told the compiler that DataMsg is a regular struct, so it complains
when you later tell it that it's a nx_struct...
David Gay
and this is the type definition:
typedef nx_struct DataMsg{
nx_uint16_t dato;
ControlInfo control;
} DataMsg;
typeDef nx_struct ControlInfo{
nx_uint16_t some_info;
} ControlInfo
Is it because I use a type inside another one??
Could anyone help me??
Thanks in advance,
Flavio
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] How to measure the memory cost
Hi Janos, thanks for your precious answer. Where can i read more about this? I'm looking for a document but i still don't find it. Thanks a lot for your time. Roberto 2008/2/13, Janos Sallai [EMAIL PROTECTED]: Roberto, The local automatic variables are not counted when the make system prints out the RAM usage. I suspect you have some of those in your code. They are created dynamically on the stack, and thus, it's hard to tell what is the maximum possible stack depth. (There exist static stack depth analysis tools, but, as of now, the TinyOS make system does not make use of any of them.) Janos -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *AIGroup *Sent:* Tuesday, February 12, 2008 6:51 AM *To:* TinyOS *Subject:* [Tinyos-help] How to measure the memory cost Hi all, solved the problems explained in my previous post, I'm interesting to study the memory cost. I know the importante of RAM and ROM value following the command make micaz But, enough I allocate many variables an many arrays, the corresponding RAM value is 453bytes. Is it possibile? The style of my code is very simple (is taken from Blink example). In Blink I include two file : an header file (svm.h) and an implementation C file (svm.c). May the C code doesn't involve the Rom and Ram values? My variables and arrays are just in the C code. I hope my explation is good. Thanks for your help in advance Roberto ps the Rom value is about 67K ___ 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 measure the memory cost
The local automatic variables are not counted when the make system prints out the RAM usage. I suspect you have some of those in your code. They are created dynamically on the stack, and thus, it's hard to tell what is the maximum possible stack depth. (There exist static stack depth analysis tools, but, as of now, the TinyOS make system does not make use of any of them.) Speaking of which, does anyone know of any stack estimation tools for the msp430? We're using stacktool (http://www.cs.utah.edu/~regehr/stacktool/) with our Atmega128-based node and I've been looking for something similar for the msp430, but nothing's turned up yet. Michiel ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] CC2420 Hardware ACKs
Hi all,
I was trying to set Hardware ACKs for CC2420 radio chip. I did a simple
ping pong application in which I posted a task call ack() inside the
event SplitControl.startDone(error_t error).
The task call ack activates HW acknowledgements in the following way:
bool activated = TRUE;
task void ack() {
atomic{
call CC2420Config.setAutoAck(activated,activated);
if (call CC2420Config.sync() != SUCCESS) {
post ack();
}
}
However, the mote that is sending messages is not receiving any ack.
Should I do anything else to activate CC2420 HW acks?. Any help?
Regards,
-
Rodo
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Strange error about type definition
I fixed the problem changing struct to nx_struct in the declarations as you
told me..Initially I didn't understand what you adviced me!
Thanks..
-- Initial Header ---
From : David Gay [EMAIL PROTECTED]
To : Flavio Pompermaier [EMAIL PROTECTED]
Cc : Help TinyOS tinyos-help@millennium.berkeley.edu
Date : Wed, 13 Feb 2008 18:36:40 -0800
Subject : Re: [Tinyos-help] Strange error about type definition
On Feb 13, 2008 3:23 PM, Flavio Pompermaier [EMAIL PROTECTED] wrote:
Hi to all,
I have a very problem in defining a message types to send over the radio!
I want to make they endianess-indipendent so I use the nx_ suffix with
structures and basic types.
However, when I compile my application I get errors like the following:
'DataMsg' defined as wrong kind of tag.
Did you bychance previously declare (not define) struct DataMsg
somewhere (e.g. used 'struct DataMsg *p' somewhere)? If so, you've
told the compiler that DataMsg is a regular struct, so it complains
when you later tell it that it's a nx_struct...
David Gay
and this is the type definition:
typedef nx_struct DataMsg{
nx_uint16_t dato;
ControlInfo control;
} DataMsg;
typeDef nx_struct ControlInfo{
nx_uint16_t some_info;
} ControlInfo
Is it because I use a type inside another one??
Could anyone help me??
Thanks in advance,
Flavio
___
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] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
Currently Msp430RefVoltArbiterImplP intercept the requests of ADC clients to the Resource interface, it is not really arbitrating access itself. If the DAC needs access to the RefVolt component too, then we might need a real arbiter for the RefVolt component that is independent of the actual ADC arbiter. The drawback is then that for every ADC/DAC request involving RefVolt we'd need to request two resources from two different arbiters before the client can start sampling/outputting. Alternatively we could agree that ADC and DAC share the same arbiter, which makes arbitration a lot easier, but is less efficient because you'd never be able to run ADC and DAC in parallel. Jan On Wed, Feb 13, 2008 at 7:53 PM, Vlado Handziski [EMAIL PROTECTED] wrote: The access to the refvolt generator has to be properly arbitrated between the ADC and the DAC. Pins, timers, etc. are all potential shared resource between the two. Jan, who is responsible for the msp430 ADC stack, is at a project meeting and probably has not read the thread. Please get in touch with him to coordinate. No #ifdefs please :) Vlado On Wed, Feb 13, 2008 at 6:43 PM, John Griessen [EMAIL PROTECTED] wrote: Sandip Bapat wrote: a DAC module would either have to wire to Msp430RefVoltArbiterP (in which case it also has to provide the AdcConfigure interface) or be expected to provide wiring for these interfaces. This is fine for apps that just want to use the DAC and not ADC but what if both are used and the ADC is already using Ref Voltage ? I guess we could use #ifdefs in the DAC but wouldn't having a Msp430RefVoltArbiterC that does the wirings required for Msp430RefVoltGeneratorP be better? The best thing would be to create new function in the RefVoltArbiter so it can stay on after an ADC12 or Dac12 call has requested it if another request is heard within a time period. As far as I can tell, Dac12 and Adc12 of a MSP430F1611 can both be going at once. John Griessen -- Ecosensory Austin TX tinyOS devel on: ubuntu Linux; tinyOS v2.0.2; telosb ecosens1 ___ Tinyos-devel mailing list [EMAIL PROTECTED] 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] CC2420 Hardware ACKs
Are you requesting an acknowledgment before sending?
call PacketAcknowledgements.requestAck(myMsg);
call AMSend.send(0x0, myMsg, sizeof(my_payload_t));
Does it the software work as expected using software acknowledgments?
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rodolfo de
Paz Alberola
Sent: Thursday, February 14, 2008 4:28 AM
To: tinyos-help
Subject: [Tinyos-help] CC2420 Hardware ACKs
Hi all,
I was trying to set Hardware ACKs for CC2420 radio chip. I did a simple
ping pong application in which I posted a task call ack() inside the
event SplitControl.startDone(error_t error).
The task call ack activates HW acknowledgements in the following way:
bool activated = TRUE;
task void ack() {
atomic{
call CC2420Config.setAutoAck(activated,activated);
if (call CC2420Config.sync() != SUCCESS) {
post ack();
}
}
However, the mote that is sending messages is not receiving any ack.
Should I do anything else to activate CC2420 HW acks?. Any help?
Regards,
-
Rodo
___
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] net.tinyos.tools.Listen MIB600 No data is seen on theDisplay
The port 10001 of MIB600 is used to program the Mote and port 10002 is used to read data from the base Mote. You need to set the MOTECOM variable to port 10002 of your MIB600 for the PC tools to read data. Regards, Giri From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Giovanni Abu-Aita Sent: Monday, February 11, 2008 9:29 PM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] net.tinyos.tools.Listen MIB600 No data is seen on theDisplay hello everybody, I am running the Oscilloscope Application on the mote that is connected to MIB600. I am trying to read the packets and display them on the screen using net.tinyos.tools.Listen but nothing seems to appear on the screen. with MIB510 everything goes fine. with MIB600 I set the value of MOTECOM: export MOTECOM:[EMAIL PROTECTED]:10001 but still the Listen gives me: [EMAIL PROTECTED]:10001: resynchronising and stops there. anybody can help in this. P.S. : 1) I had this problem before and I have changed the settings of the MIB600 by browsing it: I set the Speed of channel 1 to 115200 and the speed of channel 2 57600 and i made sure the ports are 10001 and 10002 respectively. Fortunately It worked. But now I don;t know what I did wrong; I even restored to factory settings plus the changes above but it did;t work. 2) I also tried the SerialForwarder but it seemed it doesn't read the packets. Any help??? Thanks in advance Never miss a thing. Make Yahoo your homepage. http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
Jan, In the latter approach you outlined, where they share the same arbiter, if we assume that the ADC and DAC require the same reference voltage, would they still not be able to run in parallel? Here's one scenario which might be common to a lot of sensing apps: An app uses RefVolt via Msp430AutoRVGClient to do its sensing and requires some reference (say 2.5V). Occasionally, the app also needs to use the DAC, with the same reference voltage, for instance, to change the gain setting on the sensor by varying the DAC voltage. If both used the same reference, could they still not work in parallel? Also, the DAC has a 3x multiplier setting so effectively it can produce the same range of outputs regardless of what reference voltage is being used by others (ADC). We could (re)implement the getState() function in RefVolt so that the DAC client can figure out which, if any, reference voltage is being used by the ADC and scale its inputs accordingly. But perhaps I'm missing something even more fundamental here as to why they can't run in parallel. Sandip - Original Message From: Jan Hauer [EMAIL PROTECTED] To: Vlado Handziski [EMAIL PROTECTED] Cc: TinyOS Development [EMAIL PROTECTED]; tinyos-help@Millennium.Berkeley.EDU list tinyos-help@millennium.berkeley.edu Sent: Thursday, February 14, 2008 10:42:02 AM Subject: Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2 Currently Msp430RefVoltArbiterImplP intercept the requests of ADC clients to the Resource interface, it is not really arbitrating access itself. If the DAC needs access to the RefVolt component too, then we might need a real arbiter for the RefVolt component that is independent of the actual ADC arbiter. The drawback is then that for every ADC/DAC request involving RefVolt we'd need to request two resources from two different arbiters before the client can start sampling/outputting. Alternatively we could agree that ADC and DAC share the same arbiter, which makes arbitration a lot easier, but is less efficient because you'd never be able to run ADC and DAC in parallel. Jan On Wed, Feb 13, 2008 at 7:53 PM, Vlado Handziski [EMAIL PROTECTED] wrote: The access to the refvolt generator has to be properly arbitrated between the ADC and the DAC. Pins, timers, etc. are all potential shared resource between the two. Jan, who is responsible for the msp430 ADC stack, is at a project meeting and probably has not read the thread. Please get in touch with him to coordinate. No #ifdefs please :) Vlado On Wed, Feb 13, 2008 at 6:43 PM, John Griessen [EMAIL PROTECTED] wrote: Sandip Bapat wrote: a DAC module would either have to wire to Msp430RefVoltArbiterP (in which case it also has to provide the AdcConfigure interface) or be expected to provide wiring for these interfaces. This is fine for apps that just want to use the DAC and not ADC but what if both are used and the ADC is already using Ref Voltage ? I guess we could use #ifdefs in the DAC but wouldn't having a Msp430RefVoltArbiterC that does the wirings required for Msp430RefVoltGeneratorP be better? The best thing would be to create new function in the RefVoltArbiter so it can stay on after an ADC12 or Dac12 call has requested it if another request is heard within a time period. As far as I can tell, Dac12 and Adc12 of a MSP430F1611 can both be going at once. John Griessen -- Ecosensory Austin TX tinyOS devel on: ubuntu Linux; tinyOS v2.0.2; telosb ecosens1 ___ Tinyos-devel mailing list [EMAIL PROTECTED] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel ___ Tinyos-devel mailing list [EMAIL PROTECTED] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] CC2420 Hardware ACKs
Also, are you calling CC2420Config.sync() to commit your hardware
acknowledgment changes to the CC2420 hardware?
call CC2420Config.setAutoAck(TRUE, TRUE);
call CC2420Config.sync();
// wait awhile
event void CC2420Config.syncDone() {
...
}
-David
-Original Message-
From: Rodolfo de Paz Alberola [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 14, 2008 9:12 AM
To: David Moss
Cc: 'tinyos-help'
Subject: RE: [Tinyos-help] CC2420 Hardware ACKs
Hi David,
On Thu, 2008-02-14 at 08:56 -0700, David Moss wrote:
Are you requesting an acknowledgment before sending?
call PacketAcknowledgements.requestAck(myMsg);
call AMSend.send(0x0, myMsg, sizeof(my_payload_t));
No, I thought that only calling the command setAutoAck
it should enable MDMCTRL0.AUTOACK leaving to the CC2420 radio chip
all the process.
This command that you mention for requesting acks I think that only
works for SW acks.
Does it the software work as expected using software acknowledgments?
Yes, I did another application using software acknowledgments and it
works fine,
but in this case I would like to use hw acks since i am trying to model
the
cc2420 radiochip which has hw acks as well.
Thanks for your help. Any idea?
Rodo
On Thu, 2008-02-14 at 08:56 -0700, David Moss wrote:
Are you requesting an acknowledgment before sending?
call PacketAcknowledgements.requestAck(myMsg);
call AMSend.send(0x0, myMsg, sizeof(my_payload_t));
Does it the software work as expected using software acknowledgments?
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rodolfo
de
Paz Alberola
Sent: Thursday, February 14, 2008 4:28 AM
To: tinyos-help
Subject: [Tinyos-help] CC2420 Hardware ACKs
Hi all,
I was trying to set Hardware ACKs for CC2420 radio chip. I did a simple
ping pong application in which I posted a task call ack() inside the
event SplitControl.startDone(error_t error).
The task call ack activates HW acknowledgements in the following way:
bool activated = TRUE;
task void ack() {
atomic{
call CC2420Config.setAutoAck(activated,activated);
if (call CC2420Config.sync() != SUCCESS) {
post ack();
}
}
However, the mote that is sending messages is not receiving any ack.
Should I do anything else to activate CC2420 HW acks?. Any help?
Regards,
-
Rodo
___
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] CC2420 Hardware ACKs
The CC2420 radio requires the acknowledgment request flag be set in the FCF
byte before it will automatically generate a hardware acknowledgment for any
received packet.
-David
-Original Message-
From: Rodolfo de Paz Alberola [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 14, 2008 9:12 AM
To: David Moss
Cc: 'tinyos-help'
Subject: RE: [Tinyos-help] CC2420 Hardware ACKs
Hi David,
On Thu, 2008-02-14 at 08:56 -0700, David Moss wrote:
Are you requesting an acknowledgment before sending?
call PacketAcknowledgements.requestAck(myMsg);
call AMSend.send(0x0, myMsg, sizeof(my_payload_t));
No, I thought that only calling the command setAutoAck
it should enable MDMCTRL0.AUTOACK leaving to the CC2420 radio chip
all the process.
This command that you mention for requesting acks I think that only
works for SW acks.
Does it the software work as expected using software acknowledgments?
Yes, I did another application using software acknowledgments and it
works fine,
but in this case I would like to use hw acks since i am trying to model
the
cc2420 radiochip which has hw acks as well.
Thanks for your help. Any idea?
Rodo
On Thu, 2008-02-14 at 08:56 -0700, David Moss wrote:
Are you requesting an acknowledgment before sending?
call PacketAcknowledgements.requestAck(myMsg);
call AMSend.send(0x0, myMsg, sizeof(my_payload_t));
Does it the software work as expected using software acknowledgments?
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rodolfo
de
Paz Alberola
Sent: Thursday, February 14, 2008 4:28 AM
To: tinyos-help
Subject: [Tinyos-help] CC2420 Hardware ACKs
Hi all,
I was trying to set Hardware ACKs for CC2420 radio chip. I did a simple
ping pong application in which I posted a task call ack() inside the
event SplitControl.startDone(error_t error).
The task call ack activates HW acknowledgements in the following way:
bool activated = TRUE;
task void ack() {
atomic{
call CC2420Config.setAutoAck(activated,activated);
if (call CC2420Config.sync() != SUCCESS) {
post ack();
}
}
However, the mote that is sending messages is not receiving any ack.
Should I do anything else to activate CC2420 HW acks?. Any help?
Regards,
-
Rodo
___
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] CC2420 Hardware ACKs
Hi David,
On Thu, 2008-02-14 at 08:56 -0700, David Moss wrote:
Are you requesting an acknowledgment before sending?
call PacketAcknowledgements.requestAck(myMsg);
call AMSend.send(0x0, myMsg, sizeof(my_payload_t));
No, I thought that only calling the command setAutoAck
it should enable MDMCTRL0.AUTOACK leaving to the CC2420 radio chip
all the process.
This command that you mention for requesting acks I think that only
works for SW acks.
Does it the software work as expected using software acknowledgments?
Yes, I did another application using software acknowledgments and it
works fine,
but in this case I would like to use hw acks since i am trying to model
the
cc2420 radiochip which has hw acks as well.
Thanks for your help. Any idea?
Rodo
On Thu, 2008-02-14 at 08:56 -0700, David Moss wrote:
Are you requesting an acknowledgment before sending?
call PacketAcknowledgements.requestAck(myMsg);
call AMSend.send(0x0, myMsg, sizeof(my_payload_t));
Does it the software work as expected using software acknowledgments?
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rodolfo de
Paz Alberola
Sent: Thursday, February 14, 2008 4:28 AM
To: tinyos-help
Subject: [Tinyos-help] CC2420 Hardware ACKs
Hi all,
I was trying to set Hardware ACKs for CC2420 radio chip. I did a simple
ping pong application in which I posted a task call ack() inside the
event SplitControl.startDone(error_t error).
The task call ack activates HW acknowledgements in the following way:
bool activated = TRUE;
task void ack() {
atomic{
call CC2420Config.setAutoAck(activated,activated);
if (call CC2420Config.sync() != SUCCESS) {
post ack();
}
}
However, the mote that is sending messages is not receiving any ack.
Should I do anything else to activate CC2420 HW acks?. Any help?
Regards,
-
Rodo
___
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] Deluge T2 Dissemination
Hello, I'm working with Deluge T2 to use in a Tmote Sky testbed. So far I have looked into various documents and material, including the mailing list (eg http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2007-December/030076.html ), but I keep having one issue. I have updated my system (XubunTOS) to the latest version (including Ubuntu 7.10). I have also updated TinyOS-2.x from CVS and recompiled the tools. I used burn-net script to program a couple of motes. This works fine; but then, I injected an image to slot 0 with success and sent a disseminate-and-reprogram command, which doesn't seem to work! The green led of page received doesn't lit and nothing seems to be going on. If I do it in slot 1, everything works perfectly. But with slot 0, I can only reprogram the base station and not disseminate! Am I doing anything wrong or is this a problem with Deluge T2? Any suggestions? Thanks in advance -- Bernardo Maciel [EMAIL PROTECTED] ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Compilation problem with iris motes....but works fine with micaz
Hi Friends I have an application that uses MTS400 GPS sensorboard. Until now I used this application on Micaz motes without any problem. I now decided to switch to IRIS motes as these motes have better transmission power and distance. I installed MoteWorks provided by Crossbow for IRIS support. In MoteWorks when I compiled the application for micaz it compiled without any problem but when I tried compiling for iris it gave me compile error. The problem is that it cannot detect certain variables from the SODebug.h file present in $TOSROOT/tos/sensorboards/mts400/SODebug.h This mts400 is the one provided by crossbow. I have listed a part of error below. I will really appreciate any help provided. Mir Murtuza [EMAIL PROTECTED] /opt/MoteWorks/apps/general/GPSSndRec_NC_0.9 $ less file.txt Mir Murtuza [EMAIL PROTECTED] /opt/MoteWorks/apps/general/GPSSndRec_NC_0.9 $ make iris mkdir -p build/iris compiling GPSRec to a iris binary ncc -o build/iris/main.exe -Os -I/opt/MoteWorks/tos/lib/MyLib -finline-limit=10 -DPLATFORM_M ICAZC -I%T/platform/iris -I%T/lib/Queue -I%T/sensorboards/mts400 -I%T/lib/Broadcast -I%T/lib/XL ib-DROUTE_PROTOCOL=0x90 -I%T/radio/rf230 -I%T/lib/internal/XMesh -DMULTIHOPROUTER=XMeshRoute r -Wall -Wshadow -DDEF_TOS_AM_GROUP=126 -Wnesc-all -target=iris -fnesc-cfile=build/iris/app.c -b oard=mts400 -DTOSH_DATA_LENGTH=39 -DTOSH_MAX_TASKS_LOG2=5 -DCC2420_TXPOWER=TXPOWER_MAX -DCC2420_ DEF_CHANNEL=11 -DIDENT_PROGRAM_NAME=GPSRec -DIDENT_PROGRAM_NAME_BYTES=71,80,83,82,101,99,0 - DIDENT_USER_ID=MirMurtuzaAli -DIDENT_USER_ID_BYTES=77,105,114,77,117,114,116,117,122,97,65,10 8,105,0 -DIDENT_HOSTNAME=namreen -DIDENT_HOSTNAME_BYTES=110,97,109,114,101,101,110,0 -DIDEN T_USER_HASH=0xeb22567dL -DIDENT_UNIX_TIME=0x47b482cbL -DRF230_DEF_CHANNEL=11 -DRF230_TXPOWER=TX POWER_MAX GPSRec.nc -lm In file included from /opt/MoteWorks/tos/sensorboards/mts400/IntersemaPressureM.nc:91, from /opt/MoteWorks/tos/sensorboards/mts400/IntersemaPressure.nc:81, from GPSRec.nc:10: In component `IntersemaPressureM': /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h: In function `init_debug': /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:17: `U2X' undeclared (first use in this functio n) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:17: (Each undeclared identifier is reported onl y once /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:17: for each function it appears in.) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:18: `UCSZ1' undeclared (first use in this funct ion) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:18: `UCSZ0' undeclared (first use in this funct ion) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:20: `TXEN' undeclared (first use in this functi on) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h: In function `init_debug_mica2dot': /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:29: `UCSZ1' undeclared (first use in this funct ion) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:29: `UCSZ0' undeclared (first use in this funct ion) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:31: `TXEN' undeclared (first use in this functi on) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h: In function `UARTPutChar': /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:38: `UDRE' undeclared (first use in this functi on) In file included from /opt/MoteWorks/tos/sensorboards/mts400/GpsPacket.nc:94, from /opt/MoteWorks/tos/sensorboards/mts400/UARTGpsPacket.nc:81, from GPSRec.nc:16: In component `GpsPacket': /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h: In function `init_debug': /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:17: `U2X' undeclared (first use in this functio n) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:18: `UCSZ1' undeclared (first use in this funct ion) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:18: `UCSZ0' undeclared (first use in this funct ion) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:20: `TXEN' undeclared (first use in this functi on) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h: In function `init_debug_mica2dot': /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:29: `UCSZ1' undeclared (first use in this funct ion) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:29: `UCSZ0' undeclared (first use in this funct ion) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:31: `TXEN' undeclared (first use in this functi on) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h: In function `UARTPutChar': /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:38: `UDRE' undeclared (first use in this functi on) In file included from /opt/MoteWorks/tos/sensorboards/mts400/HPLUART1M.nc:81, from /opt/MoteWorks/tos/sensorboards/mts400/HPLUARTC1.nc:79, from /opt/MoteWorks/tos/sensorboards/mts400/UART1.nc:75,
RE: [Tinyos-help] Compilation problem with iris motes....but works finewith micaz
Your error log is missing from your e-mail below. Can you send the complete compile output including the commands you type and the folder you are in? Thanks, Giri From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Murtuza Sent: Thursday, February 14, 2008 10:07 AM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] Compilation problem with iris motesbut works finewith micaz Hi Friends I have an application that uses MTS400 GPS sensorboard. Until now I used this application on Micaz motes without any problem. I now decided to switch to IRIS motes as these motes have better transmission power and distance. I installed MoteWorks provided by Crossbow for IRIS support. In MoteWorks when I compiled the application for micaz it compiled without any problem but when I tried compiling for iris it gave me compile error. The problem is that it cannot detect certain variables from the SODebug.h file present in $TOSROOT/tos/sensorboards/mts400/SODebug.h This mts400 is the one provided by crossbow. I have listed a part of error below. I will really appreciate any help provided. Mir Murtuza [EMAIL PROTECTED] /opt/MoteWorks/apps/general/GPSSndRec_NC_0.9 $ less file.txt Mir Murtuza [EMAIL PROTECTED] /opt/MoteWorks/apps/general/GPSSndRec_NC_0.9 $ make iris mkdir -p build/iris compiling GPSRec to a iris binary ncc -o build/iris/main.exe -Os -I/opt/MoteWorks/tos/lib/MyLib -finline-limit=10 -DPLATFORM_M ICAZC -I%T/platform/iris -I%T/lib/Queue -I%T/sensorboards/mts400 -I%T/lib/Broadcast -I%T/lib/XL ib-DROUTE_PROTOCOL=0x90 -I%T/radio/rf230 -I%T/lib/internal/XMesh -DMULTIHOPROUTER=XMeshRoute r -Wall -Wshadow -DDEF_TOS_AM_GROUP=126 -Wnesc-all -target=iris -fnesc-cfile=build/iris/app.c -b oard=mts400 -DTOSH_DATA_LENGTH=39 -DTOSH_MAX_TASKS_LOG2=5 -DCC2420_TXPOWER=TXPOWER_MAX -DCC2420_ DEF_CHANNEL=11 -DIDENT_PROGRAM_NAME=GPSRec -DIDENT_PROGRAM_NAME_BYTES=71,80,83,82,101,99,0 - DIDENT_USER_ID=MirMurtuzaAli -DIDENT_USER_ID_BYTES=77,105,114,77,117,114,116,117,122,97,65,10 8,105,0 -DIDENT_HOSTNAME=namreen -DIDENT_HOSTNAME_BYTES=110,97,109,114,101,101,110,0 -DIDEN T_USER_HASH=0xeb22567dL -DIDENT_UNIX_TIME=0x47b482cbL -DRF230_DEF_CHANNEL=11 -DRF230_TXPOWER=TX POWER_MAX GPSRec.nc -lm In file included from /opt/MoteWorks/tos/sensorboards/mts400/IntersemaPressureM.nc:91, from /opt/MoteWorks/tos/sensorboards/mts400/IntersemaPressure.nc:81, from GPSRec.nc:10: In component `IntersemaPressureM': /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h: In function `init_debug': /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:17: `U2X' undeclared (first use in this functio n) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:17: (Each undeclared identifier is reported onl y once /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:17: for each function it appears in.) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:18: `UCSZ1' undeclared (first use in this funct ion) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:18: `UCSZ0' undeclared (first use in this funct ion) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:20: `TXEN' undeclared (first use in this functi on) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h: In function `init_debug_mica2dot': /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:29: `UCSZ1' undeclared (first use in this funct ion) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:29: `UCSZ0' undeclared (first use in this funct ion) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:31: `TXEN' undeclared (first use in this functi on) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h: In function `UARTPutChar': /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:38: `UDRE' undeclared (first use in this functi on) In file included from /opt/MoteWorks/tos/sensorboards/mts400/GpsPacket.nc:94, from /opt/MoteWorks/tos/sensorboards/mts400/UARTGpsPacket.nc:81, from GPSRec.nc:16: In component `GpsPacket': /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h: In function `init_debug': /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:17: `U2X' undeclared (first use in this functio n) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:18: `UCSZ1' undeclared (first use in this funct ion) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:18: `UCSZ0' undeclared (first use in this funct ion) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:20: `TXEN' undeclared (first use in this functi on) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h: In function `init_debug_mica2dot': /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:29: `UCSZ1' undeclared (first use in this funct ion) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:29: `UCSZ0' undeclared (first use in this funct ion) /opt/MoteWorks/tos/sensorboards/mts400/SODebug.h:31: `TXEN' undeclared
[Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
In the latter approach you outlined, where they share the same arbiter, if we assume that the ADC and DAC require the same reference voltage, would they still not be able to run in parallel? By parallel I meant at the same time: in the second approach if two components would request to use the the ADC and DAC at the same time (i.e. overlapping in time) the second of them would have to wait until the first is finished (it would simply get the Resource.granted event later). But both, ADC and DAC could of course be used in the same app. If both clients wanted to use the RefVolt arbiter (possible at different settings), then there's no way around. But - and that is the drawback - if the ADC client wasn't even using the RefVolt the DAC client would still have to wait for the ADC client operation to finish. Jan On Thu, Feb 14, 2008 at 5:14 PM, Sandip Bapat [EMAIL PROTECTED] wrote: Jan, In the latter approach you outlined, where they share the same arbiter, if we assume that the ADC and DAC require the same reference voltage, would they still not be able to run in parallel? Here's one scenario which might be common to a lot of sensing apps: An app uses RefVolt via Msp430AutoRVGClient to do its sensing and requires some reference (say 2.5V). Occasionally, the app also needs to use the DAC, with the same reference voltage, for instance, to change the gain setting on the sensor by varying the DAC voltage. If both used the same reference, could they still not work in parallel? Also, the DAC has a 3x multiplier setting so effectively it can produce the same range of outputs regardless of what reference voltage is being used by others (ADC). We could (re)implement the getState() function in RefVolt so that the DAC client can figure out which, if any, reference voltage is being used by the ADC and scale its inputs accordingly. But perhaps I'm missing something even more fundamental here as to why they can't run in parallel. Sandip - Original Message From: Jan Hauer [EMAIL PROTECTED] To: Vlado Handziski [EMAIL PROTECTED] Cc: TinyOS Development [EMAIL PROTECTED]; tinyos-help@Millennium.Berkeley.EDU list tinyos-help@millennium.berkeley.edu Sent: Thursday, February 14, 2008 10:42:02 AM Subject: Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2 Currently Msp430RefVoltArbiterImplP intercept the requests of ADC clients to the Resource interface, it is not really arbitrating access itself. If the DAC needs access to the RefVolt component too, then we might need a real arbiter for the RefVolt component that is independent of the actual ADC arbiter. The drawback is then that for every ADC/DAC request involving RefVolt we'd need to request two resources from two different arbiters before the client can start sampling/outputting. Alternatively we could agree that ADC and DAC share the same arbiter, which makes arbitration a lot easier, but is less efficient because you'd never be able to run ADC and DAC in parallel. Jan On Wed, Feb 13, 2008 at 7:53 PM, Vlado Handziski [EMAIL PROTECTED] wrote: The access to the refvolt generator has to be properly arbitrated between the ADC and the DAC. Pins, timers, etc. are all potential shared resource between the two. Jan, who is responsible for the msp430 ADC stack, is at a project meeting and probably has not read the thread. Please get in touch with him to coordinate. No #ifdefs please :) Vl o On Wed, Feb 13, 2008 at 6:43 PM, John Griessen [EMAIL PROTECTED] wrote: Sandip Bapat wrote: a DAC module would either have to wire to Msp430RefVoltArbiterP (in which case it also has to provide the AdcConfigure interface) or be expected to provide wiring for these interfaces. This is fine for apps that just want to use the DAC and not ADC but what if both are used and the ADC is already using Ref Voltage ? I guess we could use #ifdefs in the DAC but wouldn't having a Msp430RefVoltArbiterC that does the wirings required for Msp430RefVoltGeneratorP be better? The best thing would be to create new function in the RefVoltArbiter so it can stay on after an ADC12 or Dac12 call has requested it if another request is heard within a time period. As far as I can tell, Dac12 and Adc12 of a MSP430F1611 can both be going at once. John Griessen -- Ecosensory Austin TX tinyOS devel on: ubuntu Linux; tinyOS v2.0.2; telosb ecosens1 ___ Tinyos-devel mailing list [EMAIL PROTECTED] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel ___ Tinyos-devel mailing list [EMAIL PROTECTED] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
RE: [Tinyos-help] CC2420 Hardware ACKs
Thanks David for your reply, but now I don't know then the difference
between call or not call setAutoAck.
If I send a packet requesting the ack using the requestAck(myMsg)
comand, which means set the request flag in the FCF, I don't have to do
anything in the receiver to obtain an ack in the sender. The receiver
sends an ack automatically to the sender. So, what am i doing with this
command...sw or hw acks? Is then MDMCTRL0.AUTOACK enabled as default?
My understanding after reading the data sheet was:
- If MDMCTRL0.AUTOACK is not enabled: you have to check the request flag
and crc, if the flag is set and the crc valid, then you have to send the
ack. This meant for me SW acks.
- However, if autoack is enabled in the receiver, this mote sends the
ack automatically to the sender when the requested flag is set and crc
is valid.
Sorry for bother you again but I'm more confused now.
On Thu, 2008-02-14 at 09:34 -0700, David Moss wrote:
Also, are you calling CC2420Config.sync() to commit your hardware
acknowledgment changes to the CC2420 hardware?
call CC2420Config.setAutoAck(TRUE, TRUE);
call CC2420Config.sync();
// wait awhile
event void CC2420Config.syncDone() {
...
}
-David
-Original Message-
From: Rodolfo de Paz Alberola [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 14, 2008 9:12 AM
To: David Moss
Cc: 'tinyos-help'
Subject: RE: [Tinyos-help] CC2420 Hardware ACKs
Hi David,
On Thu, 2008-02-14 at 08:56 -0700, David Moss wrote:
Are you requesting an acknowledgment before sending?
call PacketAcknowledgements.requestAck(myMsg);
call AMSend.send(0x0, myMsg, sizeof(my_payload_t));
No, I thought that only calling the command setAutoAck
it should enable MDMCTRL0.AUTOACK leaving to the CC2420 radio chip
all the process.
This command that you mention for requesting acks I think that only
works for SW acks.
Does it the software work as expected using software acknowledgments?
Yes, I did another application using software acknowledgments and it
works fine,
but in this case I would like to use hw acks since i am trying to model
the
cc2420 radiochip which has hw acks as well.
Thanks for your help. Any idea?
Rodo
On Thu, 2008-02-14 at 08:56 -0700, David Moss wrote:
Are you requesting an acknowledgment before sending?
call PacketAcknowledgements.requestAck(myMsg);
call AMSend.send(0x0, myMsg, sizeof(my_payload_t));
Does it the software work as expected using software acknowledgments?
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rodolfo
de
Paz Alberola
Sent: Thursday, February 14, 2008 4:28 AM
To: tinyos-help
Subject: [Tinyos-help] CC2420 Hardware ACKs
Hi all,
I was trying to set Hardware ACKs for CC2420 radio chip. I did a simple
ping pong application in which I posted a task call ack() inside the
event SplitControl.startDone(error_t error).
The task call ack activates HW acknowledgements in the following way:
bool activated = TRUE;
task void ack() {
atomic{
call CC2420Config.setAutoAck(activated,activated);
if (call CC2420Config.sync() != SUCCESS) {
post ack();
}
}
However, the mote that is sending messages is not receiving any ack.
Should I do anything else to activate CC2420 HW acks?. Any help?
Regards,
-
Rodo
___
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] complile problem
When I operate the commandmake telosb, it failed and display nesc1: nesc-semantics.c:145: language_name: Assertion `0' failed. nesC: Internal error. Please send a bug report to the nesC bug mailing list at [EMAIL PROTECTED] I am confusing about it. it did not indicate which file which line make some error. I have no idea about this problem. I hope to get instruction. Thanks! Fangming he _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
I like Sandip's idea to create an arbiter that reserves use of refvolt to the first process that asks, but also responds to queries about the refvolt value. Do arbiters as they are now allow for keeping a queue of asking routines satisfied with a resource with no breaks? Would a shared arbiter for DAC and ADC be able to handle both these cases: 1. ADC is claiming a resource for a longer time than DAC asks for it, responds with volt value, DAC runs and stops before ADC stops, and ADC keeps using it uninterrupted? 2. ADC asks for a resource, then DAC asks for it, and starts sharing it, ADC stops and releases resource in a way that DAC keeps using it uninterrupted? - Original Message From: Jan Hauer [EMAIL PROTECTED] Alternatively we could agree that ADC and DAC share the same arbiter, which makes arbitration a lot easier, but is less efficient because you'd never be able to run ADC and DAC in parallel. Jan I have a third alternative, so it's not stopping me completely from going ahead. To get my soil moisture sensors supplied with 2.500 +/- .005 Volts, I could create a PWM DAC and use a program to adjust it to 2.50 V, but it seems useful to have more options. John Griessen -- Ecosensory Austin TX tinyOS devel on: ubuntu Linux; tinyOS v2.0.2; telosb ecosens1 ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] CC2420 Hardware ACKs
Hi Rodo -
By default, software acknowledgments are enabled. This means
MDMCTRL0.AUTOACK is *disabled* by default. With the hardware auto-ack's
disabled, it is left up to CC2420ReceiveP to decide whether or not to issue
a software ack (via the SACK strobe).
There are two methods to enable automatic hardware acknowledgments:
1. On boot, turn on the radio, call CC2420Config.setAutoAck(TRUE, TRUE); and
then call CC2420Config.sync() to synchronize your settings with the radio
hardware. The (TRUE, TRUE) settings of setAutoAck are saying YES, issue
acknowledgments, and YES, use hardware acknowledgements instead of software
acknowledgments.
You will receive a syncDone() event when it's done configuring the hardware.
The radio will then automatically issue acknowledgments for valid packets
that have the acknowledgment flag set in the FCF byte of the header (set by
calling PacketAcknowledgements.requestAck(myMsg);
2. Enable hardware acknowledgments at compile time. This lets you avoid the
extra coding hassle required to enable hardware acks during runtime. Do this
by editing your Makefile to include the line:
CFLAGS+=-DCC2420_HW_ACKNOWLEDGEMENTS
When you compile, hardware acknowledgments will be the default
(MDMCTRL0.AUTOACK = 1) and software acknowledgments will be disabled.
-David
-Original Message-
From: Rodolfo de Paz Alberola [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 14, 2008 1:01 PM
To: David Moss
Cc: tinyos-help
Subject: RE: [Tinyos-help] CC2420 Hardware ACKs
Thanks David for your reply, but now I don't know then the difference
between call or not call setAutoAck.
If I send a packet requesting the ack using the requestAck(myMsg)
comand, which means set the request flag in the FCF, I don't have to do
anything in the receiver to obtain an ack in the sender. The receiver
sends an ack automatically to the sender. So, what am i doing with this
command...sw or hw acks? Is then MDMCTRL0.AUTOACK enabled as default?
My understanding after reading the data sheet was:
- If MDMCTRL0.AUTOACK is not enabled: you have to check the request flag
and crc, if the flag is set and the crc valid, then you have to send the
ack. This meant for me SW acks.
- However, if autoack is enabled in the receiver, this mote sends the
ack automatically to the sender when the requested flag is set and crc
is valid.
Sorry for bother you again but I'm more confused now.
On Thu, 2008-02-14 at 09:34 -0700, David Moss wrote:
Also, are you calling CC2420Config.sync() to commit your hardware
acknowledgment changes to the CC2420 hardware?
call CC2420Config.setAutoAck(TRUE, TRUE);
call CC2420Config.sync();
// wait awhile
event void CC2420Config.syncDone() {
...
}
-David
-Original Message-
From: Rodolfo de Paz Alberola [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 14, 2008 9:12 AM
To: David Moss
Cc: 'tinyos-help'
Subject: RE: [Tinyos-help] CC2420 Hardware ACKs
Hi David,
On Thu, 2008-02-14 at 08:56 -0700, David Moss wrote:
Are you requesting an acknowledgment before sending?
call PacketAcknowledgements.requestAck(myMsg);
call AMSend.send(0x0, myMsg, sizeof(my_payload_t));
No, I thought that only calling the command setAutoAck
it should enable MDMCTRL0.AUTOACK leaving to the CC2420 radio chip
all the process.
This command that you mention for requesting acks I think that only
works for SW acks.
Does it the software work as expected using software acknowledgments?
Yes, I did another application using software acknowledgments and it
works fine,
but in this case I would like to use hw acks since i am trying to model
the
cc2420 radiochip which has hw acks as well.
Thanks for your help. Any idea?
Rodo
On Thu, 2008-02-14 at 08:56 -0700, David Moss wrote:
Are you requesting an acknowledgment before sending?
call PacketAcknowledgements.requestAck(myMsg);
call AMSend.send(0x0, myMsg, sizeof(my_payload_t));
Does it the software work as expected using software acknowledgments?
-David
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Rodolfo
de
Paz Alberola
Sent: Thursday, February 14, 2008 4:28 AM
To: tinyos-help
Subject: [Tinyos-help] CC2420 Hardware ACKs
Hi all,
I was trying to set Hardware ACKs for CC2420 radio chip. I did a simple
ping pong application in which I posted a task call ack() inside the
event SplitControl.startDone(error_t error).
The task call ack activates HW acknowledgements in the following way:
bool activated = TRUE;
task void ack() {
atomic{
call CC2420Config.setAutoAck(activated,activated);
if (call CC2420Config.sync() != SUCCESS) {
post ack();
}
}
However, the mote that is sending messages is not receiving any ack.
Should I do anything else to activate CC2420 HW acks?. Any help?
Regards,
-
Rodo
Re: [Tinyos-help] RSSI and TOSSIM
Hi all, I found this previous post from Dec. 19th in tynios-help and I would like to have some points clarified. First, I agree with Phil that the received signal strength will be (assuming waves are in phase) the addition of both desired signal's power and existing noise power level. As far as I understand TOSSIM's code, no radio stack is simulated. All the radio communications are simulated by TossimActiveMessageC, which relies in CPMModel. CPMModel computes the packet's received power with it's corresponding noise level using CPM gain/noise model. At this point is calculated the strength value as mentioned by Tal, which is included in the metadata of the packet. This strength field can then be accessed by TossimPacket interface. So, having this scenario, I understand the goal of TossimPacket interface is to give the application a chance to access radiolink quality information, am I right? Accessing received message's strength value, it is possible to have a rough idea of the link quality between the sender and the receiver. However, I am not completely comfortable with using signal strength as link quality indicator. Although I agree received signal strength is the sum of both the original signal and noise, I don't think this truly reflects link quality. It would be possible to have really noisy links (with low desired signal power level) that would have as good strength values as really good links (where desired signal power is much bigger than noise level). Instead, since signal's power level and noise level are accessible by the CPMModel component, why not use Signal To Noise Ratio? That is why I would like to know if there is any reason that makes necessary to have the strength value included in the metadata. Would not be possible to include the SNR value in that field? My point here is that, since no radio stack is simulated in TOSSIM, it would be more useful to offer a SNR indicator than the strength field. Thanks in advance for your attention, Iñigo On Wed, Dec 19, 2007 at 11:40 AM, Philip Levis [EMAIL PROTECTED] wrote: On Dec 19, 2007, at 6:09 AM, Tal Rusak wrote: Hi, I noticed that TOSSIM uses the following formula to compute RSSI: rcv-strength = (int8_t)(floor(10.0 * log(pow(10.0, power/10.0) + pow(10.0, noiseStr/10.0)) / log(10.0))); (in CpmModelC.nc) I notice that this is adding the signal power (gain) and noise levels. I am wondering if this is a true reflection of the physical phenomenon--i.e., in the CC2420, when RSSI is computed (CC2420Packet.getRssi(packet)), do signal and noise strength contribute in an additive fashion? Are there any paper or documents that support this notion? I appreciate any response in advance. It's basic wave physics. This is a very simplistic way to compose the signals. If the signals are completely in phase, it will be additive. In practice, they're not, so it's less. But trying to capture this more accurately becomes strange, especially when the two signals are not precisely the same frequency. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Fwd: [Tinyos-help] TOS_Msg length is invalid
I tried -comm serial@/dev/ttyS0:mica2 and It works perfectly!! Thank you very much Under T1 at least the micaz message that comes over the serial line has been converted to a mica2 format by TOSBase. This puts the header fields in the 'wrong' places. Try -comm serial@/dev/ttyS0:mica2 or setting the MOTECOM env variable like that. might work... MS Juan José Roncero wrote: Hi everyone! I´m working with micaz motes and tinyos-1.x. I´trying to connect them to a middleware application through Serial Forwarder tool but it outputs some errors: TOS_Msg length is invalid: header_lenght=265, real_lenght=9 modifying msg to fit Received message: FF FF 04 7D 04 00 01 00 01 I always run SerialForwarder with this command: java net.tinyos.sf.SerialForwarder -comm serial@/dev/ttyS0 My micaz application was implemented before to being used under Moteworks (windows), but I need to use it under xubunTOS. Is that possible? In addition, I`ve tried to use another default application (CountRadio) but it outputs the same error. I think it could be a problem with tinyos-1.x configuration, couldn´t it? Please, can someone help me? Thanks ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Platform: WinXP/Cygwin TinyOS version: 1.x, Boomerang Programmer: MIB510 Device(s): Mica2, MicaZ, Tmote Sensor board: homebrew ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2
What we really need I think is a way of allowing the reference voltage component have multiple owners simultaneously. Most components that provide the Resource interface are used to grant exclusive access to a device that is used to perform some operation. The reference voltage component is a bit different though in that once it is turned on and set to some value, it can be used by both the ADC and the DAC at the same time. Right now what happens when you make an ADC request is that this request implicitly requests access to the reference voltage component underneath, giving the ADC exclusive access over it and therefore blocking the DAC from getting access to it until the ADC is finished with it. Conversely, if a DAC operation were started, a similar chain of events would occur: Request of the DAC - Request of the ReferenceVoltage. I think the right way to solve this and still allow DAC operations and ADC operations to be performed in parallel is to build a custom Arbiter for the ReferenceVoltage component. This arbiter needs to be able to couple requests for access to the Reference Voltage with the value it wants to be set to (i.e. provide two parameterized resource interfaces; one for 1.5 and one for 2.5). As long as requests are only coming in through one of the two parameterized interfaces, the arbiter can signal granted to all incoming requests. Once a request is made on the other set of interfaces though, the arbiter needs to stop granting requests on the previous one and switch over to the new one once all components that have been granted requests on the other side have called release (just use a reference counter or something similar and switch over once it reaches 0). On top of this then you then have a separate (normal) arbiter for the ADC and another one for the DAC. Kevin On Thu, Feb 14, 2008 at 1:26 PM, John Griessen [EMAIL PROTECTED] wrote: I like Sandip's idea to create an arbiter that reserves use of refvolt to the first process that asks, but also responds to queries about the refvolt value. Do arbiters as they are now allow for keeping a queue of asking routines satisfied with a resource with no breaks? Would a shared arbiter for DAC and ADC be able to handle both these cases: 1. ADC is claiming a resource for a longer time than DAC asks for it, responds with volt value, DAC runs and stops before ADC stops, and ADC keeps using it uninterrupted? 2. ADC asks for a resource, then DAC asks for it, and starts sharing it, ADC stops and releases resource in a way that DAC keeps using it uninterrupted? - Original Message From: Jan Hauer [EMAIL PROTECTED] Alternatively we could agree that ADC and DAC share the same arbiter, which makes arbitration a lot easier, but is less efficient because you'd never be able to run ADC and DAC in parallel. Jan I have a third alternative, so it's not stopping me completely from going ahead. To get my soil moisture sensors supplied with 2.500 +/- .005 Volts, I could create a PWM DAC and use a program to adjust it to 2.50 V, but it seems useful to have more options. John Griessen -- Ecosensory Austin TX tinyOS devel on: ubuntu Linux; tinyOS v2.0.2; telosb ecosens1 ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- ~Kevin ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Deluge(ify) MultihopOscilloscope
What are the reported RAM / ROM sizes of your compiled app. It looks like the binary may be too large Kevin On Wed, Feb 13, 2008 at 1:33 PM, Andrew Parson O'Brien [EMAIL PROTECTED] wrote: Hello, I'm trying to modify a vanilla MultihopOscilliscope so that it may serve as a Deluge T2-enabled app. Following the manual, I included TINYOS_NP=BNP in the Makefile and added a DelugeC component in MultihopOscilliscopeAppC.nc. At first it complained about StorageVolumes.h but after I copied Blink's volumes-at45db.xml and volumes-stm25p.xml to the program directory it compiles fine. At that point I can compile, inject and successfully reboot the mote using the build/telosb/tos_image.xml file. When I try to compile it with CFLAGS=-DDELUGE_BASESTATION make telosb however, I get the following errors: msp430-ld: address 0x1010a of build/telosb/main.exe section .text is not within region text msp430-ld: section .vectors [ffe0 - ] overlaps section .text [4a00 - 00010109] msp430-ld: build/telosb/main.exe: section .vectors lma 0xffe0 overlaps previous sections make: *** [exe0] Error 1 Am I doing this properly? The GoldenImage and Blink apps work fine. I'm using tinyos-2.x's latest CVS, ncc: 1.2.4, nescc: 1.2.9, gcc: gcc (GCC) 4.1.2, msp430-ld --version reports GNU ld version 2.17 TIA! Andy ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- ~Kevin ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] RSSI and TOSSIM
On Feb 14, 2008, at 1:37 PM, Iñigo Urteaga wrote: Hi all, I found this previous post from Dec. 19th in tynios-help and I would like to have some points clarified. First, I agree with Phil that the received signal strength will be (assuming waves are in phase) the addition of both desired signal's power and existing noise power level. As far as I understand TOSSIM's code, no radio stack is simulated. All the radio communications are simulated by TossimActiveMessageC, which relies in CPMModel. CPMModel computes the packet's received power with it's corresponding noise level using CPM gain/noise model. At this point is calculated the strength value as mentioned by Tal, which is included in the metadata of the packet. This strength field can then be accessed by TossimPacket interface. So, having this scenario, I understand the goal of TossimPacket interface is to give the application a chance to access radiolink quality information, am I right? Accessing received message's strength value, it is possible to have a rough idea of the link quality between the sender and the receiver. However, I am not completely comfortable with using signal strength as link quality indicator. Although I agree received signal strength is the sum of both the original signal and noise, I don't think this truly reflects link quality. It would be possible to have really noisy links (with low desired signal power level) that would have as good strength values as really good links (where desired signal power is much bigger than noise level). Instead, since signal's power level and noise level are accessible by the CPMModel component, why not use Signal To Noise Ratio? That is why I would like to know if there is any reason that makes necessary to have the strength value included in the metadata. Would not be possible to include the SNR value in that field? My point here is that, since no radio stack is simulated in TOSSIM, it would be more useful to offer a SNR indicator than the strength field. Of course SNR is a better indicator than S+N. But all most radios let you do is sample the RF power, which is inherently S+N. The CC2420 provides an indirect measure of SNR through its chip correlation indicator (commonly but incorrectly called LQI, for link quality indicator). This measures the soft chip correlation across a couple of symbols. LQI is pretty good as a very lightweight way to see if a link has a good SNR, but as you point out, if the link has varying SNR then you don't get it on bad periods. So it turns out that a cross-layer approach -- uses layer 1 feedback as well as layer 2 delivery -- generally works better.[1] Phil [1] Rodrigo Fonseca, Omprakash Gnawali, Kyle Jamieson, and Philip Levis. Four-Bit Wireless Link Estimation. In Proceedings of the Sixth Workshop on Hot Topics in Networks (HotNets VI), 2007. http:// sing.stanford.edu/pubs/hotnets07-4b.pdf ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] net.tinyos.tools.Listen MIB600 No data is seen on theDisplay
Thank you very much. I did try the port 10002 first and it did not work; but after playing with the data rate (Speed=57600) it worked fine. Thanks again. Giri Baleri [EMAIL PROTECTED] wrote: The port 10001 of MIB600 is used to program the Mote and port 10002 is used to read data from the base Mote. You need to set the MOTECOM variable to port 10002 of your MIB600 for the PC tools to read data. Regards, Giri - From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Giovanni Abu-Aita Sent: Monday, February 11, 2008 9:29 PM To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] net.tinyos.tools.Listen MIB600 No data is seen on theDisplay hello everybody, I am running the Oscilloscope Application on the mote that is connected to MIB600. I am trying to read the packets and display them on the screen using net.tinyos.tools.Listen but nothing seems to appear on the screen. with MIB510 everything goes fine. with MIB600 I set the value of MOTECOM: export MOTECOM:[EMAIL PROTECTED]:10001 but still the Listen gives me: [EMAIL PROTECTED]:10001: resynchronising and stops there. anybody can help in this. P.S. : 1) I had this problem before and I have changed the settings of the MIB600 by browsing it: I set the Speed of channel 1 to 115200 and the speed of channel 2 57600 and i made sure the ports are 10001 and 10002 respectively. Fortunately It worked. But now I don;t know what I did wrong; I even restored to factory settings plus the changes above but it did;t work. 2) I also tried the SerialForwarder but it seemed it doesn't read the packets. Any help??? Thanks in advance - Never miss a thing. Make Yahoo your homepage. - Looking for last minute shopping deals? Find them fast with Yahoo! Search.___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Deluge T2 Dissemination
I think that slot 0 is for golden image, and its code can't be disseminated over the air. Mike On Feb 14, 2008, at 9:39 AM, Bernardo Maciel wrote: If I do it in slot 1, everything works perfectly. But with slot 0, I can only reprogram the base station and not disseminate! Am I doing anything wrong or is this a problem with Deluge T2? Any suggestions? Thanks in advance -- Bernardo Maciel [EMAIL PROTECTED] ___ 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] Can we use two genericcomm components on a single mote
HI , can any tell can we use two genericcomm on a single mote or only one due to hardware restrictions.I am using it on cricket motes I am not receiving messages from one component.I am receving with the other component.I am testing it using Listen tool.Are there any changes to be made to Listen tool to receive from two genericcomm. Thanks in advance, Regards A.Manohar 5, 50, 500, 5000 - Store N number of mails in your inbox. Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] GPS module of MTS420 not working
Hi all I have a CrossBow MTS420 board with the GPS module, and am running tinyos-1.x. I installed the XSensorMTS400 (/opt/tinyos-1.x/contrib/xbow/apps/XSensorMTS400) app on the mote, which is connected to my PC through a serial port. I then ran the XListen application , but I'm not getting any output. I did uncomment the #define MTS420 line. I also commented out the #define FEATURE_GPS_ONLY line in order to get readings from all sensors. However, the XListen app shows no output. This is all I see: $ ./xlisten -s=/dev/ttyUSB0 xlisten Ver:$Id: xlisten.c,v 1.17 2004/11/18 04:45:10 mturon Exp $ Using params: /dev/ttyUSB0 input stream opened Any ideas on what I'm doing incorrectly? Or what step I missed? Thanks! -- Nikhil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
