I have been running some more tests during the day and I have noticed that with just one timer that runs the packetSendTask with a periodicity of 250ms, makes the SYNC go away.
Regards, Pablo 2010/11/15 Pablo Marcos Oltra <[email protected]> > Thank you very much for the answer Jan. > > I did try my application commenting every printf, but even that way I had > sync problems. Anyway, I changed the aMaxLostBeacons parameter from 4 to 1, > so that if just one beacon is lost it will consider MLME_SYNC_LOSS. I have > managed to reproduce the problem with the TestData example of the tkn154 > folder. > > Please find attached a .zip with the changed files inside. > > The sync problem is probably because of the Timers as well, cause there are > no printf's in this code. I have set up a timer that is fired periodically > each 50ms to send a packet (I know that periodicity sending data is not even > real, but anyway, it should work) and another one that does nothing (just > because I wanted to reproduce the same amount of timers that I have in my > own application, one for sending packets and the other one for measuring > time). Besides, once the device loses synchronization, it turns off all the > leds. Afther a while that should happen (I have tried that a few times in > TelosB motes). > > Maybe that is happening cause I'm doing something wrong, but I don't know > what. Let's see if we can find a solution to this. > > Regards, > Pablo > > 2010/11/13 Jan Hauer <[email protected]> > > It is not unlikely that the printf debugging causes timing problems, >> because it involves low-level (interrupt) functions that can reduce >> the responsiveness of e.g. the timer subsystem. Why not test your >> application without printf and see if it works then (toggle LEDs or >> use a sniffer to see what's happening on the channel)? If you think >> there is an issue in tkn154 then please try to reproduce it based on >> one of the example apps/tests/tkn154/beacon-enabled apps, preferably >> with minimal changes. >> >> Jan >> >> >> On Fri, Nov 12, 2010 at 10:56 PM, Pablo Marcos Oltra >> <[email protected]> wrote: >> > Hi all, >> > I have been trying to program an application with the TKN154 MAC >> > implementation, intending to associate a device with the coordinator and >> > send packets periodically. It does work, but not very well, cause the >> device >> > misses some beacons periodically as well (I think that is because it >> tries >> > to send something while it should be in rx mode). I have notice that >> after >> > commenting some printf's the time at which the device loses sync is >> > different (altough periodically). >> > So, I thought that maybe it could have something related with the >> printf's, >> > and that these could made that the TKN154 implementation doesn't work as >> it >> > would. I have read that I should just use the printfflush() in non-time >> > critical operations, but even with no printf's my device is losing >> > synchronization with the coordinator (but not so often). >> > Hence, I would like to ask: has anyone experienced sync problems using >> the >> > printf function in time critical areas or know why I could have these >> > problems? How could I solve that? Is there another way to debug the >> > application without running a simulation with TOSSIM? >> > Thank you ver much in advance. >> > Regards, >> > Pablo >> > _______________________________________________ >> > 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
