On 05/18/2011 02:59 PM, Jamey Sharp wrote:
That's actually an open question. We haven't decided yet how to handle
timestamping. Since we have the sensors scattered across several
microcontrollers, maintaining a common timebase is kind of a pain. We've
considered some possibilities though:
1. As long as all the sensors are attached using USB, the host will
broadcast a start-of-frame packet to them all once per millisecond.
We can use that as a semi-precise common time source.
2. If we have a working GPS receiver: many receivers can produce a 1MHz
clock pulse that's synchronized to GPS time. Andrew has talked about
routing that signal to all the sensor nodes as a high-precision,
high-accuracy common time source.
3. I think Theo had found an NTP-like protocol we could use in this
setting, but I don't remember the details.
I assume you're asking because both Kalman and Bayesian Particle Filters
need to know how far forward to run the physics/dynamics model before
checking a new sensor measurement?
(I'm sending this to the psas-team list because it should get discussed
with the rest of the team. You might want to subscribe to that list:
I have a similar problem with the product I'm developing
(<http://geostuff.com/AnySeisdatasheet.pdf>). Each station on the bus
has an (relatively slow, 4KHz max) ADC, and all of them need to sample
at the same time in order for the sum dataset to be worth anything.
I have my (RS-485-ish) bus set up so that a particular edge of the
preamble is always used to capture the local MCU clock. The master
sends a dummy packet, then another with the clock capture from the
previous packet. All the stations use the difference between their
local captured clocks for the last two packets, as well as the master's,
to drive a PID feedback.
The feedback goes to a DAC channel that feeds the Pletronics FD77T
combo's Vctrl input, which pulls or pushes the crystal away from its
nominal speed by just a little bit. The FD77T simultaneously drives the
ADC through a straight divider (for lower jitter), and the MCU via a PLL.
The PID loop still needs a bunch of tuning, but right now I generally
see the per-period (~10Hz sync rate) drift hover about +- 0.5 cycles,
where the MCUs are running at 32MHz. It maintains this indefinitely,
except for some exceptional case I haven't tracked down yet.
As I scale this up, I need the master nodes to be in an Ethernet
cascade, and it turns out IEEE 1588 is basically the "uber-NTP" protocol
there, which ends up doing *exactly* the same thing as my bus. There's
a particular edge of the 100Base-TX frame preamble that's captured off
the internal 100MHz timer, and a sequence of packets back and forth sync
up the two clocks.
In your case, because you *can* route more wires between the nodes, I'd
be really tempted to go with door #2, running a medium-speed reference
clock throughout. It's got to be fast enough to get the timestamp
resolution you want, but slow enough that the microcontrollers involved
can capture and count off it after sampling it through their own I/O clock.
If the MCU's all have built-in PLLs, you can run them directly off this
reference, and your problem is solved outright. (With the exception of
denoting "zero time")
psas-team mailing list
This list's membership is automatically generated from the memberships of the
psas-airframe, psas-avionics, and psas-general mail lists. Visit
http://lists.psas.pdx.edu to individually subscribe/unsubscribe yourself from