Hi Mark,

> did you find out how fast you could get away with sampling the various
> devices?  I have some robot applications where I found that if I sample
> the data too fast I get different result than if I give things a chance
> to settle.  Its a function of the device you are measuring.

We *very* carefully chose the sample rates for all of our inertial
sensors on that IMU. You can argue whether or not they're optimal, but
they're definitely not too fast. They've got solid anti-aliasing filters
on them, and the whole system was designed off the noise floor of the

Also, we very carefully examed the raw data coming off the IMU (in terms
of CAN packets) before flight, and it was just what we expected. So I
don't think there's anything wrong with the IMU.

> have done the actual sampling at a very regular interval. It was just a
> micro-controller, and had low latencies in its timer interrupt handler.
> I believe Andrew tested that with a good oscilloscope.

Yep, I did, and it was dead on.

>> I'm sure it did, at one point, but once everything was integrated and
>> additional data was put on the CAN bus I'm thinking things where
>> different.

CAN packets are transmitted based on their message ID, so they can get
all out of order. That's half of the "fun" of CAN :/

>> So before lift off the data seems to come once a jiffie, after launch I
>> get 25ish samples per jiffie (most times) with spikes of 70 and lows of
>> 1.  How do I infer a uniform time per sample?

Huh. So, I want to look at that. I really thought we solved this problem
before flight, so I think we should all sit down and make sure the
post-processing isn't missing something. I swear the ADEOS patch fixed
all this junk.

Anyway: happy processing! See you all at the next meeting.


Andrew Greenberg

Portland State Aerospace Society (http://psas.pdx.edu/)
[EMAIL PROTECTED]  P: 503.788.1343  C: 503.708.7711

psas-software mailing list

Reply via email to