Generating Accurate Timestamps While Capturing Sensor Data

I'm working on a project with an MSP430 that serves to capture sensor data 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.

So the question: What would be the best way to generate an accurate timestamp 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?

-Luther

Luther Blackwood wrote:
> I'm working on a project with an MSP430 that serves to capture sensor
> data 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.
>
> So the question: What would be the best way to generate an accurate
> timestamp 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?
>
> -Luther
>

http://www.ti.com/lit/an/slaa076a/slaa076a.pdf
The incremental timer may be easier than
what they are calling a realtime clock.


-- 
Les Cargill

Hi, Luther.

On Sat, 2 Feb 2013 10:21:37 -0800 (PST), Luther Blackwood <lutherblackwood@gmail.com> wrote:
> I'm working on a project with an MSP430 that serves to capture
> sensor data 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.
>
> So the question: What would be the best way to generate an accurate
> timestamp 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?
>
> -Luther

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.

  http://www.mouser.com/ds/2/302/PCF8523-116343.pdf

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
-- 
Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney aatt mindspring ddoott com

On Sunday, February 3, 2013 7:21:37 AM UTC+13, Luther Blackwood wrote:

> 
> So the question: What would be the best way to generate an accurate timestamp 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?
> 

Some ADC's can fire on a timer, or if you have something else firing the ADCs 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-stamp.
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 @ capture instant. With streaming data, this is usually easy to catch and patch, as it is on isolated samples with predictable values.

On Sat, 02 Feb 2013 10:21:37 -0800, Luther Blackwood wrote:

> I'm working on a project with an MSP430 that serves to capture sensor
> data 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.
> 
> So the question: What would be the best way to generate an accurate
> timestamp 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?

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

On Sat, 2 Feb 2013 10:21:37 -0800 (PST), Luther Blackwood
<lutherblackwood@gmail.com> wrote:

>I'm working on a project with an MSP430 that serves to capture sensor data from an external ADC. 
>Capturing the raw data stream is relatively easy. 

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) ?

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

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.

On 2013-02-02 19:21, Luther Blackwood wrote:
> I'm working on a project with an MSP430 that serves to capture sensor data 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.
>
> So the question: What would be the best way to generate an accurate timestamp 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?
>
> -Luther
>

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

On Sunday, February 3, 2013 2:27:03 AM UTC-5, upsid...@downunder.com wrote:
> On Sat, 2 Feb 2013 10:21:37 -0800 (PST), Luther Blackwood
> 
> <lutherblackwood@gmail.com> wrote:
> 
> 
> 
> >I'm working on a project with an MSP430 that serves to capture sensor data from an external ADC. 
> 
> >Capturing the raw data stream is relatively easy. 
> 
> 
> 
> 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) ?
> 
> 
> 
> >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.
> 
> 
> 
> 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.

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!