Re: [Tinyos-help] SMAC implementation
On Mon, Sep 29, 2008 at 12:51 AM, milos rovcanin [EMAIL PROTECTED] wrote: Hi! Here is my question: how can I implement SMAC protocol on a mote? I am writing an application that should work in a network which is suppose to operate under SMAC. Am I suppose to wire SMAC to my application or what? Help me please! Thanks! Please go to this page for more information: http://www.isi.edu/ilense/software/smac/ - 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] about two packet with the same originSeqNo in the CTP header
On Sat, Sep 27, 2008 at 8:02 PM, jiwen zhang [EMAIL PROTECTED] wrote: Hello Omprakash : Recently , I am confronted with a problem about CTP , in my application , it send the data to root periodcally , but i find it send the same data two times every time , and the packets with the same originSeqNo in the CTP header , and another more odd problem is that when i use mica2 , there is no the problem , but when i use my own mote which is the same as IRIS , it will appear the problem . Do you know what is wrong ? This is the data i received : 7E 45 00 00 02 00 08 0D 00 38 00 01 00 16 00 08 00 82 04 00 02 00 0C E0 3E 7E (The red font is the CTP packet , and the blue font is the originSeqNo ) 7E 45 00 00 02 00 08 0D 00 38 00 01 00 16 00 08 00 82 04 00 02 00 0C E0 3E 7E 7E 45 00 00 02 00 08 0D 00 38 00 01 00 16 00 08 01 82 04 00 02 00 0C 81 86 7E 7E 45 00 00 02 00 08 0D 00 38 00 01 00 16 00 08 01 82 04 00 02 00 0C 81 86 7E 7E 45 00 00 02 00 08 0D 00 38 00 01 00 16 00 08 02 82 04 00 02 00 0C 03 5E 7E 7E 45 00 00 02 00 08 0D 00 38 00 01 00 16 00 08 02 82 04 00 02 00 0C 03 5E 7E -- Based on the limited information you are providing, it could be that acks are not working as well as you expect them to. Can you verify using non-CTP experiments that acks are working reasonably well. - 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] question about data aggregation when information of children nodes are not available
2008/9/24 白惠文 [EMAIL PROTECTED]: Hi, I have a question about the routing tree protocol and the collection tree protocol in TinyOS. It seems we can not get a list of the children nodes of a inner node. If that's the case, how do we use these components for an application with data aggregation? More specifically, how does a node know it has merged data from all of its children so it can go ahead and forward the merged results up the tree? There is no built-in TinyOS software that does that but there are many ideas that people have proposed. Maybe you can come up with a better idea... - 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] CollectionC
On Tue, Sep 23, 2008 at 3:36 AM, Alfonso Cardell [EMAIL PROTECTED] wrote: Hi, I'm doing an aplication with magnetometers over tmote plataform and I would like to know if CollectionC allow sends packets from master (base node) to other node (for example, send a packet for tell it that recollect a magnetometer data). Is it possible? No. You should look into Dissemination (Drip/DIP) or Tymo. - 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] Collection protocol with different payload formats
On Thu, Sep 18, 2008 at 3:20 AM, Lei Mlapom [EMAIL PROTECTED] wrote: Dear all: I am working with the collection protocol in tinyos2. I want to send different payload formats alternatively in the same micaz mote.I have read that one collection_id_t generally have the same payload format so Do I need the declaration of different collection_id_t-s? Or if the root is the same in all the cases, can I work with the same collection_id_t? You can work with the same collection id but you should make sure your node, when it receives a packet, has a way of determining the payload format. - 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] replacement for CollectionExample in 2.1
On Tue, Sep 23, 2008 at 9:07 AM, Avinash Sridharan [EMAIL PROTECTED] wrote: There used to be a CollectionExample app in 2.0.2, to explain the usage of CTP in 2.x. I can't find such an app in 2.1 . Is there an alternative app that is provided ? MultihopOscilloscope. - 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] Packet Loss/Radio On-Off/ACK's for Broadcast packets
On Fri, Sep 12, 2008 at 11:12 AM, Gaurav Chandwani [EMAIL PROTECTED] wrote: Hi All, Thanks Om and Razvan for the LPL papers, would go through them ... Chetan, i have tried multiple permutations and combinations in my network with maximum number of nodes being 30. Single-Hop - RadioCountToLeds(original and also with modifications specified in the previous mail) + BaseStation Multi-Hop - MultiHopOscilloscope(CTP - 4bitle,le and LQI) SingleHop + MultiHop - RadioCountToLeds + MultiHopOscilloscope(modified to also receive and forward broadcast messages from RadioCountToLeds to the Base Station). LQI worked better in this scenario than CTP while it should be otherwise according to the mailing lists. As I described in the previous mail, little changes in the topology/codes have significant impact on packet-loss behaviour. For example I added another snoop interface in MultiHopOscilloscope to receive and forward RadioCountToLeds messages and this leads to a big increase in packet-loss, probably the forwarding/snooping engine at the lower level(queues) etc interferes with the snooping(receive and forward of RadioCountToLeds messages) at the application level. I am trying to use the debugging information to pinpoint the issues. I don't think there is any software/buffer interference here. Any problem might be due to potential channel saturation you are causing. I think if other people have done similar tests, we should share the results to understand whether its our network/topology-specific problems or its a general problem faced by everyone. So, if you can tell me abt your testbed and results, wud b helpful. If you want more information about my testbeds, can send you the details. People probably did lots of tests similar to yours before developing LPL and other dutycycing protocols. So, I would look at them and see if they do not satisfy your needs. If you want to build another dutycycling protocols, it might be good to use the existing dutycycling protocols as a base unless you are trying to do something radically different. If you come up with ways to improve/extend the existing dutycycling approaches, that will be a great contribution to the community. - 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] CTP rtx
On Tue, Sep 9, 2008 at 9:19 AM, Nahr ... [EMAIL PROTECTED] wrote: Hi, Please how could I compute the total number of transmissions in the network for each unique delivered packet? In CtpForwardingEngineP.nc, search for the line that has NET_C_FE_SENDDONE_WAITACK. That line logs each retransmission event with the pkt origin and sequence number. You should be able to use this information to compute the statistics that you are interested in. - 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] Packet Loss/Radio On-Off/ACK's for Broadcast packets
On Thu, Sep 11, 2008 at 9:02 AM, Gaurav Chandwani [EMAIL PROTECTED] wrote: Hi All, I am facing a strange packet loss behaviour in my network which is affecting my final project. I would like to ask a few questions for the same. TestBed: 15 motes running the simple apps/RadioCountToLeds application which sends periodic(5 sec) brodcast messages, the additions are that I switch Off the Radio(to improve liftime of the mote) after SendDone and start it when the timer fires, also I have removed the receive interface. I am running the apps/BaseStation code for receiving all these messages and then check the packet loss through java. The nodes are kept close to each other. I am using tinyos-2.1. So, 15 motes sending a packet every 5 seconds and a BaseStation receiving. Result: Packet loss in high numbers and the more troubling statistics was that I lost upto 15 consecutive packets from a particular node. My application is based on calculating the presence of the motes in a particular period, lets say 30 sec(6 times the frequency), so 15 packets result into a lost mote which is not true. Acknowledgements: Are there ACK's for broadcast packets ? So, would my application wait for ack's and if it doesnt arrive retransmit ? If not, can i enable it somehow ? I read many replies on the mailing list but cudnt arrive to a conclusion. I have tried putting the following two methods(similar to TestPacketLink) but according to this I never lose any ack and packets are always ACKed. call PacketAcknowledgements.requestAck(packet); call PacketAcknowledgements.wasAcked(bufPtr). Also, I had commented CFLAGS += -DCC2420_NO_ACKNOWLEDGEMENTS in MakeFile for the BaseStation. BaseStation Queue: This sounds absurd, but is it possible that BaseStation's receive queue cannot handle packets that arrive at more or less the same time, so the Radio receives the packet and sends ACK(if it does) but the Queue somehow looses some packets. I presume that cc2420 is fast enough to handle such slow rate here but can anybody prvovide the statistics for reception of colliding packets ? how close can they be ? Tweak - If I add a delay of 100ms in SendDone before switching Off the Radio, the packet loss is much much less and max number of consecutive packet loss from one node is 6. Further if I add a delay of 200/300 ms, there is a drastic decrease in packet loss and I dont loose more than 1-2 consecutive packets from a particular node. I cant understand whatcan be the reason behind the dramatic change ACK's ? but 100/200/300 ms is a very big time. Channel: This test is done in a regular office environment where ofcourse there is wireless and other regular interferences, but nothing that can be pinpointed as 'the' problem. Will changing the default channel on which the motes are sending packets have any positive effect ? What amount of packet loss rate should be expected from the motes in such a simple environment and what can be the reasons ? Bigger Picture: Putting 200ms delay leads to an acceptable packet loss rate but decreases the lifetime of the nodes and also when I make the network a bit more complex e.g adding some nodes with MultiHopOscilloscope app which can also accept the broadcast messages from these RadioCountToLeds motes, the packet loss re-emerges. So understanding some of the above Questions is necessary for the bigger picture. Waiting for some hints, Gaurav Is there any reason you don't want to use LPL? LPL does what you are trying to do and more to minimize energy use. - 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] Intercept interface one question
On Thu, Sep 4, 2008 at 7:23 AM, Funofnet funofnet [EMAIL PROTECTED] wrote: Hi all ! I will be very thankful if someone explain to me intercept interface. As it is mentioned: The intercept interface signals that a message has been received, which is supposed to be forwarded to another destination. It returns TRUE if the packet should be forwarded, FALSE else. What I understood is : Intercept.forward returns FLASE if a node snoops a packet being transmitted. Intercept.forward returns FALSE if a node snoops a packet and decides that it should not forward the packet. To an additional clarification A sends a message to B (which can be a root or A's parent) C is in the proximity of B or let's say in Tx range of the node A. C can probably hear the packet being transmitted by A and can also snoop it. C is not qualified to forward A msg, then its Intercept.forward returns FLASE consequently. It is true??? Yes. - 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] Re : Intercept interface one question
On Thu, Sep 11, 2008 at 1:49 PM, funofnet Funofnet [EMAIL PROTECTED] wrote:
But I think that it is theoretically True (intercept.forward returns FALSE
if a node snoop a packet).
Because I tested that by adding a debug msg in the forwarding engine of the
CTP protocol at this line:
//
// I'm on the routing path and Intercept indicates that I
// should not forward the packet.
else if (!signal Intercept.forward[collectid](msg,
call Packet.getPayload(msg, call
Packet.payloadLength(msg)),
call Packet.payloadLength(msg)))
{dbg(Snoop, snooped packet from%d\n, getHeader(msg)-origin);
return msg;}
//
I didn't see any snooped packet message in my trace file.
Did I make a mistake?
Intercept.forward returns TRUE by default so you are not executing the
branch in which you inserted that debug statement.
- 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] Packet Loss/Radio On-Off/ACK's for Broadcast packets
On Thu, Sep 11, 2008 at 3:15 PM, Gaurav Chandwani [EMAIL PROTECTED] wrote: Hi Omprakash, Are you suggesting me to put LPL in the RadioCountToLeds code and not use Radio On/Off ? Does LPL save more battery than switching off the radio while its not transmitting ? can you give some statistics if available. I was of the impression that with LPL, there is more probability of loosing packets, which is more important to me ..I read abt CTP + LPL which probably is totally another thing .. but I have not read much LPL yet, would go thru it .. Meanwhile, can you just point out a bit more clearly in which ways it could help :) http://www.polastre.com/papers/sensys04-bmac.pdf - om_p ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] your experience with net2 protocols (CTP/Deluge/Drip/DIP)
I wanted to get feedback from the TinyOS community on how different people are using the net2 protocols - CTP/MultihopLQI/Deluge/Drip/DIP. In what kind of scenarios/research or prototyping projects/platforms have you used these protocols? Did you have to modify these protocols to make it work for you? If you did, in what ways? What are your results and experiences? How should we improve these protocols? Your feedback will help us improve and support these protocols better. I will also document your use cases/experiences on net2 wiki. Thanks. - om_p for TinyOS 2.0 Network Protocol Working Group (net2) ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] CTP parent switching
On Thu, Aug 28, 2008 at 1:14 AM, Michiel Konstapel [EMAIL PROTECTED] wrote: Following up on my message about the link estimator, I was also wondering about CTP's parent switching threshold. As is, CTP will switch parents if the new parent offers a path ETX that is 1.5 hops better than its current parent, if I am not mistaken. Now, this is set fairly conservatively, because a node would not replace a two-hop, 2.4 ETX parent with a direct, perfect link to the sink. However, in the back of the tree, where lots of link ETXs are added up, you don't want a low threshold or nodes would switch parents all the time. I want you to point to some related discussions about this: http://mail.millennium.berkeley.edu/pipermail/net2-wg/2007/000723.html http://mail.millennium.berkeley.edu/pipermail/net2-wg/2007/000729.html Now, would it be an idea to base this threshold on a percentage of the path ETX? For example, at 20%, a node with a path ETX of 2 would replace its parent by one that offers a path ETX of 1.6, whereas a node that has a path ETX of 10 would only switch if the new path has an ETX of 8 or lower. That way, it would favour optimal routes near the sink, where traffic is highest, and favour stable routes further down the tree. A cap would probably be needed on top of the percentage, so that it doesn't become impossible to switch in very large networks. It is definitely an interesting idea. You will notice that MultihopLQI uses a similar approach. We haven't tried this for CTP. What did you observe in your experiments? - 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] LinkEstimator, link qualities, ETX
On Thu, Aug 28, 2008 at 1:06 AM, Michiel Konstapel [EMAIL PROTECTED] wrote: ... Our thinking was that instead of initializing the qualities and ETX to zero, wouldn't it be better to set them halfway? That way, it is encoded that the quality of the link is unknown, and could go either way. An initial quality value of 180 (out of 255) means that 1/(inq*outq) results in an ETX of 2; a 50% link. Perhaps values other than 0 are better as initial values. Lets consider these CTP/LEEP mechanisms: 1. eetx for a link is not available until a link is mature 2. you transmit a lot of beacons in the beginning so there are enough beacons to bootstrap the values (are you using the router that uses Trickle timer to drive the beacons?) 3. you will eventually use the link that provides the best delivery performance So we are talking about initial setup time beyond link maturity? How much time? Another observation of ours was that after a large number of beacons ( MAX_PACKET_GAP) is missed, the route qualities are reset, but the ETX isn't. In cases where a node that is a popular parent (say, the sink) is turned off for a while, its children will see its ETX skyrocket as they try to get packets through. When the node comes back online and starts sending beacons, its old children will reset the link qualities to zero, but leave the ETX at its inflated value. This means that it will take a very long time for the node to send enough beacons to make itself look like a viable parent again. Wouldn't it be better to reset the ETX at the same time as the in and out qualities? Something like this: If you turn the node back on, you are right. But there are some other scenarios where what you propose might make things worse - lets say the link quality degrades and you slam the eetx value to the ceiling. Now, suddenly after more than MAX_PACKET_GAP (lets say after an hour), you receive a beacon, and BLQ_PKT_WINDOW consecutive beacons immediately after that. Is this link good or bad? If the last known etx for this link is a high value, why change it to some arbitrary value? One other detail - if you change inquality, you are changing the contribution to etx through the beacons. It is entirely possible that we are getting good etx estimate through the data packets while we are getting bad etx estimate through the beacons due to potentially different timescales at which the channel is sampled through these mechanisms. updateNeighborEntryIdx is only concerned with updating the beacon based estimate so it would not be appropriate to change eetx here because eetx also takes into account data pkt transmission statistics. We've done some desktop experiments with INITIAL_QUALITY_ESTIMATE = 180 and INITIAL_EETX_ESTIMATE = 10 and the recovery time improved greatly. However, we don't have results for larger networks and were wondering if there might be issues we haven't foreseen. I am not entirely convinced that we should optimize this link estimator to a scenario in which a link with a good track record suddenly becomes unavailable for a while and suddenly it becomes available with excellent delivery performance if that optimization is done at the expense of poorer response to other types of failure scenarios. Does your suggestion make recovery/adaptation worse for other types of failure scenarios? Overall, initialization value of these parameters become more important if you are using the link estimator without CTP. It would be good to see some numbers across the failure scenarios that you considered in your experiments. Thanks. - 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] Does CTP work on Mica2 ?
Were you able to get CTP to work on mica2's? Was that with or without LPL? - om_p On Wed, Aug 27, 2008 at 1:36 PM, Zainul M Charbiwala [EMAIL PROTECTED] wrote: Hi everyone, Just wanted to post my findings on the packet behavior I was observing earlier. 0 0:00:22.368266 74.74.AA.AA.AA.AA.AA.AA.AA.AA.AA.AA.AA.AB.BA.83 6.666 ms 1 0:00:22.368697 74.74.AA.AA.AA.AA.AA.AA.AA.AA.AA.AA.AA.AB.BA.83 6.666 ms This packet exchange is in fact link layer acknowledgment, which is enabled by default in the CC1000 stack. It begins in the packetReceived() function in tos/chips/cc1000/CC1000SendReceiveP.nc. Since it was causing me some trouble, I had to shut it off by setting f.ack=FALSE in Init.init() in the same file. Thanks for your help, Zainul. On Mon, Aug 25, 2008 at 8:55 AM, Zainul M Charbiwala [EMAIL PROTECTED] wrote: Thanks, I'll investigate with TestNetwork further and keep the group posted. Regards, Zainul. On Mon, Aug 25, 2008 at 8:28 AM, Omprakash Gnawali [EMAIL PROTECTED] wrote: On Sun, Aug 24, 2008 at 1:39 PM, Zainul M Charbiwala [EMAIL PROTECTED] wrote: ... 3. What is this exchange ? Is this a link layer acknowledgment ? 0 0:00:22.368266 74.74.AA.AA.AA.AA.AA.AA.AA.AA.AA.AA.AA.AB.BA.83 6.666 ms 1 0:00:22.368697 74.74.AA.AA.AA.AA.AA.AA.AA.AA.AA.AA.AA.AB.BA.83 6.666 ms I'd really appreciate if anyone could point me to the component/module that generates this message. Is this part of CTP or part of the CC1000 stack ? CTP has been tested on mica2dots which also has CC1000 radio. CTP only generates two types of pkts. So this must come from somewhere else. You can try running TestNetwork application which can give you more debugging information. If you run TestNetwork, each mote will send debug message on the UART. - 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] ctp details
On Mon, Aug 25, 2008 at 7:17 AM, João Paulo Amaro da Costa Luz Carneiro [EMAIL PROTECTED] wrote: Hi, Where can I find more details about the ctp? I read both the tutorial and teps but I would like to find out more details such as: In a network with multiple roots: - how is a sender informed of an existing receiver? - how does a node decide which root to send to? - what happens if the destination root ceases to exist (after failing silently?), how does the protocol ensures the delivery of the packet to some other root and how is the tree updated for the following transmissions? - when a new receiver joins the network, does it announce its presence? how are the trees reorganized? You might find this useful: http://sing.stanford.edu/pubs/sing-08-02.pdf - 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] Does CTP work on Mica2 ?
On Sun, Aug 24, 2008 at 1:39 PM, Zainul M Charbiwala [EMAIL PROTECTED] wrote: ... 3. What is this exchange ? Is this a link layer acknowledgment ? 0 0:00:22.368266 74.74.AA.AA.AA.AA.AA.AA.AA.AA.AA.AA.AA.AB.BA.83 6.666 ms 1 0:00:22.368697 74.74.AA.AA.AA.AA.AA.AA.AA.AA.AA.AA.AA.AB.BA.83 6.666 ms I'd really appreciate if anyone could point me to the component/module that generates this message. Is this part of CTP or part of the CC1000 stack ? CTP has been tested on mica2dots which also has CC1000 radio. CTP only generates two types of pkts. So this must come from somewhere else. You can try running TestNetwork application which can give you more debugging information. If you run TestNetwork, each mote will send debug message on the UART. - 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] Just a simple verification about data_total
On Fri, Aug 15, 2008 at 1:30 PM, Nahr ... [EMAIL PROTECTED] wrote: but to be now more exact : data_total is declared in the tinyos-2.x\tos\lib\net\4bitle\LinkEstimator.h and it is used by linkestimatorP.nc file placed in both 4bitle and le folder. I remarked that it (variable data_total) is affected by the same way in the two files. It includes the retransmissions done by the forwarding engine. - 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] Just a simple verification about data_total
On Thu, Aug 14, 2008 at 1:44 PM, Nahr ... [EMAIL PROTECTED] wrote: 2008/8/14, Omprakash Gnawali [EMAIL PROTECTED]: On Thu, Aug 14, 2008 at 4:38 AM, Nahr ... [EMAIL PROTECTED] wrote: Hi all, I would like just to verify if the variable data_total is equal to total distinct packet sent or total transmissions (including data retransmission). What file? - om_p Sorry, in this file :LinkEstimatorP.nc There are two LinkEstimatorP.nc in the repository. - 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] Just a simple verification about data_total
On Thu, Aug 14, 2008 at 4:38 AM, Nahr ... [EMAIL PROTECTED] wrote: Hi all, I would like just to verify if the variable data_total is equal to total distinct packet sent or total transmissions (including data retransmission). What file? - 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] ZigBee in current T2 cvs
On Tue, Jul 29, 2008 at 8:41 AM, Andrey Gursky [EMAIL PROTECTED] wrote: Hi! There were some discussions in devel about zigbee but it seems there were no cvs checkins of patchs in order the current implementation could work with micaz. Are they not good enough? ZigBee team is reorganizing. You will probably start seeing commits in the near future. - 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] Implementation of CompareBit interface
On Mon, Aug 11, 2008 at 5:58 PM, Tao Liu [EMAIL PROTECTED] wrote: Hi Omprakash, Thanks very much for the reply. I also have a small irrelevant question here. I am doing some experiments about the performance of the new 4bit link estimator using tmotes, which use Chipcon CC2420 radio chip. I noticed in the chips/cc2420/packet/CC2420PacketP.nc, a channel is considered of high quality when the LQI value is greater then 105 (line 107). That's where the white_bit come from. I am wondering why LQI 105 indicates a high channel quality? Is there any physical or empirical reason behind the value? A combination of empirical results (some of Phil Levis' publications), intuition, and confirmation through experiments. In other words, guess based on experience. - 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] Neighbours get deleted in cldp
You are better of contacting Youngjin Kim at USC. - om_p On Tue, Aug 12, 2008 at 5:27 PM, Pratibha S [EMAIL PROTECTED] wrote: Hi, Im running cldp_gfr code. Im using a 8-node mesh topology(all nodes are connected to all). When I run the code, even though the neighbours are getting allocated correctly, they all are getting deleted in the middle. So, when I send a packet from any node, they are getting dropped. Can anyone tell me the possible cause? . (I know its more of cldp-oriented question rather than tinyos. If anyone point to a relevant forum will also be helpful) Thanks, Pratibha ___ 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] Implementation of CompareBit interface
On Mon, Aug 11, 2008 at 5:10 PM, Tao Liu [EMAIL PROTECTED] wrote:
Hi all,
I am studying the 4bitle link estimator in the TinyOS 2. In the
tos/lib/net/4bitle/LinkEstimatorP.nc (line 647), the 4bit estimator
signals the CompareBit.shouldInsert() event when it received a beacon
message from a new neighbor when there is no room left in the neighbor
table, and the only implementation of CompareBit.shouldInsert I can
find is in the tos/lib/net/ctp/CtpRoutingEngineP.nc, starting from
line 634:
/* This should see if the node should be inserted in the table.
* If the white_bit is set, this means the LL believes this is a good
* first hop link.
* The link will be recommended for insertion if it is better* than some
* link in the routing table that is not our parent.
* We are comparing the path quality up to the node, and ignoring the link
* quality from us to the node. This is because of a couple of things:
* 1. because of the white bit, we assume that the 1-hop to the candidate
* link is good (say, etx=1)
* 2. we are being optimistic to the nodes in the table, by ignoring the
* 1-hop quality to them (which means we are assuming it's 1 as well)
* This actually sets the bar a little higher for replacement
* 3. this is faster
* 4. it doesn't require the link estimator to have stabilized on a link
*/
event bool CompareBit.shouldInsert(message_t *msg, void* payload,
uint8_t len, bool white_bit) {
bool found = FALSE;
uint16_t pathEtx;
//uint16_t linkEtx = evaluateEtx(0);
uint16_t neighEtx;
int i;
routing_table_entry* entry;
ctp_routing_header_t* rcvBeacon;
if ((call AMPacket.type(msg) != AM_CTP_ROUTING) ||
(len != sizeof(ctp_routing_header_t)))
return FALSE;
/* 1.determine this packet's path quality */
rcvBeacon = (ctp_routing_header_t*)payload;
if (rcvBeacon-parent == INVALID_ADDR)
return FALSE;
/* the node is a root, recommend insertion! */
if (rcvBeacon-etx == 0) {
return TRUE;
}
pathEtx = rcvBeacon-etx; // + linkEtx;
/* 2. see if we find some neighbor that is worse */
for (i = 0; i routingTableActive !found; i++) {
entry = routingTable[i];
//ignore parent, since we can't replace it
if (entry-neighbor == routeInfo.parent)
continue;
neighEtx = entry-info.etx;
//neighEtx = evaluateEtx(call
LinkEstimator.getLinkQuality(entry-neighbor));
found |= (pathEtx neighEtx);
}
return found;
}
According to the comment, this event should do the comparison based on
the white_bit argument. However, the actual code here does not take
the white_bit into account. Instead, it just compare the path ETX
value of the new beacon message with the neighbors that is already in
the routing table (different from the neighbor table in the link
estimator).
When the 4bit link estimator signals the CompareBit.shouldInsert
event, the white_bit is set to true if the LQI value in the message
header indicates the wireless channel quality is high; false
otherwise. Can somebody explain why the white_bit is ignored here? Or
it's just I missed something?
You did not miss anything :)
We found this problem about two weeks ago but it was too close to the
2.1 release and did not update the code. The comparison statement
disappeared when we did code refactoring as we moved from experiments
to code in the repository.
I am redoing some of the experiments before I update the code so stay tuned.
- 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] collection, multiple roots, multiple id's - help
On Sat, Aug 2, 2008 at 3:13 AM, De-MonHell [EMAIL PROTECTED] wrote: sorry for the previous email (it was in italian but was only a draft that i wanted to save as reminder but i've sent it indeed.) yesterday i've started dig into the collection module and i've seen exactly what you told me after a while, in your answer. sadly, my 2 cluster need to communicate, through another collection. So, you want three instances of collection? One for each cluster and one for the entire network? so i'm thinking to build a generic collection module that use AM ID as parameter. so i can build different tree... it will be faisible or is there something under this module that i'm missing that can be an obstacle? I think that is the right approach. - 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] eetx value doesn't increase for neighbors
On Fri, Aug 1, 2008 at 3:05 AM, Philippe BAYLE [EMAIL PROTECTED] wrote: Thanks for your answer, I thought that etx value should increase once the link becomes bad...? What I understand now is that the link eetx is only increased for the parent motes, not for the neighborsunless you send data packets that you see there not acknowledgedbut beacons don't use acknowledgment so I can't know if neighbors in the table are alive or not... The EETX value will decrease but much slower than you expect because the beacon frequency is controlled by a Trickle timer which might be firing at large intervals. - 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] collection, multiple roots, multiple id's - help
On Fri, Aug 1, 2008 at 1:06 AM, De-MonHell [EMAIL PROTECTED] wrote: yeah, i made a typo in my question (more than one, i see), but you've right understood however. now i have another question: doing as you suggest to me, it's better to work on a modified version of the already existing CollectionC module or it's better to take the basic components and write/wire a new component from scratch. anyway, that's a bad news for me, because i've based a more than a month work for my thesis on this idea (different-id == different roots). I don't blame the wiki for this, because maybe it's only my bad english or my poor experience with tinyos (this is my real first work with it), but i think some more examples, maybe with some schemas showing the tree build up in a scenario like mine, will be useful for future newbie. If the two clusters don't need to communicate with each other, you can compile one cluster with one AM ID and another cluster with a different AM ID. The AM ID is specified in CtpP.nc. We will improve the documentation based on user feedback. - 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] Implementation of CTP - SentCache
On Thu, Jul 31, 2008 at 7:01 AM, Oliver Frietsch
[EMAIL PROTECTED] wrote:
Hello list,
I'm currently working on a special-purpose derivate of CTP and therefore
read all the source code to get an overview. One point that is totally
unclear to me is in CtpForwardingEngineP (most recent CVS release).
It says (line 439):
// Once we are here, we have decided to send the packet.
if (call SentCache.lookup(qe-msg)) {
call CollectionDebug.logEvent(NET_C_FE_DUPLICATE_CACHE_AT_SEND);
call SendQueue.dequeue();
if (call MessagePool.put(qe-msg) != SUCCESS)
call CollectionDebug.logEvent(NET_C_FE_PUT_MSGPOOL_ERR);
if (call QEntryPool.put(qe) != SUCCESS)
call CollectionDebug.logEvent(NET_C_FE_PUT_QEPOOL_ERR);
post sendTask();
return;
}
OK, so it should *stop sending* and drop the next packet, in the case
that this packet (i.e. something very similar...) has already been sent
before. That's what I think...
Unfortunately, my opinion collides with the comment Once we are here,
we have decided to send the packet.
The comment is misleading. As you note, there are more tests done
after the comment before deciding to send the packet.
and the implementation of the cache
itself.
As stated in LruCtpMsgCacheP, the result of lookup is: if key [packet]
is in cache returns the index (offset by first), otherwise returns count
[of enqueued packets].
So... The packet is dropped *everytime*, except that is is the first one
in the sent cache or the cache is empty? What does this position imply
for the packet, except that it is the oldest one that I can remember?
I'm very sure that I missed something important, as this implementation
looks senseless to me ATM. Please help me!
Cache.lookup returns TRUE if a packet with the same signature is in
the cache. This TRUE/FALSE return by Cache.lookup is different from
what the internal lookup function in LruCtpMsgCacheP.nc returns. The
internal lookup function in LruCtpMsgCacheP.nc returns the position of
a packet in the cache if a similar packet is found, otherwise the size
of the cache. CTP does not use the internal lookup function
LruCtpMsgCacheP.nc.
- 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] eetx value doesn't increase for neighbors
On Thu, Jul 31, 2008 at 8:50 AM, Philippe BAYLE [EMAIL PROTECTED] wrote: Hi all, I am working on tinyos 2.x (not the latest CVS release). I am currently doing modifications on CtpRoutingEngineP.nc file in order to choose a parent considering severals parameters such as congestion and energy in extra of ETX. For that I check all the neighbors in the Routing Table built in the file. The problem is when a node is no longer alive ( for example if you move the motes) , it stays in the routing Tableand then it is considered for the choice of a new parent. I guess that the link Etx value should avoid to consider bad link but it doesn't. The link quality must increase in a signifiant way when a neighbor mote die but in fact, towards what I observed, it stays at the same valueThis comes from LinkEstimator component with the eetx value. I know that there was problems about eetx not increasing in the past but I am using the revision 1.6 of this file and it should works so I don't understand at all what happens. Can someone tell me if this is a bug or if the eetx value only increases when the parent (and not a simple neighbor) is lost? The link estimator value will decrease slowly - the estimator might send beacons once every 1024 seconds if the trickle timer has settled at that value and you will need to realize that you have missed a few beacons before you start seeing lower values. But if you send some data packets, the estimator will be updated rapidly. - 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] collection, multiple roots, multiple id's - help
On Thu, Jul 31, 2008 at 4:05 AM, De-MonHell [EMAIL PROTECTED] wrote: hi all. THE EXAMPLE: i have 4 motes: 0,1,3,4 (these are their TOS_NODE_ID) Inside them i have basically the same application that use a single collection with AREA_ID as colllection id BUT: node 0 and 1 have a enum inside them like this: AREA_ID=0 node 3 and 4 have AREA_ID=1 (for every node: i change the AREA_ID, i recompile and finally i deploy) Node 0 and 2 will act as root of the collection service. node 2? You have five motes? Node 1 and 3 will measure the ambient temperature and send it the the leader of their respective area (using the collection sender) so node 1 will send its data to node 0 and node 4 to node 3 I think there is a typo here - is node 3 your root? This is (my) exptected behavior. THE PROBLEM: but this case sometimes work and sometimes not. both temperature nodes sent their data (connecting them to the pc i can see their printf ) node 0 and 2 indeed, sometimes both thei receive the data, sometimes only one of the two. INFO i'm using the tinyos 2 from CVS 4 tmotesky motes i attach the files of the application ANSWER?! am i missing something about the collection protocol? what can i check to understand what is failing? why sometimes work and sometimes not? The argument you pass to CollectionSenderC during its instantiation is protocol id, the dispatch id of the protocol or application running on top of CTP. So, you are not forming two separate/disjoint trees. If you want two disjoint trees, you should run one instance of CTP in one part of the network and another instance of CTP in another part of the network. To do this, you can run CTP on two different AM types. Otherwise, you will have multiple roots in the same network and the packets will go to any or all of the roots depending on the dynamics or topology. - 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] Multihop in TinyOS 2.x
On Mon, Jul 28, 2008 at 1:33 AM, afuba edwin [EMAIL PROTECTED] wrote: Hi all, I was wondering if there is a multihop communication component in TinyOS 2.x like the GenericCommPromiscuous in TinyOS 1.x. Can anyone please help ? Please take a look at CTP, which replaces Multihop communication protocol in TinyOS 1.x. GenericCommPromiscuous has nothing to do with multihop communication. It allows you to send one hop messages and receive one hop messages even though they are not addressed to you. Hence Promiscuous. - 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] help please : turn off mote packet loss rate ?
On Fri, Jul 25, 2008 at 3:22 PM, fatima zohra [EMAIL PROTECTED] wrote: 2008/7/25 Omprakash Gnawali [EMAIL PROTECTED]: On Fri, Jul 25, 2008 at 7:37 AM, fatima zohra [EMAIL PROTECTED] wrote: 2008/7/25 Omprakash Gnawali [EMAIL PROTECTED]: On Wed, Jul 23, 2008 at 11:45 AM, fatima zohra [EMAIL PROTECTED] wrote: 2008/7/23 Omprakash Gnawali [EMAIL PROTECTED]: If you put sequence numbers in the packet, you can find out which packets were not received. For example, you sent sequence numbers 1 through 10 but and received 1,2,3,4,6,7,8,9,10 then you know exactly how many packets were not received. - om_p actually this isn't my scenario; here is an example of my protocol mechanism: we assume Node1 neighbor of nodes 2 3, and these two nodes are neighbors of source S (S will send 10 msgs for example) if 3 crashes so node 1 won't receive any more packets from 3. which means if You said there is one source but why is node 3 sending packets? because node 3 will forward what the source is sending in order to reach the sink (let's say for example sink = node1 to make it easier) S sends messages (from numSeq = 5 to 9) node A will never notice that he Node A is mentioned here for the first time. Is it node A or 1 or 2 or 3? sorry, it's node 1 (which isn't a direct neighbor to the source S) missed the 5 last nodes (because he doesn't communicate with S directly , Nodes or packets? sorry again, it's packets and node 3 is turned off for ever and node 2 won't help him to know what node 3 lost as messages (from S or other sources) because seq number is unique and different for each node (the 5th seqNum for node 2 may be the 1st message of the source S) now i wonna to calculate packet loss rate in my network since i have a set of nodes who crash and will lose some sent messages. am i clear now ? if yes, how to handle this situation. thanks in advance. best regards. Your description has some typos and could use some clarification. - om_p i mention in addition of what was said that: this simulation is done to study the behavior of the network after some nodes crash. so, first i choose some faulty nodes, then , turn them off for the rest of simulation (they won't receive any packet in the future). in the end of my simulation, i calculate my packet loss rate (i.e number of sent messages but not received by faulty nodes once they are stopped). is it clear now ? Almost. So you have a topology that looks like this: S -- 3 -- 1 but 3 is turned off so 1 is not receiving any packets but you want to find the loss rate on the link 3--1? - om_p that's it, but S--3--1 is just a piece of my topology (i just noticed it to clarify , my topology is larger than that). let's work with this small scenario. what's the way to find the packet loss rate ? Considering your scenario and objective, you should have each node send packets periodically just for link estimation. Then you will be able to estimate link quality even in the absence of data packets. - 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] Collection ack retransmission
On Thu, Jul 24, 2008 at 11:32 PM, Nahr ... [EMAIL PROTECTED] wrote: 2008/5/13 Nahr ... [EMAIL PROTECTED]: Thank you very much. yes yes colection concerns routing not link layer. Cheers, Nahr Elk 2008/5/13, Omprakash Gnawali [EMAIL PROTECTED]: On Mon, May 12, 2008 at 12:27 PM, Nahr ... [EMAIL PROTECTED] wrote: Hi, I just want to know how much a node retransmit a not acked msg and how long? for exemple A sends msg to B B receive the msg and sends Ack :( ack is lost. 1. How long A wait the msg ack? Collection does not send an ack - it relies on link layer ack. 2. How much A retransmit the not acked msg ? CTP will usually retransmit 5-7 times before it switches the parent. - om_p I am sorry for asking the same question an other time, but you said to me that CTP retransmit 5-7 times before it switches the parent but when I look to the Forwarding engine I found that MAx-retries = 30 !!! so how do you calculate the number of packet retransmission? When a re/transmission fails, that information is fed back to the link estimator which will update the quality of the link. If there are a few failures, the link estimator will have updated the quality of the link to be low enough that you will have paths through other links that are better than the path through the current parent. At that point, you switch the parent. So, you are retransmitting to a parent a few times before you switch to a new parent. - 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] help please : turn off mote packet loss rate ?
On Wed, Jul 23, 2008 at 11:45 AM, fatima zohra [EMAIL PROTECTED] wrote: 2008/7/23 Omprakash Gnawali [EMAIL PROTECTED]: If you put sequence numbers in the packet, you can find out which packets were not received. For example, you sent sequence numbers 1 through 10 but and received 1,2,3,4,6,7,8,9,10 then you know exactly how many packets were not received. - om_p actually this isn't my scenario; here is an example of my protocol mechanism: we assume Node1 neighbor of nodes 2 3, and these two nodes are neighbors of source S (S will send 10 msgs for example) if 3 crashes so node 1 won't receive any more packets from 3. which means if You said there is one source but why is node 3 sending packets? S sends messages (from numSeq = 5 to 9) node A will never notice that he Node A is mentioned here for the first time. Is it node A or 1 or 2 or 3? missed the 5 last nodes (because he doesn't communicate with S directly , Nodes or packets? and node 3 is turned off for ever and node 2 won't help him to know what node 3 lost as messages (from S or other sources) because seq number is unique and different for each node (the 5th seqNum for node 2 may be the 1st message of the source S) now i wonna to calculate packet loss rate in my network since i have a set of nodes who crash and will lose some sent messages. am i clear now ? if yes, how to handle this situation. thanks in advance. best regards. Your description has some typos and could use some clarification. - 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] help please : turn off mote packet loss rate ?
On Fri, Jul 25, 2008 at 7:37 AM, fatima zohra [EMAIL PROTECTED] wrote: 2008/7/25 Omprakash Gnawali [EMAIL PROTECTED]: On Wed, Jul 23, 2008 at 11:45 AM, fatima zohra [EMAIL PROTECTED] wrote: 2008/7/23 Omprakash Gnawali [EMAIL PROTECTED]: If you put sequence numbers in the packet, you can find out which packets were not received. For example, you sent sequence numbers 1 through 10 but and received 1,2,3,4,6,7,8,9,10 then you know exactly how many packets were not received. - om_p actually this isn't my scenario; here is an example of my protocol mechanism: we assume Node1 neighbor of nodes 2 3, and these two nodes are neighbors of source S (S will send 10 msgs for example) if 3 crashes so node 1 won't receive any more packets from 3. which means if You said there is one source but why is node 3 sending packets? because node 3 will forward what the source is sending in order to reach the sink (let's say for example sink = node1 to make it easier) S sends messages (from numSeq = 5 to 9) node A will never notice that he Node A is mentioned here for the first time. Is it node A or 1 or 2 or 3? sorry, it's node 1 (which isn't a direct neighbor to the source S) missed the 5 last nodes (because he doesn't communicate with S directly , Nodes or packets? sorry again, it's packets and node 3 is turned off for ever and node 2 won't help him to know what node 3 lost as messages (from S or other sources) because seq number is unique and different for each node (the 5th seqNum for node 2 may be the 1st message of the source S) now i wonna to calculate packet loss rate in my network since i have a set of nodes who crash and will lose some sent messages. am i clear now ? if yes, how to handle this situation. thanks in advance. best regards. Your description has some typos and could use some clarification. - om_p i mention in addition of what was said that: this simulation is done to study the behavior of the network after some nodes crash. so, first i choose some faulty nodes, then , turn them off for the rest of simulation (they won't receive any packet in the future). in the end of my simulation, i calculate my packet loss rate (i.e number of sent messages but not received by faulty nodes once they are stopped). is it clear now ? Almost. So you have a topology that looks like this: S -- 3 -- 1 but 3 is turned off so 1 is not receiving any packets but you want to find the loss rate on the link 3--1? - 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] help please : turn off mote packet loss rate ?
On Wed, Jul 23, 2008 at 12:13 AM, fatima zohra [EMAIL PROTECTED] wrote: Thanks Omprakash for your reply, may be i miss something... so this is the whole situation. i am using a protocol which sends periodic messages ( so i can calculate the number of the packets sent bu each node), however, how could i calculate the number of packets that were not received ( i have no ACK reply). is there any interface which does this ? your help is kindly appreciated. thanks in advance If you put sequence numbers in the packet, you can find out which packets were not received. For example, you sent sequence numbers 1 through 10 but and received 1,2,3,4,6,7,8,9,10 then you know exactly how many packets were not received. - 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] help please : turn off mote packet loss rate ?
On Mon, Jul 21, 2008 at 1:05 PM, fatima zohra [EMAIL PROTECTED] wrote: ... 2) i want to know also, if there is any way to calculate packet loss rate ? You can send a sequence of packets and calculate the number of packets that were not received. - 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] Discovering Neighbors
On Wed, Jul 16, 2008 at 5:40 AM, Nahr ... [EMAIL PROTECTED] wrote: Hi all. I remarked in CTP protocol that a node discovers its neighbors from received messages. But there is a case in which my neighbor could see me so I can receive his messages but him not so he can't receive msg from me consequently, why should I put him in my neighbor table? This description of the scenario is unclear - your neighbor could see you so you can receive his messages? That does not make sense. If your neighbor could see you, that means your neighbor could receive your message. If you are talking about a scenario in which there is no bi-directional link, although such links are not useful for CTP, the only way to determine that a link is not bi-directional is by maintaining some state about the link. So you have to insert the neighbor into the table. - 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] Network Protocols
On Sun, Jul 13, 2008 at 7:45 PM, Varun Jain [EMAIL PROTECTED] wrote: Hi TinyOS users, I want to deliver control data to a particular addressed node in the network from the BaseStation. I have already tested Collection which sends the data upto a tree root whereas Dissemination sends small data items to all the nodes in the network. Is there anyone who has worked around to send data to a particular node down the tree to a particular node using these two protocols or any other protocol. Please take a look at Tymo. - 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] about CTP
2008/7/10 jiwen zhang [EMAIL PROTECTED]: Hello om_p : yes , you are right , when the user send the data , he does not put the data at the beginning of the payload of the message_t , but an offset whose length is the size of the ctp_header . i understand . another question : maybe i have asked the question to someone , but i can't find it . you use nx_uint8_t data[0] in ctp_data_header , what is the function of this field ? because it's size is zero . is it similar to a pointer ? This allows you to access the variable size byte array as an array. If the data always had n bytes, we would have used data[n]. - 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] about CTP
On Wed, Jul 9, 2008 at 8:15 PM, jiwen zhang [EMAIL PROTECTED] wrote:
Hello Omprakash :
I have a question about the code in the file CtpForwardingEngineP.nc
In the implementation of Send.send , you use hdr = getHeader(msg) to
make hdr point to the payload field of the msg in order to inset the ctp
header before the user's data , and then you give the values to the
fields of the data structure of ctp_data_header_t . does these operations
will destroy the user's data ?
becase the CTP works well , so i think the user's data is not destroied ,
i don't know why .
because the function of getHeader is :
ctp_data_header_t* getHeader(message_t* m) {
return (ctp_data_header_t*)call SubPacket.getPayload(m,
sizeof(ctp_data_header_t));
}
so the returned pointer points to the user's data , so when you evaluate to
the fields , it shoud destroy the original datas according to my
understanding to the pointer . why ? can you give me an explain ?
CTP data header is in the payload section of the link layer packet.
What the code fragment above does is get a pointer to the link layer
payload (SubPacket gives you access to the link layer packet) and cast
the return value as a ctp_data_header_t. The user data would appear
immediately after the CTP data header in the link layer payload
section so by assigning values to the fields of CTP data header, we
are not touching the user data.
- 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] sending and receiving
On Wed, Jul 9, 2008 at 4:11 AM, funofnet Funofnet [EMAIL PROTECTED] wrote: Hi Mr Omprakash, I found that : If I place two motes one as a sender the second as a receiver, the sender will send packet only if it has received an ack of the last packet sent (isn't it ?) so how could I eliminate this restriction? Is it by denying ack control ? (if yes How ?) If you are talking about just sending and receiving messages (not CTP), this restriction is not there. If you are talking about CTP, if you do not receive an ack after many attempts, CTP concludes that you have a bad link and might wait until a better link is discovered (in this case there is none). - 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] Re : sending and receiving
On Wed, Jul 9, 2008 at 4:52 AM, funofnet Funofnet [EMAIL PROTECTED] wrote: First thank you very much. Yes I am using CTP components but I guess from your last mail that I could do not use it if I have just two nodes. (CTP is a routing protocol so logically we use routing only when we have 3 nodes or plus). You can use CTP with two nodes but if the link between the nodes is bad, you won't see messages reaching the destination. - 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] Multiple receive when using CollectionC
On Tue, Jul 8, 2008 at 6:31 AM, Philipp Küderli [EMAIL PROTECTED] wrote: Hi, I use CollectionSenderC and CollectionC of the ctp package to send my data to the sink node. I just use a timer to send a message each second and the node with id zero receives it. I only use two sensors. Unfortunately, I always receive the packages many times, as you can see below. The sending does not answer with any errors and I only send the next message when the channel is not busy. This becomes also clear by looking at the sequence number. What is the reason for this multiple receivings? Most likely the link layer acks are not working. Make sure to turn them on. - 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] Multihop in TOS 2.0
On Tue, Jul 8, 2008 at 12:36 PM, Mr Meddage Saliya Ranal Fernando [EMAIL PROTECTED] wrote: Dear all, Is there a multihop application in TOS 2.0 for telosb motes? Because I tried Antitheft it is only for Mica motes. You can also look at MultihopOscilloscope and tests/TestNetwork for examples of collection routing. - 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] about Broadcast component in tinyos2.x
On Wed, Jul 2, 2008 at 12:51 AM, jiwen zhang [EMAIL PROTECTED] wrote: Hello David : I see there is Broadcast component in tinyos1.x in tos\lib\Broadcast, is there the similar component in tinyos2.x ? i want to use it , but i don't find . why is it taken out ? You should look into Dissemination. - 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] Begginer in tinyos an tenet.
On Mon, Jun 30, 2008 at 5:34 AM, Érico Lemos [EMAIL PROTECTED] wrote: Hi, Can I test tenet without a mote ?? Yes. There is a support for emstar emulation now. You should read this document to learn how: http://enl.usc.edu/cgi-bin/viewcvs/viewcvs.cgi/tenet/doc/Centroute_and_Emulation.HOWTO?rev=1.8content-type=text/vnd.viewcvs-markup - 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 CTP Messages to the Serial Port
On Fri, Jun 27, 2008 at 2:35 AM, Philipp Küderli [EMAIL PROTECTED] wrote: Hi, I use the CTP CollectionC to forward my data to the sink. Then I want to send the data to the PC using the serial port. When I use AMSend for normal sending or the CollectionC in the lqi package, I just can forward the messages to the serial port to my Java application, which uses for my data a message class generated by mig. I am not sure, but I think the Java application cannot read the received data correctly, because the ctp implementation writes into the payload of the message, is this true? If I cannot forward the ctp message directly, how should I forward it in the most efficient way? CTP does not forward the packets to the UART. You can take a look at tests/TestNetwork, which shows how an application can forward the packets received at the sink to the UART. - 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] MultiHopOscilloscope Packet Loss
On Wed, Jun 25, 2008 at 7:09 AM, Gaurav Chandwani [EMAIL PROTECTED] wrote: Hi All, ... I saw a strange behaviour using SerialForwarder - When the application is running for some hours, sometimes, i dont receive messages from a particular node for some minutes and then it comes back again. Its reproduced many times. Has anybody seen this kind of behaviour ? Since MHO is stable, so there should be a problem at my end but I am not able to find where. If there is no viable path between the nodes and the root, CTP won't be able to deliver packets. Have you considered that possibility? Since the nodes can reach root node directly, they will send message only to it or also other nodes ? It can be either way depending on the link and path qualities. Can there be a problem with root node sending of messages on UART or some other queue overflow ? I am using baud rate of 115200. Next, I will try to use printf to understand at which level the problem is. Queues should not overflow if you are not sending a lot of packets and if there are viable paths. It is possible to overflow a queue if a node is not able to drain it fast enough (too many retransmissions, for example) As i read, the reliability of CTP should be 99.9% at low traffic rate, but the 0.1% messages that are lost, are lost periodically or there is a possibility that they can be lost in chunks of messages ? and what will be high traffic rate ? If you are planning to saturate the channel, you should expect a lot of losses. If these motes are connected with a PC during the experiment, I suggest running tests/TestNetwork and looking at the debug messages logged by each mote to understand the cause for the loss you are seeing. - 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] MultiHopOscilloscope Packet Loss
On Wed, Jun 25, 2008 at 8:27 AM, Gaurav Chandwani [EMAIL PROTECTED] wrote: Hi Omprakash, Thanks for the quick reply. Viable path - I see the node lost behaviour even with nodes that are directly connected(no hop, very close) to the root node. Do you mean something else by viable path ? Sometimes, even when the nodes are close, the link qualities might be bad. If all the links are bad, you do not have a viable path. How much traffic amounts to saturation of the channel ? I have 10 nodes having MHO code sending a packet every 5 sec, i think this should make very less traffic ? This should be OK unless the nodes are retransmitting incessantly due to lossy links. If i put tests/TestNetwork on all the nodes, to see the debug messages, i have to enable a flag or these are simply printf statements ? Right now, I have only root node connected to the PC, but as you suggested, to check the debug messages,i can connect other nodes too. Will try this. It will generate debug messages without any flags. - 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] Dissemination and Collection protocols...
On Tue, Jun 24, 2008 at 5:22 AM, Varun Jain [EMAIL PROTECTED] wrote: Hi, I am trying to implement the multi hop protocols for which I was implementing the 'AntiTheft' application. I am able to achieve Dissemination as I can change the 'interval' via the AntiTheft Gui. But while doing the Collection, it always gives me the same message whether I send it from TOS_NODE_ID=2 or TOS_NODE_ID=3. The mote running the Root application has a TOS_NODE_ID=1. I suggest trying tests/TestNetwork first if you suspect the collection part is broken. ... As we can see, it always gives the stolenId as zero but it only gives this once actually the event happens on the nodes. Has anyone got this problem Also when I am trying to achieve multihop with the application, it does not happen. This is what I do: I keep NODE=3 outside the range of the 'Root node' and then plug NODE=2 in between such that NODE=2 acts as a bridge for NODE=3 to get to the 'Root node'. I am using Chipcon's CC2420DBK which has Atmega-128 and CC2420 with Tinyos-2.0.2 running under cygwin. How can I solve this problem? When you put node 2 between node 1 and node 3, are you sure that node 1 and node 3 do not have the capability (too far) to communicate directly? CTP will pick, in its opinion, the best routes to the sink. Even if you have a node in between, it is possible that it is less costly (ETX) to communicate directly with the root. For example, if the link between 1 and 3 is still pretty good, it will require about one transmission while the path through node 2 will require at least two transmissions. So, CTP might still pick the one hop path. I am able to implement 'TestDissemination' application and other applications doing Dissemination which means that it is working correctly, but I have a very basic question about 'diddemination'. I wanted to know if it is possible to disseminate the value from the ROOT ID to a particular NODE-ID, say we want the BaseStation to change the control parameter of only one particular node, i think we cant do that in dissemination as it broadcasts to all the nodes, so is there any protocol in TinyOS to do this kind of networking which does a multi-hop delivery of data to a particular addressed node. TyMo. Or you can build a protocol on top of Dissemination. - 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] questions about CTP
On Sat, Jun 21, 2008 at 1:52 AM, jiwen zhang [EMAIL PROTECTED] wrote: Hello Omprakash : Yes , i don't instantiate a CollectionSenderC , because my applications is similar to AntiTheft , and i don't need the component CollectionSenderC in the Root application . Does these warnings affect the application's running ? -:) if yes , How should i correct it ? i also test the Root application in AntiTheft , when i compile it , it also gives the same warnings . http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2007-July/027051.html - 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] questions about CTP
On Sat, Jun 21, 2008 at 2:13 AM, jiwen zhang [EMAIL PROTECTED] wrote:
Hello Omprakash :
i think the last four commands (numNeighbors() ,
getNeighborLinkQuality(uint8_t neighbor),getNeighborRouteQuality(uint8_t
neighbor) and getNeighborAddr(uint8_t neighbor)) are provided for the users
of CTP to get the information of the routetable , because i don't see they
are used in other components . ???
Yes.
How do you want to fix them ? does the way like
command uint16_t CtpInfo.getNeighborLinkQuality(uint8_t n) {
return (n routingTableActive)? evaluateEtx(call
LinkEstimator.getLinkQuality(routingTable[n].neighbor)):0x;
}
command uint16_t CtpInfo.getNeighborRouteQuality(uint8_t n) {
return (n routingTableActive)? evaluateEtx(call
LinkEstimator.getLinkQuality(routingTable[n].neighbor)) +
routingTable[n].info.etx:0xf;
}
Yes.
because i don't find they are called in other components , so i think i only
need to change these . am i right ? are there any other places i need to
change ?
No need to change anything else.
- 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] how-to use MultiHopRouter
On Sat, Jun 21, 2008 at 8:57 AM, Juri Lelli [EMAIL PROTECTED] wrote: Hi, I want to use the MultiHopRouter library component. I've read the tutorial and I've watched to Surge application, but I can't understand how can I use the multi hop feature in my application. Where can I find more help? I wonder how I have to wire my components to MultiHopRouter to send and receive messages. If you are not constrained to using TinyOS 1.x, you can read the tutorial on collection protocol for TinyOS 2.x: http://docs.tinyos.net/index.php/TinyOS_Tutorials For TinyOS 1.x Multihop router, conceptually you should do something similar but you should just read the code for Surge to find the details. - 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] questions about CTP
On Thu, Jun 19, 2008 at 12:07 AM, jiwen zhang [EMAIL PROTECTED] wrote: ... today , i write an application using CTP , when i compile it , it can be compiled successfully , but gives some warnings like : /home/Administrator/local2/src/tinyos-2.x/tos/lib/net/ctp/CtpForwardingEngineP.n c: In function `CtpForwardingEngineP$0$sendTask$runTask': /home/Administrator/local2/src/tinyos-2.x/tos/lib/net/ctp/CtpForwardingEngineP.n c:493: warning: comparison is always false due to limited range of data type /home/Administrator/local2/src/tinyos-2.x/tos/lib/net/ctp/CtpForwardingEngineP.n c: In function `CtpForwardingEngineP$0$SubSend$sendDone': /home/Administrator/local2/src/tinyos-2.x/tos/lib/net/ctp/CtpForwardingEngineP.n c:575: warning: comparison is always false due to limited range of data type /home/Administrator/local2/src/tinyos-2.x/tos/lib/net/ctp/CtpForwardingEngineP.n c:597: warning: comparison is always false due to limited range of data type i am using tinyos2.x CVS tree , Do you know the reason , Omprakash ? Maybe the problem you describe is similar to this: http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2008-May/033460.html - 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] questions about CTP
On Thu, Jun 19, 2008 at 12:07 AM, jiwen zhang [EMAIL PROTECTED] wrote:
...
so i think the implementation of CtpInfo.getNeighborRouteQuality should
change into :
command uint16_t CtpInfo.getNeighborRouteQuality(uint8_t n) {
return (n routingTableActive)? evaluateEtx(call
LinkEstimator.getLinkQuality(routingTable[n].neighbor)) +
routingTable[n].info.etx:0xf;
}
what do you think , Omprakash ?
You are right - we need to not only fix getNeighborRouteQuality as you
suggested but also getNeighborLinkQuality for the same reason.
Unfortunately, this will have to wait until after the 2.1 release.
a bug :
in component CtpSenderP , it use the component CtpC , i don't find the
component . can you check it , Omprakash ?
Yes, this is a bug. The fix will need to wait a week or so. It turns
out we had those files to enable running multiple collection protocols
at the same time but that work was never completed. We will look into
this after the release.
- 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] questions about CTP
On Tue, Jun 17, 2008 at 5:42 AM, jiwen zhang [EMAIL PROTECTED] wrote:
Hello Omprakash :
maybe i don't express my problems distinctly .
1 . the field etx in the struct route_info_t . Is it the current
node's ETX through it's parent ? or is it the parent's ETX ?
That neighbor's ETX or the cost from that neighbor to the root. If
that neighbor is the parent, then it would be the cost from the parent
to the root.
2. what are the meaning of commands getNeighborLinkQuality(uint8_t
neighbor) and getNeighborRouteQuality(uint8_t neighbor) in the interface
of CtpInfo ?
in my opinion , the command getNeighborLinkQuality returns the ext
between the current node and one neighbor in routetable , and the
command
getNeighborRouteQuality returns the etx between current node and
root throught the neighbor . am i right ? can you expalin it detailedly ?
You are right.
3 . i have seen the implementation of the interface CtpInfo , and the
command getNeighborRouteQuality which is
command uint16_t CtpInfo.getNeighborRouteQuality(uint8_t n) {
return (n routingTableActive)? call
LinkEstimator.getLinkQuality(routingTable[n].neighbor) +
routingTable[n].info.etx:0xf;
}
if it returns the value of the neighbor's ETX through this neighbor's parent
, i think it should be changed into :
command uint16_t CtpInfo.getNeighborRouteQuality(uint8_t n) {
return (n routingTableActive)? routingTable[n].info.etx:0xf;
}
because routingTable[n].info.etx is the neighbor's ETX through this
neighbor's parent , why do you add the link quality between the current node
and this neighbor ?
What we are trying to do is return the path quality from the current
node, through the given neighbor, to the root. So, we need to add the
cost from the node to the parent (link quality) to the cost from the
parent to the root (getNeighborRouteQuality).
- 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] Protocols for tinyos2.x
On Mon, Jun 16, 2008 at 7:41 AM, [EMAIL PROTECTED] wrote: I would like to know if any of you know of any protocols for tinyos 2.x which I could download to test and study here. Most of the ones that I found are for tinyos 1.x, I've found something named like dymo for tinyos 2.x, but when I try to use it, lots of error messages appear. So, that's why I wanted to know if someone know where to find a working implemented protocol for tinyos 2.x. What errors do you get when you try to use Tymo? You can look in tinyos2.x-contrib for more protocols and applications. - 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] questions about CTP
On Sun, Jun 15, 2008 at 8:54 PM, jiwen zhang [EMAIL PROTECTED] wrote:
Hello Omprakash :
I have some questions about the interface CtpInfo .
Firstly , i am puzzled to the meaning of some fields in routetable.
in the structure routing_table_entry (TreeRouting.h), there are some
information of the current node . the field of parent in route_info_t should
be the parent of one neighbor in the routetable , and what does the ETX mean
? is it the the neighbor's parent's EXT or the neighbor's the ETX ?(the EXT
here should be the path metric to the root??) .
i have seen the implementation of CtpInfo in CtpRoutingEngineP, and i have
interest to the command which get the neighbors' information.
command uint16_t CtpInfo.getNeighborLinkQuality(uint8_t n) {
return (n routingTableActive)? call
LinkEstimator.getLinkQuality(routingTable[n].neighbor):0x;
}
command uint16_t CtpInfo.getNeighborRouteQuality(uint8_t n) {
return (n routingTableActive)? call
LinkEstimator.getLinkQuality(routingTable[n].neighbor) +
routingTable[n].info.etx:0xf;
}
in my opinion , the command of getNeighborLinkQuality returns a value of the
quality between the current node and this neighbor in the routetable .
if the field of ETX in route_info_t is the neighbor's EXT to the root , i
think the command getNeighborRouteQuality returns a value of path metric
between the current node and the root node through this neighbor (which is
the sum of this neighbor's ETX to the root and the quility between the
current node and the neighbor node).
the command Ctp.getEtx(uint16_t* etx) will return the value of the path
metric between the current node and the root through the node's parent. i
find there are some differencs with the way in
CtpInfo.getNeighborRouteQuality.
*etx = routeInfo.etx + evaluateEtx(call
LinkEstimator.getLinkQuality(routeInfo.parent));
and the function evaluateEtx() is
uint16_t evaluateEtx(uint16_t quality) {
return (quality + 10);
}
i don't know whether i have expressed the problem distinctly , i think the
two ways have the difference of 10 . am i right ,Omprakash ? can you give
me an explain?
Yes. The algorithms use the metric ETX*10 but the metric is encoded as
(ETX-1)*10 in the packets.
- 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] Ctp Problem with micaz
On Tue, Jun 10, 2008 at 12:08 AM, Yiannis Yiakoumis [EMAIL PROTECTED] wrote: OK, I will and let you know when I have any news. By the way, is address filtering platform specific, or something that could work on telosb and not in micaz? It should work on both the platforms but I suspect that you do not have a clean TinyOS source tree. At least that was the case when I saw the problem similar to yours. - 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] Ctp Problem with micaz
On Mon, Jun 9, 2008 at 10:33 PM, Yiannis Yiakoumis [EMAIL PROTECTED] wrote: Hi all, I run into problems using ctp in micaz. I use TestNetwork application installed in micaz. Root node seems to work ok, sending beacons with itself as parent and etx=0. But the receivers even though they get this beacon ( I have gone until insertNeighbor() which returns SUCCESS),they will keep on advertising as a parent and complain about having no route. The strange thing is that exactly the same code, compiled for telosb works without any problem... Is there any point that I should pay attention? We have tested TestNetwork on MicaZ as well as TelosB. Each mote sends debug output through the UART. Can you send the debug output form the nodes? - 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] CollectionSenderC.send(...) does not signal sendDone(error_t)
On Fri, Jun 6, 2008 at 3:35 AM, Nicola Wegner [EMAIL PROTECTED] wrote: 2008/6/6 Paul Stickney [EMAIL PROTECTED]: [...] I don't have in-depth enough knowledge about the Collection implementations, but I suspect that (in priority of where I'd start looking) 1) No route is being found and it's waiting and waiting and ... This really seems to be the problem. I have put some debug messages in CtpForwardingEngineP.nc to check it. It retries to send every 10 You can also use the built-in debugging system that should report a lack of path when you try to send a packet. seconds. If no route is found it blocks forever. There is an empty implementation of event void UnicastNameFreeRouting.noRoute(); that is signaled. I think this is the place where a cancel after several retries could be implemented. But this does not really make very much sense in case of the collection protocol. So your conclusion is what it is doing is the right behavior? - 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] CTP clarification
On Wed, Jun 4, 2008 at 11:36 PM, Varun Jain [EMAIL PROTECTED] wrote: Hello TinyOS users, I have read all the papers and comparisons cited in the earlier posts for CTP. CTP is meant to be Collecting data from various motes lying in the field and send the data to a central BaseStation. As Dissemination is for broadcasting certain common data/ small packets to all the nodes in the network, it will only suit first part of my application which is to send certain data everyday once to the remote motes. Secondly, I need to collect data when a particular event happens at a particular node which can be done by Collection. Third part of my application is to send some particular data to a particular node in the network for which I want guidance that can CTP be used for it??? If we consider the BaseStation as main root of the tree, then we cannot send the data packet down the tree or can we?? As TEP-119 says, Collection provides a best-effort, multihop delivery of packets to one of a network's tree roots: it is an anycast protocol so that makes me believe that we can deliver particular data to a particular tree root from the BaseStation but not further down those tree roots, in which case we will have to make every node a 'tree root' which is not possible, so how do we overcome this issue? I am currently also considering to apply TYMO for my application. Are there any papers comparing TYMO and CTP protocols??? You can not use CTP to route from the root to the nodes in the network. You might need to add some kind of reverse path routing or other kinds of mechanisms. Or you can use TYMO as you suggested. There are no papers comparing TYMO and CTP but you can look up Romain's Master's thesis or the tutorial pages for a detailed description of TYMO. I have 4 Texas Instruments CC2420DBK, so for testing 'TestNetwork' application, do we program 3 boards with this application and 1 board with the BaseStation application. Can anyone please include a guide/Readme.txt for TestNetwork as they are really helpful…. You should program a mote whose ID % 500 is 0 to make that node a root. You can look at apps/MultihopOscilloscope for a more realistic example of an application that uses Collection and Dissemination. - 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] why we need a MessagePool in forward() function in CTPForwardingEngine ?
On Thu, Jun 5, 2008 at 3:04 PM, 贾鹏 [EMAIL PROTECTED] wrote: Hi there, I' m scrutinizing the CTPForwardingEngine now, I'm little confused by the function forward(); I realize the QEntryPool is necessary, for it will put a new recieved packet into the queue. But I cannot understand the function of MessagePool. Everytime it grab a space from this pool and return a pointer newMsg, but it assign it equals to 0 and let the SubReceive.receive return this value. why we need to do this, and assign this newMsg's pointing space equal to 0, does the SubReceive.receive needs such a return value? I cannot see its point. QEntryPool is a pool of fe_queue_entry, not the packets. MessagePool is a pool of message_t. fe_queue_entry has information about the client and retries but the packet is buffered using entries from MessagePool. We could not use a single pool because we need to enqueue the packets but we need additional information as well such as how many retransmits have been attempted. - 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] something wrong happened in CC1000 driver in tinyos-2.x tree of cvs version
I looked into this a little bit and it seems like this bug was
introduced when we put code that sets the white bit in the metadata.
The problem is in packetReceiveDone(), we are checking if the radio is
in RECEIVED_STATE before setting it to RECEIVED_STATE. The radio would
be in RX_STATE and discard the packet. Here is the relevant code
snippet:
void enterReceivedState() {
radioState = RECEIVED_STATE;
}
void packetReceiveDone() {
message_t* pBuf;
uint16_t snr;
atomic {
if (radioState != RECEIVED_STATE) {
return;
}
post signalPacketReceived();
enterReceivedState();
}
Phil, you own this code so you should decide how to fix this problem.
BTW, I did not get the out of bound error that John found - maybe I
did not run the test long enough...
Thanks.
- om_p
On Mon, Jun 2, 2008 at 4:03 PM, John Regehr [EMAIL PROTECTED] wrote:
Ok, we found some mica2s and put Oscilloscope on them after hacking
CC1000SendReceiveP.nc to check for count going out of bounds. It is
definitely going out of bounds at line 501.
John
On Sun, 1 Jun 2008, John Regehr wrote:
We think we have found a problem in the CC1000 receive-side code that is
perhaps related to the behavior described here.
The suspected culprit is at line 501 of CC1000SendReceiveP.nc which looks
like this:
((uint8_t *)rxBufPtr)[count++] = nextByte;
We think that count is going out of bounds, leading to RAM corruption.
To test this, introduce some code just before this line that is something
like
if (count=sizeof(message_t)) { ... blink LEDs in infinite loop ... }
Confirmation that this check fails (or not) would be useful to us.
We'd do this ourselves but we seem to have very few mica2s sitting
around.
The root problem may be a failure to clear count at an appropriate time.
John
On Sun, 1 Jun 2008, Philip Levis wrote:
On May 30, 2008, at 1:22 PM, Dima Kogan wrote:
I can confirm this. My CC1000-based motes work fine with the 2.0.2
release but crash with the latest cvs. I run a modified BlinkToRadio
to test, with one node only transmitting and the other node only
receiving. The transmitting node works ok. The receiving node seems
to crash. As a test, I turn on an LED in Boot.booted() and don't
turn it off in any part of the code. This LED blinks or turns off at
various times on the transmitted node, which indicates that the mote
is
rebooting. ALso, the first packet from the transmitter is always
received properly, with the erroneous behavior starting with the
second
packet.
There have only been a few small changes to the CC1000 stack; the
first was that it actually checks for CRCs, the second was the
inclusion of support for 4 bit link estimation.
Om, you were going to run some tests on mica2dots, right? Can you see
if you encounter this problem?
Phil
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] How to use LinkEstimatorDummyP
2008/5/28 funofnet Funofnet [EMAIL PROTECTED]: Hi, I want to use this module so which components should I add or modify in CTP folder? Ideally you would change ListEstimatorP to LinkEstimatorDummyP in CtpP.nc. But LinkEstimatorDummyP.nc might not support the latest LinkEstimator interface. I removed LinkEstimatorDummyP.nc from the CVS recently because it was supposed to be used in initial testing for routing engine without a live estimator. - 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] Multihop network basics
On Thu, May 29, 2008 at 12:06 AM, Dima Kogan [EMAIL PROTECTED] wrote: Hi. I would like to set up a multihop, power efficient network with TinyOS. I have basic CTP working, but I would like to get answers to a few simple and general questions before I get in too deep. 1. It seems like CTP is the preferred system I should be using, since it has a TEP, but I also see mention of LQI. Is there a document somewhere that describes LQI? Should I be considering it at all? Are there other algorithms out there that I should be looking at? Those are the two collection protocols included in the core distribution. There might be more in contrib. 2. I'm using the CC1000 radio, so I have RSSI measurements available to me. Looking at the LinkEstimator codes (le and 4bitle), it's not obvious to me that these are using RSSI. Should they be? Is this something that I should code up myself, or is there a fundamental reason that RSSI is not appropriate here? 4bitle uses one bit of information derived from RSSI (in case of CC1000) - was the link good or not? It might be difficult to build a routing protocol that uses only RSSI as its routing metric, but it might be possible to do so if you can make some assumptions about your environment. CTP tries to be platform-independent which is why it does not use actual RSSI values from CC1000. 3. My motes need to run off of a single battery charge for a very long time, so low power listening is very highly desireable. Reading the forum archives, it seems like CTP+LPL is not very thoroughly tested and that they don't play nice together currently. Is this correct? Are people achieving power efficiency through other ways? Is the right answer to write something myself? We are testing this combination. There are other ways to achieve energy efficiency too. SCP-MAC is an example. - 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] Multihop network basics
On Thu, May 29, 2008 at 1:46 PM, Dima Kogan [EMAIL PROTECTED] wrote: Thanks for your reply, Omprakash. I've just looked at the MAC protocol you mentioned, SCP-MAC, and also S-MAC and B-MAC. I'm a bit unclear on what these are. Are these point-to-point or multi-hop protocols? The papers imply that they are multi-hop, but other sources seem to suggest that TinyOS 1.x was using B-MAC for its Mica2 radio stack, which would suggest that it's point-to-point. Thanks in advance for the help. MACs are used for single-hop communication but multihop protocols work on top of these MACs. Although MACs are used for single-hop communication, in their implementation they might need to propagate information specific to those MAC protocols over multiple hops. - 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] Re : threshold link estimator
2008/5/28 funofnet Funofnet [EMAIL PROTECTED]: Hi, Thank you very much Mr Omprakash and excuse me for insistance, but concerning MintRoute why is the threshold equals to 384 Remember, the way MintRoute and 4bitle compute the estimates are not exactly the same which is why the threshold is probably different. - 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] Re
On Wed, May 28, 2008 at 12:56 PM, funofnet Funofnet [EMAIL PROTECTED] wrote: Hi, I am greatly thankful for your replies, but what I need to know how could I specify an accurate threshold for any estimator (espacially wmewma and prr). Is there a formula to apply ?. You can do experiments to find out the link qualities and determine the thresholds so that you don't filter out all the links. - 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] Routing
On Thu, May 22, 2008 at 9:03 AM, Maria Taramigkou [EMAIL PROTECTED] wrote: Hello!! Is there an implemented algorithm for routing in tinyos-1.x?I want to implement routing for Oscilloscope.Which protocol is it preferable to use?There are MultihopLQI, Route,MintRoute... Thank you in advance!! You can use any of those protocols. Some will work better than others depending on the situation. You can experiment with those protocols in your environment and determine what works best for you. - 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] Tracking routes in CTP
2008/5/21 Antonio Prados Vilchez [EMAIL PROTECTED]: Hi TinyOS users!! Is there any way to know the route that a packet has followed in a Collection Tree? I want to track the hops of the communication between the motes and the root of the tree. I'm using CTP and MICA2 motes. If all the motes are connected through USB, you can write a script to analyze the debug output - each mote outputs the packet serial number, origin, and the next hop for each packet forwarded. You can combine information this information from all the motes to construct the path. If the motes are not connected through USB, you will need to put the local node id in the packet somewhere each time it is forwarded. - 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] Problem with MultiHopOscilloscope
On Tue, May 20, 2008 at 1:26 AM, Antonio Prados Vilchez [EMAIL PROTECTED] wrote: Hi TinyOS users!! I'm trying to understand how Collection Tree Protocol works. MultiHopOscilloscope would help me to do that, so I have downloaded it into three MICA2 motes. The problem is that it doesn't work. I have modified the application in order to know why it happens. The Send.sendDone event doesn't occur when a radio-transmission has finished. Am I doing anything wrong? Does anybody know if there is an actualized version of this application? Or should I modify anything in some library? Did you make any changes at all in the application? Would it be possible for you to run apps/tests/TestNework on your motes - make sure one of the nodes has id 0. You should then see the root forwarding the received packets on the UART. The rest of the motes will also send debug messages on their UARTs. If you send those debug messages, we can look at the error messages. - 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] Q about CTP protocol
On Mon, May 19, 2008 at 1:14 PM, gaurav mathur [EMAIL PROTECTED] wrote: Hi, CTP provides Intercept interface, I am not getting how to use event Intercept.forward. Please give me a sample code demonstrating Intercept.forward event. I do not have an example but maybe you can ask Dimas: http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2008-January/030768.html - 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] some thing what shouldn't be in footer-neighborList
On Tue, May 20, 2008 at 12:26 AM, funofnet Funofnet [EMAIL PROTECTED] wrote:
Hi,
this is where I suspect the bug : LinkEstimatorP.nc
**
j = 0;
newPrevSentIdx = 0;
NEIGHBOR_TABLE_SIZE = 10 // I added to have all the constants mentionned
for (i = 0; i NEIGHBOR_TABLE_SIZE j maxEntries; i++) {
k = (prevSentIdx + i + 1) % NEIGHBOR_TABLE_SIZE;
if ((NeighborTable[k].flags VALID_ENTRY)
(NeighborTable[k].flags MATURE_ENTRY)) {
footer-neighborList[j].ll_addr = NeighborTable[k].ll_addr;
footer-neighborList[j].inquality = NeighborTable[k].inquality;
newPrevSentIdx = k;
dbg(LI, Loaded on footer: %d %d %d\n, j,
footer-neighborList[j].ll_addr,
footer-neighborList[j].inquality);
j++;
}
}
***
Normally footer-neighborList[] should contain distinct neighbour but in the
case where the second and last element in the
NeighborTable are mature and valid only element index 1 will be insert.
Isn't it?
I explain more:
k = 0 + 0 + 1 % 10 = 1 (NeighborTable[1] is mature and valid) then
footer-neighborList[0].ll_addr = NeighborTable[1].ll_addr;
footer-neighborList[0].inquality = NeighborTable[1].inquality;
then we continue until * i = 9 *
k = 1 + 9 + 1 = 11 % 10 = 1 (NeighborTable[1] is mature and valid) then
You are updating prevSentIdx in the expression above to 1 - that
happens only after you exit the for loop. The correct expression
should be 0 + 9 + 1 = 10 % 10 = 0 so I don't think this is a bug.
Does this make sense?
- 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] LinkEstimatorDummyP
I removed this file from the repository - it was used to test CTP
without a live link estimator.
- om_p
On Mon, May 19, 2008 at 10:26 AM, funofnet Funofnet [EMAIL PROTECTED] wrote:
Hi,
I have a question about this module : what is its utility and its relation
ship with LinkEstimatorP.nc,
Also, why these commands return 1 and 2 ??
command uint8_t LinkEstimator.getLinkQuality(uint16_t neighbor) {
return 2;
}
command uint8_t LinkEstimator.getReverseQuality(uint16_t neighbor) {
return 1;
}
command uint8_t LinkEstimator.getForwardQuality(uint16_t neighbor) {
return 1;
}
Thanks
__
Do You Yahoo!?
En finir avec le spam? Yahoo! Mail vous offre la meilleure protection
possible contre les messages non sollicités
http://mail.yahoo.fr Yahoo! Mail
___
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] Collection ack retransmission
On Mon, May 12, 2008 at 12:27 PM, Nahr ... [EMAIL PROTECTED] wrote: Hi, I just want to know how much a node retransmit a not acked msg and how long? for exemple A sends msg to B B receive the msg and sends Ack :( ack is lost. 1. How long A wait the msg ack? Collection does not send an ack - it relies on link layer ack. 2. How much A retransmit the not acked msg ? CTP will usually retransmit 5-7 times before it switches the parent. - 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] How to send data from one node to multiple (and visaversa)
On Fri, May 9, 2008 at 5:01 AM, Nick Verbaendert [EMAIL PROTECTED] wrote: Hi, I have a question about connecting 1 node to multiple nodes. * I have a network of 5 telosb nodes: * 3 anchor nodes (I know the x and y values) , lets call them A1, A2 and A3 * 1 blind node (x and y are unknown), lets call this BLINDNODE * 1 basestation * I know how to retreive the RSSI value from a packet. How do send the RSSI values from A1, A2 and A3 regarding the BLINDNODE to the basestation. Any help would be greatly appriciated! You can use collection. For an example, please take a look at the MultihopOscilloscope application. This application grabs data from sensors and sends to a designated node (root) in the network. - 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] packets received packets sent ?????
On Fri, May 9, 2008 at 7:27 AM, Nahr ... [EMAIL PROTECTED] wrote:
Hi,
I am steel facing bizarre things.
How could a receiver receive more than the packet sent ??
//
void sendMessage() {
if (call Send.send(packet, sizeof(EasyCollectionMsg)) != SUCCESS) {
failedSend();
}
else {
sendBusy = TRUE;
printf(I am node n %d I sent a msg \n,TOS_NODE_ID);
}
//
event message_t* Receive.receive(message_t* msg, void* payload, uint8_t len)
{
printf(I am node n %d I receive a msg \n,TOS_NODE_ID);
}
I calculate the number of (I am node n %d I sent a msg) I found that its
number is less
than
I am node n %d I receive a msg \n
How is that ???
When a transmitter sends a packet and the receiver receives it
successfully but the ack gets lost, there is no way for the
transmitter to know if it was the packet or the ack that was lost.
Then the transmitter retransmits the packet. This retransmission could
result in multiple copies of packets at the receiver.
- 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] How to send data from one node to multiple (and visaversa)
On Fri, May 9, 2008 at 7:49 AM, Nick Verbaendert [EMAIL PROTECTED] wrote: Yes, I already use the Collection protocol in my application, but this chooses the parent id automaticly. Somehow I need to set the parentId of my anchor nodes to the id of the blindnode. e.g. * anchornode1 (id=1, parentid=4) * anchornode2 (id=2, parentid=4) * anchornode3 (id=3, parentid=4) * blindnode (id=4, parentid=0) * basestation (id=0, parentid=0) I have really no idea how this is done. You should just use AMSender at the anchornodes. The blind node will use AMReceiver to receive those packets. You should run collection only between blind node, any potential relay nodes and the base station. - 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] Routing
On Fri, May 9, 2008 at 8:20 AM, Maria Taramigkou [EMAIL PROTECTED] wrote: Hello!! I would like to ask how hard is to achieve routing using Oscilloscope.I mean, I need to use one mote as a gateway that receives data packets over the radio and transmits them over the serial port. Any kind of help is appreciated! Even though it seems too complicated thank you very much! If any of you has a simpler idea I would be grateful!! You should run Collection on the motes. The forwarding functionality is already built there. You set the base station as the root. Then all the data generated in the network will be forwarded to the root. Because the application you are looking for is the most common application, we even have an application that does exactly what you want - it is called MultihopOscilloscope. You can find it in the apps directory. - 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] Routing
On Fri, May 9, 2008 at 10:23 AM, Maria Taramigkou [EMAIL PROTECTED] wrote: I should have mentioned that I use tinyos-1.x under cygwin.The MultihopOscilloscope application does not exist in tinyos-1.x . You can look at Surge. - 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] packets received packets sent ?????
On Fri, May 9, 2008 at 12:40 PM, Nahr ... [EMAIL PROTECTED] wrote: Hi, thank you very much, so if I want to calculate the number of packet received by the root the best way is to calculate the number of packet acked? Is it correct??? It depends on what you are trying to measure. If you want to know the number of unique packets received, you need to get the origin sequence number. For an example, you can look at how apps/tests/TestNetwork extracts the sequence number in each packet. - 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] No Route !!!!!!!!!! I will be crazy
On Thu, May 8, 2008 at 9:05 AM, Nahr ... [EMAIL PROTECTED] wrote: Hi, I am using the native EasyCollection app. When I debug the messages of forward engine Always it shows me no route: why??? I lost my day to solve that but in vain. Please help me There might be some problem with your simulation setup - double check the TOSSIM tutorial to make sure your topology makes sense. - 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] About the performance evaluation of CTP
On Wed, May 7, 2008 at 5:00 AM, Xiaojun Zhu [EMAIL PROTECTED] wrote: Hi everyone, Has any work been done towards the performance evaluation of CTP in tinyos2.x?I failed to find one. I mean a comparative stduy of CTP vs. other protocols. We have compared CTP with MultiHopLQI. Please take a look at this paper: Rodrigo Fonseca, Omprakash Gnawali, Kyle Jamieson, Philip Levis, Four Bit Wireless Link Estimation, In Proceedings of the Sixth Workshop on Hot Topics in Networks (HotNets VI), November 2007 - 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] Protocols
On Wed, May 7, 2008 at 6:08 AM, [EMAIL PROTECTED] wrote: Recently I have started studying some protocols for tinyOS, and I wanted to test some, by installing them in the motes. However, I found some protocols codes only for the TinyOS1.x version, are there any TinyOS2.x protocol codes available for download? Furthermore, if any tutorial is available for the installation, or maybe even its usage, I would gladly accept it too ! :) hahah In TinyOS 2.x, there are two dissemination protocols, two collection protococls, and TYMO available for your use as of right now. You can look at the tutorials on this page: http://docs.tinyos.net/index.php/TinyOS_Tutorials - 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] Routing
On Wed, May 7, 2008 at 12:07 PM, Maria Taramigkou [EMAIL PROTECTED] wrote: Hello!! I would like to ask how hard is to achieve routing using Oscilloscope.I mean, I need to use one mote as a gateway that receives data packets over the radio and transmits them over the serial port. Any kind of help is appreciated! If you use tinyos-2.x/apps/MultihopOscilloscope, it does what you want to do. - 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] who sends ack
On Tue, May 6, 2008 at 11:20 AM, Nahr ... [EMAIL PROTECTED] wrote: Hi, I whould like to know please, who sends ack? The root of the tree or the parent of the node I mean the forwarding node? If you are talking about link layer acks, when a receiver receives a packet, it sends an ack to the transmitter. There is no notion of multi-hop acks at the link layer. CTP uses link layer acks. - 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] Problem about duplicate receiving
2008/5/5 laizhiquan [EMAIL PROTECTED]: hello, all, I'm simulating apps/tests/TestNetwork with Tossim under TinyOS 2.0.2. It's found that there are always duplicate receiving on the root node . Is it because of the mechanism of acknowledgment in the CTP? As I find that nodes often send, or forward, one packet for several times after no acked is reported each time. I imagine that, althought no acked is reported, sometimes the packet has send successfully and received by the root, and once retransmitting, duplicate happens. So, I suppose that there is something wrong with the acknowledgment mechanism. Is it ? And if it is, how can I improve it? If the ack gets lost, the sender retransmits because the sender does not know if the receiver received the packet. - 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] Collection: Loosing Connection to a Node
2008/4/28 Bulut ERSAVAS [EMAIL PROTECTED]: Also, when CTP is used, ETX values are quite large. Even for a single hop, it is about 265. You will notice ETX values as large as 700 with 3-hop routes. However, with no LPL it was usually less than 300 even for 6-hop routes. Can this be due to beacons/acks getting lost with LPL? The numbers are ETX*10 but they are still too big. For comparison, lets look at my logs: 00 ff ff 00 08 25 00 18 0a 0c 80 ff ff 00 00 00 0f 2d 00 16 16 00 02 13 00 09 30 00 1e 00 00 10 00 00 03 16 00 17 00 00 0a 19 00 1d 19 00 ff ff 00 10 25 00 18 0a 07 80 ff ff 00 00 00 1e 30 00 1d 00 00 0f 30 00 08 19 00 17 00 00 0a 19 00 18 19 00 11 19 00 1f 00 00 09 00 00 ff ff 00 09 25 00 18 0a 08 80 ff ff 00 00 00 08 44 00 02 00 00 10 16 00 03 30 00 0f 30 00 17 00 00 0a 19 00 18 19 00 11 00 00 16 00 00 ff ff 00 10 25 00 18 0a 16 00 00 71 00 13 00 1e 39 00 0b 30 00 0f 54 00 08 26 00 13 00 00 0a 25 00 18 13 00 11 75 00 1f 00 00 71 19 00 ff ff 00 06 25 00 18 0a 0a 00 00 71 00 16 00 05 2d 00 1e 16 00 04 16 00 71 30 00 1d 00 00 0b 13 00 0c 44 00 03 44 00 0f 00 00 09 2b 00 ff ff 00 09 25 00 18 0a 17 00 00 71 00 16 00 08 6b 00 71 30 00 10 0f 00 03 4a 00 0f 22 00 17 00 00 0a 24 00 18 13 00 0d 00 00 06 00 00 ff ff 00 10 25 00 18 0a 17 00 00 71 00 13 00 1e 33 00 0b 30 00 0f 54 00 08 26 00 13 00 00 0a 25 00 18 13 00 11 75 00 1d 00 00 71 19 00 ff ff 00 09 25 00 18 0a 18 00 00 71 00 17 00 08 79 00 71 44 00 10 0d 00 03 4a 00 0f 22 00 17 00 00 0a 24 00 18 13 00 0d 00 00 06 00 You notice that I am getting 0 ETX10 when the nodes do not have parents but when they do, ETX10 is not as large as yours. Because your network is sparse with perhaps fewer and worse best links, I would expect ETX10 to be larger but not as large as you are reporting. You can send the debug logs through the radio by wiring UARTDebugSenderP's UARTSend to an AMSender. - 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] LEEP and CTP Routing Frame
On Fri, May 2, 2008 at 9:03 AM, Nahr ... [EMAIL PROTECTED] wrote: Hi, I miss understand the difference between LEEP packet and CTP Routing frame. Also When each of them is sent? CTP Routing frame is sent as a payload of LEEP frame. So they are sent together in a single packet. - 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] [Tinyos-devel] AM ID guidelines for net2 protocols and other applications
On Tue, Apr 29, 2008 at 7:59 PM, Philip Levis [EMAIL PROTECTED] wrote: On Apr 29, 2008, at 7:41 PM, Matt Welsh wrote: This seems like an unnecessarily large swath of the AM address space for one small working group. It would be better to justify this in terms of your actual needs, rather than projected. How many AM IDs do the net2 protocols currently need and can we estimate the growth in the protocol space over the next few years based on past trends? The idea was that since net2 is technically responsible for protocols sitting on top of AM, it's the WG responsible for preventing confusion and collisions in the AM identifier space. So really, the way to see this is protocols in the TinyOS tree use this range. To answer Matt's question, right now we need about ten IDs. We might need five more next year. Do you foresee 0-127 being inadequate for applications and protocols not provided in the TinyOS distribution? One other issue is protocols in contrib - we can suggest that those also occupy a certain id range, perhaps a subset of the range reserved by net2. Although there will be no mechanism to patrol those contrib protocols to conflict each other, but at least the applications will know what range is safe for them. - 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] Q about tinyos-2.x
On Wed, Apr 30, 2008 at 1:47 AM, gaurav mathur [EMAIL PROTECTED] wrote: Hi, I am programming Tmote Sky using tinyos-2.x. I am using CTP interface. How can I find out sensor node ID of neighboring nodes. You will need to wire to the link estimator, the component that maintains a neighbor table. You can look at how the routing engine for an example of how to wire to the link estimator to learn about the nodes in the neighborhood. - 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] [Tinyos-devel] AM ID guidelines for net2 protocols and other applications
On Wed, Apr 30, 2008 at 10:51 AM, Vlado Handziski [EMAIL PROTECTED] wrote: On Wed, Apr 30, 2008 at 6:52 PM, Matt Welsh [EMAIL PROTECTED] wrote: I think we're on the same page here but there are some details to work out. Anything in tos could be assigned an AM ID range by the net2 WG. The question is how do things move from contrib, apps, etc. to tos? An example might be a new timesync protocol that someone develops and wants to be part of the official release (by which I mean, in tos). There needs to be a clear way for someone to (a) get their code in there and (b) get the AM IDs assigned for it. Being a member of the net2 WG is one way to do that, but I would hope there are other avenues that permit inclusion of third-party protocols as part of the standard tree. The current policy on this is that code should move into the core only via the TEP process. The TEPs are reviewed by the corresponding WGs, but anyone in the community is free to write a TEP and submit it for review. Right. And if the protocol wants to be a part of net2 protcols, we would like the contributor/maintainer to be a member of net2 because net2, as a group, will be responsible for supporting the protocol. Garbage collection will get triggered if net2 loses that official maintainer for that piece of software and can not find a new person to support the software. In summary, at least until now, net2's policy has been to put the TEP in the standards track and software in the release track only through membership in the group. For TEP, I can see the value of being more flexible with this policy because someone could submit a TEP with some nice observations about some protocols or best practices in network protocol which we would be happy to sponsor. Back to AM IDs - the various entities involved are: protocols that are distributed with the core, protocols with assigned AM IDs, protocols that are in contrib, applications and protocols in apps, and finally applications and protocols users want to write and test for their experiments and deployments. For the protocols that are distributed with the core (lib/net), it is clear that we want ID allocation and they MUST not conflict. The applications and protocols in apps directory distributed with the core, should probably also use allocated IDs. What to do with the protocols in contrib? Although we don't want to patrol, it would be good provide some guidelines for these protocols and applications too. For the user applications and protocols, it is clear that they should use the unassigned addresses. Can there be an official protocol with an assigned ID that is not a member of one of these four classes of applications and protocols? - 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] Q about CTP and AMSenderC
On Tue, Apr 29, 2008 at 3:38 AM, gaurav mathur [EMAIL PROTECTED] wrote: ... I have programmed a node such that it broad casts its node_id in every 2 seconds. This node uses interface AMSenderC to send the packets. I programmed other nodes to make a collection tree. These nodes uses Snoop interface of CollectionC . My problem is the nodes programmed with snoop interface of CollectionC does not over hear the packets sent by the node programmed with AMSenderC. CollectionC.Snoop is intended to snoop the CTP data packets. You probably want to use a different AM ID for your broadcast packet, use AMSnooperC to snoop those packets, and use CollectionSender to send those snooped packets using Collection. - 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] Q About MultiHopOscilloscope in tinyos-2.x
On Fri, Apr 25, 2008 at 9:30 AM, gaurav mathur [EMAIL PROTECTED] wrote: 1. I have installed MultiHopeOscilloscope with node id = 0, it means this node will act as root. 2. I attached root node with PC and run Listen application on PC. 3. Without anyother node with MultiHopeOscilloscope application my root is continuously sending some counter values. I cannot understand why it is sending some counter values. Please help me. Sounds like routing beacons. - 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] results+EasyCollection+Tossim+network configuration
On Fri, Apr 25, 2008 at 9:23 AM, Nahr ... [EMAIL PROTECTED] wrote: if I defined only one root in EasyCollection application and I used CTP or MultihopLQI as routing protocol. Is it safe to do that? especially it is known that CTP make a set of trees. It is fine have a single root. Also my third question is about the lesson building a network topology for Tossim: after writing the configuration file and using this command $ java LinkLayerModel configurationFileName there are 2 files as output my question is about this files how could I exploit them for simulation Please read the tossim tutorial on the website: http://docs.tinyos.net/index.php/TOSSIM - 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] Q About MultiHopOscilloscope in tinyos-2.x
On Fri, Apr 25, 2008 at 10:28 AM, gaurav mathur [EMAIL PROTECTED] wrote: Hi, Thanks for reply but it cannot be routing beacons becase LED (which indicates event message_t* Receive.receive(message_t* msg, void *payload, uint8_t len)) is not blinking. If you are so convinced that those are not routing beacons, you should find the AM type of the message being sent and look into the code to find out what is sending the message of that type. Please read this to find out how to determine the AM type of the message: http://docs.tinyos.net/index.php/Mote-PC_serial_communication_and_SerialForwarder - om_p ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] AM ID guidelines for net2 protocols and other applications
The TinyOS Networking Protocol Working Group (net2) would like to reserve AM ids whose first bit is 1 (128-255) to be used by Collection/Dissemination/TYMO and other net2 protocols. We recommend that the application developers use AM ids 0..127. If anyone has any problem with this proposal, please let me know by next Friday (May 2nd, 2008). - om_p ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
