As I told Jeremy, David Gay and Sam Madden built timesync using the hooks currently in place in the radio stack. The resolution of the timesync is on the order of the timer we use (in our case ~1-2ms). If you use higher resolution timers or the fast oscillator, then you'd have better resolution.
Overall, I think we should define an interface of hooks into the radio stacks and expose that. Services can then wire into the radio stack to perform to receive these async events. On the power management side, ServiceScheduler can manage when the high speed oscillator is on with knowledge of the timesync component so long as timesync isn't integrated into the radio code itself. This is why I think the hook model that is componentized and contains inlining is a much better solution than checking in changes to the core radio stack. -Joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lewis Girod Sent: Monday, July 14, 2003 1:56 PM To: Joe Polastre Cc: [EMAIL PROTECTED]; 'Jeremy Elson' Subject: Re: [Tinyos-users] Can radio stack changes be checked in? Hi Joe, > We did have the support in the CC1000 radio stack and took it out > because it did not play nicely with Power Management > (HPLPowerManagement). The problem is that if the timestamping uses the > 4/7MHz oscillator, then the node can never be powered down in low duty > cycle operations (aka the oscillator can never be turned off and the cpu > run off the 32khz oscillator). i agree that for duty cycling the fast clock will need to be disabled. but this may not be a problem if there are hooks for applications to become aware that the fast clock was disabled. for example, from the perspective of the time synch software, shutting down the processor just means that it will need to re-sync before it can achieve high precision again; so it should throw away any cached relations to other node and start re-syncing (if and when an application needs sync again) for applications that don't care so much about precision, the fast clock counter can be bumped forward (approximately) based on how long the sleep was. > Changing from 16 to 32 bits in the internal TOSMsg format doesn't seem > to be a problem. I think we need to have a more elaborate conversation > about the side effects of having timestamping as a default feature in > the radio stack. Adding hooks for it isn't a problem (there already are > signaled events for being notified when the beginning of the packet is > being sent and when it is being received). More analysis of how it > affects Timers, HPLPowerManagement, and use of the oscillators is needed > imho. yes, there is a larger question here about how best to present a consistent view of time on the node. the time synch service we envision does not assume a single consistent time-base, but rather a series of piecewise-consistent time bases, which may be related to each other if need be -- but are not forced into a global relation. this structure fits well with the idea of duty cycling and multiple oscillators in use at different times. -lew > -Joe > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Jeremy Elson > Sent: Monday, July 14, 2003 12:58 PM > To: [EMAIL PROTECTED] > Subject: [Tinyos-users] Can radio stack changes be checked in? > > > Hello, > > At UCLA a number of us have been working on high-precision time > synchronization. We've been keeping our changes in our own repository > for a long time (e.g. since tinyos 0.43) but historically it's been > very difficult for us to track the newer TinyOS code as it is > released. So, if possible, we'd like to check a lot of this code into > sourceforge. The problem is that it makes (small) changes to the > radio stack, and we're not sure if these kind of checkins are > "allowed". > > Specifically, we'd like to put packet reception timestamping back into > the stack at interrupt-time. We shoot for microsecond resolution, so > would like to get the timestamps using the TimerHeap component - which > constructs a virtual 32-bit timer with both high precision and long > range (i.e. by combining one of the on-chip counters with a software > accumulator to track how many times it has wrapped). The problem is > that doing so adds a TimerHeap dependency to the basic comm stack. > > We'd also like to change the timestamp field of TOS_Msg from 16 to 32 > bits, but this changes the packet format. (Just the internally used > format, though, hopefully not the over-the-air format.) > > Cheers, > UCLA Tinyos Folks > _______________________________________________ > Tinyos-users mailing list > [EMAIL PROTECTED] > http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-users > > _______________________________________________ > Tinyos-users mailing list > [EMAIL PROTECTED] > http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-users _______________________________________________ Tinyos-users mailing list [EMAIL PROTECTED] http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-users _______________________________________________ Tinyos-users mailing list [EMAIL PROTECTED] http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-users
