Hi all, Thanks for help! But i have one more question, in tinyOs CAP, CFP and GTS are implement? if are, how can i use?
Thanks, Best regards. On Thu, Nov 18, 2010 at 7:48 PM, Pablo Marcos Oltra < [email protected]> wrote: > Hi, > > Thank you very much for your response Aitor. I had two motes running for 3 > days with BO=14 and I had no problems of sync using the TestSync > application. Not even one beacon was missed. This was the first test I ran > to check if I was about to have clock drift problems in later experiments. > I'm currently using channels 19 and 20 because in my building there are just > a few spare channels to use (20 are mainly being used right now). Besides, > I always set up BO and SO < 7, using usually 5, but not even that way works > properly. > > Anyway, I don't really know if it has something to do with using timers, > but I have noticed that the losing of the sync is kind of periodically. I > have noticed today as well that both devices lose sync even if they don't > even start at the same time (I was hoping a different periodicity for each > one), but they both were losing the same beacons. Hence, I'm thinking right > now about the possibility that it has something to do with the coordinator, > cause the other two devices are not even tx packets, just trying to me sync > with the coordinator. > > I sent another mail a few days ago to the tinyos-help list cause I thought > that maybe the problems were cause because I was using printf to debug the > application, but without using it is losing sync as well, so... now I'm the > one that is lost :S. > > Could you please check if the application attached is working for you? It > is just the original TestData but with a Timer that once is fired sends the > packets. When I try that, the device loses sync after a while. > > Thank you very much in advance. > > Regards, > Pablo > > 2010/11/18 Aitor Hernandez <[email protected]> > >> Hi, >> >> We have been using this implementation for several wireless process and we >> made a performance evaluation of it. We haven't found any problem with the >> timers (used to start a transmission, or something else). The idea that >> comes up is that maybe there are some interferences on the same channel that >> you are using or you have a high beacon order. >> >> As we have seen, if we receive packets on the period where we are waiting >> the beacon, we could miss them. Moreover I've just realized that by using a >> high beacon order (> 10) some motes could have problems to synchronize with >> the beacon. I guess that I could be due to the clock drift, but Jan can >> clarify this point. >> >> What I recommend you, is to use a BO=6 and a SO =5,6 with this values you >> shouldn't have any problems.... Furthermore, try to change the channel and >> see if the problem persists. Channels between 22 and 26 don't have any >> overlapping with WiFi channels. >> >> At the moment, there is nothing else in my mind. I hope it will work for >> you. >> >> Good luck! >> >> >> On 18 November 2010 16:27, Pablo Marcos Oltra < >> [email protected]> wrote: >> >>> I found the error and the UserButton is now working in my test >>> application. So, I wait for 3 nodes to have synchronization and then I push >>> all of their buttons and they start tx data. However, after a while, they >>> lose sync, as always, and I don't know why. >>> >>> Aitor, have you ever used timers that once they're fired they send the >>> data (for example, to send data every minute or so)? Cause I'm having >>> trouble with that (even with just one device), and don't if that could be >>> something related with the problem you told us a few mails ago. >>> >>> Regards, >>> Pablo >>> >>> 2010/11/18 Aitor Hernandez <[email protected]> >>> >>> In my case, I just program all the motes at the same time by using "&" >>>> function on the shell, something like: >>>> >>>> $ make tmote >>>> $ make tmote reinstall,1 bsl,/dev/ttyUSB1 & make tmote >>>> reinstall,2 bsl,/dev/ttyUSB2 >>>> >>>> By the way, I've been using the UserButton for some time, and I've never >>>> noticed the behaviour you explain, with or without TKN154_DEBUG enabled. >>>> >>>> Best, >>>> >>>> Aitor >>>> >>>> >>>> On 18 November 2010 13:28, Pablo Marcos Oltra < >>>> [email protected]> wrote: >>>> >>>>> May I add other option to the Aitor ones? >>>>> >>>>> I thought about letting the motes synchronize first, and then start >>>>> sending packets once they're all synchronized. How could you do this? I >>>>> have >>>>> tried doing that with the telosb user button, hence once you pressed it >>>>> you >>>>> change a flag that starts sending packets. The problem is that I have just >>>>> been able to do that with the TKN154_DEBUG enabled, otherwise, the event >>>>> void Notify.notify( button_state_t state ) is not working. >>>>> >>>>> You can see an example of how to use the telosb user button in >>>>> $TOSROOT/apps/tests/telosb. >>>>> >>>>> Regards, >>>>> Pablo >>>>> >>>>> 2010/11/18 Jan Hauer <[email protected]> >>>>> >>>>> yes - I can reproduce the problem and also believe that it is due to >>>>>> wrong (beacon) timestamps. will look into it and try to fix it asap. >>>>>> >>>>>> thanks, >>>>>> jan >>>>>> >>>>>> On Thu, Nov 18, 2010 at 10:02 AM, Aitor Hernandez <[email protected]> >>>>>> wrote: >>>>>> > Hi guys, >>>>>> > I've seen this problem with TKN15.4. It is possible to synchronize N >>>>>> nodes >>>>>> > with TKN15.4 the problem is that they need to start the app at the >>>>>> same >>>>>> > time. From my experience I've realized that the problem comes from >>>>>> the >>>>>> > cc2420_tkn154 (maybe it happens with the default cc2420 >>>>>> implementation as >>>>>> > well). >>>>>> > If we have a network with N nodes running and transmitting data >>>>>> between >>>>>> > them, when we try to add another node we could have this problem. As >>>>>> far as >>>>>> > we have the radio enabled for reception for a long period (Scan >>>>>> period), the >>>>>> > cc2420 receives the beacons but data packets as well. Once it >>>>>> detects that >>>>>> > the received packet is a beacon, it sets the timestamp, but >>>>>> sometimes the >>>>>> > timestamp is wrong, due to the data packets, and then we lost the >>>>>> next >>>>>> > beacons. >>>>>> > Possible solutions: >>>>>> > >>>>>> > Check the CC2420ReceiveP.nc and the m_timestamp_queue. I guess that >>>>>> the >>>>>> > problem should be there. I did some modifications on >>>>>> > the CC2420ReceiveP.nc to solve this problem, but I haven't test it >>>>>> properly. >>>>>> > If we lost the synchronization, scan again with MLME_SCAN.request(). >>>>>> It is a >>>>>> > "fake" solution, because the problem is still there, but for some >>>>>> app it >>>>>> > will work. >>>>>> > Start the nodes at the same time. It is not possible in a real >>>>>> deployment. >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > Aitor Hernandez >>>>>> > KTH | Automatic Control >>>>>> > Research engineer >>>>>> > Stockholm >>>>>> > Phone: +46 (0)704 26 87 99 >>>>>> > >>>>>> > _______________________________________________ >>>>>> > Tinyos-help mailing list >>>>>> > [email protected] >>>>>> > >>>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>>>> > >>>>>> >>>>>> _______________________________________________ >>>>>> Tinyos-help mailing list >>>>>> [email protected] >>>>>> >>>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Aitor Hernandez >>>> KTH | Automatic Control >>>> Research engineer >>>> Stockholm >>>> Phone: +46 (0)704 26 87 99 >>>> >>>> >>> >> >> >> -- >> Aitor Hernandez >> KTH | Automatic Control >> Research engineer >> Stockholm >> Phone: +46 (0)704 26 87 99 >> >> > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
