Thread Subject: Serial Accelerometer

Hi,

I'm having a tough time with this serial port. I've surfed the forums for a while now and can't get anything working.

I'm trying to have a serial accelerometer work with MATLAB. Wrote some m-file code that would do this and it almost worked. The accelerometer data was being plotted decently; taking the area underneath the curve gave velocity and integrating it further gave the distance...which is our final goal..getting the distance moved. We got this to work with real-time data. As the accelerometer was moving, data was being plotted. The velocity was being done by the 'trapz' function. Not good enough data though, the velocity wasn't being plotted properly.

So now we're trying to use Simulink to solve this problem and hopefully get it to work in real time a bit better. Question is, where do I begin?
How can I get Simulink to read data from the serial port (accelerometer) and plot the data in real time?

Any help would be appreciated :)

Anubhav Khanna wrote:
> Hi,
>
> I'm having a tough time with this serial port. I've surfed the forums
> for a while now and can't get anything working.
>
> I'm trying to have a serial accelerometer work with MATLAB. Wrote
> some m-file code that would do this and it almost worked. The
> accelerometer data was being plotted decently; taking the area
> underneath the curve gave velocity and integrating it further gave
> the distance...which is our final goal..getting the distance moved.
> We got this to work with real-time data. As the accelerometer was
> moving, data was being plotted. The velocity was being done by the
> 'trapz' function. Not good enough data though, the velocity wasn't
> being plotted properly.
>
> So now we're trying to use Simulink to solve this problem and
> hopefully get it to work in real time a bit better. Question is,
> where do I begin? How can I get Simulink to read data from the serial
> port (accelerometer) and plot the data in real time?
>
> Any help would be appreciated :)

What, specifically wasn't "good enough data" and why do you think
switching to Simulink would be the solution?

If the acceleration data are being collected and displayed correctly,
then a problem w/ velocity would seem to be more related to the sampling
rate and the trapezoidal assumption in integration and that won't change
with computing platform.

Of course, integration and double-integration of an accelerometer is
reknown for difficulties as any DC bias in the input is amplified for
starters.

--

Hi,

Apparently I thought the forums would send me an email when there was a new reply to the post. Anyways....

By good enough data, I mean that the acceleration and deceleration don't necessarily match in area covered over the time axis. Don't know if something is wrong with the timing or what. We're using a Sparkfun Accelerometer (http://www.sparkfun.com/datasheets/Accelerometers/SerAccel-v5.pdf). I thought maybe our m-file was a bit off, so Simulink would have a better solution to this, i.e. built-in code that could read in the data. I don't know much about it.

The accelerometer is using a serial interface. So we thought using fscan and all those commands we can get the data in. (I have the detailed code with me obviously). The problem lies with the timing information I believe. Do I use tic/toc? or something else?

Pretty much this close to giving up on this project.

Thanks.


dpb <none@non.net> wrote in message <hbkh97$rpc$1@news.eternal-september.org>...
> Anubhav Khanna wrote:
> > Hi,
> >
> > I'm having a tough time with this serial port. I've surfed the forums
> > for a while now and can't get anything working.
> >
> > I'm trying to have a serial accelerometer work with MATLAB. Wrote
> > some m-file code that would do this and it almost worked. The
> > accelerometer data was being plotted decently; taking the area
> > underneath the curve gave velocity and integrating it further gave
> > the distance...which is our final goal..getting the distance moved.
> > We got this to work with real-time data. As the accelerometer was
> > moving, data was being plotted. The velocity was being done by the
> > 'trapz' function. Not good enough data though, the velocity wasn't
> > being plotted properly.
> >
> > So now we're trying to use Simulink to solve this problem and
> > hopefully get it to work in real time a bit better. Question is,
> > where do I begin? How can I get Simulink to read data from the serial
> > port (accelerometer) and plot the data in real time?
> >
> > Any help would be appreciated :)
>
> What, specifically wasn't "good enough data" and why do you think
> switching to Simulink would be the solution?
>
> If the acceleration data are being collected and displayed correctly,
> then a problem w/ velocity would seem to be more related to the sampling
> rate and the trapezoidal assumption in integration and that won't change
> with computing platform.
>
> Of course, integration and double-integration of an accelerometer is
> reknown for difficulties as any DC bias in the input is amplified for
> starters.
>
> --

Anubhav Khanna wrote:
...
> By good enough data, I mean that the acceleration and deceleration
> don't necessarily match in area covered over the time axis. Don't
> know if something is wrong with the timing or what. We're using a
> Sparkfun Accelerometer
> (http://www.sparkfun.com/datasheets/Accelerometers/SerAccel-v5.pdf).
> I thought maybe our m-file was a bit off, so Simulink would have a better
> solution to this, i.e. built-in code that could read in the data. I
> don't know much about it.
>
> The accelerometer is using a serial interface. So we thought using
> fscan and all those commands we can get the data in. (I have the
> detailed code with me obviously). The problem lies with the timing
> information I believe. Do I use tic/toc? or something else?
...
...Please don't top post--makes conversation following hard...

I don't know the particular device and w/ my dialup their pdf files took
too long to look at to get any real details, sorry...

All the serial devices I've used had enough onboard intelligence to do
the sampling interval control internally and all one did was upload the
resulting timeseries data. If that isn't the case w/ this device I'd
say the chances of controlling sampling close enough to do what you're
trying are nil--it's difficult enough w/ just the signal conditioning alone.

I don't know Simulink at all as to whether it has any better realtime
control or not if that is indeed the issue; you might try again either
TMW technical support or another thread asking that specific question
re: Simulink itself.

Oh, last note--while typing this the pdf document did display--I see it
is simply a baud-rate-limited device. Trying to use it for time series
analyses would be essentially impossible w/o an external timer to be
sampled and even then you'd be guessing when the actual S/H amp was
triggered internally and the conversion finished for precise timing.

I think you'll probably need a different device for that type of
analysis unless the sample rate can be quite slow so the timing
uncertainty can be much reduced--as I gather from your present problems
isn't suitable for the input trying to be measured.

This device seems suitable only for monitoring magnitudes and general
information, not applications relying on sampled time series analyses.

Don't think it's ML's fault... :) (ie, you'd have similar problem if
wrote the app in C/C++ altho again depending on the actual data you
_might_ be able to get the interface overhead down to nearly enough a
fixed timing as to make it workable, but it would be pretty dicey
probably, still).

hth...

--

dpb wrote:
...
> Don't think it's ML's fault... :) (ie, you'd have similar problem if
> wrote the app in C/C++ altho again depending on the actual data you
> _might_ be able to get the interface overhead down to nearly enough a
> fixed timing as to make it workable, but it would be pretty dicey
> probably, still).

Actually, a thought...what sort of sampling rate do you require? What
if you wrote an interrupt-driven poller that strobed the device--would
that be "fast enough"? It _might_ reduce the jitter. Of course, it
would still have the vagaries of any OS scheduling and other stuff so
would have to run it as a higher-priority task or take other steps to
not disturb it during data collection.

All in all, I'd probably look at a more traditional solution of a
simultaneous S&H data acq card w/ a separate triaxial accelerometer.
That would solve the jitter leaving you then w/ the other issues of
signal conditioning, etc., that are still non-trivial to integrate
acceleration to zero displacement over a transient (if I follow the
application).

--

Hi..i dont have a solution to your problem but even we are implementing a similar project and we are facing difficulty in working with real time...could you help us out with that?

Hii i saw ur post,i am trying to do the same.I want to plot accelerometer data continuously in matlab and later i want to perform fft on it.But i dont know how to plot the data in real time.can you please share the work u have done.



dpb <none@non.net> wrote in message <hbkh97$rpc$1@news.eternal-september.org>...
> Anubhav Khanna wrote:
> > Hi,
> >
> > I'm having a tough time with this serial port. I've surfed the forums
> > for a while now and can't get anything working.
> >
> > I'm trying to have a serial accelerometer work with MATLAB. Wrote
> > some m-file code that would do this and it almost worked. The
> > accelerometer data was being plotted decently; taking the area
> > underneath the curve gave velocity and integrating it further gave
> > the distance...which is our final goal..getting the distance moved.
> > We got this to work with real-time data. As the accelerometer was
> > moving, data was being plotted. The velocity was being done by the
> > 'trapz' function. Not good enough data though, the velocity wasn't
> > being plotted properly.
> >
> > So now we're trying to use Simulink to solve this problem and
> > hopefully get it to work in real time a bit better. Question is,
> > where do I begin? How can I get Simulink to read data from the serial
> > port (accelerometer) and plot the data in real time?
> >
> > Any help would be appreciated :)
>
> What, specifically wasn't "good enough data" and why do you think
> switching to Simulink would be the solution?
>
> If the acceleration data are being collected and displayed correctly,
> then a problem w/ velocity would seem to be more related to the sampling
> rate and the trapezoidal assumption in integration and that won't change
> with computing platform.
>
> Of course, integration and double-integration of an accelerometer is
> reknown for difficulties as any DC bias in the input is amplified for
> starters.
>
> --