Hi all, Has anyone been able to reproduce the same sync problem I had with timers and the tkn154? Thanks in advance.
Regards, Pablo 2010/11/15 Pablo Marcos Oltra <[email protected]> > 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
