Hi all,

I am designing a small 6-DOF IMU with digital outputs that uses the newest MEMs devices on the market (some of which haven't been released yet) to keep the footprint small and the cost low. I'm hoping to make a bunch of them and sell them at low margins so that DIY'ers like us can afford to tinker without breaking the bank. If they sell well enough, I'll be able to keep the cost on the order of $100 for the full 6-DOF with digital outputs. :-)

If you had the choice, what do you all think the "best" pinout would be?

My current design has two .1" headers mounted on opposite ends of the board, so that prototyping and mounting is easy.

Alternatively, I could add mounting holes, and then put little shrouded headers that you'd plug into; then, you wouldn't have to mount the IMU on a PCB - you could put it anywhere on the airframe.

Another option would be to use low-profile board-to-board connectors, but they wouldn't be easy to use (have really fine pitch).

What do you think?

Views: 1314

Reply to This

Replies to This Discussion

Alignment is important with IMU's, so I'd be in favor of having mounting holes available, independent of what pinout arrangment and connectors you choose.

Would your board handle sampling and filtering? What data rates would you use? Or would it simply provide access to the chips for offboard processing?

Yes, it handles sampling and filtering; the analog BW of the gyros is 140 Hz, so the MCU will sample at 280 Hz to prevent aliasing; then, a digital low-pass filter with configurable BW does extra processing. I wrote code for an optional KF to provide pitch and roll angle estimates, but I don't know whether people actually want that or not.

Sounds interesting.

What is the digital interface? I2C? SPI? Will the on-board MCU be user programmable? I might want to do my own signal processing and filtering - like oversampling and averaging. Which MCU do you plan to use. Are the accelerometers also analog, or are they digital?

- Roy
Interface will be TTL UART and SPI. All the programming pins for the MCU are routed out, so you can reprogram it if you want; I might release the source code as well, but I won't have time to provide any development support - this whole project will only be sustainable if I can outsource almost everything. Otherwise I would have to charge more. :-)

The on-board digital filter will perform much better than an averager, and you will be able to tune the 3-dB BW much easier. So, hopefully you won't have to resort to an averager.

The MCU is the C8051F353 from Silicon Labs; I chose it because it has a 16-bit A/D converter, it is cheap, and it has a really small footprint and a precision internal oscillator (few external components). Interestingly, the C8051F351 is exactly the same, except it has a 24-bit A/D converter... The noise floor of the sensors is way higher than the 24-bit A/D, so it would be overkill... it is fun to think of putting it on anyway, though. :-)

The accels are analog.
Theoretically, if you oversample and average you can get better resolution. I think its something like 1 extra bit for each factor of 4 oversample rate (if you average the 4x samples to provide data at 1x - of course you still have to take the Nyquist frequency into account. This also presumes there's noise on the signal - which shouldn't be an issue). Depending on what you mean by sensor bandwidth, you scheme sounds like it could still result in aliasing. I'm not sure how important that is to our application, but its of course nice to have as much control over the processing as possible. I wouldn't expect direct support from you for custom code, of course.

At this time, I'm not willing to solder these small parts myself, so I'm somewhat at the mercy of those who can. A friend is designing a board for us, so we'll be using that. But, its always good to see what else is out there. Depending on the specs of the sensors themselves, it may be something to keep in mind for the future.

What is the development environment like for this 8051 processor? Are there free c compilers available?


Yes, the SDCC compiler is free, and Silicon Labs has a free IDE.

This IMU will always sample at at least twice the analog 3-dB bandwidth of the sensors - so, aliasing won't be a problem.

My observation about oversampling and averaging was just that, as I understand it, an average is a very poor low-pass filter - it's one saving grace is that it is easy to implement. If you oversampled and used something besides an averager, you could have a much flatter response in the pass-band, and you could set the 3-dB cutoff of the filter to a wider range of values.

But, of course, it has been a while since I had a signal processing class. :-) You might know much more about it than I do.
I can send you some links that describe the idea, if you're interested.

- Roy
Thanls, Roy. This is really good information.

I should have realized that a passive, single-pole low-pass filter wouldn't have a sharp enough corner to sample at twice its bandwidth and not see any aliasing.
Hmmm... Here is something I should have thought more carefully about! The MCU I chose can only sample at up to 1 kHz. With 6 channels to measure, I can't even sample at twice the analog 3 dB corner on each channel!

I think I will lower the corner on the accels by a lot (to less than 40 Hz) and sample them less frequently than the rate gyros. Then the best I could do would be to sample each gyro channel at 250 Hz, and each accel channel at 83 Hz. The accels are super-noisy anyway...
How about using a different processor instead?

- Roy

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service