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 <pablo.marcos.ol...@gmail.com>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 <aito...@kth.se> > > 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 < >> pablo.marcos.ol...@gmail.com> 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 <ha...@tkn.tu-berlin.de> >>> >>> 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 <aito...@kth.se> >>>> 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 >>>> > 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 >>>> >>> >>> >> >> >> -- >> 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 Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
