> 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.
the precision of the oscillator is not the only limitation; you also need to know the phase of the start symbol. (that is, which bit of a cc1000 byte the start symbol starts on, so you can adjust the timestamp of the cc1000 incoming byte interrupt). this was the nature of the changes to the stack. > 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. i don't think we are in disagreement here. the point was to extend the interface to factor in this additional piece of information. there are two possible solutions to that problem: extending the interface to add the phase in addition to the counter value, or integrating somewhat with the counter component so that the radio stack can just output the (phase-corrected) counter value. it seemed more sensible to integrate it with the counter component, because that seems like a less hardware-specific interface to provide, given that the existence of this phase offset is very specific to the cc1000 radio. > 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. perhaps the original message was confusing.. we never intended to integrate timesynch into the core radio stack. the only changes to the radio stack are to achieve a more precise timestamp, in the event that the high speed counter is running, which seems to suggest some integration between the radio and the counter. the details of timesync, computing conversions, control traffic to other nodes, providing an API for other applications, etc. is all very much at the application layer. -lew > -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 _______________________________________________ Tinyos-users mailing list [EMAIL PROTECTED] http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-users
