[Tinyos-help] Unified Broadcast
The TinyOS code for unified broadcast, presented at IPSN 2011, can now be found in tinyos-2.x-contrib/csau/ub Morten. -- 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
Ok, so lets conclude. Assuming a reliable logging system DST_MSG is not needed if one logs when the max payload length test fails and RCV_BEACON might overload the logging system in dense networks. I guess what you need to decide is whether you want tinyos-main to log when the max payload length test fails and/or add an ifdef to optionally enable logging of RCV_BEACON. I just brought this up as others (as well as I did) might wonder why these events are defined but never reported. Morten. On Fri, Nov 19, 2010 at 10:32 PM, Omprakash Gnawali gnaw...@cs.stanford.edu wrote: On Thu, Nov 18, 2010 at 2:39 PM, Morten Tranberg Hansen m...@cs.au.dk wrote: Oh I didn't realize you were talking about the RCV_MSG event. Yeah the only unlogged event between the RCV_MSG event and a possible DST_MSG event at the root would be if the max payload length test fails. I'm not sure when/if this test fails, but maybe it should be logged for correctness. The test can fail if the length field gets corrupted and still passes the CRC test. Or, if you have two versions of code (different max. available payload size) in the network and the received packet won't fit in the payload of the outgoing message. etc. Even if you have DST_MSG, keep in mind that there is no guarantee that this will be logged because the logging buffer could be full. You can detect that by looking for missing sequence number in the logged messages but that won't be enough either... So, if you want to be correct in the strictest sense, you probably need to do something much more sophisticated. If you are really worried about this test, a better approach might be to log when that test fails. That could be useful for understanding other problems that might occur in the network as well. - om_p -- 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
Oh I didn't realize you were talking about the RCV_MSG event. Yeah the only unlogged event between the RCV_MSG event and a possible DST_MSG event at the root would be if the max payload length test fails. I'm not sure when/if this test fails, but maybe it should be logged for correctness. Morten. On Fri, Nov 19, 2010 at 2:42 AM, Philip Levis p...@cs.stanford.edu wrote: On Nov 17, 2010, at 8:36 PM, Morten Tranberg Hansen wrote: I argue that the application, which is signaled receive from the ctp forwarding engine, should not necessarily have to tell anybody that it received this event, and hence CTP should debug the NET_C_FE_DST_MSG. In case the application, whichever one is used, decides to report the receive event (this is application dependent), one of the two reports is redundant. I just think its wrong to assume that all applications report the receive event signaled from the ctp forwarding engine. I feel like we're talking in circles, or completely misunderstanding each other. The application doesn't need to report the event. If a node is a root and receives a packet to forward, it signals receive(). Correspondingly, if you see a NET_C_FE_RCV_MSG event, and a node is a root, Receive.receive will be signaled. For a root, you would always see RCV_MSG log message followed by the receive event log message. Or is your concern the max payload length test? Whether or not this reaches an application (the app has wired to the particular receive event ID) is a wholly separate concern. E.g., it could be that the application does not handle that CTP data type. Phil -- 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
[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
[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 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
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
[Tinyos-help] rfxlink in TOSSIM
Hi Miklos, I used your rfxlink layers to add packet link and LPL support for TOSSIM on a dual radio CSIRO platform. Using your LowPowerListeningLayerP.nc in TOSSIM I found that the layer will return EBUSY in state SLEEP_SUBSTOP_DONE, which I believe is not desirable seen from an upper layer point of view. Is this done on purpose? Preferable the LowPowerListeningLayer should start the radio after the SubControl.stopDone event and then send the packet instead of returning EBUSY. Thoughts? Related to this. I also have the mentioned rfxlink layers running in TOSSIM for the IRIS platform, anything you would be interested in for tinyos-main? Morten. -- 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
[Tinyos-help] TOSSIM SNR loss: why is packets checked twice and acknowledgements once?
TinyOS users and authors of CpmModelC, The CpmModelC in tos/lib/tossim simulates packet loss based on a fixed SNR-PRR curve. A packet loss is determined by calls to shouldReceive(snr) and a lost acknowledgement is determined by calls to shouldAckReceive(snr). In the current implementation shouldReceive(snr) is called twice per packet - when a packet is put on the event queue (CpmModelC line 388) _and_ when the event is handled through the checkReceive(snr) function (CpmModelC line 308) - while shouldAckReceive(snr) is only called once per acknowledgement (CpmModelC line 183). Whats the reasoning about this? That data packets are longer than acknowledgements and hence should be checked twice? As far as I can tell, the actual time on air for an acknowledgement and a data packet containing 0bytes payload should be the same. Let me demonstrate with an example using the debug output from CpmModelC: 1. DEBUG (2): SNR is 8.25, PRR is 0.976911 2. DEBUG (2): Packet from 3 to 2 3. DEBUG (2): SNR is 8.25, PRR is 0.976911 4. -signaling reception 5. DEBUG (3): SNR is -5.75, ARR is 0.001306 6. 7. DEBUG (2): SNR is -8.75, PRR is 0.004112 8. DEBUG (2): Lost packet from 3 to 2 due to SNR being too low (-8) 9. DEBUG (2): Packet from 3 to 2 10. DEBUG (2): SNR is 8.25, PRR is 0.976911 11. -packet was lost. In line 1-5 a packet passes the check twice (line 1 and 3) and reception is signaled (line 4) before an acknowledgement is checked (line 5). In line 7-11 a packet fails the first check (line 7-8) and is marked lost on reception (line 11). The outcome of the second check has no influence as the packet is already marked lost after the first check. Morten. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Compile time warning when using LocalTimeMilliC without any TimerMilliC instances
Hi, When using LocalTimeMilliC in an application without a TimeMilliC instances i get the following warnings: /opt/tinyos-2.x/tos/lib/timer/VirtualizeTimerC.nc: In function `VirtualizeTimerC$0$updateFromTimer$runTask': /opt/tinyos-2.x/tos/lib/timer/VirtualizeTimerC.nc:102: warning: comparison is always false due to limited range of data type /opt/tinyos-2.x/tos/lib/timer/VirtualizeTimerC.nc: In function `VirtualizeTimerC$0$fireTimers': /opt/tinyos-2.x/tos/lib/timer/VirtualizeTimerC.nc:66: warning: comparison is always false due to limited range of data type They disappear when i add a TimerMilliC to my application as: components new TimerMilliC(); It seems to be due to the fact that a VirtualizeTimerC is instantiated in HilTimerMilliC (im using msp430) with uniqueCount(UQ_TIMER_MILLI)=0. Maybe the responsible person has a nice solution to how we get rid of these warnings? - Morten. -- 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
[Tinyos-help] TUnit setup on ubuntu
Hi list, Im trying to set TUnit up on my ubuntu laptop, but it doesnt seem to work for me. I've followed the setup guidelines from doc.tinyos.net. I have appended a run from the rincon FifiQueue test that should work but is not. It seems like its not able to compile the application. Any help would be appreciated.. thanks, Morten. INTERESTING_PART 3346 [main] INFO com.rincon.tunit.build.Make - Building platform telosb in /opt/tinyos-2.x-contrib/tunit/tests/tinyos-2.x-contrib/rincon/tos/system/TestFifoQueueC 3346 [main] INFO com.rincon.tunit.exec.CmdExec - make -C /opt/tinyos-2.x-contrib/tunit/tests/tinyos-2.x-contrib/rincon/tos/system/TestFifoQueueC telosb tunit TUNITCFLAGS=-I/opt/tinyos-2.x-contrib/tunit/tos/lib/tunit -I/opt/tinyos-2.x-contrib/tunit/tos/lib/tunitstats -I/opt/tinyos-2.x-contrib/tunit/tos/system -I/opt/tinyos-2.x-contrib/tunit/tos/interfaces -I/opt/tinyos-2.x-contrib/tunit/tos/lib/directserial -I/opt/tinyos-2.x-contrib/tunit/tos/lib/fifoqueue -DTUNIT_TOTAL_NODES=1 -I../../../../../../../rincon/tos/interfaces -I../../../../../../../rincon/tos/system -DMAX_TUNIT_QUEUE=20 3352 [main] DEBUG com.rincon.tunit.exec.CmdExec - Exit Value: 2 /INTERESTING_PART OUTPUT [EMAIL PROTECTED]:/opt/tinyos-2.x-contrib/tunit/tests/tinyos-2.x-contrib/rincon/tos/system/TestFifoQueueC$ tunit 0 [main] INFO com.rincon.tunit.TUnit - Base package directory located: / 6 [main] INFO com.rincon.tunit.TUnit - Found a TOSCONTRIB environment variable 6 [main] DEBUG com.rincon.tunit.TUnit - Found TUnit! /opt/tinyos-2.x-contrib/tunit Running TUnit from /opt/tinyos-2.x-contrib/tunit/tests/tinyos-2.x-contrib/rincon/tos/system/TestFifoQueueC 7 [main] DEBUG com.rincon.tunit.TUnit - Processing /opt/tinyos-2.x-contrib/tunit/tunit.xml 106 [main] DEBUG com.rincon.tunit.TUnit - tunit.xml processed successfully 108 [main] DEBUG com.rincon.tunit.run.RerunRegistry - Cleaning rerun registry 108 [main] INFO com.rincon.tunit.TUnit - STARTING TEST RUN 1_TELOSB 110 [main] DEBUG com.rincon.tunit.run.TestRunManager - Creating serial forwarder serial@/dev/ttyUSB0:tmote 165 [Thread-1] DEBUG com.rincon.tunit.sf.Sf - serial@/dev/ttyUSB0:tmote.9100: serial@/dev/ttyUSB0:115200: resynchronising 166 [Thread-1] DEBUG com.rincon.tunit.run.TestRunManager - serial@/dev/ttyUSB0:115200: resynchronising 166 [main] DEBUG com.rincon.tunit.run.TestRunManager - Disconnecting all serial forwarders 2263 [Thread-0] DEBUG com.rincon.tunit.sf.Sf - serial@/dev/ttyUSB0:tmote.9100: server stopped 3264 [main] DEBUG com.rincon.tunit.run.TestRunManager - Serial forwarders initialized successfully 3265 [main] DEBUG com.rincon.tunit.run.Traverser - Traverser.traverse(/opt/tinyos-2.x-contrib/tunit/tests/tinyos-2.x-contrib/rincon/tos/system/TestFifoQueueC) 3283 [main] DEBUG com.rincon.tunit.properties.TUnitSuiteProperties - This test applies to the given test run 3286 [main] DEBUG com.rincon.tunit.run.Traverser - Found a compilable project 3290 [main] INFO com.rincon.tunit.run.TestRunner - PACKAGE 1_telosb.pt.tinyos-2.x-contrib.tunit.tests.tinyos-2.x-contrib.rincon.tos.system.TestFifoQueueC 3294 [main] DEBUG com.rincon.tunit.run.TestRunner - Clean 3294 [main] INFO com.rincon.tunit.build.Make - Cleaning build files in /opt/tinyos-2.x-contrib/tunit/tests/tinyos-2.x-contrib/rincon/tos/system/TestFifoQueueC 3295 [main] INFO com.rincon.tunit.exec.CmdExec - make -C /opt/tinyos-2.x-contrib/tunit/tests/tinyos-2.x-contrib/rincon/tos/system/TestFifoQueueC clean 3345 [main] DEBUG com.rincon.tunit.exec.CmdExec - Exit Value: 0 3346 [main] DEBUG com.rincon.tunit.exec.CmdExec - Done executing make -C /opt/tinyos-2.x-contrib/tunit/tests/tinyos-2.x-contrib/rincon/tos/system/TestFifoQueueC clean 3346 [main] DEBUG com.rincon.tunit.run.TestRunner - Build properties are identical for nodes using target telosb 3346 [main] INFO com.rincon.tunit.build.Make - Building platform telosb in /opt/tinyos-2.x-contrib/tunit/tests/tinyos-2.x-contrib/rincon/tos/system/TestFifoQueueC 3346 [main] INFO com.rincon.tunit.exec.CmdExec - make -C /opt/tinyos-2.x-contrib/tunit/tests/tinyos-2.x-contrib/rincon/tos/system/TestFifoQueueC telosb tunit TUNITCFLAGS=-I/opt/tinyos-2.x-contrib/tunit/tos/lib/tunit -I/opt/tinyos-2.x-contrib/tunit/tos/lib/tunitstats -I/opt/tinyos-2.x-contrib/tunit/tos/system -I/opt/tinyos-2.x-contrib/tunit/tos/interfaces -I/opt/tinyos-2.x-contrib/tunit/tos/lib/directserial -I/opt/tinyos-2.x-contrib/tunit/tos/lib/fifoqueue -DTUNIT_TOTAL_NODES=1 -I../../../../../../../rincon/tos/interfaces -I../../../../../../../rincon/tos/system -DMAX_TUNIT_QUEUE=20 3352 [main] DEBUG com.rincon.tunit.exec.CmdExec - Exit Value: 2 3352 [main] DEBUG com.rincon.tunit.exec.CmdExec - Done executing make -C /opt/tinyos-2.x-contrib/tunit/tests/tinyos-2.x-contrib/rincon/tos/system/TestFifoQueueC telosb tunit TUNITCFLAGS=-I/opt/tinyos-2.x-contrib/tunit/tos/lib/tunit -I/opt/tinyos-2.x-contrib/tunit/tos/lib/tunitstats
[Tinyos-help] CC2420 Secure Packer Layout
Hi tinyos folks, I have a question regarding the CC2420 packer layout using its in-line secure mode. As far as a can read from the data sheet, the frame counter and key sequence counter is not appended to the packet, and is instead expected to be explicit managed. This would result in a secure mode packet of the form: 1 1 0..20n 2,4,8 2 | FCF | DSN | Addr Info | payload | MAC | FCS | Instead of the normally expected: 1 1 0..20 41n 2,4,8 2 | FCF | DSN | Addr Info | Frame Counter | Key ID | payload | MAC | FCS | Am i right? Does anybody have any experience with that? Can't test it myself as I am currently not in position of such a radio. Thanks in advance, Morten. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
