Re: [Tinyos-help] CTP: ETX values vs. LPL wake-up interval
Generally, yes. As ETX increases lossses also increase. I can observe the fact that RetxmitTimer in CtpForwardingEngine being fired quite a few times before sucessfully transmitting every packet. But, only a few times this does not hold with packets getting through although ETX remains at a higher value. Please let me know if you want me to redo the experiments if you need any other information. Regards, Manjunath D *** On Thu, 21 Oct 2010, Omprakash Gnawali wrote: On Tue, Oct 19, 2010 at 1:04 AM, Manjunath Doddavenkatappa dodda...@comp.nus.edu.sg wrote: Dear All, ? We are not able to figure out a reason why ETX values in CTP increases as wake-up interval of the LPL (BoXMaC-One) increases. We have a simple setup of a sender and a root node placed adjacent to each other. Nodes use maximum power of 0 dBm. ? 1) We are using IPI of 15s. We repeated the experiment at three different places with sevral runs runs at every location. Different wake-up intervals were tried back-to-back so that temporal variations are minimized. We used wake-up intervals of 10, 20, 40, 100, and 1000 (ms). ? 2) We also used LPL.setRemoteWakeupInterval(packet, WAKEUP_INTERVAL + 100) but without any luck. ? 3) Our debug messages show that CTP's RetxmitTimer being fired quite a few times before sucessfully transmitting every packet. ? 4) I first thought that the loss of data packets in the BoXMAC's preamble could be the reason, but looking into the LPL code, I understand that preamble packet losses are not fed into the Link Estimator. ? 5) In some experimental runs, particularly when the wake-up interval is 1000ms, no packet go-through. Requires a hard reboot. ?6) Searching the archieves for CTP and LPL on tmote, I found that similar problem being discussed sometime in Dec 2008. The discussion suggests quite a few number of changes. http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/2008-December/003510.html We should debug this. Do you also observe loss in delivery ratio along with high ETX values? - om_p ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] FTSP and microsecond precision on Crossbow Iris platform
Hi Urs, I used a testbed of 15 IRIS sensor nodes which are placed in communication range of the reference broadcaster. I constructed a line topology by configuring each node such that it will accept incoming messages from the nodes with id one more or one less of the id of the current node. Packets from all other nodes are ignored. I attached a base station node to a PC to log logical clock values broadcasted by the nodes. At the end of each interval which are uniformly distributed between 5 and 8 seconds, the reference broadcaster node broadcasts a message. The corresponding message is received approximately at the same time by all nodes. This message is timestamped by the receiving nodes. After that, the nodes broadcast their logical clock values and a base station node transfers these messages to the serial port of the PC. An application listening the serial port logs these messages. For the sample result, just disgard the left-side column. The right-side column is the logical clock values of the nodes at a time instant. 1287678021203: *[nodeid=0x1] [clock=0x1f3fc724]* 1287678021250: *[nodeid=0x2] [clock=0x1f3fc76a]* 1287678021294: *[nodeid=0x3] [clock=0x1f3fc75d]* 1287678021350: *[nodeid=0x4] [clock=0x1f3fc6ae]* 1287678021398: *[nodeid=0x5] [clock=0x1f3fc47d]* Sinan. 2010/10/21 Urs Hunkeler urs.hunke...@epfl.ch Hi, As an interested outside observer of the conversation (I have no experience with FTSP), how do you measure the clock skews? What do the values in the different columns mean? Thanks, Urs On 10/21/2010 06:17 PM, Sinan Yildirim wrote: Hi Janos, I have done the modifications as you have said and also used the NoSleepC component of your implementation in tinyos-2.x-contrib repository. But I don't get tight skew values on a line of 5 iris sensor nodes. Here are the results after a 15 minute run: 1287678021203: [nodeid=0x1] [clock=0x1f3fc724] 1287678021250: [nodeid=0x2] [clock=0x1f3fc76a] 1287678021294: [nodeid=0x3] [clock=0x1f3fc75d] 1287678021350: [nodeid=0x4] [clock=0x1f3fc6ae] 1287678021398: [nodeid=0x5] [clock=0x1f3fc47d] Why am I measuring such big clock skew in this small network?? Any suggestions? ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] FTSP and microsecond precision on Crossbow Iris platform
Hi Janos, In fact I have developed another time synchronization protocol and I have tested it using the same testbed. I can get 2-3 miroseconds accuracy. Thus, I feel that the timestamping mechanism works well (but just a feeling :)). I just suspect about if some modification to TimeSyncP is needed in order to get accurate results. I have a final detail that the results I presented in the previous email are taken by setting the skew variable to zero in TimeSyncP. Otherwise, the result is much more worse... Sinan 2010/10/21 Janos Sallai sal...@isis.vanderbilt.edu I can make some wild guesses, but can't give you a solution. - The 7.3mhz crystal has a precision of 50ppm. The beaconing rate of FTSP is 10 seconds by default (can be set with PFLAGS+=-DTIMESYNC_RATE=value in the Makefile), which can result in an 500 us error per hop. However, FTSP's linear regression should take care of this. Also, 500 us is really the worst case scenario. You can try decreasing TIMESYNC_RATE and see how the results change. - I am not sure if the packet-level time synchronization implementation of the IRIS is calibrated. There's a chance that it's not, which can result in a constant one-hop synchronization error. Miklos could clarify this. Janos On Thu, Oct 21, 2010 at 11:17 AM, Sinan Yildirim sinanyi...@gmail.com wrote: Hi Janos, I have done the modifications as you have said and also used the NoSleepC component of your implementation in tinyos-2.x-contrib repository. But I don't get tight skew values on a line of 5 iris sensor nodes. Here are the results after a 15 minute run: 1287678021203: [nodeid=0x1] [clock=0x1f3fc724] 1287678021250: [nodeid=0x2] [clock=0x1f3fc76a] 1287678021294: [nodeid=0x3] [clock=0x1f3fc75d] 1287678021350: [nodeid=0x4] [clock=0x1f3fc6ae] 1287678021398: [nodeid=0x5] [clock=0x1f3fc47d] Why am I measuring such big clock skew in this small network?? Any suggestions? 2010/10/18 Janos Sallai sal...@isis.vanderbilt.edu Sinan, It's not there, but it's not terribly complicated to accomplish. Just take a look at TimeSyncC and TimeSync32kC, and based on those, come up with your TimeSyncMicroC. As far as I can tell, this is the only file you'll need to cook for yourself, you don't need to touch anything else. A couple of notes: - On the iris, the interface provided by TimeSyncMessageC that gives you microsecond precision packet-level timesync is called TimeSyncAMSendRadio. - You can get microsecond-precision local time from LocalTimeMicroC, however, time will stop when the mote goes to sleep. You will need to keep the MCU awake all the time to get FTSP to work properly. There are a couple of different ways to do this, for example by having a component that provides McuPowerOverride and the lowestState function always returns ATM128_POWER_IDLE. You'll need to wire this component to McuSleepC. Janos On Sat, Oct 16, 2010 at 4:33 AM, Sinan Yildirim sinanyi...@gmail.com wrote: Hi all, I have a question on getting microsecond precision using FTSP on Iris platform. Current version of tinyos 2.1.1 does not include components and modules in tos/lib/ftsp directory in order to achieve microsecond precision. As far as I know, previous version of tinyos (1.x) had a support for getting microsecond precision using FTSP. Has anybody a modified version of the FTSP code for tinyos 2.1.1 in order to get microsecond precision global time value? Is it possible to share it here? I want to test this code on a line topology of 20 Iris motes. Thanks for your helps, Sinan. ___ 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] MICA2 transmission power adjustment in tinyos 2.x
In order to get this behaviour i simply added a few lines of code to my
application:
module /**/ {
uses {
//...
interface CC1000Control as RadioStrengthControl;
//...
}
}
and
event void Boot.booted() {
//...
#ifdef RFPOWER
call RadioStrengthControl.setRFPower(RFPOWER);
#endif
//..
}
Am Donnerstag, 21. Oktober 2010, 03:03:40 schrieb Prusayon Nintanavongsa:
Hi all,
How do you adjust MICA2 transmission power in tinyos 2.x other than
adding CFLAG in the Makefile? In tinyos 1.x, there's CC1000RadioC which
can be wired to CC1000Control in order to call SetRFPower(). I would like
to adjust the transmission power adaptively. Thank you.
rdgs,
PN
___
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] compilation error
Hi
I am using tinyos to save data(which is received from another node) on EEPROM
of mote. when I am compiling code there is an error
Parse error at the end of input.
My code is given below:
includes SenseMessage; // header file for message struc
module SenseReceiveM {
provides interface StdControl;
uses {
interface Leds;
interface ReceiveMsg;
interface LoggerWrite;
}
}
implementation {
uint8_t currentBuffer;
char* ptr;
command result_t StdControl.init() {
call Leds.init();
return SUCCESS;
}
command result_t StdControl.start() {
call Leds.redOff();
call Leds.greenOff();
call Leds.yellowOff();
return SUCCESS;
}
TOS_MsgPtr buffer;
event TOS_MsgPtr ReceiveMsg.receive(TOS_MsgPtr m)
{
TOS_MsgPtr tmp;
tmp = buffer;
buffer = m;
atomic {
ptr = (char*)m;
currentBuffer ^= 0x01;
}
call LoggerWrite.append(ptr);
return tmp;
}
command result_t StdControl.stop() {
return SUCCESS;
}
event result_t LoggerWrite.writeDone( result_t status ) {
if (status) call Leds.yellowOn();
return SUCCESS;
}
What is mistake in code?
Thanks in advance.
Nida
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Compilation error
Hi
I am using tinyos to save data(which is received from another node) on EEPROM
of mote. when I am compiling code there is an error
Parse error at the end of input.
My code is given below:
includes SenseMessage; // header file for message struc
module SenseReceiveM {
provides interface StdControl;
uses {
interface Leds;
interface ReceiveMsg;
interface LoggerWrite;
}
}
implementation {
uint8_t currentBuffer;
char* ptr;
command result_t StdControl.init() {
call Leds.init();
return SUCCESS;
}
command result_t StdControl.start() {
call Leds.redOff();
call Leds.greenOff();
call Leds.yellowOff();
return SUCCESS;
}
TOS_MsgPtr buffer;
event TOS_MsgPtr ReceiveMsg.receive(TOS_MsgPtr m)
{
TOS_MsgPtr tmp;
tmp = buffer;
buffer = m;
atomic {
ptr = (char*)m;
currentBuffer ^= 0x01;
}
call LoggerWrite.append(ptr);
return tmp;
}
command result_t StdControl.stop() {
return SUCCESS;
}
event result_t LoggerWrite.writeDone( result_t status ) {
if (status) call Leds.yellowOn();
return SUCCESS;
}
What is mistake in code?
Thanks in advance.
Nida
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] unable to receive UART frame
Hi Urs, thank you for your clues. I copied the lib/serial files to my test project folder. Now I can receive single bytes and can follow the state machine step by step in the SerialP.nc file. If I send single bytes 0x7E (Framing byte) and 0x44 (Frame Type) the state machine accepts the frame and goes to the expected state. The new problem is if I send all bytes in a row the second byte (the Frame type check fails). To send the bytes I use hterm and the UART baud rate is 57600. Is the TinyOS code probably to slow? Is there a buffer implemented for new received bytes pending to be analysed? Thank you for your help and your time. And yes I am German and from Munich. Cheers, Mario -Ursprüngliche Nachricht- Von: Urs Hunkeler [mailto:urs.hunke...@epfl.ch] Gesendet: Dienstag, 19. Oktober 2010 08:19 An: Mario Riesner Cc: tinyos-help@Millennium.Berkeley.EDU Betreff: Re: AW: AW: [Tinyos-help] unable to receive UART frame Hi Mario, For single byte operation of the serial port you are interested in the interfaces: UartControl, UartByte and UartStream. You'll have to find out which modules in your platform implement them (they are certainly implemented as they are used for SerialAMSenderC and SerialAMReceiverC. The Receive code is in $TOSROOT/tos/lib/serial, most likely split amongst SerialActiveMessageP and SerialDispatcherP (and similar files). My guess is that the dispatcher does the framing (since the serial port is a stream interface, the stream has to be split into frames, and for some reason TinyOS uses a framing protocol that also supports other protocols), and SerialActiveMessageP does then the actual interpretation of the AM packet (which part of the program should receive the packet). If you don't want to fully understand the code but still debug your framing program, I recommend you copy the files from the lib/serial to your TinyOS test program folder. If you change them locally in your folder, the compiler will take the local version rather than the version in the default installation. That way you can modify TinyOS code without changing the installation. You can then add LED code to stepwise figure out where your message is rejected. Cheers, Urs PS: Yes, I am Swiss. Are you German? On 10/18/10 11:17 PM, Mario Riesner wrote: Hi Urs, I tryed to use the serialsend C code: = Sending ff writing 44 26 ff encoded 7e 44 26 ff dd 73 7e noack But it doesn't work. And the encoded frame is a bit short, I think the source and destination address are missing. The second point is I have to explain some stuff in my Master Theses. Maybe there is a problem with the implementation of my hardware. I'm using a Meshbean mote it's similar to the Mica mote. Students of the ETH Zürich ported TinyOS to the Mesbean board. You are Swiss? How can I test the raw UART or to receive all single bytes? Cheers, Mario -Ursprüngliche Nachricht- Von: Urs Hunkeler [mailto:urs.hunke...@epfl.ch] Gesendet: Montag, 18. Oktober 2010 19:38 An: Mario Riesner Cc: tinyos-help@Millennium.Berkeley.EDU Betreff: Re: AW: [Tinyos-help] unable to receive UART frame Hi Mario, Why do you implement the framing protocol yourself? I personally do not know about the different fields in the message format and would have to study the source code in detail myself. There are two approaches, try to understand the source code of the TinyOS nesC code, or try to find out how the TinyOS message interface tools generate the serial messages. There is code available for different platforms. E.g. have a look in the $TOSROOT/support/sdk/c/sf/ directory. In the readme in there it is mentioned: This serial forwarder implements the standard TinyOS 2.0 serial forwarder protocol (see comments in support/sdk/java/net/tinyos/packet/SFProtocol.java for a brief overview). This is where I would start, and then maybe read the source code of the implementation in the language which was closest to my needs. Or you could try the message interface generator (mig) utility. I think it supports other languages besides Java. Cheers, Urs ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] unable to receive UART frame
Hi Urs, again, I reduced the baud rate to 38400 now it works. The module receives a whole frame and sends an ACK frame. Now I have to find out why the highest event in my test code is not called. For now thank you for your help. Cheers, Mario -Ursprüngliche Nachricht- Von: Urs Hunkeler [mailto:urs.hunke...@epfl.ch] Gesendet: Dienstag, 19. Oktober 2010 08:19 An: Mario Riesner Cc: tinyos-help@Millennium.Berkeley.EDU Betreff: Re: AW: AW: [Tinyos-help] unable to receive UART frame Hi Mario, For single byte operation of the serial port you are interested in the interfaces: UartControl, UartByte and UartStream. You'll have to find out which modules in your platform implement them (they are certainly implemented as they are used for SerialAMSenderC and SerialAMReceiverC. The Receive code is in $TOSROOT/tos/lib/serial, most likely split amongst SerialActiveMessageP and SerialDispatcherP (and similar files). My guess is that the dispatcher does the framing (since the serial port is a stream interface, the stream has to be split into frames, and for some reason TinyOS uses a framing protocol that also supports other protocols), and SerialActiveMessageP does then the actual interpretation of the AM packet (which part of the program should receive the packet). If you don't want to fully understand the code but still debug your framing program, I recommend you copy the files from the lib/serial to your TinyOS test program folder. If you change them locally in your folder, the compiler will take the local version rather than the version in the default installation. That way you can modify TinyOS code without changing the installation. You can then add LED code to stepwise figure out where your message is rejected. Cheers, Urs PS: Yes, I am Swiss. Are you German? On 10/18/10 11:17 PM, Mario Riesner wrote: Hi Urs, I tryed to use the serialsend C code: = Sending ff writing 44 26 ff encoded 7e 44 26 ff dd 73 7e noack But it doesn't work. And the encoded frame is a bit short, I think the source and destination address are missing. The second point is I have to explain some stuff in my Master Theses. Maybe there is a problem with the implementation of my hardware. I'm using a Meshbean mote it's similar to the Mica mote. Students of the ETH Zürich ported TinyOS to the Mesbean board. You are Swiss? How can I test the raw UART or to receive all single bytes? Cheers, Mario -Ursprüngliche Nachricht- Von: Urs Hunkeler [mailto:urs.hunke...@epfl.ch] Gesendet: Montag, 18. Oktober 2010 19:38 An: Mario Riesner Cc: tinyos-help@Millennium.Berkeley.EDU Betreff: Re: AW: [Tinyos-help] unable to receive UART frame Hi Mario, Why do you implement the framing protocol yourself? I personally do not know about the different fields in the message format and would have to study the source code in detail myself. There are two approaches, try to understand the source code of the TinyOS nesC code, or try to find out how the TinyOS message interface tools generate the serial messages. There is code available for different platforms. E.g. have a look in the $TOSROOT/support/sdk/c/sf/ directory. In the readme in there it is mentioned: This serial forwarder implements the standard TinyOS 2.0 serial forwarder protocol (see comments in support/sdk/java/net/tinyos/packet/SFProtocol.java for a brief overview). This is where I would start, and then maybe read the source code of the implementation in the language which was closest to my needs. Or you could try the message interface generator (mig) utility. I think it supports other languages besides Java. Cheers, Urs ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] About BlinkToRadio-The Packet is different
I am now studying Lesson 4: Mote-PC serial communication But when I run the net.tinyos.tools.Listen This is my BlinkToRadio Packet： 00 00 FF FF 00 01 06 00 06 00 01 00 01 01 00 FF FF 00 01 06 00 06 00 01 00 02 02 00 FF FF 00 01 06 00 06 00 01 00 03 03 00 FF FF 00 01 06 00 06 00 01 00 04 and Lesson 4： 00 FF FF 00 00 04 22 06 00 02 00 01 00 FF FF 00 00 04 22 06 00 02 00 02 00 FF FF 00 00 04 22 06 00 02 00 03 00 FF FF 00 00 04 22 06 00 02 00 04 I didn't change anything,Listen-tools and code ** are original. Is there anyone know what happend? Thanks for your help：) ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] compilation error
Looks like you forgot the final closing curly brace (}).
Cheers,
Urs
On 10/21/2010 08:25 AM, Nida Sahar Syed wrote:
Hi
I am using tinyos to save data(which is received from another node) on
EEPROM of mote. when I am compiling code there is an error
Parse error at the end of input.
My code is given below:
includes SenseMessage; // header file for message struc
module SenseReceiveM {
provides interface StdControl;
uses {
interface Leds;
interface ReceiveMsg;
interface LoggerWrite;
}
}
implementation {
uint8_t currentBuffer;
char* ptr;
command result_t StdControl.init() {
call Leds.init();
return SUCCESS;
}
command result_t StdControl.start() {
call Leds.redOff();
call Leds.greenOff();
call Leds.yellowOff();
return SUCCESS;
}
TOS_MsgPtr buffer;
event TOS_MsgPtr ReceiveMsg.receive(TOS_MsgPtr m)
{
TOS_MsgPtr tmp;
tmp = buffer;
buffer = m;
atomic {
ptr = (char*)m;
currentBuffer ^= 0x01;
}
call LoggerWrite.append(ptr);
return tmp;
}
command result_t StdControl.stop() {
return SUCCESS;
}
event result_t LoggerWrite.writeDone( result_t status ) {
if (status) call Leds.yellowOn();
return SUCCESS;
}
What is mistake in code?
Thanks in advance.
Nida
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] XServe
Hi guys, Has anyone ever actually successfully worked with XML RPCs to XServe? I have XServe running fine, and I'm able to use XServeTerm without any issues.. but all I'm reading about is lots of documentation on XServe, and a lack of actual working implementations. For the moment, all I want to do is setup a client using the apache xml-rpc library and make a get_config call for a node with an ID of 1.. should be simple? My xserve instance is running on localhost, port 9001. Nothing but issues!! Using MicaZ sensors.. data is showing on my terminal window fine but can't make an XML RPC method call! Any ideas? Regards, Dave ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] unable to receive UART frame
Hi Urs, the official baud rate is 57600 but the AVR ATMega1281 on my platform (Meshbean) should use double rate for the UART but the controller does not use double rate even though the flag is set (should be set??). I think the accuracy at 57600 is not high enough. Using the baud rate 38400 the error (jitter) is less and it works. The modules uses a RC oscillator instead of a crystal this circumstances affects less clock accuracy. Now the received data and the signaled event ends in the default event message_t *Receive.received[uart_id_t idxxx](message_t *msg, void *payload, unit8_t len) in the file: SerialDispacherP.nc I expected an signaled event in my testSerialC.nc at the line: event message_t *Receive.receive(message_t * bufPtr, void * payload, uint8_t len) How can I signal my Receive.receive event? Or should I use an other received event? Is it a wiring problem? Cheers, Mario -Ursprüngliche Nachricht- Von: Urs Hunkeler [mailto:urs.hunke...@epfl.ch] Gesendet: Donnerstag, 21. Oktober 2010 20:13 An: Mario Riesner Cc: tinyos-help@Millennium.Berkeley.EDU Betreff: Re: AW: AW: AW: [Tinyos-help] unable to receive UART frame Hi Mario, Glad it works now. What's the official platform baudrate (normaly in $TOSROOT/tos/platform/yourplatform/hardware.h defined as PLATFORM_BAUDRATE)? Cheers, Urs On 10/21/2010 04:14 PM, Mario Riesner wrote: Hi Urs, again, I reduced the baud rate to 38400 now it works. The module receives a whole frame and sends an ACK frame. Now I have to find out why the highest event in my test code is not called. For now thank you for your help. Cheers, Mario ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] unable to receive UART frame
Hi Mario, The default event is indeed only called if no wiring has been specified. This could have two reasons: (1) you have a wiring problem (as you suggested), or (2) or the type of the message (the value in the square brackets [] before the function parameters) is not the expected value. Personally, since this is not a value that you specify yourself in the code, I'd go with option (2). In SerialActiveMessageC the SerialDispatcherC.Receive is wired for TOS_SERIAL_ACTIVE_MESSAGE_ID, which is defined in Serial.h as 0. Without spending more time analyzing the code I think this means the following. The framing protocol used by the serial connection supports multiplexing different types of messages (why ever they would need this). The ID of the messages used for TinyOS communication is 0, your PC-based code could be sending a frame type different from 0. Ok, I looked a bit more into it: Byte 2 (Framer-level dispatch) is set to 0x45 = 69 = SERIAL_PROTO_PACKET_ACK, which is the only frame type that is handled (see SerialP.nc). Byte 3 (as expected in SerialP.nc) seems to be a sequence number (so make sure to increment it :-) ). (here you seem to miss a byte in your list) Byte 4 is the frame data type If my reading of the source code is correct, this value would need to be 0 (TOS_SERIAL_ACTIVE_MESSAGE_ID). Byte 5-6: destination address (see Serial.h, serial_header) Byte 7-8: source address (see Serial.h, serial_header) Byte 9: length (see Serial.h, serial_header) Byte 10 would be the group ID (see serial_header in Serial.h). The group ID is used to logically separate different sensor networks sharing the same radio channel. Byte 11: AM type (see Serial.h, serial_header) Let me know whether inserting the missing Byte 4 (frame data type) with a value of 0 solves your problems (you might need to update the checksum). Cheers, Urs On 10/22/2010 12:40 PM, Mario Riesner wrote: Hi Urs, the official baud rate is 57600 but the AVR ATMega1281 on my platform (Meshbean) should use double rate for the UART but the controller does not use double rate even though the flag is set (should be set??). I think the accuracy at 57600 is not high enough. Using the baud rate 38400 the error (jitter) is less and it works. The modules uses a RC oscillator instead of a crystal this circumstances affects less clock accuracy. Now the received data and the signaled event ends in the default event message_t *Receive.received[uart_id_t idxxx](message_t *msg, void *payload, unit8_t len) in the file: SerialDispacherP.nc I expected an signaled event in my testSerialC.nc at the line: event message_t *Receive.receive(message_t * bufPtr, void * payload, uint8_t len) How can I signal my Receive.receive event? Or should I use an other received event? Is it a wiring problem? Cheers, Mario ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] erasing the log
Hi all, is there any simple method of erasing the log on the node NOT from the code itself? E.g. when installing a new program? Anna -- Dr. Anna Förster PostDoctoral Researcher Networking Laboratory, SUPSI Via Cantonale, Galleria 2 Manno, Switzerland Tel. + 41 58 666 6597 http://www.dti.supsi.ch/~afoerste/ ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Deluge Post-Dissemination Reboot Problem
From: eced...@ece.iisc.ernet.in From my experience with deluge, if you opt for 'disseminate and reboot' option, the program gets disseminated and all the nodes now reboot with this code. You can verify this by ping command and find the name in the Currently Executing: part. Could you tell me the exact sequence of the commands that you are using here? And also a flag in the Makefile has to be changed for basestation and non-basestation motes. Hi, First, thanks for your help. This is the method I have used: cd to tosboot directory make telosb cd $TOSROOT/apps/tests/deluge/Basestation make telosb install,52 bsl,/dev/ttyUSB1 tos-deluge serial@/dev/ttyUSB1:115200 -i 0 build/telosb/tos_image.xml cd $TOSROOT/apps/tests/deluge/GoldenImage make telosb install,XXX bsl,/dev/ttyUSB2 tos-deluge serial@/dev/ttyUSB2:115200 -i 0 build/telosb/tos_image.xml Repeat previous two commands for each node. To test dissemination: make telosb tos-deluge serial@/dev/ttyUSB1:115200 -i 1 build/telosb/tos_image.xml tos-deluge serial@/dev/ttyUSB1:115200 -dr 1 Result with CVS version: Code disseminates, nodes reprograms, node requires tap on reset button to start up. Result with new version: No code dissemination occurs: no nodes overhear data exchange. The main problem I would really like to solve, even if I have to code it myself, is to have the nodes properly reset at the end so that they do not need to be reset using the button. I'm assuming that Basestation and GoldenImage do not require CFLAGS+=-DELUGE_LIGHT_BASESTATION or whatever to be included on the command line since this appears in the Makefile. Any help appreciated! ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP: ETX values vs. LPL wake-up interval
Are you using TestNetworkLpl and changing the flags in the Makefile to control various intervals? If not, you should tell me how to replicate your problem starting with TestNetworkLpl. - om_p On Thu, Oct 21, 2010 at 11:01 PM, Manjunath Doddavenkatappa dodda...@comp.nus.edu.sg wrote: Generally, yes. As ETX increases lossses also increase. I can observe the fact that RetxmitTimer in CtpForwardingEngine being fired quite a few times before sucessfully transmitting every packet. But, only a few times this does not hold with packets getting through although ETX remains at a higher value. Please let me know if you want me to redo the experiments if you need any other information. Regards, Manjunath D *** On Thu, 21 Oct 2010, Omprakash Gnawali wrote: On Tue, Oct 19, 2010 at 1:04 AM, Manjunath Doddavenkatappa dodda...@comp.nus.edu.sg wrote: Dear All, We are not able to figure out a reason why ETX values in CTP increases as wake-up interval of the LPL (BoXMaC-One) increases. We have a simple setup of a sender and a root node placed adjacent to each other. Nodes use maximum power of 0 dBm. 1) We are using IPI of 15s. We repeated the experiment at three different places with sevral runs runs at every location. Different wake-up intervals were tried back-to-back so that temporal variations are minimized. We used wake-up intervals of 10, 20, 40, 100, and 1000 (ms). 2) We also used LPL.setRemoteWakeupInterval(packet, WAKEUP_INTERVAL + 100) but without any luck. 3) Our debug messages show that CTP's RetxmitTimer being fired quite a few times before sucessfully transmitting every packet. 4) I first thought that the loss of data packets in the BoXMAC's preamble could be the reason, but looking into the LPL code, I understand that preamble packet losses are not fed into the Link Estimator. 5) In some experimental runs, particularly when the wake-up interval is 1000ms, no packet go-through. Requires a hard reboot. 6) Searching the archieves for CTP and LPL on tmote, I found that similar problem being discussed sometime in Dec 2008. The discussion suggests quite a few number of changes. http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/2008-December/003510.html We should debug this. Do you also observe loss in delivery ratio along with high ETX values? - om_p ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Forwarding Message
On Mon, Oct 18, 2010 at 10:15 AM, Urs Hunkeler urs.hunke...@epfl.ch wrote:
On the relay nodes you just need to increment the hop count for each
message. You can intercept messages before they are forwarded. To do
this you'll have to implement the Intercept interface. The code could
look something likes this:
event bool forward(message_t* msg, void* payload, uint8_t len) {
MyMsg* data = (MyMsg*)payload; // cast to your own data structure
data-hopCount++; // increase the hop count of the message
return true; // tell the underlying system to forward the message
}
If you use CTP, you can read the value of the THL field for hopcount.
- om_p
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] MICA2 transmission power adjustment in tinyos 2.x
Thanks for your reply. However, it has compilation error
RadioStrengthControl.setRFPower not connect. What component should I put in
the configuration file? For example, what component provides interface
CC1000Control? Then I'll put that into my configuration file and wire it
accordingly (myApp.RadioStrengthControl - ??? ). In tinyos 1.x, It's just
myApp.RadioStrengthControl - CC1000RadioC . But CC100RadioC disappears in
tinyos 2.x THank you.
rdgs,
PN
Quoting Enrico Treu m...@e-treu.de:
In order to get this behaviour i simply added a few lines of code to my
application:
module /**/ {
uses {
//...
interface CC1000Control as RadioStrengthControl;
//...
}
}
and
event void Boot.booted() {
//...
#ifdef RFPOWER
call RadioStrengthControl.setRFPower(RFPOWER);
#endif
//..
}
Am Donnerstag, 21. Oktober 2010, 03:03:40 schrieb Prusayon Nintanavongsa:
Hi all,
How do you adjust MICA2 transmission power in tinyos 2.x other than
adding CFLAG in the Makefile? In tinyos 1.x, there's CC1000RadioC which
can be wired to CC1000Control in order to call SetRFPower(). I would like
to adjust the transmission power adaptively. Thank you.
rdgs,
PN
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] could someone help me with the installation, thx
Hi, I'm a new user to TinyOS, and when I started to install the Moteiv Tmote tools 2.0.5 setup, it will tell me there is a problem with this installer package and a program required for this install to complete could not be run. I don't know where the problem is. Could anyone help me? Thanks. Michael ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Problem with 4bitle link estimator
I just committed some tweaks to the estimator. Can you check now? - om_p On Thu, Oct 21, 2010 at 11:07 PM, Qiu Ying qy.n...@gmail.com wrote: I would need a little bit more information to help you debug CTP. How can I reproduce this bug? It's easy to reproduce it on my platform(atmega1281+rf230). Use 2 mote with TestNetwork application, suppose root id is 0, the other is 1. Start the root first, then start mote 1, the etx changes as follows: (I add a printf in updateETX(), LinkEstimatorP.nc) etx=6553 etx=5906 etx=5320 etx=4791 etx=4314 etx=3885 etx=3498 etx=3150 etx=2836 etx=2554 etx=2300 etx=2071 etx=1865 etx=1679 etx=1512 etx=1362 ... but in the reverse power on order(start mote1 then start root), it's OK. etx=10 etx=14 etx=13 etx=15 etx=14 ... 2010/10/22 Omprakash Gnawali gnaw...@cs.stanford.edu: On Thu, Oct 21, 2010 at 12:42 AM, qiu ying qy.n...@gmail.com wrote: Hi,all I found mote(ctp+4bitle) sometimes failed to send ctp packet as no parent is chosen, even the root is very close the mote. The reason I found is VERY_LARGE_ETX_VALUE is set to 0x in tos/lib/net/4bitle/LinkEstimatorP.nc, it is too large maybe, once used in computeETX(), the etx is much larger than ETX_THRESHOLD for a long time due to the EWMA algorithm. SVN r4975 make this change(0xff- 0x), anyone know the reason? We wanted the largest 16-bit value we could return to indicate an invalid ETX. Setting this constant to 0xFF can confuse exceptionally large ETX (e.g., ETX=25) as an invalid ETX. I would need a little bit more information to help you debug CTP. How can I reproduce this bug? - om_p ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] MultihopOscilloscope in Google Code doesn't work
Hi, I just switched to the Tinyos on Google Code. It seems that the MultihopOscilloscope does work. I can only receive data from root node, but not from other nodes. It seems the problem is that sendDone() is never triggered on a node who is not root. Does someone else have MultihopOscilloscope working? The older version I got from CVS did work well. Thanks, Lan ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] MultihopOscilloscope in Google Code doesn't work
Forgot to mention, I am using TelosB. I just tried MultihopOscilloscopeLqi, doesn't work either. The red LED toggles on root node, which comes from report_problem() in the code. Lan From: lancey...@hotmail.com To: tinyos-help@millennium.berkeley.edu Date: Sat, 23 Oct 2010 08:56:05 +0800 Subject: [Tinyos-help] MultihopOscilloscope in Google Code doesn't work Hi, I just switched to the Tinyos on Google Code. It seems that the MultihopOscilloscope does work. I can only receive data from root node, but not from other nodes. It seems the problem is that sendDone() is never triggered on a node who is not root. Does someone else have MultihopOscilloscope working? The older version I got from CVS did work well. Thanks, Lan ___ 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] CC2420DBK using TinyOS
Hi Jingyao, I use Tinyos-2.0.2... You will have to make changes to some files in micaz for making it work. Please also send your questions to tinyos-help as there might be other people also who can answer the questions. Regards, Varun Jain From: Jingyao [mailto:jingyao...@gmail.com] Sent: Wednesday, 20 October 2010 4:40 AM To: Varun Jain Subject: CC2420DBK using TinyOS Hi, Varun, I'm working on CC2420DBK board using TinyOS. I saw your post in TinyOS maillist. http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2008-August/03 5490.html You said My platform (Chipcons CC2420DBK) is very similar to Micaz and I have ported my platform in TinyOS correctly and all the test applications are working correctly. Can you tell me what version of TinyOS do you use? Or did you change some code of TinyOS? Because I use TinyOS 2.1.1 and load Blink application on my board, it does not work. I need to figure it out. Thanks a lot. Regards, Jingyao ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Damaged IEEE 802.15.4 header in TinyOS 2.x
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Phil, thanks for your reply. You're right, there's a problem with the current version of the CC2420CsmaP.nc. If I use the previous version of this file, wireshark captures correct IEEE headers of my applications again. However, there's one exception: Although I recompiled the tosboot component, Deluge packets still seem to be broken. Any idea how to fix that? Best regards, Jan Am 22.10.2010 00:33, schrieb Philip Levis: Stephen, I think you broke CC2420CsmaP.nc on r5174. In particular, the setting of the FCF. Can you please check that it still works with regular AM packets. Also, the current code is such that if you compile with HW security support it won't compile. Phil On Oct 20, 2010, at 12:41 PM, Jan Bauer wrote: Hi all, since I've updated my TinyOS version from 2.1.1 to the newest SVN version, I've got problems with decoding transmitted packets in wireshark (using the Jackdaw RZUSBStick). For example, I've captured these two Drip/Deluge-Hello-Packets below. The first was sent from a TelosB mote running TinyOS 2.1.1 and the second from the same mote running the current version of TinyOS. 1) IEEE Header: | Payload | IEEE FCS Flags SN PANID DA SA | AMType Drip/Deluge Hello | 4188 01 2200 beef | 3f60 de00 | a7ef 2) IEEE Header: | Payload | IEEE FCS Flags SN PANID | | 4100 01 2200 | 3fff beef 0060 de00 | e478 As far as I know, the second byte 00 of the IEEE flags in TinyOS 2.x is not consistent with the IEEE 802.15.4 standard. Besides, this byte is the reason of interpreting all bytes between PANID and FCS as payload. But there are more inconsistencies. Any ideas what's wrong here? Thanks in advance! Best regards, Jan ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzBtvEACgkQn5zXZhfsUo6k/gCeLNWVM9TA3FhZrbPgU/avkzv9 OJ4AoMSTx54n6ZTCGfQLlPhKVk2aWh60 =oJm+ -END PGP SIGNATURE- ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] cant run : make micaz sim
Hello! Well it seems like you are facing a Python version mismatch and it has happened because the sim.extra which is a file inside your tinyos make directory which is usually at /opt/tinyos-2.x/support/make has a hard coded line which says PYTHON_VERSION. Yuo gotta change that to 2.6 or whichever the python version yu use. After this change, try make micaz sim and do report if it solves your problem. I hope it does :) talk2kish wrote: I tried the commands you mentioned but ended up at the same problem. mkdir -p simbuild/micaz make: python2.5-config: Command not found make: python2.5-config: Command not found make: python2.5-config: Command not found any suggestions? Sam Azzaro wrote: Hello,i had the same error,you must install python2.5-devif you are using TOSSIM with ubento, you just have to tape: sudo apt-cache search pythonsudo apt-get install python2.5-dev Regards Sam, Date: Thu, 20 May 2010 12:59:18 +0200 From: zied...@googlemail.com To: tinyos-help@millennium.berkeley.edu Subject: [Tinyos-help] cant run : make micaz sim hi people, when i type make micaz sim on the promt i get this error. my Python version ist : 2.6.5 /opt/tinyos-2.x/tos/lib/tossim/tossim_wrap.cxx -I/usr/include/python2.5 -I/opt/tinyos-2.x/tos/lib/tossim -DHAVE_CONFIG_H /opt/tinyos-2.x/tos/lib/tossim/tossim_wrap.cxx:26:20: error: Python.h: No such file or directory /opt/tinyos-2.x/tos/lib/tossim/tossim_wrap.cxx:296: error: ISO C++ forbids declaration of ‘PyObject’ with no type /opt/tinyos-2.x/tos/lib/tossim/tossim_wrap.cxx:296: error: expected ‘;’ before ‘*’ token /opt/tinyos-2.x/tos/lib/tossim/tossim_wrap.cxx:297: error: ‘PyObject’ has not been declared /opt/tinyos-2.x/tos/lib/tossim/tossim_wrap.cxx:302: error: ‘PyObject_HEAD’ does not name a type /opt/tinyos-2.x/tos/lib/tossim/tossim_wrap.cxx:306: error: expected initializer before ‘*’ token /opt/tinyos-2.x/tos/lib/tossim/tossim_wrap.cxx:313: error: ‘FILE’ has not been declared /opt/tinyos-2.x/tos/lib/tossim/tossim_wrap.cxx: In function ‘int swig_varlink_print(swig_varlinkobject*, int*, int)’: /opt/tinyos-2.x/tos/lib/tossim/tossim_wrap.cxx:316: error: ‘fprintf’ was not declared in this scope /opt/tinyos-2.x/tos/lib/tossim/tossim_wrap.cxx:317: error: ‘struct swig_varlinkobject’ has no member named ‘vars’ /opt/tinyos-2.x/tos/lib/tossim/tossim_wrap.cxx: At global scope: /opt/tinyos-2.x/tos/lib/tossim/tossim_wrap.cxx:325: error: expected initializer before ‘*’ token /opt/tinyos-2.x/tos/lib/tossim/tossim_wrap.cxx:3496: error: expected ‘}’ at end of input make: *** [sim-exe] Fehler 1 _ Votre messagerie et bien plus où que vous soyez. Passez à Windows Live Hotmail, c'est gratuit ! https://signup.live.com/signup.aspx?id=60969 ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- View this message in context: http://old.nabble.com/cant-run-%3A-make-micaz-sim-tp28628756p30026886.html Sent from the TinyOS - Help mailing list archive at Nabble.com. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CC2420DBK using TinyOS
Hi, Varun, Thank you so much for your reply. Would you please give me some clue what files should I change? Currently, I loaded binaries of Blink to CC2420DBK board, it does not work. Thanks. Regards, Jingyao From: Varun Jain Sent: October 22, 2010 9:17 PM To: Jingyao Cc: tinyos-help@millennium.berkeley.edu Subject: RE: CC2420DBK using TinyOS Hi Jingyao, I use Tinyos-2.0.2... You will have to make changes to some files in micaz for making it work. Please also send your questions to tinyos-help as there might be other people also who can answer the questions. Regards, Varun Jain From: Jingyao [mailto:jingyao...@gmail.com] Sent: Wednesday, 20 October 2010 4:40 AM To: Varun Jain Subject: CC2420DBK using TinyOS Hi, Varun, I'm working on CC2420DBK board using TinyOS. I saw your post in TinyOS maillist. http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2008-August/035490.html You said My platform (Chipcons CC2420DBK) is very similar to Micaz and I have ported my platform in TinyOS correctly and all the test applications are working correctly. Can you tell me what version of TinyOS do you use? Or did you change some code of TinyOS? Because I use TinyOS 2.1.1 and load Blink application on my board, it does not work. I need to figure it out.Thanks a lot.Regards,Jingyao___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] CTP: CtpForwardingEngineP component error
-- Forwarded message --
From: Philip Levis p...@cs.stanford.edu
Date: 2010/10/23
Subject: Re: [Tinyos-devel] CTP: CtpForwardingEngineP component error
To: Dongyu Yang yangdy.n...@gmail.com
Cc: tinyos-de...@millennium.berkeley.edu
Please send questions to tinyos-help.
Phil
On Oct 22, 2010, at 10:12 PM, Dongyu Yang wrote:
Hello!
I set up one network containing four Node and one Root, and use drip to
disseminate command, and use ctp to collect data.The Root disseminates
command every 200 ~ 700 ms (randomly), and the Node use ctp to send
data to the Root when receive the command from the Root. I find the Node
can receive the Root dissemination command, but can nerver send out data
after about several minutes (about 5 minutes). And I find ever time when
call Send.send(), the return value is EBUSY. And I find every time it
return form
the Send.send() command in the component CtpForwardingEngineP as bellow:
command error_t Send.send[uint8_t client](message_t* msg, uint8_t len) {
ctp_data_header_t* hdr;
fe_queue_entry_t *qe;
dbg(Forwarder, %s: sending packet from client %hhu: %x, len
%hhu\n, __FUNCTION__, client, msg, len);
if (!hasState(ROUTING_ON)) {return EOFF;}
if (len call Send.maxPayloadLength[client]()) {return ESIZE;}
..
if (clientPtrs[client] == NULL) {
dbg(Forwarder, %s: send failed as client is busy.\n,
__FUNCTION__);
return EBUSY;
}
..
}
I find in the task sendTask(), when the subsendResult value is not SUCCESS
or ESIZE, the phenomenon mentioned above will happen, as below:
task void sendTask() {
..
subsendResult = call SubSend.send(dest, qe-msg, payloadLen);
if (subsendResult == SUCCESS) {
// Successfully submitted to the data-link layer.
setState(SENDING);
dbg(Forwarder, %s: subsend succeeded with %p.\n,
__FUNCTION__, qe-msg);
return;
}
// The packet is too big: truncate it and retry.
else if (subsendResult == ESIZE) {
dbg(Forwarder, %s: subsend failed from ESIZE: truncate
packet.\n, __FUNCTION__);
call Packet.setPayloadLength(qe-msg, call
Packet.maxPayloadLength());
post sendTask();
call CollectionDebug.logEvent(NET_C_FE_SUBSEND_SIZE);
}
else {
dbg(Forwarder, %s: subsend failed from %i\n, __FUNCTION__,
(int)subsendResult);
}
..
}
I find the code didn't deal with when the subsendResult value is not
SUCCESS
or ESIZE. And when I add post sendTask(); in the else path as below,
it is
OK and do not appear the above phenomenon (I test about one hour).
task void sendTask() {
..
subsendResult = call SubSend.send(dest, qe-msg, payloadLen);
if (subsendResult == SUCCESS) {
// Successfully submitted to the data-link layer.
setState(SENDING);
dbg(Forwarder, %s: subsend succeeded with %p.\n,
__FUNCTION__, qe-msg);
return;
}
// The packet is too big: truncate it and retry.
else if (subsendResult == ESIZE) {
dbg(Forwarder, %s: subsend failed from ESIZE: truncate
packet.\n, __FUNCTION__);
call Packet.setPayloadLength(qe-msg, call
Packet.maxPayloadLength());
post sendTask();
call CollectionDebug.logEvent(NET_C_FE_SUBSEND_SIZE);
}
else {
post sendTask();
dbg(Forwarder, %s: subsend failed from %i\n, __FUNCTION__,
(int)subsendResult);
}
..
}
I think it's may be forget to add the code post sendTask();, because
some reason.
Best regards!
___
Tinyos-devel mailing list
tinyos-de...@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
