Generating Accurate Timestamps While Capturing Sensor Data

The incremental timer may be easier than what they are calling a realtime clock.

--
Les Cargill

You've specified that you need to obtain the timestamp in under

4000usec (64000 clocks if the MSP430 is running at 16MHz), but you haven't mentioned any partcount, space, or power restrictions.

One approach would be to use an RTC chip, such as the NXP PCF8523, assuming you could code an I2C routine to fetch the current time value in under 4000usec, and without disturbing your data-gathering. You can also set the PCF8523 up to generate periodic interrupts.

The PCF8523 oscillator is tweakable if you need to fine-adjust things, and supports 1MHz I2C.

Mouser Q1 @ $0.92, Q2500 @ $0.678

Enjoy...

Frank McKenney

--
  No man can be judged except against the background of his own 
  time.  The standards of yesterday are not the standards of today, 
  and the circumstances of daily life were vastly different.  Before 
  one attempts to render judgement, one should consider the world in 
  which the man existed, and the customs of the time and place. 
                -- Louis L'Amour / The Sackett Companion

tamp for each data point while keeping a low overhead? Is the only solution to have an incremental timer firing faster than I need to sample my sensor s?

Some ADC's can fire on a timer, or if you have something else firing the AD Cs you can always use a capture timer from the ADC Done point. Even if that means toggle of a pin, to capture in HW.

Then the next question is if you need to capture 16/24/32 bits of time-stam p. With the simplest Sw extended timers, there is a low but finite chance of a capture aperture effect, where the HW and SW portions are not in phase @ c apture instant. With streaming data, this is usually easy to catch and patc h, as it is on isolated samples with predictable values.

My first choice in this circumstance would be to make the processor responsible for commanding the ADC start of conversion through a hardware timer.

Second choice would be to insure that the ADC SOC pulse is on a good reliable clock, and just use the ADC as the "timer". That works quite well unless you've got more than one ADC in the system and they aren't synchronized.

Third choice would be a hardware timer on the MPS430 capturing the time of the ADC start of conversion pulse.

A distant fourth choice would be a hardware timer in the MPS430, and capturing the time that the ADC ISR fires off. That's going to pretty much guarantee you way more clock jitter than the first three, and that clock jitter is going to be subject to how the software is written -- if you've got large swaths of code where interrupts are turned off, or multiple interrupts going on at once, then your jitter is going to go through the roof.

--
Tim Wescott 
Control system and signal processing consulting 
www.wescottdesign.com

an external ADC.

So you apparently have a multiplexor sampling several channels feeding a common ADC ? How is this mux controlled ?

Some external hardware ? A program instruction in a normal program ? Some timer interrupt (directly or by some SampleRequest flag to the main program) ?

point was received so that I can generate accurate graphs when this data is pulled from the device.

Is this analog bandwidth or sample rate required ? If sample rate, one multiplexor channel is sampled every 4 ms, the other channels less frequently. If you are controlling the multiplexor, you should not have to worry about sequence of event issues.

For more accurate timing, you would need some timer interrupt, say at every 1 ms. This would increment a 32 bit counter in your program that can then be used to time stamp the multiplexor channel switching. In addition, it could set Sample250Hz flag every 4th interrupt and Sample100Hz every 10th interrupt etc. and let the main program do the actual multiplexor control and conversion.

If the ADC and multiplexor is free running and the ADC has proper S&H, the best timing position would be the mux change or StartOfConversion signal, not the EndOfConversion signal, especially if the conversion time depends of the data value.

If the clock interrupt period is longer than the shortest sampling interval, two or more sampling event would occur between clock interrupts and hence receive the same time stamp. If this occurs, use a simple SequenceOfEvent list to maintain the order of these events and since the conversion takes some minimum time, it is known what is earliest time within interrupt period that each event occurred. It might be better to use average time for calculations, but this could overflow the clock interrupt period, if all conversions ended earlier than expected.

from an external ADC.

Capturing the raw data stream is relatively easy. My stumbling block is in finding a way

to properly correlate when each data point was received so that I can generate accurate graphs

when this data is pulled from the device. One of my sensors is an EKG which would require at least 250 Hz.

for each data point

while keeping a low overhead? Is the only solution to have an incremental timer firing faster than I need to sample my sensors?

Unless you are locked into the MSP430, you may want to consider to use a controller with an event system, like the AVR XMEGA parts. Then, you can set it up to generate an event on ADC ready, and the DMA controller will read the ADC,and another the timer which captured the event. Gives you a timer resolution of ~30 ns. There are other parts with an event system as well, but the XMEGA is the first, I could think of.

BR Ulf Samuelsson

from an external ADC.

point was received so that I can generate accurate graphs when this data is pulled from the device.

I have a multichannel ADC that that samples a channel based on serial command from the MCU.

Your suggestion of having a timer increment a counter and set sampling flags is mostly in line with what I was thinking before my initial post. I just wanted to make sure I'm not crazy, because I'm pretty new to embedded development.

Thank you!