Kalman filter with accelerometer

The noise/signal is bandlimited in hardware to make Mr. Nyquist happy,
I was pointing out I don't  bandlimit to accomodate a x sample rate but
rather a 64 x oversampling rate.

steve wrote:
> The noise/signal is bandlimited in hardware to make Mr. Nyquist happy,
> I was pointing out I don't  bandlimit to accomodate a x sample rate but
> rather a 64 x oversampling rate.

So which is it? Bandlimiting to satisfy the final rate, or the 64x rate? 
If the latter, averaging may not be enough bandwidth reduction to avoid 
aliasing. If the former, the noise will be correlated.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

One more question, 
I need to find out the Sz, Sw. How do I get those? from the datasheet?

		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

blackmangoes wrote:
> Okay
> Somehow I thought wk is the noise with mean equal to 0

Yes,  I was confused.  u, in that case, is a deterministic input and
w_k is the noise.

I'm used to seeing:

x_{k+1} = A x_{k} + B w_{k}

rather than

x_{k+1} = A x_{k} + B u_{k} + w_{k}

hence my confusion.  I apologise for mixing this up.

> Are we comparing the the old estimated acceleration and the measured
> acceleation from accelerometer? If so, the state will just be acceleration
> then.

It depends on whether you also want to know the position and velocity.

> Is B in my Kalman Gain equation? where B is
>
> x_{k+1} = A x_{k} + B u_{k} + w_{k}
>
> then the next estimation is
> \hat x_{k+1} = A \hat x_{k} +B \hat u_{k} + K (y - C \hat x_{k})
>
> So if u_{k} is the noise, what do I put there?

As I said, I was confused.  In this case, u_{k} is a deterministic
signal... and is usually taken to be 0.

> If w_{k} is the noise, what is u_{k} and B?
>

w is the noise, u is the deterministic (or known) signal.

If your noise is just as you've written in, then the B in your Kalman
filter will just be 1 (one).

Ciao,

Peter K.

] I need to find out the Sz, Sw. How do I get those? from
] the datasheet?

Sw is the covariance of w.  I'm not sure what Sz is ?  What's z?  Do
you mean Sn?

You had

 y(x) = Cx(t) + n

which probably should be

 y(t) = Cx(t) + n

so your Kalman filter equation will need to know Sn (the covariance of
the measurement noise, n).

Ciao,

Peter K.

As I stated, I bandlimit the 64x rate.

You can't "avoid aliasing" with software averaging  (or any other
software filter for that matter), aliasing is only prevented via
appropriate hardware filtering matched to a given sample rate.

steve wrote:
> but what are the sources of the correlation, typically?
> 
> I'm not (on purpose) bandlimiting the 64x signal BW noise in the analog
> front end so consecutive samples shouldn't be identical, is there other
> correlations I should be considering?
> 


At some point the noise will exhibit correlation.  If it didn't, you 
could achieve SNR gain without bound. Samples not being identical is not 
a good test. Not all measurement noise is associated with front end 
electronics.  There are a number physical effects that act on the 
accelerometer that are also noise mechanisms.

steve wrote:
> As I stated, I bandlimit the 64x rate.
> 
> You can't "avoid aliasing" with software averaging  (or any other
> software filter for that matter), aliasing is only prevented via
> appropriate hardware filtering matched to a given sample rate.

No. If you bandlimit properly for 64x sampling, there will be no 
aliasing in the high-speed data stream. It can then be reduced to 1x by 
the usual decimation techniques, also without aliasing. You can average 
before you filter-decimate and still have no aliasing. Taking the 
average will reduce the high-frequency content, but in general, not enough.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

"Jerry Avins" <jya@ieee.org> wrote in message
news:F5qdnR80FOxvdQDfRVn-3A@rcn.net...
> steve wrote:
> > As I stated, I bandlimit the 64x rate.
> >
> > You can't "avoid aliasing" with software averaging  (or any other
> > software filter for that matter), aliasing is only prevented via
> > appropriate hardware filtering matched to a given sample rate.
>
> No. If you bandlimit properly for 64x sampling, there will be no
> aliasing in the high-speed data stream. It can then be reduced to 1x by
> the usual decimation techniques, also without aliasing. You can average
> before you filter-decimate and still have no aliasing. Taking the
> average will reduce the high-frequency content, but in general, not enough.

Right.  If you are going from analog to digital (analog-to-digital conversion)
then aliasing must be prevented with an analog filter.  However, if you are
going from digital to digital at a lower sample rate (sample rate conversion, or
downsampling), then aliasing can be prevented with a digital filter (before the
sample rate conversion is done).

Jon Harris wrote:

>  ...  If you are going from analog to digital (analog-to-digital conversion)
> then aliasing must be prevented with an analog filter.  However, if you are
> going from digital to digital at a lower sample rate (sample rate conversion, or
> downsampling), then aliasing can be prevented with a digital filter (before the
> sample rate conversion is done).

I wish I had said that!

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������