Re: [Tinyos-help] Reg:transmission power control for preamble
Or, using #define CC2420_DEF_RFPOWER 1. 2010/11/15 manish chaturvedi msc@gmail.com Hi, For setting transmit power for each packet separately, You can use CC2420Packet interface provided by CC2420PacketC. and use the function setPower of the interface. call CC2420Packet.setPower(pkt,31);//set the output power to max i.e 0 dBm Refer to CC2420 data sheet for various tranmit power values. Hope this helps.. Regards Manish.. On components CC2420PacketC; App.CC2420Packet - CC2420PacketC; in your configuration file uses interface CC2420Packet; On Mon, Nov 15, 2010 at 11:58 AM, SHIVASANKAR GANESAN tata...@yahoo.co.in wrote: Hi How to control transmission power for the preamble(in MICAZ mote). ** *With regards* *Sivasankar* ___ 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] SPI communication On TelosB
Hello everyone, Can anyone suggest an example or tutorial in order to make a TelosB to communicate with an external microcontroller using SPI? Thanks in advance, Dennis ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Sending characters from Java appln to Mote
Hi Venkat, The tutorials explain how to create your own message format in the radio communications tutorial: http://docs.tinyos.net/index.php/Mote-mote_radio_communication In your own message format you can specify arrays, e.g., as nx_uint8_t myArray[20];. The unsigned 8-bit integer is probably the closest you get to a char array (or string). You might have to copy the contents of the array to a local structure before you can use it on the mote. To use this message format with Java, you can (automatically) create a Java class handling your message format. This is described in the serial communications tutorial (the tool is called mig): http://docs.tinyos.net/index.php/Mote-PC_serial_communication_and_SerialForwarder There are also other interesting tutorials available. Have a look at the tutorials page: http://docs.tinyos.net/index.php/TinyOS_Tutorials Cheers, Urs On 11/17/10 8:35 AM, Venkat wrote: Hi, I am running a java GUI application on my pc to send packets ( random integer) to the mote via serial port. I was just wondering how to send characters over the serial port to the mote? I modified the testserial.java application for my GUI. However, the Testserial.java has method to send only integers over the serial port. It doesnt have a method call for sending arrays. I was thinking if i cud convert the characters into hex and send it. but, still, if i want to send a string, it will again be an array of integers. I am quite new to tinyos and nesc programming. Could some one help me with this ? Thanks, Venkat ___ 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] Zigbee implementation on Tinyos2.1.1
Hello Tarek, For the moment security is not supported in the Zigbee implementation. However, we are currently trying to make that happen as we are realigning with a more stable ieee 802.15.4 implementation. Perhaps you are willing to contribute? Cheers, Ricardo Severino From: tinyos-help-boun...@millennium.berkeley.edu [mailto:tinyos-help-boun...@millennium.berkeley.edu] On Behalf Of mohammed tarek Sent: segunda-feira, 15 de Novembro de 2010 18:07 To: tinyos support; tinyos help Subject: [Tinyos-help] Zigbee implementation on Tinyos2.1.1 hello I need to ask which version of Zigbee is implemented on tinyos is it Zigbee pro (Zigbee 2007) that provides 2 security modes (Standard - High) or is it Zigbee that provides one mode for encryption Mohammed Tarek Teach assistant Computer and systems dep. Faculty of Engineering Zagazig university ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] 802.15.4
i'm testing TestData with one coordinator and two devices. Problem: -the prosmicuos print this Frametype: Data SrcAddrMode is the problem TestData (do the LEDs toggle as described?) or only TestPromiscuous? (also check with latest SVN version, http://code.google.com/p/tinyos-main/) I have other question... Whats the difference BaseStation15.4 and TestPromiscuos? apps/tests/tkn154/nonbeacon-enabled/TestPromiscuous uses the TKN15.4 MAC (tos/lib/mac/tkn154); apps/BaseStation15.4 uses ActiveMessageC, which wires the platform's default MAC (e.g. tos/chips/cc2420). Jan Thanks for all On Tue, Nov 16, 2010 at 10:59 PM, Daniel Schnit daniel.sch...@gmail.com wrote: Hi all, i'm testing TestData with one coordinator and two devices. Problem: -the prosmicuos print this Frametype: Data SrcAddrMode Frametype: Data SrcAddrMode Frametype: Data SrcAddrMode Frametype: Data SrcAddrMode - i can't syncronize two devices...just one syncronize! Thks, ___ 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] 802.15.4
I have tried TestData with two devices (compiling with TKN154_DEBUG=1) and I have noticed the same problem. Only one device at a time is sync, cause the other one loses the beacon frame and hence, sync. This could be cause the Test is thought to have just one device sync, and so this one is sending packets all the time. If you try to set up a timer so that the devices send just 1packet/second, you will have no problems in this aspect. Nevertheless, I have had some problems using timers and the tkn154, cause it makes lose sync after a while (could be 2mins or 2hours, depends on the BO and the time between packets). Regards, Pablo 2010/11/17 Jan Hauer ha...@tkn.tu-berlin.de i'm testing TestData with one coordinator and two devices. Problem: -the prosmicuos print this Frametype: Data SrcAddrMode is the problem TestData (do the LEDs toggle as described?) or only TestPromiscuous? (also check with latest SVN version, http://code.google.com/p/tinyos-main/) I have other question... Whats the difference BaseStation15.4 and TestPromiscuos? apps/tests/tkn154/nonbeacon-enabled/TestPromiscuous uses the TKN15.4 MAC (tos/lib/mac/tkn154); apps/BaseStation15.4 uses ActiveMessageC, which wires the platform's default MAC (e.g. tos/chips/cc2420). Jan Thanks for all On Tue, Nov 16, 2010 at 10:59 PM, Daniel Schnit daniel.sch...@gmail.com wrote: Hi all, i'm testing TestData with one coordinator and two devices. Problem: -the prosmicuos print this Frametype: Data SrcAddrMode Frametype: Data SrcAddrMode Frametype: Data SrcAddrMode Frametype: Data SrcAddrMode - i can't syncronize two devices...just one syncronize! Thks, ___ 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] 802.15.4
but Promiscuos are better to use for 802.15.4 and the examples? the problem is one device cant syncro and the promiscuos print this code, but if i reset promiscuos he starts print correct and after just Frametype: Data SrcAddrMode On Wed, Nov 17, 2010 at 9:21 AM, Jan Hauer ha...@tkn.tu-berlin.de wrote: i'm testing TestData with one coordinator and two devices. Problem: -the prosmicuos print this Frametype: Data SrcAddrMode is the problem TestData (do the LEDs toggle as described?) or only TestPromiscuous? (also check with latest SVN version, http://code.google.com/p/tinyos-main/) I have other question... Whats the difference BaseStation15.4 and TestPromiscuos? apps/tests/tkn154/nonbeacon-enabled/TestPromiscuous uses the TKN15.4 MAC (tos/lib/mac/tkn154); apps/BaseStation15.4 uses ActiveMessageC, which wires the platform's default MAC (e.g. tos/chips/cc2420). Jan Thanks for all On Tue, Nov 16, 2010 at 10:59 PM, Daniel Schnit daniel.sch...@gmail.com wrote: Hi all, i'm testing TestData with one coordinator and two devices. Problem: -the prosmicuos print this Frametype: Data SrcAddrMode Frametype: Data SrcAddrMode Frametype: Data SrcAddrMode Frametype: Data SrcAddrMode - i can't syncronize two devices...just one syncronize! Thks, ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] TinyOS 2.X and PN2
Hi, I just installed Tinyos 2.X on my pc and when I compile a code with an interface of this Tinyos (PlatformSerialC) on PN2, I have many errors. I saw that I have two folders, MoteWorks and Tinyos-2.x. If I compile a code from MoteWorks' folder the problem is that PN2 don't find the interface (PlatformSerialC). In component `MyApp': MyApp.nc:34: cannot find `PlatformSerialC' MyApp.nc:35: cannot find `PlatformSerialC' MyApp.nc:36: cannot find `PlatformSerialC' I tried to copy the folder from tinyos 2.x with the the interfaces to Moteworks but still not working. What can I do? Thanks in advance and regards. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Sending characters from Java appln to Mote
Hi Venkat,
I don't see where the problem could be. Maybe there is a problem with
multiple definitions of classes. Sometimes old versions exist and the
make system does not realize it should recreate/regenerate some of the
files. I usually make sure to recompile everything by removing all
unnecessary files first. Best approach is to add all the generated files
to the list of files to be deleted by make clean. If you don't already
have something like this I recommend you add a line like the following
to your Makefile:
CLEAN_EXTRA = *.class TestSerialMsg.java
Then to compile your application, clean your build directory and compile
everything:
make clean make tmote
(Of course you'll have to replace tmote with whatever platform you're
using).
If this still doesn't help, try renaming the array and see whether you
get a different error. You can also look at the generated
TestSerialMsg.java file and verify that it indeed has a method called
set_counter(int[] something). If so, also verify that the variable
you're passing in your Java code is indeed an array. You could for
instance add a line like this:
// ...
while (flag) {
// add a line to print some debugging information
// if the variable counter is for some obscure
// reason not an array here, it will cause a compile
// error already at the print statement and we know
// the problem is in the code here and not in the
// TinyOS code:
System.out.println( Debugging: Counter[0] is + counter[0]);
payload.set_counter(counter);
moteIF.send(0, payload);
// ...
Cheers,
Urs
PS: Please copy your messages also to the tinyos-help mailing list so
others who might have similar problems or better solutions can also read
and contribute.
On 11/17/2010 11:16 AM, Venkat wrote:
Hi ,,
I still have the same problem.
my nesC header file myapp.h is
*typedef nx_struct test_serial_msg {
nx_uint16_t counter[6];
} test_serial_msg_t;*
My Makefile MIG rule is
*mig java -target=null $(CFLAGS) -java-classname=TestSerialMsg myapp.h
test_serial_msg -o $...@*
My java Application code is
*public void sendPackets() {
int counter[] = new int[6];
int newarray[] = new int[6];
int length = 0;
String intervalS = fieldInterval.getText().trim();
length = intervalS.length();
try {
for (int i =1; i=length; i++){
newarray[i] = intervalS.charAt(i);
if (newarray[i] 99) throw new NumberFormatException();
counter[i] = newarray[i];
}
}
catch (NumberFormatException e) {
//Reset field when value is bad
fieldInterval.setText( + counter);
}
TestSerialMsg payload = new TestSerialMsg();
try {
while (flag) {
payload.set_counter(counter);
moteIF.send(0, payload);
flag = false;
//catch (InterruptedException exception) {}
}
}*
I get the following error.
*TestSerial.java:56: set_counter(int[]) in TestSerialMsg cannot be
applied to (int)
payload.set_counter(counter);
^
1 error
make: *** [MyApp.class] Error 1*
Could you kindly help me with it?
Thank you ,
Regards,
Venkat.
On Wed, Nov 17, 2010 at 10:39 AM, Venkat v.venkatasubraman...@gmail.com
mailto:v.venkatasubraman...@gmail.com wrote:
Thank you for the reply. I have already gone thro the tutorials. But
I dint know that the MIG tool uses the msg structure type that is
specified in the make file to automatically create a class that
sends packet objects of the specified format. Now i think i got my way.
thank you very much.
Regards,
Venkat.
On Wed, Nov 17, 2010 at 10:23 AM, Urs Hunkeler urs.hunke...@epfl.ch
mailto:urs.hunke...@epfl.ch wrote:
Hi Venkat,
The tutorials explain how to create your own message format in
the radio communications tutorial:
http://docs.tinyos.net/index.php/Mote-mote_radio_communication
In your own message format you can specify arrays, e.g., as
nx_uint8_t myArray[20];. The unsigned 8-bit integer is
probably the closest you get to a char array (or string). You
might have to copy the contents of the array to a local
structure before you can use it on the mote.
To use this message format with Java, you can (automatically)
create a Java class handling your message format. This is
described in the serial communications tutorial (the tool is
called mig):
http://docs.tinyos.net/index.php/Mote-PC_serial_communication_and_SerialForwarder
There are also other interesting tutorials available. Have a
look at the tutorials page:
http://docs.tinyos.net/index.php/TinyOS_Tutorials
Cheers,
Urs
On 11/17/10 8:35 AM, Venkat wrote:
Hi,
I am running a java GUI application on my pc to send packets
( random
integer) to the mote via serial port. I was just wondering
how to send
characters over the serial port to the mote? I modified the
[Tinyos-help] (no subject)
http://it-entwickler.com/rew.html ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] So wierd problem about Deluge T2
Hello： Recently, I was trouble in Deluge T2 about not stoping the reprogramed client node. I had correctly injected a revised Blink image to Basestation and sent the image to client node. Then I sent : tos-deluge serial@/dev/ttyUSB0:115200 -dr 1 for reprograming. The client node also runed Blink. But when I wanted to stop the runed program in client node, I sent command: tos-deluge serial@/dev/ttyUSB0:115200 -ls 1 to Basestation by serial port. The client still was running. I could not stop it. Is it a bug, or How can I solve it？ I will very appreciate your help. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] xubuntos + boomerang
Does anybody have any advice on how to use Xubuntos with Moteiv's (Sentilla's) Boomerang distribution? I've downloaded Boomerang from here; http://tinyos.cvs.sourceforge.net/tinyos/tinyos-1.x/contrib/boomerang/ and I've put it at /opt/tinyos-1.x/contrib/boomerang however when I try to run make tmote on the Boomerang version of Oscilloscope at; /opt/tinyos-1.x/contrib/boomerang/apps/Oscilloscope I get; ERROR, tmote ident_flags tos_image bnp does not specify a valid target. Stop. This is after I've run tos1 to set up for TinyOS 1.x Can anybody shed some light on this matter? Regards, CJ Davies ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] CTP not reporting NET_C_FE_DST_MSG and NET_C_TREE_RCV_BEACON
Hi Om,
I've always wondered why CTP does not report arrived messages and received
beacons. Over time I've found these events very useful when debugging CTP.
Is there a reason for not reporting these events? If not, see proposed
changes below.
Morten.
CtpForwardingEngineP.nc
@@ -712,13 +712,17 @@ implementation {
}
// If I'm the root, signal receive.
-else if (call RootControl.isRoot())
+else if (call RootControl.isRoot()) {
+ call CollectionDebug.logEventMsg(NET_C_FE_DST_MSG,
+ call
CollectionPacket.getSequenceNumber(msg),
+ call
CollectionPacket.getOrigin(msg),
+ thl--);
return signal Receive.receive[collectid](msg,
call Packet.getPayload(msg,
call Packet.payloadLength(msg)),
call
Packet.payloadLength(msg));
// I'm on the routing path and Intercept indicates that I
// should not forward the packet.
-else if (!signal Intercept.forward[collectid](msg,
+} else if (!signal Intercept.forward[collectid](msg,
call
Packet.getPayload(msg, call Packet.payloadLength(msg)),
call
Packet.payloadLength(msg)))
return msg;
CtpRoutingEngineP.nc
@@ -485,6 +485,8 @@ implementation {
congested = call CtpRoutingPacket.getOption(msg, CTP_OPT_ECN);
+call CollectionDebug.logEventSimple(NET_C_TREE_RCV_BEACON, call
AMPacket.source(msg));
+
dbg(TreeRouting,%s from: %d [ parent: %d etx: %d]\n,
__FUNCTION__, from,
rcvBeacon-parent, rcvBeacon-etx);
--
Morten Hansen, http://mortent.dk
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP not reporting NET_C_FE_DST_MSG and NET_C_TREE_RCV_BEACON
On Nov 17, 2010, at 4:45 PM, Morten Tranberg Hansen wrote: Hi Om, I've always wondered why CTP does not report arrived messages and received beacons. Over time I've found these events very useful when debugging CTP. Is there a reason for not reporting these events? If not, see proposed changes below. It does not log receive() for data messages because the event is redundant: if the node is a root and receives a data packet, it signals receive(). It does not log received beacons because, in dense networks, received beacon events can overload the logging system's throughput and lead to lots of lost log messages. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] sim-sf deprecated warnings
Hi Phil,
When compiling sim-sf with python2.6 I get quite a few deprecated warnings
due to some missing char* casts. I looks like you have added these casts
when compiling with sim. Maybe you could apply the same changes when
compiling with sim-sf? See the below diff which also includes a fix for a
printf warning when compiling with sim-sf
Morten.
diff --git a/tos/lib/tossim/sf/Throttle.cpp b/tos/lib/tossim/sf/Throttle.cpp
index 2a5350c..01520cb 100644
--- a/tos/lib/tossim/sf/Throttle.cpp
+++ b/tos/lib/tossim/sf/Throttle.cpp
@@ -111,7 +111,7 @@ int Throttle::simSleep(double seconds) {
void Throttle::printStatistics() {
-printf(Number of throttle events %d\n, throttleCount);
+printf(Number of throttle events %lu\n, throttleCount);
if (simEndTime 0.0) {
printf(Total Sim Time: %.6f\n, simEndTime - simStartTime);
diff --git a/tos/lib/tossim/sf/tossim.c b/tos/lib/tossim/sf/tossim.c
index 5a07d71..73db9e6 100644
--- a/tos/lib/tossim/sf/tossim.c
+++ b/tos/lib/tossim/sf/tossim.c
@@ -123,8 +123,8 @@ variable_string_t Variable::getData() {
memcpy(data, ptr, len);
}
else {
-str.ptr = no such variable;
-str.type = no such variable;
+str.ptr = (char*)no such variable;
+str.type = (char*)no such variable;
str.len = strlen(no such variable);
str.isArray = 0;
}
@@ -176,7 +176,7 @@ void Mote::setID(unsigned long val) {
}
Variable* Mote::getVariable(char* name) {
- char* typeStr = ;
+ char* typeStr = (char*);
int isArray;
Variable* var;
diff --git a/tos/lib/tossim/sf/tossim.i b/tos/lib/tossim/sf/tossim.i
index 7789c3b..509acab 100644
--- a/tos/lib/tossim/sf/tossim.i
+++ b/tos/lib/tossim/sf/tossim.i
@@ -312,8 +312,8 @@ PyObject* listFromArray(char* type, char* ptr, int len)
{
}
}
else {
-app-variableNames[i] = bad string;
-app-variableTypes[i] = bad string;
+app-variableNames[i] = (char*)bad string;
+app-variableTypes[i] = (char*)bad string;
}
}
--
Morten Hansen, http://mortent.dk
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP not reporting NET_C_FE_DST_MSG and NET_C_TREE_RCV_BEACON
Thats what I thought were the arguments. Personally I like to debug CTP independent of the application, and hence find the arrived event useful, and for debugging purposes and less dense networks I still argue that the receive beacon is useful. Maybe these could be added optionally with an ifdef? Morten. On Thu, Nov 18, 2010 at 10:58 AM, Philip Levis p...@cs.stanford.edu wrote: On Nov 17, 2010, at 4:45 PM, Morten Tranberg Hansen wrote: Hi Om, I've always wondered why CTP does not report arrived messages and received beacons. Over time I've found these events very useful when debugging CTP. Is there a reason for not reporting these events? If not, see proposed changes below. It does not log receive() for data messages because the event is redundant: if the node is a root and receives a data packet, it signals receive(). It does not log received beacons because, in dense networks, received beacon events can overload the logging system's throughput and lead to lots of lost log messages. Phil -- Morten Hansen, http://mortent.dk ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP not reporting NET_C_FE_DST_MSG and NET_C_TREE_RCV_BEACON
On Nov 17, 2010, at 5:34 PM, Morten Tranberg Hansen wrote: Thats what I thought were the arguments. Personally I like to debug CTP independent of the application, and hence find the arrived event useful, Why is the current logic for receive() dependent on the application? and for debugging purposes and less dense networks I still argue that the receive beacon is useful. Maybe these could be added optionally with an ifdef? Generally, we try to avoid ifdefs: Om, what do you think? Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP not reporting NET_C_FE_DST_MSG and NET_C_TREE_RCV_BEACON
On Thu, Nov 18, 2010 at 12:00 PM, Philip Levis p...@cs.stanford.edu wrote: Why is the current logic for receive() dependent on the application? The application would either have to send the NET_C_FE_DST_MSG event through the CollectionDebug interface or report the reception of a data packet in some other way. With the first choice a processing script for collection debug messages would only need to worry about the predefined collection debug message types, and not some arbitrary data message. Morten. and for debugging purposes and less dense networks I still argue that the receive beacon is useful. Maybe these could be added optionally with an ifdef? Generally, we try to avoid ifdefs: Om, what do you think? Phil -- Morten Hansen, http://mortent.dk ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP not reporting NET_C_FE_DST_MSG and NET_C_TREE_RCV_BEACON
On Nov 17, 2010, at 6:38 PM, Morten Tranberg Hansen wrote: On Thu, Nov 18, 2010 at 12:00 PM, Philip Levis p...@cs.stanford.edu wrote: Why is the current logic for receive() dependent on the application? The application would either have to send the NET_C_FE_DST_MSG event through the CollectionDebug interface or report the reception of a data packet in some other way. With the first choice a processing script for collection debug messages would only need to worry about the predefined collection debug message types, and not some arbitrary data message. I guess this is why I'm confused. If a root node receives a packet for forwarding, it signals reception. Therefore, if a root node receives a packet for forwarding, you implicitly know it signaled receive(). In terms of the log, you'd always see the two paired together, and so the latter is redundant. Or is there a case I'm missing? Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP: ETX values vs. LPL wake-up interval
I don't think this quite answers my question: it was whether, on using setLocalWakeupInterval(), you see a change in PRR on simple AM transmissions. I.e., is this a general link layer issue, or an interaction between the link layer and CTP? My guess is that it is the former, but evidence would help. Phil On Nov 16, 2010, at 9:55 PM, Manjunath Doddavenkatappa wrote: Dear Sir, The problem and its cause can be summarized as follows. In the case of CTP, I guess it is required to set LPL variables (local and remote sleep intervals) from the Makefile. Otherwise, I guess no preamble is sent before transmitting routing beacons thus resulting in unexpected behavior. Instead of defining LPL variables in the Makefile, I was using LowPowerListeniing interface to set LPL variables from the application. The interface allows to set local sleep interval, and remote wake-up interval for only the data packets that I send from the application and this does not have any effect on beacon transmission. As you suggested, I tested without CTP, program works without any problems in both the cases of on setting LPL variables from the Makefile and application. As no routing beacons are involved, behavior is independent of the location from where I set LPL variables. Please correct me if my understanding is wrong. Further, what is the reason for not having the LPL to use default preamble length for outgoing packets based on local sleep interval (that is set using the command setLocalWakeupInterval()). I understand that the command setRemoteWakeupInterval allows to handle different sleep intervals. But is is typical to have different schedules for different nodes ? and moreover, this requires every forwarder to know the sleep interval of its next hop. Thanking you, D. Manjunath *** On Mon, 15 Nov 2010, Philip Levis wrote: On Nov 7, 2010, at 3:40 AM, Manjunath Doddavenkatappa wrote: Dear Dr. Gnawali, Sorry to get back to you so late, we had a paper deadline. Everything works fine if I set LPL variables from the Makefile as in TestNetworkLpl. Problems arise only on trying to set LPL variables from the program using setLocalWakeupInterval(). Just to verify in the later case, I retrived sleep interval value using getLocalWakeupInterval(), the returned value is consistent with what I set it to. Manjunath D Here's a simpler question: outside of CTP, is there a relationship between the LPL interval and a link's packet reception ratio? I.e., if you send unicast LPL messages to a destination, do you see that increasing the LPL interval decreases the PRR? Note that CTP is often going to be using borderline links that are near the SNR/PRR threshold. Phil ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP not reporting NET_C_FE_DST_MSG and NET_C_TREE_RCV_BEACON
I argue that the application, which is signaled receive from the ctp forwarding engine, should not necessarily have to tell anybody that it received this event, and hence CTP should debug the NET_C_FE_DST_MSG. In case the application, whichever one is used, decides to report the receive event (this is application dependent), one of the two reports is redundant. I just think its wrong to assume that all applications report the receive event signaled from the ctp forwarding engine. Morten. On Thu, Nov 18, 2010 at 12:42 PM, Philip Levis p...@cs.stanford.edu wrote: On Nov 17, 2010, at 6:38 PM, Morten Tranberg Hansen wrote: On Thu, Nov 18, 2010 at 12:00 PM, Philip Levis p...@cs.stanford.edu wrote: Why is the current logic for receive() dependent on the application? The application would either have to send the NET_C_FE_DST_MSG event through the CollectionDebug interface or report the reception of a data packet in some other way. With the first choice a processing script for collection debug messages would only need to worry about the predefined collection debug message types, and not some arbitrary data message. I guess this is why I'm confused. If a root node receives a packet for forwarding, it signals reception. Therefore, if a root node receives a packet for forwarding, you implicitly know it signaled receive(). In terms of the log, you'd always see the two paired together, and so the latter is redundant. Or is there a case I'm missing? Phil -- Morten Hansen, http://mortent.dk ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
