Re: [Tinyos-help] Hi Xiaohui Liu
Hi Sulaiman, You can use $TOSDIR/chips/msp430/timer/AlarmMicro16C.nc. -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ On Sun, Feb 9, 2014 at 12:04 PM, Sulaiman Rais sulaimanr...@yahoo.comwrote: I am having same trouble finding Microsecond timer for telosb. i have to send a gaussian signal with my telosb mote. Did u find any solution? Thanks Regards Sulaiman Rais ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Snooping does not works
Hi Faisal,
What platform are you using? Have you disabled address recognition, which
is the default in cc2420 stack?
One simply way is
CFLAGS+=-DCC2420_NO_ADDRESS_RECOGNITION
Hope this helps.
--
-Xiaohui Liu
TelosB
TinyOS 2.1.2
www.cs.wayne.edu/xliu/
On Tue, Feb 4, 2014 at 9:07 AM, Faisal Aslam faisal.as...@gmail.com wrote:
Thanks for your reply Djemma. Any help will be great.
I have tried on Telosb on a Testbed as well as also in Avroa simulator. I
can receive packets but no snooping. I have tried different network
typologies too. Here is a simple code that I have used:
--
configuration TestSnoopAppC {}
implementation {
components MainC, TestSnoopC as App;
components new AMSenderC(6);
components new AMReceiverC(6);
components new AMSnooperC(6) as Snoop;
components new TimerMilliC();
components PrintfC, SerialStartC;
components ActiveMessageC;
App.Boot - MainC.Boot;
App.Snoop - Snoop;
App.Receive - AMReceiverC;
App.AMSend - AMSenderC;
App.AMControl - ActiveMessageC;
App.MilliTimer - TimerMilliC;
App.Packet - AMSenderC;
}
-
#include Timer.h
#include printf.h
module TestSnoopC @safe() {
uses {
interface Boot;
interface Receive;
interface Receive as Snoop;
interface AMSend;
interface TimerTMilli as MilliTimer;
interface SplitControl as AMControl;
interface Packet;
}
}
implementation {
typedef nx_struct snoop_data {
nx_uint16_t counter;
} snoop_t;
message_t packet;
bool locked;
uint16_t counter = 0;
event void Boot.booted() {
call AMControl.start();
}
event void AMControl.startDone(error_t err) {
if (err == SUCCESS) {
call MilliTimer.startPeriodic(1000);
}
else {
call AMControl.start();
}
}
event void AMControl.stopDone(error_t err) {
// do nothing
}
event void MilliTimer.fired() {
uint8_t addr = 5;
counter++;
if (locked) {
return;
}
else {
snoop_t* rcm = (snoop_t*)call Packet.getPayload(packet,
sizeof(snoop_t));
if (rcm == NULL) {
return;
}
rcm-counter = counter;
if (call AMSend.send(addr, packet, sizeof(snoop_t)) == SUCCESS) {
locked = TRUE;
}
}
}
event message_t* Snoop.receive(message_t* bufPtr,
void* payload, uint8_t len) {
printf(\n%u Snoop is called. YES!, TOS_NODE_ID);
printfflush();
return bufPtr;
}
event message_t* Receive.receive(message_t* bufPtr,
void* payload, uint8_t len) {
if (len != sizeof(snoop_t)) {return bufPtr;}
else {
snoop_t* rcm = (snoop_t*)payload;
printf(\n%u Receive %u, TOS_NODE_ID, rcm-counter);
printfflush();
return bufPtr;
}
}
event void AMSend.sendDone(message_t* bufPtr, error_t error) {
if (packet == bufPtr) {
locked = FALSE;
}
}
}
On Tue, Feb 4, 2014 at 8:15 AM, Djemaa Adel a_dje...@esi.dz wrote:
hello,
give us please more specifications of your question.
are you using simulation envirement with TOSSIM, or real nodes?
good luck
2014-02-02 Faisal Aslam faisal.as...@gmail.com:
Hi,
I want to snoop the data packets. The send and unicast receive works
fine but no packets are received at the snooping nodes.
Any ideas what I may have been doing wrong?
best regards,
Faisal
___
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] Calculate time taken for a function execution.
Hi everyone, AFAIK, TOSSIM does not simulate execution time. -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ On Sat, Dec 7, 2013 at 8:23 PM, Eric Decker cire...@gmail.com wrote: you probably should also use LocalTimeMicroC for better resolution. I don't know how that behaves in the SIM environment... I know it works in the real world. On Sat, Dec 7, 2013 at 3:53 AM, nivedita datta sweetniv...@gmail.comwrote: I am trying to calculate the time taken by a function that I wrote. I am using the component LocalTimeMilliC to do this. I have added the following lines to the configuration file: *components LocalTimeMilliC; TestC.LocalTime - LocalTimeMilliC;* ...and in the module section of the implementation: *uses interface LocalTimeTMilli;* ...and in the code: *uint32_t timestamp, timestamp1;**timestamp = call LocalTime.get(); **... function called here ... ... timestamp1 = call LocalTime.get(); dbg(Boot, Function took %f millisecs\n, (ts1 - ts) ); * However, it always prints the value as 0.00 millisecs. Please let me know what am I doing wrong in this code or if there is a better method to calculate the time taken for execution of a function. Thanks for your time effort. Regards, Nivedita Datta ___ 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] Timer not fired
Hi, By log I mean a serial message sent from a mote to a PC. I'm using telosb and T2.1.1. Log fails because of a bug in my code. Sent from my iPhone On Nov 1, 2013, at 6:15 PM, Eric Decker cire...@gmail.com wrote: On Fri, Nov 1, 2013 at 2:00 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi Micha, How do you know if the timer fails to fire? I experienced the same problem before. Whenever the timer fires, a log is sent to the UART. If no log is received when a timer is supposed to fire, the timer is regarded to fail to fire. This turns out wrong because no log can be also caused by UART failure, which is the case. what is a log? What platform are you talking about and what version of the software? -Xiaohui On Friday, August 9, 2013, Ádám Erdélyi wrote: Hi Micha, could you show us the wiring code for the timer, how you initialize the timers and how you handle the firing event? Does it fire when started by other functions? (e.g. a simple Timer.start) Did you use the unique() function at the beginning? Cheers, Adam On Aug 8, 2013 3:02 PM, Micha Rappaport micha.rappap...@aau.at wrote: Hello, I am using multiple instances of the TimerMilliC component on a telosB mote. When I use the timer.startOneShot() command, the timer does not always fire. I checked the timer.isRunning() command which returns TRUE! Next I checked the times now, t0 and dt which look all promising: This works: now: 13530, t0: 13529, dt: 2500 This does not: now: 21513, to: 21512, dt: 2500 Any ideas where else the problem could lie? Thanks, Micha ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ 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
Re: [Tinyos-help] Timer not fired
Hi Micha,
How do you know if the timer fails to fire?
I experienced the same problem before. Whenever the timer fires, a log is
sent to the UART. If no log is received when a timer is supposed to fire,
the timer is regarded to fail to fire. This turns out wrong because no log
can be also caused by UART failure, which is the case.
-Xiaohui
On Friday, August 9, 2013, Ádám Erdélyi wrote:
Hi Micha,
could you show us the wiring code for the timer, how you initialize the
timers and how you handle the firing event? Does it fire when started by
other functions? (e.g. a simple Timer.start) Did you use the unique()
function at the beginning?
Cheers,
Adam
On Aug 8, 2013 3:02 PM, Micha Rappaport
micha.rappap...@aau.atjavascript:_e({}, 'cvml', 'micha.rappap...@aau.at');
wrote:
Hello,
I am using multiple instances of the TimerMilliC component on a telosB
mote. When I use the timer.startOneShot() command, the timer does not
always fire. I checked the timer.isRunning() command which returns TRUE!
Next I checked the times now, t0 and dt which look all promising:
This works:
now: 13530, t0: 13529, dt: 2500
This does not:
now: 21513, to: 21512, dt: 2500
Any ideas where else the problem could lie?
Thanks,
Micha
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu javascript:_e({}, 'cvml',
'Tinyos-help@millennium.berkeley.edu');
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
--
-Xiaohui Liu
TelosB
TinyOS 2.1.2
www.cs.wayne.edu/xliu/
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Synchronization Precision with Ftsp using 32Khz timer
Hi, What platforms are you using? If telosb, are you using CC2420X stack? The default CC2420 stack has a timestamping bug, making ftsp yield large errors. -Xiaohui On Sat, Oct 26, 2013 at 6:34 AM, wasif masood rwmas...@gmail.com wrote: Dear All, I just changed the wiring in the TestFtsp to TimeSync32kC to test for synchronization in us but I see a huge difference with the results compared to millisecond timer. In the attachment, there are PDF showing the sync, precision between 2 nodes one with 32khz timer wired while the other with millisec timer wired. Please do share your experiences coz in my point-of-view, 32khz timer do not give any stable results since I have been struggling with it from quite some time now. -- Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] What is DCO?
Hi, Thanks for the reply. If quartz crystal oscillator is used, it mostly does not drift more than 40 ppm. What about DCO's frequency drift? Cheers, -Xiaohui On Fri, May 10, 2013 at 8:22 PM, Jeonghoon Kang gadin.k...@gmail.comwrote: Most answers are on the the datasheet. Good luck ! http://www.google.co.kr/#newwindow=1sclient=psy-abq=dco+msp430+datasheetoq=dco+msp430+datasheetgs_l=hp.3...5186.6707.1.6864.10.10.0.0.0.0.138.930.6j3.9.0...0.0...1c.1.12.psy-ab.ITpRwb2Ld9Ipbx=1bav=on.2,or.r_qf.bvm=bv.46340616,d.aGcfp=c76d164efb6c1041biw=1177bih=775 2013/5/11 Xiaohui Liu xiao...@wayne.edu Hi everyone, One of the clock sources in TelosB is digitally-controlled oscillator (DCO). How does it work? How does it compare to RC oscillator and MHz quartz crystal oscillator, in terms of expense, accuracy, stability and etc.? Thanks. -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] What is DCO?
Hi, *The DCO takes something like 3.5uS to come out of sleep and when syncronized to the 32KiHz Xtal is pretty stable because it is automatically (via h/w) being tweaked to be pretty stable.* Do you have any typical number on the stability of DCO's frequency? 32KiHz Xtal usually drifts up to 40 ppm. Another follow up question, for a Xtal, given its frequency drift, it is the maximum. In reality, the frequency varies over time, even it's bounded. How fast does the frequency change, typically? (For simplicity, we can assume other factors do not change, e.g., temperature.) Even time sync protocols such as *ftsp* estimate local clock skew via linear regression, the skew seems time-varying (as Figure 5http://www.math.u-szeged.hu/tagok/mmaroti/okt/2010t/ftsp.pdfshows). Thus, it necessitates continuous re-sync. The same question applies for DCO. Thank you all for your hints. On Sun, May 12, 2013 at 4:56 PM, Eric Decker cire...@gmail.com wrote: The biggest problem with a crystal is it is a power hog. Also takes a long time to stabilize when coming out of sleep. And if you are trying for low power, you want to sleep the cpu most of the time. I think I measured an 16 MHz Xtal as taking 5 ms to stabilize coming out of sleep. I don't remember the details though. But it was enough for us to reject it in our design. The DCO takes something like 3.5uS to come out of sleep and when syncronized to the 32KiHz Xtal is pretty stable because it is automatically (via h/w) being tweaked to be pretty stable. All the above is written assuming a 5438a On Sun, May 12, 2013 at 1:31 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi, Thanks for the reply. If quartz crystal oscillator is used, it mostly does not drift more than 40 ppm. What about DCO's frequency drift? Cheers, -Xiaohui On Fri, May 10, 2013 at 8:22 PM, Jeonghoon Kang gadin.k...@gmail.comwrote: Most answers are on the the datasheet. Good luck ! http://www.google.co.kr/#newwindow=1sclient=psy-abq=dco+msp430+datasheetoq=dco+msp430+datasheetgs_l=hp.3...5186.6707.1.6864.10.10.0.0.0.0.138.930.6j3.9.0...0.0...1c.1.12.psy-ab.ITpRwb2Ld9Ipbx=1bav=on.2,or.r_qf.bvm=bv.46340616,d.aGcfp=c76d164efb6c1041biw=1177bih=775 2013/5/11 Xiaohui Liu xiao...@wayne.edu Hi everyone, One of the clock sources in TelosB is digitally-controlled oscillator (DCO). How does it work? How does it compare to RC oscillator and MHz quartz crystal oscillator, in terms of expense, accuracy, stability and etc.? Thanks. -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ 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 -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] What is DCO?
Hi everyone, One of the clock sources in TelosB is digitally-controlled oscillator (DCO). How does it work? How does it compare to RC oscillator and MHz quartz crystal oscillator, in terms of expense, accuracy, stability and etc.? Thanks. -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] does shadow fading change if obstacles are fixed?
Hello everybody, I have a generic question regarding shadowing effect and hope somebody in the mailing list can give me a hint, even though it is not TinyOS-specific. Given a RF sender and a receiver, suppose the obstacles between them are fixed, both their material and dielectric properties, does the path loss caused by their shadowing vary? If yes, what causes the variation? If not, why is it generally modeled as a log-normal random variable? We can assume there is only one path between the sender and receiver if this simplifies the question. Thanks and look forward to your reply. -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] signal attenuation depends on tx power?
Hi Sergio, So an important question is, how are you getting these 56 and 57 dB? Could you explain your setup? I can find difference up to 2 dB. A receiver is placed about 4 feet away from a sender. When the sender transmits at power level 3 (-25 dBm), the measured RSS at the receiver is -82 dBm on average (excluding noise), leading to an average attenuation of 57. While the average attenuation is 55 dB at power level 0 (0 dBm). In my experience, the levels specified by the CC2420 brochure were not very accurate. I'm just wondering if the signal attenuation difference of 1~2 dB using different tx power can be explained by measurement error (e.g., RSSI sampling precision of 1 dB and hardware variation) alone, so the theory that tx power does not affect attenuation actually holds. Do you know how many dBs can the actual tx power deviate from what the datasheet says, typically? Thank you very much and anyone else is welcome to share their perspective. -Xiaohui On Sat, Mar 23, 2013 at 1:45 AM, Sergio Donal serteck...@gmail.com wrote: Hi Xiaohui, Signal attenuation depends on the path of transmission from the transmitter to the receiver. For instance, lets say that the power amplifier is able to transmit at 10 dBm. This 10 dBm get into the antenna, which may add some gain, lets say the gain is 3dB, in some specific directions (but note that it may also loose power in a different direction). At this point is important to note the difference between absolute units (i.e., dBm which is like speaking of milli-watts, watts or horse-power) as opposed to relative units (like dB, which says how many times your signal is increased or reduced (i.e., 3 dB means that the power of the signal is multiplied by 2, while -3dB means that the signal is attenuated by 2, or multiplied by 0.5). So coming back to the scheme, in some specific direction the transmitter radiates electromagnetic waves at 13dBm (10dBm +3dB you can add them up for some reasons). The propagation channel typically attenuates the signal. And the amount of attenuation depends on some factors like distance, frequency, weather conditions, reflections in people moving around in the environment, etc. But, since attenuation is given as a relative quantity, it should not be influenced by the output power (at least in theory). Nevertheless, in practice, there may be many factors that could make variations in your measurement of the attenuation. So an important question is, how are you getting these 56 and 57 dB? Could you explain your setup? Two years ago, I used a very precise setup (plugging the RF connector of the mote into a vector-signal-analyzer in which I even was able to demodulate the signal) and tested a bunch of radios... In my experience, the levels specified by the CC2420 brochure were not very accurate. I don't find the table with the results, but I remember that the maximum output power was never achieved and that the levels were not consistent across different radios, especially the lower levels, which they were poorly mapped. Best!! Sergio On Fri, Mar 22, 2013 at 9:33 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi everyone, Does signal attenuation depend on transmission power? Based on my limited knowledge of physics, it does not. However, in measurement, noticeable difference is observed. For a sender and receiver, the measured signal attenuation of the link is *56* dB when the sender transmits at power level *3* while the signal attenuation for the same link is *57* dB at power level *31*. Another related question, according to CC2420 datasheet, the tx power is -25 dBm when power level is 3. Is the actual tx power equal to -25 dBm or there is some variation depending on the specific hardware? How large is the typical variation if any? Look forward to your explanation. Thanks in advance. -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] signal attenuation depends on tx power?
Hi everyone, Does signal attenuation depend on transmission power? Based on my limited knowledge of physics, it does not. However, in measurement, noticeable difference is observed. For a sender and receiver, the measured signal attenuation of the link is * 56* dB when the sender transmits at power level *3* while the signal attenuation for the same link is *57* dB at power level *31*. Another related question, according to CC2420 datasheet, the tx power is -25 dBm when power level is 3. Is the actual tx power equal to -25 dBm or there is some variation depending on the specific hardware? How large is the typical variation if any? Look forward to your explanation. Thanks in advance. -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] SRFOFF and SRXON strobes necessary to switch channel
Hi Janos,
You are right. Through experiments, I find there are nodes unable to
receive any new packet after channel change without turning CC2420 off and
on during channel setting. Thanks for your explanation.
-Xiaohui
On Mon, Mar 4, 2013 at 10:39 AM, Janos Sallai
janos.sal...@vanderbilt.eduwrote:
In theory, you could change the channel without turning off receive mode.
However, then you would have to prepare for some edge cases, which would
make the source code of the driver more complicated.
For example, what if you don't issue an SRFOFF, and a packet preamble
comes in after *writeFsctrl() *is called, but before the frequency
register is set. The packet will clearly not be receivced, because the
frequency change will take place in the middle of receiving the packet.
It's hard to tell by reading the cc2420 datasheet what happens to the radio
state machine in this case (page 43), and how the FIFO, FIFOP and SFD pins
would behave.
To sum it up, I guess it's safer to put the radio in IDLE state before
changing the channel frequency. I do the same in the cc2420x stack. I don't
think there's a performance penalty in doing that. The radio is deaf for 12
symbol periods after changing the channel either way -- there's no way you
to get around that. It's just physics. That's how PLLs behave.
Janos
On Sun, Mar 3, 2013 at 5:17 PM, Xiaohui Liu xiao...@wayne.edu wrote:
Hi everyone,
In CC2420 stack, channel switch can done through *
CC2420ControlP$CC2420Config$setChannel() *and then* **
CC2420ControlP$CC2420Config$sync()**, *which goes to the following event:
* event void SyncResource.granted() {
** call CSN.clr();
* * call SRFOFF.strobe();
* * writeFsctrl();
* * writeMdmctrl0();
** writeId();
* * call CSN.set();
* * call CSN.clr();
* * call SRXON.strobe();
* * call CSN.set();
** call SyncResource.release();
** post syncDone();
* * }*
Can anyone please give me some hint why SRFOFF and SRXON strobes are
necessary here? Thanks.
--
-Xiaohui Liu
TelosB
TinyOS 2.1.2
www.cs.wayne.edu/xliu/
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
--
-Xiaohui Liu
TelosB
TinyOS 2.1.2
www.cs.wayne.edu/xliu/
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] SRFOFF and SRXON strobes necessary to switch channel
Hi everyone,
In CC2420 stack, channel switch can done through *
CC2420ControlP$CC2420Config$setChannel() *and then* **
CC2420ControlP$CC2420Config$sync()**, *which goes to the following event:
* event void SyncResource.granted() {
** call CSN.clr();
** call SRFOFF.strobe();
** writeFsctrl();
** writeMdmctrl0();
** writeId();
** call CSN.set();
** call CSN.clr();
** call SRXON.strobe();
** call CSN.set();
** call SyncResource.release();
** post syncDone();
** }*
Can anyone please give me some hint why SRFOFF and SRXON strobes are
necessary here? Thanks.
--
-Xiaohui Liu
TelosB
TinyOS 2.1.2
www.cs.wayne.edu/xliu/
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Alarm fire before expiration
Hi everyone, When I set an alarm at d0 to fire dt microseconds later, it quite often fires by tens or hundreds of microseconds earlier than *d0 + dt* (based on Alarm.fired() event). My understanding is that the underlying interrupt will be generated at (d0 + dt). But because of ISR handling delay, fired() event should be signaled no later than *d0 + dt*. So the above phenomena should not occur. Can anyone please give me a hint? -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] bug to set default tx power in CC2420X stack
Hi everyone, There is a bug when you set default tx power for CC2420X stack. A quick fix is posted herehttp://xiaohuiliucuriosity.blogspot.com/2013/02/bug-to-set-tx-power-in-cc2420x-stack.htmlin case anyone else experiences it. Janos will commit it later. -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] CC2420X stack crash
Hi everyone, I'm using CC2420X stack to deliver unicast traffic over 100 links. Every sender transmits with a period of 100 ms. Around 10% of the nodes crash within 3 minutes. I have witnessed similar issuehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2011-July/051837.html before, don't know if they are related. No node crashes if CC2420 stack is used. Does anyone encounter this problem using CC2420X? Please do not hesitate to share any thought. Thank you. -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CC2420X stack crash
Hi Janos,
I tried the default RadioCountToLeds with cc2420x, with only the following
changes. Within 3 minutes, about 10% of nodes stop toggling led 2 and
crash. If MilliTimer fires every 100 ms, about 30% of nodes crash.
* event void MilliTimer.fired() {*
*counter++;*
*call Leds.led2Toggle();*
*...*
*}*
* event message_t* Receive.receive(message_t* bufPtr, *
* void* payload, uint8_t len) {*
*dbg(RadioCountToLedsC, Received packet of length %hhu.\n, len);*
*if (len != sizeof(radio_count_msg_t)) {return bufPtr;}*
*else {*
*// radio_count_msg_t* rcm = (radio_count_msg_t*)payload;*
*// if (rcm-counter 0x1) {*
*// call Leds.led0On();*
*// }*
*// else {*
*// call Leds.led0Off();*
*// }*
*// if (rcm-counter 0x2) {*
*// call Leds.led1On();*
*// }*
*// else {*
*// call Leds.led1Off();*
*// }*
*// if (rcm-counter 0x4) {*
*// call Leds.led2On();*
*// }*
*// else {*
*// call Leds.led2Off();*
*// }*
* return bufPtr;*
*}*
* }*
Please let me know if you have any idea what may go wrong. Thanks for your
reply.
-Xiaohui
On Mon, Jan 14, 2013 at 12:37 PM, Janos Sallai
sal...@isis.vanderbilt.eduwrote:
Xiaohui:
I have not seen this issue. Can you verify that RadioCountToLeds
works? It's essentially the same application that you describe, with
250ms delay instead of 100ms in your case.
Can you put together a simple application that demonstrates this
freezing behavior? I'd be more than happy to take a look at it.
Janos
On Mon, Jan 14, 2013 at 11:22 AM, Xiaohui Liu xiao...@wayne.edu wrote:
Hi everyone,
I'm using CC2420X stack to deliver unicast traffic over 100 links. Every
sender transmits with a period of 100 ms. Around 10% of the nodes crash
within 3 minutes. I have witnessed similar issue before, don't know if
they
are related. No node crashes if CC2420 stack is used. Does anyone
encounter
this problem using CC2420X? Please do not hesitate to share any thought.
Thank you.
--
-Xiaohui Liu
TelosB
TinyOS 2.1.2
www.cs.wayne.edu/xliu/
--
-Xiaohui Liu
TelosB
TinyOS 2.1.2
www.cs.wayne.edu/xliu/
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Msp430AlarmC not connected compilation error
Hi, You are certainly right. There can only be up to 3 32khz alarms when compiling with the cc2420x extra. I'll replace extra ones with microsecond alarms, which can be up to 6. This is the first time I've encounter this issue. It could take me much longer to figure this out had you not replied promptly. Thanks a lot. -Xiaohui On Tue, Jan 8, 2013 at 10:21 AM, Janos Sallai sal...@isis.vanderbilt.eduwrote: Is this all the error message you're getting? My first guess is that you're running out of 32khz physical timers. If that's the case, try using a microsecond resolution alarm instead. Janos On Mon, Jan 7, 2013 at 10:07 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi everyone, In the configuration: * components new Alarm32khz32C() as SlotTimer;* * Forwarder.SlotTimer - SlotTimer;* In the implementation module: *interface AlarmT32khz, uint32_t as SlotTimer;* The following error pops up when I launch make telosb *cc2420x* *In component `IMACForwarderC.SlotTimer.AlarmC.Msp430Alarm':* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/timer/Msp430AlarmC.nc: In function `Alarm.startAt':* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/timer/Msp430AlarmC.nc(IMACForwarderC.SlotTimer.AlarmC.Msp430Alarm):85: Msp430Timer.get not connected* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/timer/Msp430AlarmC.nc(IMACForwarderC.SlotTimer.AlarmC.Msp430Alarm):89: Msp430Compare.setEventFromNow not connected* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/timer/Msp430AlarmC.nc(IMACForwarderC.SlotTimer.AlarmC.Msp430Alarm):95: Msp430Compare.setEventFromNow not connected* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/timer/Msp430AlarmC.nc(IMACForwarderC.SlotTimer.AlarmC.Msp430Alarm):97: Msp430Compare.setEvent not connected* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/timer/Msp430AlarmC.nc(IMACForwarderC.SlotTimer.AlarmC.Msp430Alarm):99: Msp430TimerControl.clearPendingInterrupt not connected* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/timer/Msp430AlarmC.nc(IMACForwarderC.SlotTimer.AlarmC.Msp430Alarm):100: Msp430TimerControl.enableEvents not connected* *make: *** [exe0] Error 1* This occurs ONLY if ftsp (i.e., TimeSyncMicroC) is included and disappears without compilation error if no ftsp is included. Hope this helps. Thanks in advance. -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] CFLAGS vs PFLAGS
Hi everyone, What is the difference between CFLAGS and PFLAGS, if any? Some Makefiles use CFLAGS while others use PFLAGS for the same purpose, e.g., define preprocessor symbol. Here is a related discussionhttp://tinyos-help.10906.n7.nabble.com/Changing-tinyos-2-1-1-tos-chips-cc2420-transmit-td21537.html#a31485775 . Thanks in advance. -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Msp430AlarmC not connected compilation error
Hi everyone, In the configuration: * components new Alarm32khz32C() as SlotTimer;* * Forwarder.SlotTimer - SlotTimer;* In the implementation module: *interface AlarmT32khz, uint32_t as SlotTimer;* The following error pops up when I launch make telosb *cc2420x* *In component `IMACForwarderC.SlotTimer.AlarmC.Msp430Alarm':* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/timer/Msp430AlarmC.nc: In function `Alarm.startAt':* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/timer/Msp430AlarmC.nc(IMACForwarderC.SlotTimer.AlarmC.Msp430Alarm):85: Msp430Timer.get not connected* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/timer/Msp430AlarmC.nc(IMACForwarderC.SlotTimer.AlarmC.Msp430Alarm):89: Msp430Compare.setEventFromNow not connected* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/timer/Msp430AlarmC.nc(IMACForwarderC.SlotTimer.AlarmC.Msp430Alarm):95: Msp430Compare.setEventFromNow not connected* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/timer/Msp430AlarmC.nc(IMACForwarderC.SlotTimer.AlarmC.Msp430Alarm):97: Msp430Compare.setEvent not connected* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/timer/Msp430AlarmC.nc(IMACForwarderC.SlotTimer.AlarmC.Msp430Alarm):99: Msp430TimerControl.clearPendingInterrupt not connected* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/timer/Msp430AlarmC.nc(IMACForwarderC.SlotTimer.AlarmC.Msp430Alarm):100: Msp430TimerControl.enableEvents not connected* *make: *** [exe0] Error 1* This occurs ONLY if ftsp (i.e., TimeSyncMicroC) is included and disappears without compilation error if no ftsp is included. Hope this helps. Thanks in advance. -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] microsecond ftsp on TelosB without cc2420x
Hi, What is *AutoResourceAcquireLayerC* for, to acquire SPI resource? However, isn't SPI resource already accounted for in *CC2420XDriverLayerC*? Wish everyone a happy holiday. -Xiaohui On Mon, Dec 10, 2012 at 6:46 PM, Janos Sallai sal...@isis.vanderbilt.eduwrote: internals -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] cannot compile after upgrade to TinyOS 2.1.2 on MaC OS X Snow Leopard
Hi, I upgraded msp430-gcc it to 4.6.3 and got the *two source files specified*compilation error witnessed herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2011-November/052858.html. Then I upgraded nesc from 1.3.0 to 1.3.3 as suggested, and I'm getting the following error. */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/msp430hardware.h:43:26: error: legacymsp430.h: No such file or directory* *In file included from /Users/xiaohui/Dropbox/tinyos-2.1.2/tos/platforms/telosb/hardware.h:4,* * from /Users/xiaohui/Dropbox/tinyos-2.1.2/tos/system/SchedulerBasicP.nc:52,* * from /Users/xiaohui/Dropbox/tinyos-2.1.2/tos/system/TinySchedulerC.nc:51:* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/msp430hardware.h: In function `__nesc_disable_interrupt':* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/msp430hardware.h:393: warning: implicit declaration of function `dint'* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/msp430hardware.h: In function `__nesc_enable_interrupt':* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/msp430hardware.h:399: warning: implicit declaration of function `eint'* Any idea? Thank all for your reply. -Xiaohui On Wed, Dec 26, 2012 at 6:24 PM, Eric Decker cire...@gmail.com wrote: You need to get the current msp430-gcc available on macports. It is 4.6.3 On Wed, Dec 26, 2012 at 1:28 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi everyone, After I upgraded from TinyOS 2.1.1 to TinyOS 2.1.2 by replacing the distributed source filehttp://code.google.com/p/tinyos-main/source/browse/#svn%2Ftrunk, the following error prompts when I compile: *WARNING: Minimum recommended msp430-gcc version for this TinyOS release is 4.6.3!!!* *...* *In component `McuSleepC':* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/McuSleepC.nc: In function `getPowerState':* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/McuSleepC.nc:77: `TACCTL0' undeclared (first use in this function)* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/McuSleepC.nc:77: (Each undeclared identifier is reported only once* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/McuSleepC.nc:77: for each function it appears in.)* However, msp-gcc version is shown as 3.2.3. Can you please advise what other changes are necessary to complete the upgrade? Thanks in advance. -- -Xiaohui Liu TelosB OS X 10.6.8 TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ 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 -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] cannot compile after upgrade to TinyOS 2.1.2 on MaC OS X Snow Leopard
Hi, The error vanishes after: sudo port install msp430-libc Hope this is complete for archive purpose. -Xiaohui On Thu, Dec 27, 2012 at 11:25 AM, Xiaohui Liu xiao...@wayne.edu wrote: Hi, I upgraded msp430-gcc it to 4.6.3 and got the *two source files specified* compilation error witnessed herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2011-November/052858.html. Then I upgraded nesc from 1.3.0 to 1.3.3 as suggested, and I'm getting the following error. */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/msp430hardware.h:43:26: error: legacymsp430.h: No such file or directory* *In file included from /Users/xiaohui/Dropbox/tinyos-2.1.2/tos/platforms/telosb/hardware.h:4,* * from /Users/xiaohui/Dropbox/tinyos-2.1.2/tos/system/SchedulerBasicP.nc:52,* * from /Users/xiaohui/Dropbox/tinyos-2.1.2/tos/system/TinySchedulerC.nc:51:* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/msp430hardware.h: In function `__nesc_disable_interrupt':* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/msp430hardware.h:393: warning: implicit declaration of function `dint'* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/msp430hardware.h: In function `__nesc_enable_interrupt':* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/msp430hardware.h:399: warning: implicit declaration of function `eint'* Any idea? Thank all for your reply. -Xiaohui On Wed, Dec 26, 2012 at 6:24 PM, Eric Decker cire...@gmail.com wrote: You need to get the current msp430-gcc available on macports. It is 4.6.3 On Wed, Dec 26, 2012 at 1:28 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi everyone, After I upgraded from TinyOS 2.1.1 to TinyOS 2.1.2 by replacing the distributed source filehttp://code.google.com/p/tinyos-main/source/browse/#svn%2Ftrunk, the following error prompts when I compile: *WARNING: Minimum recommended msp430-gcc version for this TinyOS release is 4.6.3!!!* *...* *In component `McuSleepC':* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/McuSleepC.nc: In function `getPowerState':* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/McuSleepC.nc:77: `TACCTL0' undeclared (first use in this function)* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/McuSleepC.nc:77: (Each undeclared identifier is reported only once* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/McuSleepC.nc:77: for each function it appears in.)* However, msp-gcc version is shown as 3.2.3. Can you please advise what other changes are necessary to complete the upgrade? Thanks in advance. -- -Xiaohui Liu TelosB OS X 10.6.8 TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ 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 -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] cannot compile after upgrade to TinyOS 2.1.2 on MaC OS X Snow Leopard
Hi everyone, After I upgraded from TinyOS 2.1.1 to TinyOS 2.1.2 by replacing the distributed source filehttp://code.google.com/p/tinyos-main/source/browse/#svn%2Ftrunk, the following error prompts when I compile: *WARNING: Minimum recommended msp430-gcc version for this TinyOS release is 4.6.3!!!* *...* *In component `McuSleepC':* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/McuSleepC.nc: In function `getPowerState':* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/McuSleepC.nc:77: `TACCTL0' undeclared (first use in this function)* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/McuSleepC.nc:77: (Each undeclared identifier is reported only once* */Users/xiaohui/Dropbox/tinyos-2.1.2/tos/chips/msp430/McuSleepC.nc:77: for each function it appears in.)* However, msp-gcc version is shown as 3.2.3. Can you please advise what other changes are necessary to complete the upgrade? Thanks in advance. -- -Xiaohui Liu TelosB OS X 10.6.8 TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] microsecond ftsp on TelosB without cc2420x
Hi Janos, I'm porting my protocol from cc2420 to cc2420x. Is there any documentation on cc2420x besides the source code? Thanks. -Xiaohui On Wed, Dec 5, 2012 at 6:26 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi, Once again, thanks very much for your prompt answer. How to use FTSP, 32khz and microsecond precision, with CC2420X stack? Just make telosb cc2420x[_32khz]? -Xiaohui On Wed, Dec 5, 2012 at 6:14 PM, Janos Sallai sal...@isis.vanderbilt.eduwrote: Tasklet -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] microsecond ftsp on TelosB without cc2420x
Hi Janos,
(1) SFD capture is disabled during both transmission and reception. Does
CC2420x timestamping still work if it is enabled?
(2) What is *Tasklet* for? If it is used to make code async, then why not
just use function call directly? That is, to replace *Tasklet.schedule()* with
what is inside *Tasklet.run() {}*.
(3) What is keyword *spi_atomic*?
I'll be truly grateful if you could have me understand these questions.
-Xiaohui
On Tue, Dec 4, 2012 at 2:00 PM, Janos Sallai sal...@isis.vanderbilt.eduwrote:
transmission
--
-Xiaohui Liu
TelosB
TinyOS 2.1.2
www.cs.wayne.edu/xliu/
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] microsecond ftsp on TelosB without cc2420x
Hi, Once again, thanks very much for your prompt answer. How to use FTSP, 32khz and microsecond precision, with CC2420X stack? Just make telosb cc2420x[_32khz]? -Xiaohui On Wed, Dec 5, 2012 at 6:14 PM, Janos Sallai sal...@isis.vanderbilt.eduwrote: Tasklet -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] FW: when does CC2420 radio drop a frame?
Hello David, But in this case, the radio cannot receive/decode the frame in the first place and thus it would not be present in RXFIFO, right? By discarding, I mean flushing the frame out of RXFIFO after it is already there. Thanks for your reply. -Xiaohui On Tue, Dec 4, 2012 at 2:28 AM, David Rodenas drod...@outlook.com wrote: Hi Collision due to two transmitters sending a frame to the same receiver simultaneously (if these transmitters don't listen to each other - they are not in coverage area -, then this is called the hidden terminal problem). Regards David -- Date: Tue, 4 Dec 2012 01:07:26 -0500 From: xiao...@wayne.edu To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] when does CC2420 radio drop a frame? Hi everyone, If address recognition is enabled, the CC2420 radio hardware will drop any incoming frame failing the address recognition. Is there any other case that CC2420 discards a frame, at the hardware level? Thanks in advance. -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ 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 -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] microsecond ftsp on TelosB without cc2420x
Hi Janos, I really appreciate your invaluable clarification. Still a few questions in line. On Mon, Dec 3, 2012 at 9:39 AM, Janos Sallai sal...@isis.vanderbilt.eduwrote: Xiaohui: (1) What if a frame fails address recognition and is automatically flushed? How is this case handled? I avoided this problem by doing the address recognition in software, so there's no automatic flushing. The only thing the driver does is it signals RadioReceive.header(rxMsg), the return value of which decides whether to keep the message or discard it. Are you aware of any case other than failing address recognition that will cause CC2420 to discard a frame? If not, problem (2) (see herehttp://electronics.stackexchange.com/questions/50335/how-to-timestamp-packets-with-cc2420-and-msp430f1611) seems gone if address recognition is disabled. What about problem (1)? How is it handled in CC2420X? Regarding your question about the code in *readLengthFromRxFifo* after reading the length byte: the FastSpi interface groups a SPI read operation with the write operation of the following SPI byte transfer, so we don't need to block on a flag/interrupt to wait for completion. In this particular function, we initiate the next operation after reading the length byte. This is done for efficiency. Is is necessary for SPI to be faster than packet reception for CC2420X's timestamping mechanism to work correctly? Or it is just of performance concern? Janos On Sun, Dec 2, 2012 at 1:59 PM, Xiaohui Liu xiao...@wayne.edu wrote: Xiaohui -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] microsecond ftsp on TelosB without cc2420x
Hi, Thanks for clarifying the reception timestamping. Why is *TX_SFD_DELAY* accounted for during transmission, but not during reception? Isn't *sfdTime* the time SFD byte has been transmitted so there is no need to add *TX_SFD_DELAY*? * // adjust time32 with the time elapsed since the SFD event* * time -= sfdTime;* * time32 -= time;* * * * // adjust for delay between the STXON strobe and the transmission of the SFD* * time32 += TX_SFD_DELAY;* * * *call PacketTimeStamp.set(msg, time32);* -Xiaohui On Mon, Dec 3, 2012 at 1:45 PM, Janos Sallai sal...@isis.vanderbilt.eduwrote: FALSE -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] microsecond ftsp on TelosB without cc2420x
Hi Janos, I see. I changed the timestamping in CC2420 stack accordingly, but occasionally wrong timestamps still pop up. My speculation is that the following corner case is causing problem: __||__||_ As SFD pin activity shown above, a packet transmission ensues a packet reception. The MCU does not respond to the 1st SFD rising till after the 2nd SFD rises. After the packet is read out of RXFIFO, there is no other packet in RXFIFO and thus the timestamp of the transmitted packet is mistakenly assigned to the received packet. I'm reading CC2420X but haven't found how this case is dealt with. Please give me some hint. Thanks again. -Xiaohui On Mon, Dec 3, 2012 at 5:26 PM, Janos Sallai sal...@isis.vanderbilt.eduwrote: The hardware is fairly deterministic: After issuing the STXON strobe the SFD will be transmitted with a constant delay. It's more efficient to take a timestamp when issuing STXON and adjust it with a constant TX_SFD_DELAY than servicing an SFD interrupt. Janos On Mon, Dec 3, 2012 at 4:10 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi, Thanks for clarifying the reception timestamping. Why is *TX_SFD_DELAY* accounted for during transmission, but not during reception? Isn't *sfdTime* the time SFD byte has been transmitted so there is no need to add *TX_SFD_DELAY*? * // adjust time32 with the time elapsed since the SFD event* * time -= sfdTime;* * time32 -= time;* * * * // adjust for delay between the STXON strobe and the transmission of the SFD* * time32 += TX_SFD_DELAY;* * * *call PacketTimeStamp.set(msg, time32);* -Xiaohui On Mon, Dec 3, 2012 at 1:45 PM, Janos Sallai sal...@isis.vanderbilt.eduwrote: FALSE -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] microsecond ftsp on TelosB without cc2420x
Hi, Another question: STXON is strobed when header is loaded in TXFIFO, while the payload is loaded later. Why is there no second STXON strobe to transmit the payload? Thanks for your patience. -Xiaohui On Mon, Dec 3, 2012 at 9:44 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi Janos, I see. I changed the timestamping in CC2420 stack accordingly, but occasionally wrong timestamps still pop up. My speculation is that the following corner case is causing problem: __||__||_ As SFD pin activity shown above, a packet transmission ensues a packet reception. The MCU does not respond to the 1st SFD rising till after the 2nd SFD rises. After the packet is read out of RXFIFO, there is no other packet in RXFIFO and thus the timestamp of the transmitted packet is mistakenly assigned to the received packet. I'm reading CC2420X but haven't found how this case is dealt with. Please give me some hint. Thanks again. -Xiaohui On Mon, Dec 3, 2012 at 5:26 PM, Janos Sallai sal...@isis.vanderbilt.eduwrote: The hardware is fairly deterministic: After issuing the STXON strobe the SFD will be transmitted with a constant delay. It's more efficient to take a timestamp when issuing STXON and adjust it with a constant TX_SFD_DELAY than servicing an SFD interrupt. Janos On Mon, Dec 3, 2012 at 4:10 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi, Thanks for clarifying the reception timestamping. Why is *TX_SFD_DELAY* accounted for during transmission, but not during reception? Isn't *sfdTime* the time SFD byte has been transmitted so there is no need to add *TX_SFD_DELAY*? * // adjust time32 with the time elapsed since the SFD event* * time -= sfdTime;* * time32 -= time;* * * * // adjust for delay between the STXON strobe and the transmission of the SFD* * time32 += TX_SFD_DELAY;* * * *call PacketTimeStamp.set(msg, time32);* -Xiaohui On Mon, Dec 3, 2012 at 1:45 PM, Janos Sallai sal...@isis.vanderbilt.edu wrote: FALSE -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] when does CC2420 radio drop a frame?
Hi everyone, If address recognition is enabled, the CC2420 radio hardware will drop any incoming frame failing the address recognition. Is there any other case that CC2420 discards a frame, at the hardware level? Thanks in advance. -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] microsecond ftsp on TelosB without cc2420x
Hi Janos,
I'm looking at CC2420XDriverLayerP.nc, and I have the following questions:
(1) What if a frame fails address recognition and is automatically flushed?
How is this case handled?
(2) in the function reading the length byte
* inline cc2420X_status_t readLengthFromRxFifo(uint8_t* lengthPtr)*
* {*
* cc2420X_status_t status;*
*
*
* RADIO_ASSERT( call SpiResource.isOwner() );*
* RADIO_ASSERT( call CSN.get() == 1 );*
*
*
*
*
* call CSN.set(); // set CSN, just in clase it's not set*
* call CSN.clr(); // clear CSN, starting a multi-byte SPI command*
*
*
* // XL: wait till length byte is completely received*
* // wait for fifo to go high*
* waitForRxFifoNoTimeout();*
* *
* // issue SPI command*
* call FastSpiByte.splitWrite(CC2420X_CMD_REGISTER_READ | CC2420X_RXFIFO);*
* status.value = call FastSpiByte.splitRead();*
* call FastSpiByte.splitWrite(0);*
* *
* *lengthPtr = call FastSpiByte.splitRead();*
* *
* // XL: isn't the length byte already read, then what's going on here,
what's the next byte?*
* // start reading the next byte*
* // important! fifo pin must be checked after the previous SPI read
completed*
* waitForRxFifo();*
* call FastSpiByte.splitWrite(0);*
* return status; *
* }*
Thanks and look forward to your explanation.
-Xiaohui
On Thu, Nov 15, 2012 at 3:35 PM, Janos Sallai
janos.sal...@vanderbilt.eduwrote:
Hi,
So essentially, ftsp only works with cc2420x stack, not cc2420.
The cc2420 stack has a timestamping bug, so it won't work well.
What are the changes to the default cc2420 stack if the fix is to be
ported to it?
I can't tell that. I found the cc2420 stack to be very complicated.
Instead of trying to figure out how to fix the timestamping bug, I wrote a
complete new stack from scratch.
I find something under $TOSDIR/platforms/telosa/chips/cc2420x/ and
$TOSDIR/chips/cc2420x, but not sure which files to look at.
The file that contains the cc2420x timestamping implementation
is tos\chips\cc2420x\CC2420XDriverLayerP.nc.
Provided that the fix solves the timestamping issue, what else has to be
changed to make microsecond ftsp work with cc2420 stack?
If you can fix the timestamping issue on the cc2420 stack, then FTSP
should work correctly.
BTW, can you please also help answer my previous
questionhttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2012-October/055927.html
related
to timestamping?
That question is related to the cc2420 stack, so I can't answer this. I
more than happy to answer questions related to the cc2420x stack, though.
Janos
On Thu, Nov 15, 2012 at 2:12 PM, Xiaohui Liu xiao...@wayne.edu wrote:
Hi,
So essentially, ftsp only works with cc2420x stack, not cc2420.
What are the changes to the default cc2420 stack if the fix is to be
ported to it? I find something under
$TOSDIR/platforms/telosa/chips/cc2420x/ and $TOSDIR/chips/cc2420x, but not
sure which files to look at.
Provided that the fix solves the timestamping issue, what else has to be
changed to make microsecond ftsp work with cc2420 stack?
BTW, can you please also help answer my previous
questionhttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2012-October/055927.html
related
to timestamping?
Your help is sincerely appreciated.
-Xiaohui Liu
On Thu, Nov 15, 2012 at 2:12 PM, Janos Sallai
janos.sal...@vanderbilt.edu wrote:
There is weird bug in the timestamping code in the cc2420 stack.
Sometimes packets get timestamps that should be associated with a different
packet. A few people tried to fix it, yet unsiccessfully. That was the
primary reason why the cc2420x stack was created.
Janos
On Thu, Nov 15, 2012 at 10:48 AM, Xiaohui Liu xiao...@wayne.edu wrote:
Hi everybody,
I'm working on a TDMA protocol which requires high precision, even
32khz ftsp does not work for me. I can get microsecond precision if cc2420x
stack is used instead of the default cc2420 based on the discussions like
herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2011-April/050745.html
and herehttp://ftsp%20microseconds%20synchronization%20usign%20telosb/.
However, there are many changes of the default cc2420 driver I made, so
it's much easier for me to stick to cc2420 than to apply all changes to
cc2420x. Is microsecond-level ftsp implemented on TelosB using default
cc2420? If not, what changes are necessary to have it? Thanks for any hint
in advance.
-Xiaohui Liu
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
--
-Xiaohui Liu
TelosB
TinyOS 2.1.2
www.cs.wayne.edu/xliu/
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] attempt to fix the timestamp bug in the default CC2420 radio stack
Hi everyone, I want to timestamp each incoming packet, whose reception time is indicated by the SFD pin rising of CC2420. The SFD pin of CC2420 is connected to P4.1/TB1 of MSP430F1611 as seen from the schematic. One straightforward way is to buffer the timestamps: whenever an SFD rising edge is captured (e.g., by channel 1 of TimerB), store the captured timestamp in a queue. When each packet is read out from RXFIFO, a timestamp is dequeued and associated with it. This is actually what the default CC2420 radio driver does. There are several problems with this approach. (1) Before a captured timestamp is placed into the queue, another packet arrives and triggers a SFD rising edge, overwriting the previous timestamp. There is no timestamp for the corresponding packet. What's worse, it's unknown which remaining timestamp corresponds to which received packet. The mapping from the packet and timestamp is messed up. (2) Some packets are dropped by CC2420 (e.g., fail to pass address recognition) and not placed into RXFIFO. Nevertheless, it still generates SFD rising edge. There is no packet for the corresponding timestamp. Again, the mapping is messy. Can anyone please give me some suggestion, if any, on how to overcome these two issues and timestamp packets correctly, especially under heavy load? I'm trying to leverage the COV bit in TBCCTL1 to see if any timestamp is overwritten. My requirement can be relaxed not to timestamp all packets correctly, but a fraction of them. Your help will be sincerely appreciated. BTW, timestamping is only one small part of my protocol, which changes the default CC2420 stack extensively, thus switching to CC2420*X* stack is not a viable option for me. -- -Xiaohui Liu TelosB TinyOS 2.1.2 www.cs.wayne.edu/xliu/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] large regression computation error in FTSP
Hi everyone, Sometimes the linear regression result computed by FTSP is quite different from that computed offline. For instance, for the following reference point table, localtime offset 5021124 162575 5082335 162671 5078357 162681 5057159 162757 5054204 162756 5047944 162757 5030543 162758 5025524 162758 1) FTSP gives: offset = 40 * 10^(-6) * localtime + 162713 offset at localtime 5025524 is 162710 2) Offline gives: offset = 40.4 * 10^(-6) * localtime + 162510 offset at localtime 5025524 is 162920 It yields difference of 162920 - 162710 = 210 ticks (1 tick is about 1/32 ms), which is, unfortunately, too large for my purpose. Can anyone please advise if there is anything wrong in the linear regression computation of FTSP, or this is what can be achieved with integer arithmetic? Some threads have reported related issues (see herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-devel/2010-November/004731.htmland herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2012-September/055616.html), but I'm unsure whether the latest TinyOS distribution has fixed them. Your help will be sincerely appreciated. Best regards, -Xiaohui Liu TinyOS 2.1.2 TelosB ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] large regression computation error in FTSP
Hi Marcin, Thanks for your prompt reply. It turns out I'm using msp430-gcc 4.6.3, which works for you. Any other suggestion on what may go wrong? -Xiaohui Liu On Mon, Nov 26, 2012 at 10:24 PM, Marcin Szczodrak mar...@ieee.org wrote: Hi Xiaohui, I was digging this for a while and found the issue to be related to the compiler. See the following: http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2012-September/055731.html Best, Marcin On Mon, Nov 26, 2012 at 10:15 PM, Xiaohui Liu xiao...@wayne.edu wrote: Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] large regression computation error in FTSP
Hi Marcin, I'm using FTSP with the default CC2420 stack for ~120 TelosB motes. So far, I can get sync error (pairwise global time difference) up to 200 ticks. But my protocol requires sync error no larger than 32 ticks (or tens of ticks if this is impossible). There are two suspects that can account for this unexpected large error: (1) timestamping bug in the default CC2420 stack; (2) linear regression computation in FTSP. My protocol involves many changes to the default stack, so I would not try the alternative CC2420X stack unless doing so is even simpler than fixing FTSP with the default stack. Can you please elaborate how you managed to get FTSP working for your purpose? This may well shed some light on how I customize it for my protocol. Your assistance will be invaluable to me, and perhaps others who are struggling to get FTSP work as well as the original paper claims. -Xiaohui On Mon, Nov 26, 2012 at 10:44 PM, Marcin Szczodrak mar...@ieee.org wrote: Hi Xiaohui, I have noticed three things related to FTSP 1) you really need to give it time to synchronize 2) maybe switch to manual beacon reconfiguration and increase the number of beacons (but not too much - depends on the density of the network) 3) it never runs perfect for me on CC2420 - so after running experiments for a while and checking that everything is fine you can either accept the synchronization you get or not. Overall, I found the FTSP to be OK to get global synchronization for 100+ nodes with tolerable offset (let's say for duty-cycling), but not for something more advanced (or things like 1% duty cycling). Best, Marcin P.S. I was running a different network stack than the one from TinyOS. So I neither used the default cc2420 nor cc2420x stack. Some people may suggest to try cc2420x. On Mon, Nov 26, 2012 at 10:33 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi Marcin, Thanks for your prompt reply. It turns out I'm using msp430-gcc 4.6.3, which works for you. Any other suggestion on what may go wrong? -Xiaohui Liu On Mon, Nov 26, 2012 at 10:24 PM, Marcin Szczodrak mar...@ieee.org wrote: Hi Xiaohui, I was digging this for a while and found the issue to be related to the compiler. See the following: http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2012-September/055731.html Best, Marcin On Mon, Nov 26, 2012 at 10:15 PM, Xiaohui Liu xiao...@wayne.edu wrote: Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] microsecond ftsp on TelosB without cc2420x
Hi, Is it possible that while a packet is being received, another packet arrives? How does CC2420X stack deal with this case? Thanks. On Mon, Nov 19, 2012 at 10:45 AM, Janos Sallai janos.sal...@vanderbilt.eduwrote: The two stacks differ in how the SFD interrupts are handled on the receiver, and in when the received packet is downloaded from the radio chip's FIFO. The default stack saves the SFD timestamp in a queue. After the SFD interrupt, the default stack waits until the entire packet is received into the radio chip's FIFO buffer. Only after the entire packet has been received does it start downloading it to a message_t structure in the MCU's RAM. When the download of the packet is complete and the CRC is OK, the corresponding timestamp is removed from the queue and placed in the metadata of the message_t structure. In the default stack, FIFO download of one packet may overlap with the reception of a subsequent packet. Of course, if something goes wrong during reception (e.g. length byte corrupted, bad CRC, etc.) the timestamp corresponding to the SFD event of that particular bad message must be discarded. This timestamp might not be at either end of the timestamp queue. Peope suspect that this what's done wrong in the CC2420 code, because the timestamp mixup only happens under heavy load, when the timestamp queue is long. The CC282X stack, on the other hand, doesn't maintain a timestamp queue. If an SFD event occurs, it stays in interrupt context until the entire packet is downloaded from the radio chip's FIFO buffer. The bytes are downloaded as they are received (vs. the default stack, where the download starts after the entire packet is received). This way, if the message reception is complete, we can be sure that the correct timestamp is associated with the buffer. Janos On Sun, Nov 18, 2012 at 9:23 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi, According to this figurehttp://www.cs.wayne.edu/xliu/downloads/offset_vs_local_time.jpg, there is definitely some bug for timestamping in the default CC2420 radio stack, especially under heavy load. Can you please tell me how timestamping is done in CC2420X and how it avoids the potential bug CC2420 stack has? Thanks. On Thu, Nov 15, 2012 at 4:00 PM, Xiaohui Liu xiao...@wayne.edu wrote: Thanks. Anyone else wants to share some experience implementing microsecond ftsp on TelosB? -Xiaohui Liu On Thu, Nov 15, 2012 at 3:49 PM, Janos Sallai janos.sal...@vanderbilt.edu wrote: You will probably have to change the clock source (change T32khz to TMicro). I'm not familiar with the code, so I can't tell you where this has to be done in the code. Also, you'll have to prevent the MCU from sleeping, because the TMicro clock stops when the mote goes to sleep. Janos On Thu, Nov 15, 2012 at 2:39 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi, Thanks again. Still one question in line. On Thu, Nov 15, 2012 at 3:35 PM, Janos Sallai janos.sal...@vanderbilt.edu wrote: Hi, So essentially, ftsp only works with cc2420x stack, not cc2420. The cc2420 stack has a timestamping bug, so it won't work well. What are the changes to the default cc2420 stack if the fix is to be ported to it? I can't tell that. I found the cc2420 stack to be very complicated. Instead of trying to figure out how to fix the timestamping bug, I wrote a complete new stack from scratch. I find something under $TOSDIR/platforms/telosa/chips/cc2420x/ and $TOSDIR/chips/cc2420x, but not sure which files to look at. The file that contains the cc2420x timestamping implementation is tos\chips\cc2420x\CC2420XDriverLayerP.nc. Provided that the fix solves the timestamping issue, what else has to be changed to make microsecond ftsp work with cc2420 stack? If you can fix the timestamping issue on the cc2420 stack, then FTSP should work correctly. 32khz and millisecond ftsp should work. What about *microsecond*ftsp? What changes are necessary? BTW, can you please also help answer my previous questionhttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2012-October/055927.html related to timestamping? That question is related to the cc2420 stack, so I can't answer this. I more than happy to answer questions related to the cc2420x stack, though. Janos On Thu, Nov 15, 2012 at 2:12 PM, Xiaohui Liu xiao...@wayne.eduwrote: Hi, So essentially, ftsp only works with cc2420x stack, not cc2420. What are the changes to the default cc2420 stack if the fix is to be ported to it? I find something under $TOSDIR/platforms/telosa/chips/cc2420x/ and $TOSDIR/chips/cc2420x, but not sure which files to look at. Provided that the fix solves the timestamping issue, what else has to be changed to make microsecond ftsp work with cc2420 stack? BTW, can you please also help answer my previous questionhttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2012-October/055927.html related
Re: [Tinyos-help] microsecond ftsp on TelosB without cc2420x
Hi, I'm aware of the timing issue in the default CC2420 stack, e.g., timestamping under heavy load as this figurehttp://www.cs.wayne.edu/xliu/downloads/offset_vs_local_time.jpg shows. Consequently, FTSP is yielding up to 200 jiffies error when integrated into my protocol which generates heavy traffic, not precise enough. One choice would be fixing the timestamping bug in CC2420 and I'm trying to see how CC2420*X* avoids the bug, which may give me some hint. Thus the previous question about CC2420*X.* Another choice would be get microsecond timestamping and FTSP, but I'm not sure how much sync error this can help reduce given the timestamping bug. Any comment on this? Thanks all for your replies. -Xiaohui Liu On Mon, Nov 19, 2012 at 7:42 PM, Eric Decker cire...@gmail.com wrote: On Mon, Nov 19, 2012 at 4:21 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi, Is it possible that while a packet is being received, another packet arrives? How does CC2420X stack deal with this case? Thanks. that would have to stack in the fifo in the cc2420. I'm not sure how the driver and the cc2420 deals with being able to see the packet boundary. there are numerous timing issues and I'm not sure that the corner cases have been dealt with. good question though. I like the way you think. On Mon, Nov 19, 2012 at 10:45 AM, Janos Sallai janos.sal...@vanderbilt.edu wrote: The two stacks differ in how the SFD interrupts are handled on the receiver, and in when the received packet is downloaded from the radio chip's FIFO. The default stack saves the SFD timestamp in a queue. After the SFD interrupt, the default stack waits until the entire packet is received into the radio chip's FIFO buffer. Only after the entire packet has been received does it start downloading it to a message_t structure in the MCU's RAM. When the download of the packet is complete and the CRC is OK, the corresponding timestamp is removed from the queue and placed in the metadata of the message_t structure. In the default stack, FIFO download of one packet may overlap with the reception of a subsequent packet. Of course, if something goes wrong during reception (e.g. length byte corrupted, bad CRC, etc.) the timestamp corresponding to the SFD event of that particular bad message must be discarded. This timestamp might not be at either end of the timestamp queue. Peope suspect that this what's done wrong in the CC2420 code, because the timestamp mixup only happens under heavy load, when the timestamp queue is long. The CC282X stack, on the other hand, doesn't maintain a timestamp queue. If an SFD event occurs, it stays in interrupt context until the entire packet is downloaded from the radio chip's FIFO buffer. The bytes are downloaded as they are received (vs. the default stack, where the download starts after the entire packet is received). This way, if the message reception is complete, we can be sure that the correct timestamp is associated with the buffer. Janos On Sun, Nov 18, 2012 at 9:23 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi, According to this figurehttp://www.cs.wayne.edu/xliu/downloads/offset_vs_local_time.jpg, there is definitely some bug for timestamping in the default CC2420 radio stack, especially under heavy load. Can you please tell me how timestamping is done in CC2420X and how it avoids the potential bug CC2420 stack has? Thanks. On Thu, Nov 15, 2012 at 4:00 PM, Xiaohui Liu xiao...@wayne.edu wrote: Thanks. Anyone else wants to share some experience implementing microsecond ftsp on TelosB? -Xiaohui Liu On Thu, Nov 15, 2012 at 3:49 PM, Janos Sallai janos.sal...@vanderbilt.edu wrote: You will probably have to change the clock source (change T32khz to TMicro). I'm not familiar with the code, so I can't tell you where this has to be done in the code. Also, you'll have to prevent the MCU from sleeping, because the TMicro clock stops when the mote goes to sleep. Janos On Thu, Nov 15, 2012 at 2:39 PM, Xiaohui Liu xiao...@wayne.eduwrote: Hi, Thanks again. Still one question in line. On Thu, Nov 15, 2012 at 3:35 PM, Janos Sallai janos.sal...@vanderbilt.edu wrote: Hi, So essentially, ftsp only works with cc2420x stack, not cc2420. The cc2420 stack has a timestamping bug, so it won't work well. What are the changes to the default cc2420 stack if the fix is to be ported to it? I can't tell that. I found the cc2420 stack to be very complicated. Instead of trying to figure out how to fix the timestamping bug, I wrote a complete new stack from scratch. I find something under $TOSDIR/platforms/telosa/chips/cc2420x/ and $TOSDIR/chips/cc2420x, but not sure which files to look at. The file that contains the cc2420x timestamping implementation is tos\chips\cc2420x\CC2420XDriverLayerP.nc. Provided that the fix solves the timestamping issue, what else has to be changed to make microsecond ftsp work with cc2420 stack? If you can fix
[Tinyos-help] is timestamping working in CC2420 radio stack in TinyOS 2.1.2?
Hi everyone, I'm using packet-level time sync (T32khz) and notice even though the offset between the clock of the sender and receiver is approximately a linear function of time mostly, there are sporadic outliershttp://www.cs.wayne.edu/xliu/downloads/offset_vs_local_time.jpg. Are they normal? They can deviate from the regression line by as large as 60 ticks (1 tick is about 1/32 ms), making time sync not precise enough for my application. I suspect the problem may be caused by timestamping bug in the default CC2420 radio stack and wonder if timestamping is working in TinyOS 2.1.2. There are conflicting claims, somehttp://docs.tinyos.net/tinywiki/index.php/PacketTimeStamp_CC2420_bugindicating it is while others nothttp://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg42489.htmlhttp://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg42489.html. Can anybody give me some definite answer, please? Thanks. -Xiaohui Liu TelosB TinyOS 2.1.2 ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] microsecond ftsp on TelosB without cc2420x
Hi, According to this figurehttp://www.cs.wayne.edu/xliu/downloads/offset_vs_local_time.jpg, there is definitely some bug for timestamping in the default CC2420 radio stack, especially under heavy load. Can you please tell me how timestamping is done in CC2420X and how it avoids the potential bug CC2420 stack has? Thanks. On Thu, Nov 15, 2012 at 4:00 PM, Xiaohui Liu xiao...@wayne.edu wrote: Thanks. Anyone else wants to share some experience implementing microsecond ftsp on TelosB? -Xiaohui Liu On Thu, Nov 15, 2012 at 3:49 PM, Janos Sallai janos.sal...@vanderbilt.edu wrote: You will probably have to change the clock source (change T32khz to TMicro). I'm not familiar with the code, so I can't tell you where this has to be done in the code. Also, you'll have to prevent the MCU from sleeping, because the TMicro clock stops when the mote goes to sleep. Janos On Thu, Nov 15, 2012 at 2:39 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi, Thanks again. Still one question in line. On Thu, Nov 15, 2012 at 3:35 PM, Janos Sallai janos.sal...@vanderbilt.edu wrote: Hi, So essentially, ftsp only works with cc2420x stack, not cc2420. The cc2420 stack has a timestamping bug, so it won't work well. What are the changes to the default cc2420 stack if the fix is to be ported to it? I can't tell that. I found the cc2420 stack to be very complicated. Instead of trying to figure out how to fix the timestamping bug, I wrote a complete new stack from scratch. I find something under $TOSDIR/platforms/telosa/chips/cc2420x/ and $TOSDIR/chips/cc2420x, but not sure which files to look at. The file that contains the cc2420x timestamping implementation is tos\chips\cc2420x\CC2420XDriverLayerP.nc. Provided that the fix solves the timestamping issue, what else has to be changed to make microsecond ftsp work with cc2420 stack? If you can fix the timestamping issue on the cc2420 stack, then FTSP should work correctly. 32khz and millisecond ftsp should work. What about *microsecond* ftsp? What changes are necessary? BTW, can you please also help answer my previous questionhttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2012-October/055927.html related to timestamping? That question is related to the cc2420 stack, so I can't answer this. I more than happy to answer questions related to the cc2420x stack, though. Janos On Thu, Nov 15, 2012 at 2:12 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi, So essentially, ftsp only works with cc2420x stack, not cc2420. What are the changes to the default cc2420 stack if the fix is to be ported to it? I find something under $TOSDIR/platforms/telosa/chips/cc2420x/ and $TOSDIR/chips/cc2420x, but not sure which files to look at. Provided that the fix solves the timestamping issue, what else has to be changed to make microsecond ftsp work with cc2420 stack? BTW, can you please also help answer my previous questionhttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2012-October/055927.html related to timestamping? Your help is sincerely appreciated. -Xiaohui Liu On Thu, Nov 15, 2012 at 2:12 PM, Janos Sallai janos.sal...@vanderbilt.edu wrote: There is weird bug in the timestamping code in the cc2420 stack. Sometimes packets get timestamps that should be associated with a different packet. A few people tried to fix it, yet unsiccessfully. That was the primary reason why the cc2420x stack was created. Janos On Thu, Nov 15, 2012 at 10:48 AM, Xiaohui Liu xiao...@wayne.eduwrote: Hi everybody, I'm working on a TDMA protocol which requires high precision, even 32khz ftsp does not work for me. I can get microsecond precision if cc2420x stack is used instead of the default cc2420 based on the discussions like herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2011-April/050745.html and herehttp://ftsp%20microseconds%20synchronization%20usign%20telosb/. However, there are many changes of the default cc2420 driver I made, so it's much easier for me to stick to cc2420 than to apply all changes to cc2420x. Is microsecond-level ftsp implemented on TelosB using default cc2420? If not, what changes are necessary to have it? Thanks for any hint in advance. -Xiaohui Liu ___ 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] microsecond ftsp on TelosB without cc2420x
Hi everybody, I'm working on a TDMA protocol which requires high precision, even 32khz ftsp does not work for me. I can get microsecond precision if cc2420x stack is used instead of the default cc2420 based on the discussions like herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2011-April/050745.html and here http://ftsp%20microseconds%20synchronization%20usign%20telosb/. However, there are many changes of the default cc2420 driver I made, so it's much easier for me to stick to cc2420 than to apply all changes to cc2420x. Is microsecond-level ftsp implemented on TelosB using default cc2420? If not, what changes are necessary to have it? Thanks for any hint in advance. -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] microsecond ftsp on TelosB without cc2420x
Thanks. Anyone else wants to share some experience implementing microsecond ftsp on TelosB? -Xiaohui Liu On Thu, Nov 15, 2012 at 3:49 PM, Janos Sallai janos.sal...@vanderbilt.eduwrote: You will probably have to change the clock source (change T32khz to TMicro). I'm not familiar with the code, so I can't tell you where this has to be done in the code. Also, you'll have to prevent the MCU from sleeping, because the TMicro clock stops when the mote goes to sleep. Janos On Thu, Nov 15, 2012 at 2:39 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi, Thanks again. Still one question in line. On Thu, Nov 15, 2012 at 3:35 PM, Janos Sallai janos.sal...@vanderbilt.edu wrote: Hi, So essentially, ftsp only works with cc2420x stack, not cc2420. The cc2420 stack has a timestamping bug, so it won't work well. What are the changes to the default cc2420 stack if the fix is to be ported to it? I can't tell that. I found the cc2420 stack to be very complicated. Instead of trying to figure out how to fix the timestamping bug, I wrote a complete new stack from scratch. I find something under $TOSDIR/platforms/telosa/chips/cc2420x/ and $TOSDIR/chips/cc2420x, but not sure which files to look at. The file that contains the cc2420x timestamping implementation is tos\chips\cc2420x\CC2420XDriverLayerP.nc. Provided that the fix solves the timestamping issue, what else has to be changed to make microsecond ftsp work with cc2420 stack? If you can fix the timestamping issue on the cc2420 stack, then FTSP should work correctly. 32khz and millisecond ftsp should work. What about *microsecond* ftsp? What changes are necessary? BTW, can you please also help answer my previous questionhttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2012-October/055927.html related to timestamping? That question is related to the cc2420 stack, so I can't answer this. I more than happy to answer questions related to the cc2420x stack, though. Janos On Thu, Nov 15, 2012 at 2:12 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi, So essentially, ftsp only works with cc2420x stack, not cc2420. What are the changes to the default cc2420 stack if the fix is to be ported to it? I find something under $TOSDIR/platforms/telosa/chips/cc2420x/ and $TOSDIR/chips/cc2420x, but not sure which files to look at. Provided that the fix solves the timestamping issue, what else has to be changed to make microsecond ftsp work with cc2420 stack? BTW, can you please also help answer my previous questionhttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2012-October/055927.html related to timestamping? Your help is sincerely appreciated. -Xiaohui Liu On Thu, Nov 15, 2012 at 2:12 PM, Janos Sallai janos.sal...@vanderbilt.edu wrote: There is weird bug in the timestamping code in the cc2420 stack. Sometimes packets get timestamps that should be associated with a different packet. A few people tried to fix it, yet unsiccessfully. That was the primary reason why the cc2420x stack was created. Janos On Thu, Nov 15, 2012 at 10:48 AM, Xiaohui Liu xiao...@wayne.eduwrote: Hi everybody, I'm working on a TDMA protocol which requires high precision, even 32khz ftsp does not work for me. I can get microsecond precision if cc2420x stack is used instead of the default cc2420 based on the discussions like herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2011-April/050745.html and herehttp://ftsp%20microseconds%20synchronization%20usign%20telosb/. However, there are many changes of the default cc2420 driver I made, so it's much easier for me to stick to cc2420 than to apply all changes to cc2420x. Is microsecond-level ftsp implemented on TelosB using default cc2420? If not, what changes are necessary to have it? Thanks for any hint in advance. -Xiaohui Liu ___ 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] cannot program TelosB after setting RST/NMI pin in NMI mode
Hi everyone, I finally recovered my TelosB motes. The whole procedure is listed herehttp://xiaohuiliucuriosity.blogspot.com/2012/11/how-to-recover-telosb-motes-after.html in case anyone encounters the same issue. -Xiaohui Liu On Mon, Oct 29, 2012 at 11:20 AM, Xiaohui Liu xiao...@wayne.edu wrote: Hi, I accidentally configured RST/NMI pin from reset to NMI mode by changing $TOSROOT/tos/platforms/telosa/PlatformP.nc WDTCTL = WDTPW + WDTHOLD + WDTNMI; The BSL is not started by the BSL RESET vector if RST/NMI pin is configured for NMI functionality (NMI bit is set) according to the user's guide http://www.ti.com/lit/ug/slau319c/slau319c.pdf and erratasheethttps://docs.google.com/viewer?a=vq=cache:MZlMyl_toPQJ:www.ti.com/general/docs/lit/getliterature.tsp%3FliteratureNumber%3Dslaz141%26fileType%3Dpdf+hl=engl=uspid=blsrcid=ADGEESg1vj2eN2_9J0VEsGtFzyr3A3s260sInh4nJ9tMVNJlVxRIP-6-rTZIn0-VZU4ITxh-tHec4igG-2GhZ1fyyH6H0pHmNG0kC8KAcGahXC9WBubCT0PbU6GLbMMRqPEGbDm2Gtcnsig=AHIEtbRPXHTL688w7tvGevW3w8zDBB5FsA (many variants other than MSP430F1611 report the bug BSL5). This threadhttp://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/198966.aspx suggests some additional hardware like the MSP430 Launchpad has to be used to reprogram it. Is it possible to reprogram my motes without buying additional hardware? Thank you very much for your help. On Mon, Oct 29, 2012 at 5:14 AM, Eric Decker cire...@gmail.com wrote: On Sun, Oct 28, 2012 at 8:39 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi, After RST/NMI pin is configured in NMI mode, More details please. What do you mean the pin is configured in NMI mode? I assume you are messing with WDTCTL. TI's NMI is strange in that it can be masked off. Also: Note: Holding RST/NMI Low When configured in the NMI mode, a signal generating an NMI event should not hold the RST/NMI pin low. If a PUC occurs from a different source while the NMI signal is low, the device will be held in the reset state because a PUC changes the RST/NMI pin to the reset function. TelosB motes cannot programmed. Detailed information is shown below: */opt/tinyos-2.1.2/apps/Blink$ make telosb reinstall bsl,/dev/ttyUSB0* *cp build/telosb/main.ihex build/telosb/main.ihex.out* *installing telosb binary using bsl* *tos-bsl --telosb -c /dev/ttyUSB0 -r -e -I -p build/telosb/main.ihex.out * *MSP430 Bootstrap Loader Version: 1.39-goodfet-8* *Mass Erase...* *MSP430 Bootstrap Loader Version: 1.39-goodfet-8* *Mass Erase...* *Traceback (most recent call last):* * File /usr/bin/tos-bsl, line 1918, in module* *main(0);* * File /usr/bin/tos-bsl, line 1833, in main* *for f in toinit: f()* * File /usr/bin/tos-bsl, line 1098, in actionMassErase* *0xa506) #Required setting for mass erase!* you need to look at what is happening at this line and see what the program is expecting. * File /usr/bin/tos-bsl, line 758, in bslTxRx* *rxFrame = self.comTxRx(cmd, dataOut, len(dataOut)) #Send frame* * File /usr/bin/tos-bsl, line 440, in comTxRx* *rxHeader, rxNum = self.comRxHeader()#receive header* * File /usr/bin/tos-bsl, line 346, in comRxHeader* *if not hdr: raise BSLException(Timeout)* *__main__.BSLException: Timeout* *make: *** [program] Error 1* Can anyone please give some suggestion on how they can be programmed again? This seems also an issue for MSP430F1491http://www.ti.com/lit/er/slaz141/slaz141.pdf, as shown in bug BSL5. What exactly have you tried? Removing power should fully reset things. But if that doesn't work you may have to resort to programming the chip via the JTAG. eric -Xiaohui Liu TelosB T2.1.2 ___ 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] possible to connect to P1.1/BSLTX and P2.2/BSLRX from outside on TelosB?
Hi everyone, I cannot reprogram my TelosB motes after I accidentally configure RST/NMI pin in NMI mode as mentioned in the previous threadhttp://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg42406.html. I'm trying one approach herehttp://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/198966.aspxto recover them, which requires that TelosB's pin BSLTX and BSLRX (i.e., pin P1.1 and P2.2) to be connected to P1.6 and P1.7 of MSP430 LaunchPadhttp://processors.wiki.ti.com/index.php/MSP430_LaunchPad_%28MSP-EXP430G2%29, respectively. However, from the schematichttp://webs.cs.berkeley.edu/tos/hardware/telos/telos-revb-2004-09-27.pdf, both pins are neither exposed through expansion connectors nor JTAG. Rather, they are connected to I/O buffer. Is there anyway to achieve the connection between them and the corresponding pins on the LaunchPad? More information can be found in this threadhttp://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/p/191579/793553.aspx#793553 . Any help would be truly appreciated. Best regards, -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] cannot program TelosB after setting RST/NMI pin in NMI mode
Hi, I accidentally configured RST/NMI pin from reset to NMI mode by changing $TOSROOT/tos/platforms/telosa/PlatformP.nc WDTCTL = WDTPW + WDTHOLD + WDTNMI; The BSL is not started by the BSL RESET vector if RST/NMI pin is configured for NMI functionality (NMI bit is set) according to the user's guidehttp://www.ti.com/lit/ug/slau319c/slau319c.pdf and erratasheethttps://docs.google.com/viewer?a=vq=cache:MZlMyl_toPQJ:www.ti.com/general/docs/lit/getliterature.tsp%3FliteratureNumber%3Dslaz141%26fileType%3Dpdf+hl=engl=uspid=blsrcid=ADGEESg1vj2eN2_9J0VEsGtFzyr3A3s260sInh4nJ9tMVNJlVxRIP-6-rTZIn0-VZU4ITxh-tHec4igG-2GhZ1fyyH6H0pHmNG0kC8KAcGahXC9WBubCT0PbU6GLbMMRqPEGbDm2Gtcnsig=AHIEtbRPXHTL688w7tvGevW3w8zDBB5FsA (many variants other than MSP430F1611 report the bug BSL5). This threadhttp://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/198966.aspx suggests some additional hardware like the MSP430 Launchpad has to be used to reprogram it. Is it possible to reprogram my motes without buying additional hardware? Thank you very much for your help. On Mon, Oct 29, 2012 at 5:14 AM, Eric Decker cire...@gmail.com wrote: On Sun, Oct 28, 2012 at 8:39 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi, After RST/NMI pin is configured in NMI mode, More details please. What do you mean the pin is configured in NMI mode? I assume you are messing with WDTCTL. TI's NMI is strange in that it can be masked off. Also: Note: Holding RST/NMI Low When configured in the NMI mode, a signal generating an NMI event should not hold the RST/NMI pin low. If a PUC occurs from a different source while the NMI signal is low, the device will be held in the reset state because a PUC changes the RST/NMI pin to the reset function. TelosB motes cannot programmed. Detailed information is shown below: */opt/tinyos-2.1.2/apps/Blink$ make telosb reinstall bsl,/dev/ttyUSB0* *cp build/telosb/main.ihex build/telosb/main.ihex.out* *installing telosb binary using bsl* *tos-bsl --telosb -c /dev/ttyUSB0 -r -e -I -p build/telosb/main.ihex.out* *MSP430 Bootstrap Loader Version: 1.39-goodfet-8* *Mass Erase...* *MSP430 Bootstrap Loader Version: 1.39-goodfet-8* *Mass Erase...* *Traceback (most recent call last):* * File /usr/bin/tos-bsl, line 1918, in module* *main(0);* * File /usr/bin/tos-bsl, line 1833, in main* *for f in toinit: f()* * File /usr/bin/tos-bsl, line 1098, in actionMassErase* *0xa506) #Required setting for mass erase!* you need to look at what is happening at this line and see what the program is expecting. * File /usr/bin/tos-bsl, line 758, in bslTxRx* *rxFrame = self.comTxRx(cmd, dataOut, len(dataOut)) #Send frame* * File /usr/bin/tos-bsl, line 440, in comTxRx* *rxHeader, rxNum = self.comRxHeader()#receive header* * File /usr/bin/tos-bsl, line 346, in comRxHeader* *if not hdr: raise BSLException(Timeout)* *__main__.BSLException: Timeout* *make: *** [program] Error 1* Can anyone please give some suggestion on how they can be programmed again? This seems also an issue for MSP430F1491http://www.ti.com/lit/er/slaz141/slaz141.pdf, as shown in bug BSL5. What exactly have you tried? Removing power should fully reset things. But if that doesn't work you may have to resort to programming the chip via the JTAG. eric -Xiaohui Liu TelosB T2.1.2 ___ 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] cannot program TelosB after setting RST/NMI pin in NMI mode
Hi, After RST/NMI pin is configured in NMI mode, TelosB motes cannot programmed. Detailed information is shown below: */opt/tinyos-2.1.2/apps/Blink$ make telosb reinstall bsl,/dev/ttyUSB0* *cp build/telosb/main.ihex build/telosb/main.ihex.out* *installing telosb binary using bsl* *tos-bsl --telosb -c /dev/ttyUSB0 -r -e -I -p build/telosb/main.ihex.out* *MSP430 Bootstrap Loader Version: 1.39-goodfet-8* *Mass Erase...* *MSP430 Bootstrap Loader Version: 1.39-goodfet-8* *Mass Erase...* *Traceback (most recent call last):* * File /usr/bin/tos-bsl, line 1918, in module* *main(0);* * File /usr/bin/tos-bsl, line 1833, in main* *for f in toinit: f()* * File /usr/bin/tos-bsl, line 1098, in actionMassErase* *0xa506) #Required setting for mass erase!* * File /usr/bin/tos-bsl, line 758, in bslTxRx* *rxFrame = self.comTxRx(cmd, dataOut, len(dataOut)) #Send frame* * File /usr/bin/tos-bsl, line 440, in comTxRx* *rxHeader, rxNum = self.comRxHeader()#receive header* * File /usr/bin/tos-bsl, line 346, in comRxHeader* *if not hdr: raise BSLException(Timeout)* *__main__.BSLException: Timeout* *make: *** [program] Error 1* Can anyone please give some suggestion on how they can be programmed again? This seems also an issue for MSP430F1491http://www.ti.com/lit/er/slaz141/slaz141.pdf, as shown in bug BSL5. -Xiaohui Liu TelosB T2.1.2 ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] watchdog timer triggers reset even when disabled and no security key violation
Hi, The only explanation is that there is some memory access bug in my code, which illegally writes WDTIFG (i.e., 0x0120h) and causes security key violation. Is there any debug tool to help locate where this happens? My program is of thousands of lines, so manual check is non-trivial. Also, it changes many low-level components, so it is incompatible with TOSSIM, making gdb not an option. Please weigh in if you have any suggestion. Thank you. -Xiaohui Liu TelosB T2.1.2 On Fri, Oct 26, 2012 at 10:24 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi, One correction: In case 2), there should only be one place: /opt/tinyos-2.1.2/tos/lib/tosboot/msp430/HardwareC.nc:57:WDTCTL = 0; Sorry about the error. On Fri, Oct 26, 2012 at 6:39 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi everyone, My program is reset some time after a node boots up. After the PUC reset, IFG1 is found with WDTIFG bit set, indicating the watchdog timer triggers the reset. This can happen under two cases: 1) Watchdog timer expiration when in watchdog mode only. But when WDTCTL is read out, the lower byte is 0x80, showing WDTHOLD bit is set to 1 and watchdog timer is stopped. 2) Watchdog timer security key violation. There are two places: /opt/tinyos-2.1.2/tos/lib/tosboot/msp430/HardwareC.nc:57:WDTCTL = 0; /opt/tinyos-2.1.2/tos/lib/tosboot/msp430/ExecC.nc:53:WDTCTL = WDTPW + WDTCNTCL; But neither component HardwareC nor ExecC is used. There is no place in my program to change the default WDTCTL setting, which is disables as shown in /opt/tinyos-2.1.2/tos/platforms/telosa/PlatformP.nc: WDTCTL = WDTPW + WDTHOLD; Can anyone please help me locate what is causing this strange reset? -Xiaohui Liu TelosB T2.1.2 ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] watchdog timer triggers reset even when disabled and no security key violation
Hi everyone, My program is reset some time after a node boots up. After the PUC reset, IFG1 is found with WDTIFG bit set, indicating the watchdog timer triggers the reset. This can happen under two cases: 1) Watchdog timer expiration when in watchdog mode only. But when WDTCTL is read out, the lower byte is 0x80, showing WDTHOLD bit is set to 1 and watchdog timer is stopped. 2) Watchdog timer security key violation. There are two places: /opt/tinyos-2.1.2/tos/lib/tosboot/msp430/HardwareC.nc:57:WDTCTL = 0; /opt/tinyos-2.1.2/tos/lib/tosboot/msp430/ExecC.nc:53:WDTCTL = WDTPW + WDTCNTCL; But neither component HardwareC nor ExecC is used. There is no place in my program to change the default WDTCTL setting, which is disables as shown in /opt/tinyos-2.1.2/tos/platforms/telosa/PlatformP.nc: WDTCTL = WDTPW + WDTHOLD; Can anyone please help me locate what is causing this strange reset? -Xiaohui Liu TelosB T2.1.2 ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] watchdog timer triggers reset even when disabled and no security key violation
Hi, One correction: In case 2), there should only be one place: /opt/tinyos-2.1.2/tos/lib/tosboot/msp430/HardwareC.nc:57:WDTCTL = 0; Sorry about the error. On Fri, Oct 26, 2012 at 6:39 PM, Xiaohui Liu xiao...@wayne.edu wrote: Hi everyone, My program is reset some time after a node boots up. After the PUC reset, IFG1 is found with WDTIFG bit set, indicating the watchdog timer triggers the reset. This can happen under two cases: 1) Watchdog timer expiration when in watchdog mode only. But when WDTCTL is read out, the lower byte is 0x80, showing WDTHOLD bit is set to 1 and watchdog timer is stopped. 2) Watchdog timer security key violation. There are two places: /opt/tinyos-2.1.2/tos/lib/tosboot/msp430/HardwareC.nc:57:WDTCTL = 0; /opt/tinyos-2.1.2/tos/lib/tosboot/msp430/ExecC.nc:53:WDTCTL = WDTPW + WDTCNTCL; But neither component HardwareC nor ExecC is used. There is no place in my program to change the default WDTCTL setting, which is disables as shown in /opt/tinyos-2.1.2/tos/platforms/telosa/PlatformP.nc: WDTCTL = WDTPW + WDTHOLD; Can anyone please help me locate what is causing this strange reset? -Xiaohui Liu TelosB T2.1.2 ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] when is tx timestamp invalid
Hi everyone,
When is transmission timestamp considered invalid for a packet? AFAIK, the
only place to invalidate a packet being transmitted is in
CC2420TransmitP$CaptureSFD$captured() as the following code shows:
* /* this is the SFD for received messages */
** if ( !m_receiving sfdHigh == FALSE ) {
** sfdHigh = TRUE;
** call CaptureSFD.captureFallingEdge();
** // safe the SFD pin status for later use
** sfd_state = call SFD.get();
** call CC2420Receive.sfd( time32 );
** m_receiving = TRUE;
** m_prev_time = time;
** if ( call SFD.get() ) {
** // wait for the next interrupt before moving on
** return;
** }
** // if SFD.get() = 0, then an other interrupt happened since we
** // reconfigured CaptureSFD! Fall through
** }
**
** if ( sfdHigh == TRUE ) {
** sfdHigh = FALSE;
** call CaptureSFD.captureRisingEdge();
** m_receiving = FALSE;
** /* if sfd_state is 1, then we fell through, but at the time of
** * saving the time stamp the SFD was still high. Thus, the timestamp
** * is valid.
** * if the sfd_state is 0, then either we fell through and SFD
** * was low while we safed the time stamp, or we didn't fall through.
** * Thus, we check for the time between the two interrupts.
** * FIXME: Why 10 tics? Seams like some magic number...
** */
** if ((sfd_state == 0) (time - m_prev_time 10) ) {
** call CC2420Receive.sfd_dropped();
** if (m_msg)
** call PacketTimeStamp.clear(m_msg);
** }
** break;
** }
** }*
Can someone please help me understand what is going here, especially the
condition to regard a tx timestamp as invalid? Your help will be highly
appreciated.
-Xiaohui Liu
TelosB
TinyOS 2.1.2
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] when is tx timestamp invalid
Hi,
Just to clarify, my difficulty of understanding mainly arises from the fact
that the following code snippet seems only related to reception and thus
reception timestamping (see highlighted parts). But somehow transmission
timestamp is invalidated under some circumstances.
Please help me understand and thank you in advance.
On Thu, Oct 25, 2012 at 1:00 AM, Xiaohui Liu xiao...@wayne.edu wrote:
Hi everyone,
When is transmission timestamp considered invalid for a packet? AFAIK, the
only place to invalidate a packet being transmitted is in
CC2420TransmitP$CaptureSFD$captured() as the following code shows:
* /* this is the SFD for received messages */
** if ( !m_receiving sfdHigh == FALSE ) {
** sfdHigh = TRUE;
** call CaptureSFD.captureFallingEdge();
** // safe the SFD pin status for later use
** sfd_state = call SFD.get();
** call CC2420Receive.sfd( time32 );
** m_receiving = TRUE;
** m_prev_time = time;
** if ( call SFD.get() ) {
** // wait for the next interrupt before moving on
** return;
** }
** // if SFD.get() = 0, then an other interrupt happened since we
** // reconfigured CaptureSFD! Fall through
** }
**
** if ( sfdHigh == TRUE ) {
** sfdHigh = FALSE;
** call CaptureSFD.captureRisingEdge();
** m_receiving = FALSE;
** /* if sfd_state is 1, then we fell through, but at the time of
** * saving the time stamp the SFD was still high. Thus, the timestamp
** * is valid.
** * if the sfd_state is 0, then either we fell through and SFD
** * was low while we safed the time stamp, or we didn't fall through.
** * Thus, we check for the time between the two interrupts.
** * FIXME: Why 10 tics? Seams like some magic number...
** */
** if ((sfd_state == 0) (time - m_prev_time 10) ) {
** call CC2420Receive.sfd_dropped();
** if (m_msg)
** call PacketTimeStamp.clear(m_msg);
** }
** break;
** }
** }*
Can someone please help me understand what is going here, especially the
condition to regard a tx timestamp as invalid? Your help will be highly
appreciated.
-Xiaohui Liu
TelosB
TinyOS 2.1.2
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Internal error: Segmentation fault
Hi, After I upgrade to T2.1.2, the compiler error goes away. On Mon, Oct 22, 2012 at 1:14 AM, Xiaohui Liu xiao...@wayne.edu wrote: Hi everyone, When my program is compiled, internal error: Segmentation fault error prompts as reported herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2009-February/038529.html, herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2004-November/006480.html, and herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2009-March/038828.html. A solution is also shown herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2007-August/027578.html, attributing this error to a bug in *msp430-gcc 3.2.3* and proposing a patch. I tried to apply the patch to the source codehttp://mspgcc.cvs.sourceforge.net/viewvc/mspgcc/gcc/gcc-3.3/, but I cannot find *3.2.3*. The error seems to be fixed in *msp430-gcc 3.3*. So I tried to build *3.3*, but the *./configure* file is missing in the source code, which is required for installationhttp://mspgcc.sourceforge.net/manual/c1685.html. I also tried to upgrade msp430-gcc by apt-get install msp430-gcc-tinyos. But it is incompatible with TinyOS 2.1.1. Does anyone know where or how I can get a copy of executable *msp430-gcc*compatible with TinyOS 2.1.1? Thanks for your help in advance. Best regards, -Xiaohui Liu *msp430-gcc (GCC) 3.2.3* *tinyos 2.1.1* *Ubuntu 10.04.4* ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Internal error: Segmentation fault
Hi everyone, When my program is compiled, internal error: Segmentation fault error prompts as reported herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2009-February/038529.html, herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2004-November/006480.html, and herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2009-March/038828.html. A solution is also shown herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2007-August/027578.html, attributing this error to a bug in *msp430-gcc 3.2.3* and proposing a patch. I tried to apply the patch to the source codehttp://mspgcc.cvs.sourceforge.net/viewvc/mspgcc/gcc/gcc-3.3/, but I cannot find *3.2.3*. The error seems to be fixed in *msp430-gcc 3.3*. So I tried to build *3.3*, but the *./configure* file is missing in the source code, which is required for installationhttp://mspgcc.sourceforge.net/manual/c1685.html. I also tried to upgrade msp430-gcc by apt-get install msp430-gcc-tinyos. But it is incompatible with TinyOS 2.1.1. Does anyone know where or how I can get a copy of executable *msp430-gcc*compatible with TinyOS 2.1.1? Thanks for your help in advance. Best regards, -Xiaohui Liu *msp430-gcc (GCC) 3.2.3* *tinyos 2.1.1* *Ubuntu 10.04.4* ___ 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 handle received packets whose length field is corrupted
Thanks again for your patient reply. Please CIL. On Thu, Oct 11, 2012 at 8:57 PM, Eric Decker cire...@gmail.com wrote: On Wed, Oct 10, 2012 at 10:53 PM, Xiaohui Liu whu...@gmail.com wrote: Hi Eric, Thanks for your prompt reply. Please see my comments inline. On Wed, Oct 10, 2012 at 9:12 PM, Eric Decker cire...@gmail.com wrote: Welcome to the real world. A production/robust stack should handle these issues. I haven't spent enough time with the current cc2420 stack to know how far it was taken. I will one of these days visit this issue because I need a production quality radio stack for the CC2520 radio. So will dig into it at that time. In the meantime ... On Wed, Oct 10, 2012 at 4:05 PM, Xiaohui Liu whu...@gmail.com wrote: Hello everyone, Normally, if a packet is corrupted, the CRC is supposed to detect and discard it, at least with very high probability. However, if the corruption happens on the length field, are these issues handled by the radio stack? This issue is partially handled by the existence of a special sequence of symbols called the SFD (Start Frame Delimiter). Also if the length is corrupted the CRC will cause the packet to abort. There is a defined maximum length for a packet which will also cause the packet to abort prior to doing a CRC calculation. So if the packet is too long but below the max length, the CRC will be computed and should cause the packet to abort. Seeing the start of another frame should also cause the packet to abort. By aborting a packet, you mean the CC2420 h/w terminates its reception and the packet will not be placed at RXFIFO, or the packet is placed into RXFIFO but flushed by the CC2420 driver later? yes. Depends on the system design and how it works and what is enabled. The CC2420 is very flexible. I don't know what the current design has programmed it to do. I do know the mostly the simple default implementation was done based on what Chipcon originally provided as the reference implementation. Typically reference implementations don't handle the corner/exception cases. The problem you are describing is certainly one of the exception cases. 1) the corrupted length is larger than the actual bytes buffered in RXFIFO, and RXFIFO.beginRead() or RXFIFO.continueRead() is called to read rxFrameLength bytes from it. What could happen in this case? Underflow? There should be special signalling between the CC2420 h/w and the CC2420 driver. This signalling should tell the driver that we have an abnormal packet. Either we have received another SFD prior to the current packet finishing or that we have an underflow (we the h/w stopped seeing symbols prior to its idea of when the packet should be finished). Both of those conditions must be handled in a robust driver. I don't know how far the implementers of the current CC2420 driver took things. In the little bit of looking I've done, I haven't seen evidence that these conditions are handled. The CC2420 driver was based (from the looks of things) on some sample TI/Chipcon code that talks to the chip using some default setup. And special handling of exception processing has to be programmed into the chip special. It is actually quite capable chip. But it has to be because it is an off-load processor. (I used to design this kind of stuff (inter cpu communications, multi-processors, etc. when things were much much larger). 2) the CRC is read at the wrong offset ((buf[rxFrameLength] 7)). And it can happen to be 1, causing the corrupted packet to be signaled to upper layers as a correct packet even though it is not. I don't understand what you are saying is the behaviour. If the CRC is at the wrong offset, how can it be correct? I think one should get an indication that the packet is bad. AFAIK, there is no special signalling you mentioned above between the CC2420 h/w and the current CC2420 driver. This can happen when the h/w passes a packet with corrupted length filed to the driver. For instance, if the correct rxFameLength is 21, but it is corrupted and now becomes 20. Have you physically seen this happen? Yes. Only packets with fixed length are sent, but packets with different length are received by the default driver, passing CRC check. Out of all these packets, about 3% are actually corrupted as my measurement shows, a much higher false positive ratio than what CRC is supposed to give. This is why I started investigating this issue in the first place. Is there anyway to discard such packets with corrupted length field, maybe at the h/w level? CRC checking does not work well since the offset of CRC bit is wrong. BTW, the CRC checking does not include the length filed according to the datasheet. If the h/w is really doing this something is broken in the h/w (cc2420 module). The packet should have been aborted because of a bad CRC and the driver shouldn't have ever seen
[Tinyos-help] how to handle received packets whose length field is corrupted
Hello everyone, Normally, if a packet is corrupted, the CRC is supposed to detect and discard it, at least with very high probability. However, if the corruption happens on the length field, are these issues handled by the radio stack? 1) the corrupted length is larger than the actual bytes buffered in RXFIFO, and RXFIFO.beginRead() or RXFIFO.continueRead() is called to read rxFrameLength bytes from it. What could happen in this case? Underflow? 2) the CRC is read at the wrong offset ((buf[rxFrameLength] 7)). And it can happen to be 1, causing the corrupted packet to be signaled to upper layers as a correct packet even though it is not. 3) this has a cascade effect if there are additional packets buffered in RXFIFO after this corrupted one. Their lengths can also be mistaken because the previous packet uses a wrong boundary, identified by the wrong length field. This seems a severe issue but I haven't found any measure to cope with it in the stack. Can anyone please give me a hint? Thanks sincerely in advance. -- TelosB -Xiaohui Liu ___ 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 handle received packets whose length field is corrupted
Hi Eric, Thanks for your prompt reply. Please see my comments inline. On Wed, Oct 10, 2012 at 9:12 PM, Eric Decker cire...@gmail.com wrote: Welcome to the real world. A production/robust stack should handle these issues. I haven't spent enough time with the current cc2420 stack to know how far it was taken. I will one of these days visit this issue because I need a production quality radio stack for the CC2520 radio. So will dig into it at that time. In the meantime ... On Wed, Oct 10, 2012 at 4:05 PM, Xiaohui Liu whu...@gmail.com wrote: Hello everyone, Normally, if a packet is corrupted, the CRC is supposed to detect and discard it, at least with very high probability. However, if the corruption happens on the length field, are these issues handled by the radio stack? This issue is partially handled by the existence of a special sequence of symbols called the SFD (Start Frame Delimiter). Also if the length is corrupted the CRC will cause the packet to abort. There is a defined maximum length for a packet which will also cause the packet to abort prior to doing a CRC calculation. So if the packet is too long but below the max length, the CRC will be computed and should cause the packet to abort. Seeing the start of another frame should also cause the packet to abort. By aborting a packet, you mean the CC2420 h/w terminates its reception and the packet will not be placed at RXFIFO, or the packet is placed into RXFIFO but flushed by the CC2420 driver later? 1) the corrupted length is larger than the actual bytes buffered in RXFIFO, and RXFIFO.beginRead() or RXFIFO.continueRead() is called to read rxFrameLength bytes from it. What could happen in this case? Underflow? There should be special signalling between the CC2420 h/w and the CC2420 driver. This signalling should tell the driver that we have an abnormal packet. Either we have received another SFD prior to the current packet finishing or that we have an underflow (we the h/w stopped seeing symbols prior to its idea of when the packet should be finished). Both of those conditions must be handled in a robust driver. I don't know how far the implementers of the current CC2420 driver took things. In the little bit of looking I've done, I haven't seen evidence that these conditions are handled. The CC2420 driver was based (from the looks of things) on some sample TI/Chipcon code that talks to the chip using some default setup. And special handling of exception processing has to be programmed into the chip special. It is actually quite capable chip. But it has to be because it is an off-load processor. (I used to design this kind of stuff (inter cpu communications, multi-processors, etc. when things were much much larger). 2) the CRC is read at the wrong offset ((buf[rxFrameLength] 7)). And it can happen to be 1, causing the corrupted packet to be signaled to upper layers as a correct packet even though it is not. I don't understand what you are saying is the behaviour. If the CRC is at the wrong offset, how can it be correct? I think one should get an indication that the packet is bad. AFAIK, there is no special signalling you mentioned above between the CC2420 h/w and the current CC2420 driver. This can happen when the h/w passes a packet with corrupted length filed to the driver. For instance, if the correct rxFameLength is 21, but it is corrupted and now becomes 20. So instead of CRC failure as (buf[21] 7) indicates, CRC passes since (buf[20] 7) is mistaken for CRC, which happens to be 1. Of course, if there is special signalling, this should not happen. Note, we should also be instrumenting the behaviour of the device and there isn't any that I've found. It should also be instrumentation in the cc2420 that one can get. Stuff like how many bad packets are we seeing and or what reasons. Otherwise how does one debug what is going on. But it is difficult doing this in a severly resource constrained system. 3) this has a cascade effect if there are additional packets buffered in RXFIFO after this corrupted one. Their lengths can also be mistaken because the previous packet uses a wrong boundary, identified by the wrong length field. Shouldn't happen. Because a new SFD should cause the current packet to be closed out. It should be flagged as bogus. I don't know the details of how this works given the FIFO design of the CC2420. Do you know where I may find more information regarding the inner working of CC2420 FIFOs, namely, TXFIFO and RXFIFO? I haven't found much on the datasheet. I want to understand many details such as the layout of multiple frames in the RXFIFO. If the driver/h/w got it wrong then it is indeed a problem. If the interface between the driver and the cc2420 isn't correct, then one probably has to flush the queue and start over. Because you really don't have any other choice. For the reasons you've stated
[Tinyos-help] how to determine if there are more frames buffered in RXFIFO
Hi everybody,
The following snippet is in CC2420ReceiveP.nc.
* void waitForNextPacket() {*
*atomic {*
* if ( m_state == S_STOPPED ) {*
*call SpiResource.release();*
*return;*
* }*
* *
* atomic receivingPacket = FALSE;*
* *
* /**
* * The FIFOP pin here is high when there are 0 bytes in the RX FIFO*
* * and goes low as soon as there are bytes in the RX FIFO. The pin*
* * is inverted from what the datasheet says, and its threshold is
127.*
* * Whenever the FIFOP line goes low, as you can see from the
interrupt*
* * handler elsewhere in this module, it means we received a new
packet.*
* * If the line stays low without generating an interrupt, that means*
* * there's still more data to be received.*
* */*
* if ( ( m_missed_packets call FIFO.get() ) || !call FIFOP.get() ) {
*
*// A new packet is buffered up and ready to go*
*if ( m_missed_packets ) {*
* m_missed_packets--;*
*}*
* beginReceive();*
* } else {*
*// Wait for the next packet to arrive*
*m_state = S_STARTED;*
*m_missed_packets = 0;*
*call SpiResource.release();*
* }*
*}*
* }*
The statement in red checks if there is more frames buffered in RXFIFO. Why
not use
*if (call FIFO.get()) {*
?
Thanks in advance and await your explanation.
-- TelosB
-Xiaohui Liu
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] why issue SFLUSHRX twice to flush RXFIFO?
Hi,
This is compliant with the datasheet, which reads A SFLUSHRX command
strobe is required after a RXFIFO overflow to enable reception of new
data. Note that the SFLUSHRX command strobe should be issued *twice* to
ensure that the SFD pin goes back to its idle state.
What about when RXFIFO is not overflowed? Just one SFLUSHRX is sufficient?
What happens if SFLUSHRX when there is no byte in RXFIFO?
Essentially, I want to manually flush RXFIFO at any time, so I'm curious if
how to flush it is dependent on its status, namely, empty or not, and
overflowed or not.
Similar question is asked
herehttp://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg21417.htmlbut
no answer is given. Please help me understand. Thanks in advance for
your attention.
-Xiaohui Liu
On Tue, Sep 25, 2012 at 6:46 PM, Xiaohui Liu whu...@gmail.com wrote:
Hi everyone,
The following shows up in CC2420ReceiveP.nc to flush the RXFIFO:
*void flush() {*
* reset_state();*
* call CSN.set();*
* call CSN.clr();*
* call SFLUSHRX.strobe();*
* call SFLUSHRX.strobe();*
* call CSN.set();*
* call SpiResource.release();*
* waitForNextPacket();*
*}*
Why is SFLUSHRX strobe issued twice? Thanks for your explanation.
--
-Xiaohui Liu
--
-Xiaohui Liu
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] why issue SFLUSHRX twice to flush RXFIFO?
Hi everyone,
The following shows up in CC2420ReceiveP.nc to flush the RXFIFO:
*void flush() {*
* reset_state();*
* call CSN.set();*
* call CSN.clr();*
* call SFLUSHRX.strobe();*
* call SFLUSHRX.strobe();*
* call CSN.set();*
* call SpiResource.release();*
* waitForNextPacket();*
*}*
Why is SFLUSHRX strobe issued twice? Thanks for your explanation.
--
-Xiaohui Liu
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] hardware vs software acknowledgement
Hello everyone, Can anyone please tell the difference between h/w and s/w ack? There are discussions herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2008-February/031061.htmland herehttps://www.millennium.berkeley.edu/pipermail/tinyos-help/2008-July/034897.html, but neither gives clear explanation. More specifically, TEP 126 says: 1) This led to some issues, such as false acknowledgements where the radio chip would receive a packet and acknowledge its reception and the microcontroller would never actually receive the packet. When will this happen? 2) The current CC2420 stack uses software acknowledgements, which have a higher drop percentage. When used with the UniqueSend and UniqueReceive interfaces, dropped acknowledgements are more desirable than false acknowledgements. Received packets are always acknowledged before being filtered as a duplicate. How is drop percentage defined here? And why dropped acks are preferential over false acks? Your explanation will be sincerely appreciated. -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] WSN testbeds
You are right. On Sat, Sep 22, 2012 at 11:06 AM, wasif masood rwmas...@gmail.com wrote: those connecetions are only for debugging and logging reasons as stated there: The Ethernet connection is used as a debugging and reprogramming feature only, as nodes will generally communicate via radio. On Sat, Sep 22, 2012 at 4:46 PM, John Griessen j...@ecosensory.comwrote: On 09/22/2012 03:27 AM, wasif masood wrote: Thanks alot Xiaohui, but how can I register for that? On Sat, Sep 22, 2012 at 12:07 AM, Xiaohui Liu whu...@gmail.commailto: whu...@gmail.com wrote: Hi, You can use our testbed neteye.cs.wayne.edu http://neteye.cs.wayne.edu. http://neteye.cs.wayne.edu/neteye/home.php http://neteye.cs.wayne.edu/neteye/topology.php Suggests it needs USB connection to each mote and that USB goes to laptops. Are you up for all that? ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] WSN testbeds
Hi, You can use our testbed neteye.cs.wayne.edu. On Wed, Sep 19, 2012 at 3:24 AM, wasif masood rwmas...@gmail.com wrote: thanks Roman but I am interested in a testbed of atleast around 50 nodes, do you have anything else in your mind? On Tue, Sep 18, 2012 at 11:28 PM, Roman Lim r...@ee.ethz.ch wrote: There is for instance FlockLab @ http://www.flocklab.ethz.ch/ Cheers Roman On 09/18/2012 09:58 AM, wasif masood wrote: Hi All, I am looking for some online testbeds to test run my application on the real telosb motes. I know about Indirya and Harvard Motelab, are there any other such testbeds available for students that I can use online? Regards! Wasif Masood ___ Tinyos-help mailing listTinyos-help@millennium.berkeley.eduhttps://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 -- Wasif Masood ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] ChipSpiResource SPI release is never aborted in CC2420TransmitP.nc
Hi everyone,
CC2420TransmitP uses ChipSpiResource interface to keep hold of SPI bus when
it is expecting ACK. However, from the
code, ChipSpiResource.attemptRelease() is only called in signalDone():
* void signalDone( error_t err ) {*
*atomic m_state = S_STARTED;*
*abortSpiRelease = FALSE;*
*call ChipSpiResource.attemptRelease();*
*signal Send.sendDone( m_msg, err );*
* }*
abortSpiRelease is always FALSE when ChipSpiResource.attemptRelease() is
called, which in turn signals the following:
* async event void ChipSpiResource.releasing() {*
*if(abortSpiRelease) {*
* call ChipSpiResource.abortRelease();*
*}*
* }*
Because abortSpiRelease is FALSE, ChipSpiResource.abortRelease() is never
called.
The only place that abortSpiRelease is set TRUE is after the SFD is first
triggered:
*if ( (call CC2420PacketBody.getHeader( m_msg ))-fcf ( 1
IEEE154_FCF_ACK_REQ ) ) {*
* // This is an ack packet, don't release the chip's SPI bus lock.*
* abortSpiRelease = TRUE;*
*}*
*releaseSpiResource();*
Should *releaseSpiResource()* be replaced with *call
ChipSpiResource.abortRelease()* here? Any response is appreciated.
--
-Xiaohui Liu
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] make channel switch delay deterministic on TelosB
Hi everyone, I have been stuck by this issue for quite a few days and tried many options. Still, none of them works as PIPhttp://www.cse.unl.edu/~zzhong/F12CSCE990/paper/PIPMACSenSys10.pdfdoes. Can anyone please help? On Fri, Sep 14, 2012 at 1:20 AM, Xiaohui Liu whu...@gmail.com wrote: Hi, I removed the default resource arbitration of SPI bus. More specifically, all SPI resources are provided by a single instance of CC2420SpiC. SPI resource is only requested for the first time, after that, it is never released. But CC2420ReceiveP gets stuck. In particular, calls to RXFIFO.beginRead() or RXFIFO.continueRead() sometimes fail to signal RXFIFO.readDone() later. Can anyone please give me some hint on where things may go wrong? Thanks very much in advance. On Tue, Sep 11, 2012 at 2:31 AM, Eric Decker cire...@gmail.com wrote: On Mon, Sep 10, 2012 at 11:28 PM, Eric Decker cire...@gmail.com wrote: you might try getting rid of the arbitration that is used by default. That is make sure that the only thing hanging off USART0 is the CC2420 and then get rid of the resource arbiter that by default is used on the TelosB code. The simplest way to do this is to use Resource.immediateRequest and then never release it. As long as your code is running as a task (the default programming paradigm in TinyOS (for very good reasons)) you will have potentially non-deterministic timing. It depends on what else has already been posted to the task queue. The current architecture of the code may not be capable of doing what you are trying to do. I said MAY NOT. It depends on the timing constraints/requirements that you need for your algorithm to work properly. eric On Mon, Sep 10, 2012 at 8:44 PM, Xiaohui Liu whu...@gmail.com wrote: Hi, To be precise, my channel switch delay is defined as the interval from when CC2420Config.sync() is called to CC2420Config.syncDone() event is triggered. On Mon, Sep 10, 2012 at 11:02 PM, Xiaohui Liu whu...@gmail.com wrote: Hi everyone, I'm developing a protocol which requires fast switch between two channels. But I find the channel switch delay varies significantly from 16 to 600 jiffies, causing the sender and receiver out of sync. The major cause is the non-deterministic delay to access the SPI bus, whose distribution is long-tailed. Can anyone please share his/her experience on how to make channel switch delay more deterministic? This may be a basic issue for multi-channel protocols as discussed in related threads herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2012-May/054737.html and herehttps://www.millennium.berkeley.edu/pipermail/tinyos-help/2010-October/048160.html . One way I'm trying is to circumvent the resource arbitration of SPI bus since it is merely used to access cc2420 in TelosB as seen in the schematichttp://webs.cs.berkeley.edu/tos/hardware/telos/telos-revb-2004-09-27.pdf . Any hint will be sincerely appreciated. Cheers, -Xiaohui Liu -- -Xiaohui Liu -- Eric B. Decker Senior (over 50 :-) Researcher -- Eric B. Decker Senior (over 50 :-) Researcher -- -Xiaohui Liu -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] make channel switch delay deterministic on TelosB
Hi, I removed the default resource arbitration of SPI bus. More specifically, all SPI resources are provided by a single instance of CC2420SpiC. SPI resource is only requested for the first time, after that, it is never released. But CC2420ReceiveP gets stuck. In particular, calls to RXFIFO.beginRead() or RXFIFO.continueRead() sometimes fail to signal RXFIFO.readDone() later. Can anyone please give me some hint on where things may go wrong? Thanks very much in advance. On Tue, Sep 11, 2012 at 2:31 AM, Eric Decker cire...@gmail.com wrote: On Mon, Sep 10, 2012 at 11:28 PM, Eric Decker cire...@gmail.com wrote: you might try getting rid of the arbitration that is used by default. That is make sure that the only thing hanging off USART0 is the CC2420 and then get rid of the resource arbiter that by default is used on the TelosB code. The simplest way to do this is to use Resource.immediateRequest and then never release it. As long as your code is running as a task (the default programming paradigm in TinyOS (for very good reasons)) you will have potentially non-deterministic timing. It depends on what else has already been posted to the task queue. The current architecture of the code may not be capable of doing what you are trying to do. I said MAY NOT. It depends on the timing constraints/requirements that you need for your algorithm to work properly. eric On Mon, Sep 10, 2012 at 8:44 PM, Xiaohui Liu whu...@gmail.com wrote: Hi, To be precise, my channel switch delay is defined as the interval from when CC2420Config.sync() is called to CC2420Config.syncDone() event is triggered. On Mon, Sep 10, 2012 at 11:02 PM, Xiaohui Liu whu...@gmail.com wrote: Hi everyone, I'm developing a protocol which requires fast switch between two channels. But I find the channel switch delay varies significantly from 16 to 600 jiffies, causing the sender and receiver out of sync. The major cause is the non-deterministic delay to access the SPI bus, whose distribution is long-tailed. Can anyone please share his/her experience on how to make channel switch delay more deterministic? This may be a basic issue for multi-channel protocols as discussed in related threads herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2012-May/054737.html and herehttps://www.millennium.berkeley.edu/pipermail/tinyos-help/2010-October/048160.html . One way I'm trying is to circumvent the resource arbitration of SPI bus since it is merely used to access cc2420 in TelosB as seen in the schematichttp://webs.cs.berkeley.edu/tos/hardware/telos/telos-revb-2004-09-27.pdf . Any hint will be sincerely appreciated. Cheers, -Xiaohui Liu -- -Xiaohui Liu -- Eric B. Decker Senior (over 50 :-) Researcher -- Eric B. Decker Senior (over 50 :-) Researcher -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] some questions regarding USART on TelosB
Thank you for your patient and clear reply. I'll try my best to improve :-) On Tue, Sep 11, 2012 at 2:24 AM, Eric Decker cire...@gmail.com wrote: On Mon, Sep 10, 2012 at 8:47 PM, Xiaohui Liu whu...@gmail.com wrote: One additional comment. 3) Can USART0 and USART1 be used in parallel? yes. look at the data sheet. *So SPI can be accessed even when UART is transmitting or receiving since they are dealt with independent USART modules?* That is correct. But you really should practice being more precise. It was clear from the context what you are asking. But it would be mo' better to say, the CC2420 can be accessed via its SPI bus implemented by USART0 running in SPI mode while at the same time USART1 is running in UART mode. If I didn't already know what you are talking about I would have to say know because a USART module can't be running in SPI and UART mode simultaneously. Practice clearer communications. I assume english isn't your first language (your name), very good english by the way. eric -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] some questions regarding USART on TelosB
Thank you for your prompt and helpful reply. CIL. On Mon, Sep 10, 2012 at 1:25 AM, Eric Decker cire...@gmail.com wrote: On Sun, Sep 9, 2012 at 9:39 PM, Xiaohui Liu whu...@gmail.com wrote: Hello all, I have a few things uncertain about USART on TelosB. 1) This may be naive, but I'm really curious why USART is needed in the first place. Why can't the CPU talk to, say, CC2420 directly since they are wired togetherhttp://webs.cs.berkeley.edu/tos/hardware/telos/telos-revb-2004-09-27.pdf ? Huh? Well take a look at the 1611 data sheet. The USART hardware provides various functions but not at the same time. The CPU talks to the CC2420 through the USART as SPI. Read the TI data sheet and the user manual. And look at the telosb schematic. From page 6 of the datasheethttp://www.ti.com/lit/ds/symlink/msp430f1611.pdf showing functional block diagram of MSP430F16x, P3 and USART0 seem to be separated. But from the schematichttp://webs.cs.berkeley.edu/tos/hardware/telos/telos-revb-2004-09-27.pdf, P3.1 is used as SIMO signal when USART0 is configured as SPI mode. Is this because in TelosB, USART0's SIMO pin is physically wired to P3.1? 2) What components/devices/peripherals are communicating with CPU via USART? Via which one (USART0 or USART1) and in which mode (UART, SPI, or I2C)? look at the schematic. USART0 is connected to CC2420 in SPI or I2C mode. Its UART mode is not used. USART1 is connected to USB in UART mode. Its SPI mode is not used. 3) Can USART0 and USART1 be used in parallel? yes. look at the data sheet. For instance, can a strobe be sent to CC2420 using USART0 while the RSSI register on CC2420 is being read using USART1? huh again. I beleive a strobe is a message sent to the CC2420 but may also use a directly wired pin. The cc2420 is wired via only one set of hardware so your suggestion is non-sensical. Your explanation will be highly appreciated. -Xiaohui Liu ___ 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 -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] make channel switch delay deterministic on TelosB
Hi everyone, I'm developing a protocol which requires fast switch between two channels. But I find the channel switch delay varies significantly from 16 to 600 jiffies, causing the sender and receiver out of sync. The major cause is the non-deterministic delay to access the SPI bus, whose distribution is long-tailed. Can anyone please share his/her experience on how to make channel switch delay more deterministic? This may be a basic issue for multi-channel protocols as discussed in related threads herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2012-May/054737.html and herehttps://www.millennium.berkeley.edu/pipermail/tinyos-help/2010-October/048160.html . One way I'm trying is to circumvent the resource arbitration of SPI bus since it is merely used to access cc2420 in TelosB as seen in the schematichttp://webs.cs.berkeley.edu/tos/hardware/telos/telos-revb-2004-09-27.pdf . Any hint will be sincerely appreciated. Cheers, -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] make channel switch delay deterministic on TelosB
Hi, To be precise, my channel switch delay is defined as the interval from when CC2420Config.sync() is called to CC2420Config.syncDone() event is triggered. On Mon, Sep 10, 2012 at 11:02 PM, Xiaohui Liu whu...@gmail.com wrote: Hi everyone, I'm developing a protocol which requires fast switch between two channels. But I find the channel switch delay varies significantly from 16 to 600 jiffies, causing the sender and receiver out of sync. The major cause is the non-deterministic delay to access the SPI bus, whose distribution is long-tailed. Can anyone please share his/her experience on how to make channel switch delay more deterministic? This may be a basic issue for multi-channel protocols as discussed in related threads herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2012-May/054737.html and herehttps://www.millennium.berkeley.edu/pipermail/tinyos-help/2010-October/048160.html . One way I'm trying is to circumvent the resource arbitration of SPI bus since it is merely used to access cc2420 in TelosB as seen in the schematichttp://webs.cs.berkeley.edu/tos/hardware/telos/telos-revb-2004-09-27.pdf . Any hint will be sincerely appreciated. Cheers, -Xiaohui Liu -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] some questions regarding USART on TelosB
One additional comment. On Mon, Sep 10, 2012 at 10:25 PM, Xiaohui Liu whu...@gmail.com wrote: Thank you for your prompt and helpful reply. CIL. On Mon, Sep 10, 2012 at 1:25 AM, Eric Decker cire...@gmail.com wrote: On Sun, Sep 9, 2012 at 9:39 PM, Xiaohui Liu whu...@gmail.com wrote: Hello all, I have a few things uncertain about USART on TelosB. 1) This may be naive, but I'm really curious why USART is needed in the first place. Why can't the CPU talk to, say, CC2420 directly since they are wired togetherhttp://webs.cs.berkeley.edu/tos/hardware/telos/telos-revb-2004-09-27.pdf ? Huh? Well take a look at the 1611 data sheet. The USART hardware provides various functions but not at the same time. The CPU talks to the CC2420 through the USART as SPI. Read the TI data sheet and the user manual. And look at the telosb schematic. From page 6 of the datasheethttp://www.ti.com/lit/ds/symlink/msp430f1611.pdf showing functional block diagram of MSP430F16x, P3 and USART0 seem to be separated. But from the schematichttp://webs.cs.berkeley.edu/tos/hardware/telos/telos-revb-2004-09-27.pdf, P3.1 is used as SIMO signal when USART0 is configured as SPI mode. Is this because in TelosB, USART0's SIMO pin is physically wired to P3.1? 2) What components/devices/peripherals are communicating with CPU via USART? Via which one (USART0 or USART1) and in which mode (UART, SPI, or I2C)? look at the schematic. USART0 is connected to CC2420 in SPI or I2C mode. Its UART mode is not used. USART1 is connected to USB in UART mode. Its SPI mode is not used. 3) Can USART0 and USART1 be used in parallel? yes. look at the data sheet. *So SPI can be accessed even when UART is transmitting or receiving since they are dealt with independent USART modules?* For instance, can a strobe be sent to CC2420 using USART0 while the RSSI register on CC2420 is being read using USART1? huh again. I beleive a strobe is a message sent to the CC2420 but may also use a directly wired pin. The cc2420 is wired via only one set of hardware so your suggestion is non-sensical. Your explanation will be highly appreciated. -Xiaohui Liu ___ 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 -- -Xiaohui Liu -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] some questions regarding USART on TelosB
Hello all, I have a few things uncertain about USART on TelosB. 1) This may be naive, but I'm really curious why USART is needed in the first place. Why can't the CPU talk to, say, CC2420 directly since they are wired togetherhttp://webs.cs.berkeley.edu/tos/hardware/telos/telos-revb-2004-09-27.pdf ? 2) What components/devices/peripherals are communicating with CPU via USART? Via which one (USART0 or USART1) and in which mode (UART, SPI, or I2C)? 3) Can USART0 and USART1 be used in parallel? For instance, can a strobe be sent to CC2420 using USART0 while the RSSI register on CC2420 is being read using USART1? Your explanation will be highly appreciated. -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] questions about usage of keyword atomic
Thank you both for sharing your insights. I still have a few comments, CIL.
On Tue, Aug 28, 2012 at 3:52 AM, Eric Decker cire...@gmail.com wrote:
On Mon, Aug 27, 2012 at 6:59 PM, Xiaohui Liu whu...@gmail.com wrote:
Hello all,
1) I have the following code snippet:
*uint8_t a;*
*
*
*async event void Alarm1.fired() {*
* a = 0;*
*}*
This compiles successfully without any warning.
Isn't there a racing condition here, between Alarm1 and itself?
I don't know what you mean by the above. How can Alarm1 have a race
condition with itself?
I was thinking the interrupt that generates Alarm1 can be nested, but
turns out it is TOSH_SIGNAL and cannot be. What I actually want to express
is that if Alarm1.fired() is replaced by another event generated by a
nested interrupt TOSH_INTERRUPT, should *a* be protected?
Looks to me like in the above program there is only one place where a is
accessed, so how can there be a race condition.
2) If the following is added.
*async event void Alarm2.fired() {*
* a = 1;*
*}*
Still, this compiles successfully without any warning. Isn't there an
additional racing condition here, between Alarm1 and Alarm2 (and Alarm2 and
itself)?
async is considered to be one level of execution. So there still isn't a
race condition. When Alarm1 fires, a gets set to 0. Alarm2 can not get
in and thus there is not a race condition.
this is a nesc assumption. That async is one level of execution (one
context).
By assumption, you mean Alarm cannot be preempted? I think the assumption
holds just because the interrupt that generates Alarm is defined as
TOSH_SIGNAL rather than TOSH_INTERRUPT. It is not a nesc assumption.
What is one level of execution (one context). , a code snippet that
cannot be preempted?
3) If the following is added.
*event void Timer.fired() {*
* a = 2;*
*}*
Then there is a warning, non-atomic accesses to shared variable `a'.
Why is there no warning for
*a = 0;*
in Alarm1?
Why do you expect a warning from Alarm1?
Timer.fired is at sync level. Sync level is the other nesc execution
context. Because there is access to a from the async level nesc beleives
that there is a potential race condition between the Alarms (async level)
and Timer.fired (sync level). Hence non-atomic accesses.
According to the TinyOS book P196, a variable has to be protected by an
atomic statement *if it is accessed from an async function*. But seems
to me, *a* is accessed from an async function in all 3 cases above and
none is protected except
*a = 0;*
in Timer.
The book isn't very clear.
Typically async level is used for functions called from interrupt level
signals.
Can we replace the rule in the book by *whenever accessing a shared
variable introduces racing condition, it must be protected by atomic*?
Can anybody please share the experience on atomic? Thanks in advance.
--
-Xiaohui Liu
___
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
-- TelosB
-Xiaohui Liu
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] questions about usage of keyword atomic
Thanks again for your promptly reply. I still have a few follow-up
questions, please CIL.
On Wed, Aug 29, 2012 at 8:38 PM, Eric Decker cire...@gmail.com wrote:
On Wed, Aug 29, 2012 at 4:40 PM, Xiaohui Liu whu...@gmail.com wrote:
Thank you both for sharing your insights. I still have a few comments,
CIL.
On Tue, Aug 28, 2012 at 3:52 AM, Eric Decker cire...@gmail.com wrote:
On Mon, Aug 27, 2012 at 6:59 PM, Xiaohui Liu whu...@gmail.com wrote:
Hello all,
1) I have the following code snippet:
*uint8_t a;*
*
*
*async event void Alarm1.fired() {*
* a = 0;*
*}*
This compiles successfully without any warning.
Isn't there a racing condition here, between Alarm1 and itself?
I don't know what you mean by the above. How can Alarm1 have a race
condition with itself?
I was thinking the interrupt that generates Alarm1 can be nested, but
turns out it is TOSH_SIGNAL and cannot be. What I actually want to express
is that if Alarm1.fired() is replaced by another event generated by a
nested interrupt TOSH_INTERRUPT, should *a* be protected?
If you do indeed cause the interrupts to be nested then yes it should be
protected.
Nested interrupts on the msp430s have lots of problems and you probably
don't want to do this.
Looks to me like in the above program there is only one place where a is
accessed, so how can there be a race condition.
2) If the following is added.
*async event void Alarm2.fired() {*
* a = 1;*
*}*
Still, this compiles successfully without any warning. Isn't there an
additional racing condition here, between Alarm1 and Alarm2 (and Alarm2 and
itself)?
async is considered to be one level of execution. So there still isn't
a race condition. When Alarm1 fires, a gets set to 0. Alarm2 can not
get in and thus there is not a race condition.
this is a nesc assumption. That async is one level of execution (one
context).
By assumption, you mean Alarm cannot be preempted?
Interrupted is the correct term. Preemption is a little bit
different.
1) What is the difference?
The assumption that nesc makes is that there are two levels of context and
that the async context doesn't get interrupted.
2) If async context does not get interrupted, then there should never be
atomic in async context, at least when no interrupt is TOSH_INTERRUPT. But
this is clearly not the case. For instance, the following can be found in
CC2420ReceiveP.nc
* async event void InterruptFIFOP.fired() {*
*if ( m_state == S_STARTED ) {*
*#ifndef CC2420_HW_SECURITY*
* m_state = S_RX_LENGTH;*
* beginReceive();*
*#else*
* m_state = S_RX_DEC;*
* atomic receivingPacket = TRUE;*
* beginDec();*
*#endif*
*} else {*
* m_missed_packets++;*
*}*
* }*
So all such atomic are redundant?
So if two async pieces access the same variable it assumes that there
isn't a race condition.
3) What about async context cased by TOSH_INTERRUPT in msp430, or
equivalently, by AVR_NONATOMIC_HANDLER in avr? For example, variable
*a*is accessed both from AVR_NONATOMIC_HANDLER(SIG_OUTPUT_COMPARE3B)
and AVR_NONATOMIC_HANDLER(SIG_OUTPUT_COMPARE3C)
in HplAtm1281Timer3P.nc. There is a race condition here and it is compliant
with nesc.
I think the assumption holds just because the interrupt that generates
Alarm is defined as TOSH_SIGNAL rather than TOSH_INTERRUPT.
That is why the assumption holds. But it still is a nesc assumption and
if violated unless well understood can cause really nasty problems.
Typically intermittent failures.
It is not a nesc assumption.
Sure it is.
What is one level of execution (one context). , a code snippet that
cannot be preempted?
not sure what you are asking.
3) If the following is added.
*event void Timer.fired() {*
* a = 2;*
*}*
Then there is a warning, non-atomic accesses to shared variable `a'.
Why is there no warning for
*a = 0;*
in Alarm1?
Why do you expect a warning from Alarm1?
Timer.fired is at sync level. Sync level is the other nesc execution
context. Because there is access to a from the async level nesc beleives
that there is a potential race condition between the Alarms (async level)
and Timer.fired (sync level). Hence non-atomic accesses.
According to the TinyOS book P196, a variable has to be protected by an
atomic statement *if it is accessed from an async function*. But
seems to me, *a* is accessed from an async function in all 3 cases
above and none is protected except
*a = 0;*
in Timer.
The book isn't very clear.
Typically async level is used for functions called from interrupt level
signals.
Can we replace the rule in the book by *whenever accessing a shared
variable introduces racing condition, it must be protected by atomic*?
you can do that. But atomic adds overhead. I've looked
carefully at the code generated and introduced mechanisms for mitigating
the overhead, but there still is some overhead. Basically
[Tinyos-help] questions about usage of keyword atomic
Hello all,
1) I have the following code snippet:
*uint8_t a;*
*
*
*async event void Alarm1.fired() {*
* a = 0;*
*}*
This compiles successfully without any warning. Isn't there a racing
condition here, between Alarm1 and itself?
2) If the following is added.
*async event void Alarm2.fired() {*
* a = 1;*
*}*
Still, this compiles successfully without any warning. Isn't there an
additional racing condition here, between Alarm1 and Alarm2 (and Alarm2 and
itself)?
3) If the following is added.
*event void Timer.fired() {*
* a = 2;*
*}*
Then there is a warning, non-atomic accesses to shared variable `a'. Why
is there no warning for
*a = 0;*
in Alarm1?
According to the TinyOS book P196, a variable has to be protected by an
atomic statement *if it is accessed from an async function*. But seems to
me, *a* is accessed from an async function in all 3 cases above and none
is protected except
*a = 0;*
in Timer.
Can anybody please share the experience on atomic? Thanks in advance.
--
-Xiaohui Liu
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] telosB cpu speed
Hi everyone, I'm working on protocol where timing is critical so I need to know exactly how long it will take for a code snippet to run. To that end, I want to know how fast the cpu is and have the following questions. 1) According to the telosB datasheet, the cpu frequency is 8 MHz, but I guess this is maximum, right? Then, what is the actual frequency of the cpu? 2) What is the calibration in Msp430ClockP.nc for? It seems to be related to DCOx setting. 3) Be default MCLK is sourced from DCOCLK, where can I find DCOCLK's frequency? I failed to locate it in the MSP430F1611 datasheethttp://www.ti.com/product/msp430f1611 . 4) Be default, the cpu runs at about 4MHz, is there any reason for not running at 8 MHz? Save power? Impossible since no external Rosc is populated? I have see some related discussions herehttp://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg09808.html and herehttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2005-August/011727.html, but neither has definite answers for the questions above. If you can give any hint, that will be great. Thanks in advance. -- Cheers, -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] is this a bug of FTSP? Re: extremely large skew of 56% in FTSP
Hi,
Finally, I found out why this can happen.
Suppose A is the node with smallest id in the network and is going to be
the sync root eventually. At the beginning, it boots up later than some
nodes, which become roots prior to A. A few reference points from these
roots make into A's regression table. Because ftsp is still in the process
of convergence, the skew based on these few entries can be abnormal. What's
worse, root broadcasts this skew even if the number of entries are less
than ENTRY_SEND_LIMIT as shown below.
*if( numEntries ENTRY_SEND_LIMIT outgoingMsg-rootID !=
TOS_NODE_ID ){*
*++heartBeats;*
*state = ~STATE_SENDING;*
*}*
*else if( call Send.send(AM_BROADCAST_ADDR, outgoingMsgBuffer,
TIMESYNCMSG_LEN, localTime ) != SUCCESS ){*
*state = ~STATE_SENDING;*
*signal TimeSyncNotify.msg_sent();*
*}*
Gradually, every node synchronizes with root and gets the same abnormal
skew. This is because local clock rates of all nodes are very close with
some small skew (tens out of a million in my tests) and after sync, the
global clocks keep pace with the root's local clock.
I fixed this by making sure root's global time is always equal to its local
time as follows, regardless of the skew computed from regression table:
*async command error_t GlobalTime.local2Global(uint32_t *time)*
*{*
* if (outgoingMsg-rootID != TOS_NODE_ID)*
**time += offsetAverage + (int32_t)(skew * (int32_t)(*time -
localAverage));*
*return is_synced();*
*}*
I repeated my tests 6 times and ftsp runs like a charm now. The abnormal
skew never shows up, even root's skew based on regression table can still
be large.
On Thu, Jul 12, 2012 at 10:01 PM, Xiaohui Liu whu...@gmail.com wrote:
Hi,
I test ftsp alone and find some abnormal skews. One instance is skew of *
23%* and the corresponding regression table is:
localtime offset
5327769 1120379
59822981271252
5888794 1249698
5795290 1228145
5722274 1211314
5608281 1185039
5514777 1163486
5421273 1141932
The regression figure is
herehttp://www.cs.wayne.edu/xliu/imgs/ftsp_regression.jpg.
Almost every of the 130 nodes is returning skew of 23% !
Another is *183%*, regression table:
1474355 450851
1376050 277030
1327295 -9142
1229783 43734
Any hint on where the issue may arise from, packet-level synchronization
or packet timestamping? Thanks for your attention.
On Tue, Jul 10, 2012 at 4:29 PM, Eric Decker cire...@gmail.com wrote:
It is very difficult to tell what is going on from the outside.
what I've done with complicated situations like this is add
instrumentation (logging) of various state in nodes.
that is what I would recommend. I don't see anyway around it.
On Tue, Jul 10, 2012 at 1:16 PM, Xiaohui Liu whu...@gmail.com wrote:
Hi everyone,
I'm using FTSP of T32khz accuracy (i.e., TimeSync32kC) to synchronize a
network consisting of 130 telosB motes. Multiple runs are tested and skews
after synchronization are recorded. In some runs, the skew is incredibly
large, up to 56%. In others, it is below 0.0045%, which can be regarded
as normal. Does anyone know what might be causing this issue? One
observation is that regardless of the skew in a run, all nodes report
almost identical skews.
Your reply will be greatly appreciated.
--
-Xiaohui Liu
___
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
--
-Xiaohui Liu
--
-Xiaohui Liu
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] extremely large skew of 56% in FTSP
Hi, I test ftsp alone and find some abnormal skews. One instance is skew of *23% * and the corresponding regression table is: localtime offset 5327769 1120379 59822981271252 5888794 1249698 5795290 1228145 5722274 1211314 5608281 1185039 5514777 1163486 5421273 1141932 The regression figure is herehttp://www.cs.wayne.edu/xliu/imgs/ftsp_regression.jpg. Almost every of the 130 nodes is returning skew of 23% ! Another is *183%*, regression table: 1474355 450851 1376050 277030 1327295 -9142 1229783 43734 Any hint on where the issue may arise from, packet-level synchronization or packet timestamping? Thanks for your attention. On Tue, Jul 10, 2012 at 4:29 PM, Eric Decker cire...@gmail.com wrote: It is very difficult to tell what is going on from the outside. what I've done with complicated situations like this is add instrumentation (logging) of various state in nodes. that is what I would recommend. I don't see anyway around it. On Tue, Jul 10, 2012 at 1:16 PM, Xiaohui Liu whu...@gmail.com wrote: Hi everyone, I'm using FTSP of T32khz accuracy (i.e., TimeSync32kC) to synchronize a network consisting of 130 telosB motes. Multiple runs are tested and skews after synchronization are recorded. In some runs, the skew is incredibly large, up to 56%. In others, it is below 0.0045%, which can be regarded as normal. Does anyone know what might be causing this issue? One observation is that regardless of the skew in a run, all nodes report almost identical skews. Your reply will be greatly appreciated. -- -Xiaohui Liu ___ 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 -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] any TDMA protocol in T2?
Hi everyone, Is there any TDMA protocol implemented in T2? This question seems to be asked several times such as herehttp://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg38269.html and here http://blog.gmane.org/gmane.os.tinyos.users/month=20090401/page=5 but no such protocol is found. The only one I found is PRIMEhttp://mail.millennium.berkeley.edu/pipermail/tinyos/2003-September/97.html, which is only for T1. Thanks in advance. -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] extremely large skew of 56% in FTSP
Hi everyone, I'm using FTSP of T32khz accuracy (i.e., TimeSync32kC) to synchronize a network consisting of 130 telosB motes. Multiple runs are tested and skews after synchronization are recorded. In some runs, the skew is incredibly large, up to 56%. In others, it is below 0.0045%, which can be regarded as normal. Does anyone know what might be causing this issue? One observation is that regardless of the skew in a run, all nodes report almost identical skews. Your reply will be greatly appreciated. -- -Xiaohui Liu ___ 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 divide time into 10 ms slots?
Hi, Thanks for your reply. Doesn't the Alarm interface run at interrupt level, and AMSenderC$AMSend$send at sync level? The issue is that there is potentially long and non-deterministic delay when going from interrupt level (i.e., async) to sync level. On Mon, Jul 2, 2012 at 11:02 PM, Eric Decker cire...@gmail.com wrote: sync will always have some jitter (unless you aren't really doing anything else besides the one task). so you will have to so the TDMA slotting at interrupt level and kick the transmitter stuff at sync level. On Mon, Jul 2, 2012 at 7:51 PM, Xiaohui Liu whu...@gmail.com wrote: Hi everyone, I'm implementing a TDMA protocol, in which each slot lasts 10 ms. At the beginning of each slot, a node sends a packet (using AMSenderC$AMSend$send) if it captures the channel through some contention resolution algorithm. For the protocol to function, each slot duration has to be as close to 10 ms as possible. I tried the following two methods: 1. setup a periodic Timer with period 10 ms. But Timer interface works in synchronous context and the interval between two consecutive firing can be much larger than 10 ms as also mentioned in this threadhttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2007-May/024953.html . 2. setup an Alarm to fire every 10 ms. The timing is precise. However, Alarm$fired event is asynchronous and AMSenderC$AMSend$send is synchronous and thus cannot be called directly from Alarm$fired. If a task is post in in Alarm$fired to call AMSenderC$AMSend$send indirectly, it suffers from the same issue as Timer interface does. FTSP is also used in the protocol, which transmits via AMSenderC$AMSend$send. That's why packet transmission is through AMSenderC$AMSend$send in my TDMA protocol, to be compatible with FTSP. If you have any suggestion, please do not hesitate to share. Your help would be sincerely appreciated. -- Cheers -Xiaohui Liu -- Eric B. Decker Senior (over 50 :-) Researcher -- -Xiaohui Liu ___ 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 speed up the SPI access on Telosb mote
Hi,
Try the following:
msp430usart.h
UBR_4MHZ_57600=0x0048, UMCTL_4MHZ_57600=0x7B,
UBR_4MHZ_115200=0x0024, UMCTL_4MHZ_115200=0x29,
} msp430_uart_rate_t;
msp430_uart_union_config_t msp430_uart_default_config = {
{
ubr : UBR_4MHZ_115200,
umctl : UMCTL_4MHZ_115200,
ssel : 0x02,
pena : 0,
pev : 0,
spb : 0,
clen : 1,
listen : 0,
mm : 0,
ckpl : 0,
urxse : 0,
urxeie : 1,
urxwie : 0,
utxe : 1,
urxe : 1
}
};
TelosSerialP.nc
msp430_uart_union_config_t msp430_uart_telos_config = { {ubr:
UBR_4MHZ_115200, umctl: UMCTL_4MHZ_115200, ssel: 0x02, pena: 0, pev: 0,
spb: 0, clen: 1, listen: 0, mm: 0, ckpl: 0, urxse: 0, urxeie: 1, urxwie: 0,
utxe : 1, urxe : 1} };
Msp430ClockP.nc
BCSCTL2 = 0;
Good luck.
On Wed, Jun 27, 2012 at 4:29 AM, Cao Zhichao ca...@cse.ust.hk wrote:
Dear everyone,
** **
I want to speed up the SPI access so that I could shorten the time used
to read the data from RxFIFO of CC2420 to MCU. Based on my understanding of
TinyOS 2.1.1 system, the clock frequency of SPI is SMCLK/2. Thus I modify
the SMCLK frequency by setting the BCSCTL2 as 0 in function *
Msp430ClockInit.defaultInitClocks* (at line 94
/tos/chips/msp430/timer/Msp430ClockP.nc). Hopefully, the SMCLK equals to
DCO frequency 4MHz, which is 1MHz before.
** **
I write a small program to test whether this modification works. I read
the data of RxFIFO one byte by one byte. I write a new split-phase SPI
access interface based on FastSpiByte. I signal a readDone event after each
byte is obtained. Then I read the next byte. My payload length is 47. Under
this setting, it consumes about 2250us to finish the data swapping process
with 4MHz SMCLK. It also consumes about 2280us with 1MHz SMCLK.
** **
I am very confused about the results. Is my method of increasing SPI
speed right? Where is the time consumed during the process? Does the
split-phase way slow down the process? It seems the result is much larger
than the expected. Thank you very much in advance.
** **
Best Regards
Zhichao Cao
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
--
-Xiaohui Liu
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] how to divide time into 10 ms slots?
Hi everyone, I'm implementing a TDMA protocol, in which each slot lasts 10 ms. At the beginning of each slot, a node sends a packet (using AMSenderC$AMSend$send) if it captures the channel through some contention resolution algorithm. For the protocol to function, each slot duration has to be as close to 10 ms as possible. I tried the following two methods: 1. setup a periodic Timer with period 10 ms. But Timer interface works in synchronous context and the interval between two consecutive firing can be much larger than 10 ms as also mentioned in this threadhttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2007-May/024953.html . 2. setup an Alarm to fire every 10 ms. The timing is precise. However, Alarm$fired event is asynchronous and AMSenderC$AMSend$send is synchronous and thus cannot be called directly from Alarm$fired. If a task is post in in Alarm$fired to call AMSenderC$AMSend$send indirectly, it suffers from the same issue as Timer interface does. FTSP is also used in the protocol, which transmits via AMSenderC$AMSend$send. That's why packet transmission is through AMSenderC$AMSend$send in my TDMA protocol, to be compatible with FTSP. If you have any suggestion, please do not hesitate to share. Your help would be sincerely appreciated. -- Cheers -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] RSSI measurement and accuracy for CC2420
Hi everyone, CC2420 http://www.ti.com/product/CC2420 returns RSSI in integer. How does it compute RSSI from the actual signal strength? Round up, round down, or something else? For instance, if the actual signal strength is -71.9 dBm, what would CC2420 http://www.ti.com/product/CC2420's RSSI be? According to the datasheet, typical RSSI accuracy is +/-6 dB. Does this mean measured RSSI can deviate 6 dB from actual RSSI, which is huge error? My application intends to detect the change of interference at a node caused by other nodes' transmissions. But there is an issue. For example, the measured RSSI currently is -72.0 dBm, and then a node starts to transmit and introducing interference of -81.6 dBm, increasing the RSSI to -72.5 dBm. Because returned RSSI is integer, the RSSI can be both -72 dBm, before and after the node starts transmission. Thus the interference cannot be detected. Is there anyway to measure RSSI at better accuracy, say, 0.5 dB as my application requires? Thanks in advance. -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] high frequency RSSI sampling
Hi everybody,
I want to sample RSSI at 3 KHz, which acts as a part of my protocol. Below
is a list of approaches I come up with, but none of them can achieve the
goal.
-
while (TRUE) {
sampleRssi();
}
If something like above is used, then code beyond the while loop may never
get executed.
-
event void Timer.fired() {
sampleRssi();
}
If a timer is used to periodically trigger readRssiFast(), the firing
accuracy has to be at least ~300 microseconds, which seems very
difficulthttp://mail.millennium.berkeley.edu/pipermail/tinyos-help/2007-May/024953.html
on
TelosB, if possible at all.
-
task void sampleRssiTask() {
sampleRssi();
post sampleRssiTask();
}
If there are multiple tasks posted before sampleRssiTask(), then it can be
postponed for a much longer time than 0.33 ms before execution.
If you have any idea, please do not hesitate to share. Thank you in advance.
--
-Xiaohui Liu
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] What is a CCA hysteresis?
Hi all, Does any one know what is a CCA hysteresis as said on the CCA section of CC2420's datasheet? Thanks for sharing. -- -Xiaohui Liu ___ 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 code execution time
Hi, Where can I find the ISR for each interrupt, e.g., SFD interrupt when a packet is received? Is it part of TinyOS implementation? Thanks. On Wed, Aug 10, 2011 at 11:04 AM, Janos Sallai sal...@isis.vanderbilt.eduwrote: Have you thought of modifying each and every ISR routine to store (and accumulate) the time spent serving interrupts? This accumulated value should then be subtracted from the running time of the code snippet. I suggest that you directly read the counter registers in the ISRs (vs. calling LocalTime.get(), which may have additional overhead). The counter registers should not overflow more than once while the interrupt handler is running. This gets a little tricky, though, if there are nested interrupts. AFAIK it's only the ADC subsystem that uses nested interrupts on the AVR platforms. If your application doesn't use the ADC, the above simple solution would suffice. Janos On Tue, Aug 9, 2011 at 10:27 PM, Xiaohui Liu whu...@gmail.com wrote: Hi everyone, How can I measure the time for a snippet of code (e.g., a function call foo), either synchronous or asynchronous, to execute? A straight forward way can be: start_time = Call LocalTime.get(); foo(); end_time = call LocalTime.get(); (end_time - start_time) is regarded as the execution time of function call foo(). However, asynchronous code can preempt foo() during its execution, thus (end_time - start_time) may be overestimation of foo()'s actual execution time. An alternative can be something like the following: disable interrupt; start_time = Call LocalTime.get(); foo(); end_time = call LocalTime.get(); enable interrupt; However, this can be problematic also if some critical interrupts (e.g., packet reception) occur when the interrupt is disabled. Can anyone have some idea on how execution time can be measured without the above issues? Any help is appreciated. -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] interrupt vs event
Hi,
I find something related to TOSH_SIGNAL:
// The signal attribute has opposite meaning in msp430-gcc than in avr-gcc
#define TOSH_SIGNAL(signame) \
void sig_##signame() __attribute__((interrupt (signame), wakeup)) @C()
in msp430hardware.h
TOSH_SIGNAL(NMI_VECTOR)
{
volatile int n = IFG1;
if (n NMIIFG) { signal NMI.fired(); return; }
if (n OFIFG) { signal OF.fired(); return; }
if (FCTL3 ACCVIFG) { signal ACCV.fired(); return; }
}
in HplMsp430InterruptNMIP.nc
But I'm still not sure how the hook from an interrupt works. Can you
explain a little bit? Thanks.
On Sun, Jun 6, 2010 at 8:33 PM, Eric Decker cire...@gmail.com wrote:
okay, let me try.
On Sun, Jun 6, 2010 at 11:05 AM, Xiaohui Liu whu...@gmail.com wrote:
Hi,
Can I say event is at higher level while interrupt is at lower level? I
guess event handler may be sync if you look at Receive.receive() event.
An interrupt handler typically handles a h/w interrupt. In TinyOS you
can find where we hook into the interrupt handlers by looking for
TOSH_SIGNAL.
In TinyOS, modules are interfaced using two mechanisms, commands for call
in, and signals for call out. Signals are wired to event handlers. This
is in the context of TinyOS. Other environments will vary.
Commands and event handlers can be labelled as sync or async. Normally,
one wants to keep everything sync. Life is simpler that way. TinyOS is
about keeping things simple because less goes wrong that way. Its one of
the reasons why static allocation is preferred over dynamic (ie. malloc).
Wild pointers aren't much fun.
However, one clearly needs to be able to signal asynchronous event too.
Like how do we further connect to TinyOS modules from the interrupt
handler? To denote that things can be happening in an asynchronous
fashion, the keyword async word is used.
The toolchain keeps track of the call chain and flags sync labelled
routines that are callable from async routines because it violates the
assumptions that make sync level stuff simple.
Hopefully that adds some clarity.
Can you help me find an example of interrupt handler in TinyOS? Thank you.
Look for TOSH_SIGNAL. That is how code is hooked into the h/w interrupt
handler.
On Sat, Jun 5, 2010 at 3:28 PM, Ali Baharev ali.baha...@gmail.comwrote:
Hi,
a callback subroutine in an operating system or device driver
http://en.wikipedia.org/wiki/Interrupt_handler
When quoting, it helps to quote the whole thing...
An *interrupt handler*, also known as an *interrupt service routine* (*
ISR*), is a
callbackhttp://en.wikipedia.org/wiki/Callback_(computer_science) subroutine
in an operating system http://en.wikipedia.org/wiki/Operating_system or
device
driver http://en.wikipedia.org/wiki/Device_driver whose execution is
triggered by the reception of an
interrupthttp://en.wikipedia.org/wiki/Interrupt.
Interrupt handlers have a multitude of functions, which vary based on the
reason the interrupt was generated and the speed at which the Interrupt
Handler completes its task.
The major difference between an event and an interrupt handler is how the
event is generated. A h/w event is an interrupt and gets hooked in with
TOSH_SIGNAL. An event handler is declared using event void ... and
invoked using signal ...
---
an event handler is an asynchronous callback subroutine that handles
inputs received in a program
http://en.wikipedia.org/wiki/Event_handler
Well that depends. On the context. There are places where that is true.
However, we are talking about TinyOS. So the above confuses things.
Ali
--
-Xiaohui Liu
___
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
--
-Xiaohui Liu
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] difference between AMSenderC and ActiveMessageC
Hi, What is the difference between components new AMSenderC(APP_AM_TYPE); App.AMSend - AMSenderC; and components ActiveMessageC; App.AMSend - ActiveMessageC.AMSend[APP_AM_TYPE]; ? Can I still use ActiveMessageC directly when there are multiple communication clients, or AMSenderC abstraction is a must in this case? Thanks in advance. -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] will packets with CCA disabled backoff if channel is busy?
Hi,
The following snippet is from CC2420TransmitP:
call CSN.clr();
status = m_cca ? call STXONCCA.strobe() : call STXON.strobe();
if ( !( status CC2420_STATUS_TX_ACTIVE ) ) {
status = call SNOP.strobe();
if ( status CC2420_STATUS_TX_ACTIVE ) {
congestion = FALSE;
}
}
m_state = congestion ? S_SAMPLE_CCA : S_SFD;
call CSN.set();
}
if ( congestion ) {
totalCcaChecks = 0;
releaseSpiResource();
congestionBackoff();
} else {
call BackoffTimer.start(CC2420_ABORT_PERIOD);
}
I understand call STXONCCA.strobe() will not send the packet if channel is
busy. Will call STXON.strobe() always return CC2420_STATUS_TX_ACTIVE and
send the packet regardless of the channel state? If no, under what
condition can this happen? Thanks for your attention.
--
-Xiaohui Liu
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] source code documentation for TOSSIM
Hi everyone, Is there source code documentation for TOSSIM like other platforms such as telosb http://www.tinyos.net/tinyos-2.1.0/doc/nesdoc/telosb/index.html? I tried to generate it using make micaz sim docs, which does not work. Any hint will be highly appreciated. -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] set packet transmission power in TOSSIM
Hello all, Is there a way to set transmission power on a per packet basis in TOSSIM? I know this can be done by CC2420Packet.setPower() for telosb, but am not sure how to do it in TOSSIM if possible at all. This threadhttp://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg29355.html asks the same question, but no definite answer is given. Your assistance will be truly appreciated. -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] how to change the carrier sensing threshold for CC2420?
Hi everyone, I'm wondering how to set the carrier sensing threshold for CC2420. Can anyone please help? BTW, I find CC2420_RSSI_CCA_THR = 8 in CC2420.h but not sure what 8 means and if this is the right place to change. Hope this contributes. -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] will Send.sendDone() always be signalled if Send.cancel() is called
Hi everyone, I'm trying to use Send.cancel() command of AMSenderC. If it returns SUCCESS, then an event Send.sendDone() will be signalled later with error code ECANCEL; if it returns FAIL, the ongoing transmission cannot be cancelled and proceeds as usual, which will signal Send.sendDone(), too. So, in both cases, Send.sendDone() will be signalled. Am I right? Your help will be highly appreciated. -- -Xiaohui Liu TelosB ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] is there assert() available?
Hi everyone, Is there any function equivalent to assert()http://www.cplusplus.com/reference/clibrary/cassert/assert/ in TinyOS? If yes, can it be used on mote and/or TOSSIM? Thanks. -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] where can I find detail information about framework and function of Edge Router
In this web page, we can find detail information about how to use and configure Edge Router: http://docs.tinyos.net/tinywiki/index.php/BLIP_Tutorial Now I want to get more information about how the Edge Router working, but I can not find the on www.tinyos.net. Can you give me some clue to find them? ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] 802.11 reference implementation recommendation
Hi everyone, I'm curious on how IEEE 802.11 standard works in reality. Can anyone recommend a good reference implementation of 802.11? It does not have to be written in nesc, C/C++ or java also work. Thanks in advance. -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Connection timed out accessing remote serial forwarder
Hi everyone, I'm using the serial forwarder in c available herehttp://code.google.com/p/tinyos-main/source/browse/trunk/support/sdk/c/sf/. After I set up the serial forwarder (use the example sf.c), I succeeded in both reading from it (sflisten.c) and writing to it (sfsend.c), from the local machine. However, when I try to access it from another machine, the following error keeps prompting when function connect() is called to establish a connection to the serial forwarder: *Connection timed out*. Can anyone give some suggestion on what might be going wrong, perhaps privilege issues? Thanks very much in advance. BTW, I'm using Ubuntu and TelosB motes, serial forwarder uses port 9001. Two machines can ssh to each other. -- -Xiaohui Liu ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
