Path: news.mathworks.com!newsfeed-00.mathworks.com!oleane.net!oleane!news.ecp.fr!feeder.eternal-september.org!eternal-september.org!not-for-mail
From: dpb <none@non.net>
Newsgroups: comp.soft-sys.matlab
Subject: Re: Serial Accelerometer
Date: Tue, 03 Nov 2009 09:45:07 -0600
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <hcpjft$iq5$1@news.eternal-september.org>
References: <hbkgl6$bn4$1@fred.mathworks.com> <hbkh97$rpc$1@news.eternal-september.org> <hcphe7$l62$1@fred.mathworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.eternal-september.org U2FsdGVkX1/6Aml976hgSpgQwm/02zMzoEw8hD6BLO4kkc8sQrjJIDHVIdl25QD+pkR/dYIxltBcGIR+MtPWUhKp5eZSKYVd4mLey987VdZbqkpoQqrhogcC2IF3IfIPMzpuS1OYybc=
X-Complaints-To: abuse@eternal-september.org
NNTP-Posting-Date: Tue, 3 Nov 2009 15:50:23 +0000 (UTC)
In-Reply-To: <hcphe7$l62$1@fred.mathworks.com>
X-Auth-Sender: U2FsdGVkX1+/Bn7MPFUBqYLgxgmv1MU4xRvYZbxkSDo=
Cancel-Lock: sha1:JfSQOB1UMiHFH2BJSaDk3Ajr238=
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
Xref: news.mathworks.com comp.soft-sys.matlab:582073


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

--