On Mon, Nov 22, 2010 at 8:47 PM, Aitor Hernandez <[email protected]> wrote: > > Hi, > @Jan: thanks for the update! I haven't tested yet, but I am sure that it > will be better.
It is better, but it seems that sometimes there are still problems - I will take another look. Jan > @Pablo: One solution could be replace all the dbg_serial() for dbg() and > then they won't be shown on the serial port. But it is not nice :P If you > find another way please let us know. > For the energy consumption, the best way is to measure the current of the > mote (I've seen one paper which talks about that, but I don't have the > reference at the moment). We have measured it and we realized that the mote, > during the Inactive period does not go to the LPM3 mode because the radio is > still on during this time. For this reason we have a modification of the > implementation in order to turn off the radio during the inactive period. > We are planning to publish the GTS implementation and the energy improvement > within one week. > Best regards, > Aitor > On 22 November 2010 18:50, Pablo Marcos <[email protected]> > wrote: >> >> Hi, >> About the TKN154_DEBUG mode, I couldn't get the coordinator compiled >> correctly because of the lack of memory in some tests. I someone faces the >> same problem, should try the -Os option to optimize the code and add as well >> these few lines to disable in the coordinator some functionalities: >> CFLAGS += -I$(shell pwd)/.. \ >> -DIEEE154_SCAN_DISABLED \ >> -DIEEE154_BEACON_SYNC_DISABLED \ >> -DIEEE154_PROMISCUOUS_MODE_DISABLED \ >> This way, there is no error compiling in debug mode. Anyway, does anyone >> know how to print using the dbg_serial the TKN has implemented without >> having the default printfs the TKN is showing? And what about how to know >> how much energy the CC2420 is consuming? It has to be some way to measure >> how much time the radio is in each mode, and using the datasheet, know how >> much energ is consuming. >> Thanks in advance. >> Regards, >> Pablo >> 2010/11/19 Aitor Hernandez <[email protected]> >>> >>> Hi, >>> I've tried your app, and it is working with 6 motes + coordinator during >>> ~15min. I don't understand which could be the problem in your case. You >>> could try to change the mote that plays the coordinator role. If your motes >>> are old, it could be a problem. >>> A temporaly solution, coudl be start the MLME_SCAN (startApp();) again >>> after the MLME_SYNC_LOSS but it is not a good idea, because then you won't >>> see this kind of problems. >>> I want to remark what you said about the printf and debug. The printf >>> introduces a lot of delay, around 9x{backoff period}, but if is possible to >>> use TKN154_4, the dbg_serial takes around one backoff period (20 symbols). >>> Hence, it is really important to disable them if they are not completely >>> necessary. These values are approximations :P >>> Best regards, >>> Aitor >>> >>> On 18 November 2010 22:48, 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 >>>> >>> >>> >>> >>> -- >>> 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
