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:
http://lists.psas.pdx.edu/mailman/listinfo/psas-team)

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 (<http://pletronics.com/files/index.php/fd77t%20series.pdf>) crystal/PLL 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
psas-team@lists.psas.pdx.edu
http://lists.psas.pdx.edu/mailman/listinfo/psas-team

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 
these lists.

Reply via email to