1. Sequential ADCs
2. Flash ADCs
3. Sigma-Delta ADCs (Over Sampled ADCs)

(For a complete review of ADC technology, I suggest everyone reading Analog Devices’ ADC handbook). Sequential and Flash ADCs are fast but have a low resolution. In order to sample a gyroscope with a resolution of 24bit or more, a sigma-delta ADC (ΣΔ ADC) has to be used.
ΣΔ converters internally sample the analog inputs using a 1 bit ADC with a very high rate (that is why they are called as over-sampled ADC). After 1bit sampling operation, these 1bit samples are processed with a digital filter (and downsampled) to generate high resolution samples of the analog input. The digital filter used in ΣΔ ADC has a low pass characteristic. Therefore, ΣΔ ADCs cannot be used for high BW signals.
High speed and high resolution ΣΔ ADCs with simultaneous multiple channels can be very expensive. (they can cost more than 200$). Therefore, IMU designers who use this traditional approach find themselves in a situation in which they have to make a compromise between speed and resolution.
Having summarized the traditional approach, I can start attacking and blaming everyone who blindly follows this approach.

The main point that these people fail to understand is that we never need acceleration and rotation rates to solve the INS equations. All we need is the integral of these quantities (a.k.a angle and velocity increments). In this case, why don’t we integrate the signal with an analog front-end and then sample only this integral value? Or, even better, why don’t we use a front-end which integrates and samples the rate signal at the same time so that we don’t bother ourselves with integrating the signal (either in digital or analog domain) at all?

Here is a block diagram of such a circuit that can be used to integrate and digitize analog signals. It is in fact nothing but the simplest form of an ΣΔ modulator. Despite its simplicity it accomplishes exactly what we need.

The first summation junction is used to add sensor outputs when more than 1 inertial sensor is used per axis (i.e. orthogonal redundant configurations). Redundancy is a life saver. I strongly recommend everyone to use it even if only 1 sensor per axis is used. The feedback loop is a sigma-delta modulator. The 1 bit ADC is essentially a comparator. The feedback loop stabilizes the integrator output at “0”. Without such a feedback loop, the capacitor would not operate in the linear region. The 1 bit DAC generates either Vmax or 0 (we assume that sensor outputs changes only in the range of [Vmax 0]). The clock of the D flip-flop determines the time support of each rectangular pulse generated by the 1bit DAC. When the output of the latch (D flip flop) is high, the counter increments. Thus, the counter output is equal to the integral of the feedback signal. Therefore, it approximates the integral of the input. Thanks to the feedback loop, the maximum error on this integral is equal to dt*Vmax where dt is the period of the clock. Therefore, the faster is the clock, the better is the approximation. Regardless of the total integration time the error is bounded by this value. (In rate sampling systems the integral error keeps increasing in time without a bound. That is why we need very high BW to reduce the integration errors in rate sampling structures). Even if a moderate clock is used (e.g. 1Mhz) this error becomes completely negligible with respect to any other error source. Therefore, this integral sampling method can safely be assumed errorless.

The following figure shows a very primitive circuit which realizes the above block diagram. It assumes that the analog signal varies between Vmax and “0”. An analog designer would probably laugh at the simplicity of this circuit (no op-amp bias current compensation, no voltage isolation etc). But still, I suppose it will work as intended.

As a result, the approach described above has 2 distinct advantages which make it superior to any ADC based approach:

1. The quantization errors on the angle and velocity increments computed with this circuit is negligible.
2. A rate sensor must be sampled very fast in order to minimize the errors on the integrals. The above circuit computes the integrals in the analog domain. You only need to read the counter output whenever you need the angle/velocity increment values. Therefore, it provides a great flexibility on the timing requirements.

In my navigation projects, I started to use STM32F4 discovery board as a basic prototyping board. It is STM’s microcontroller evaluation board which costs only 19$. Despite its cheap price, it has everything that immediately makes interfering with the inertial sensors possible. It not only contains pin-outs for the microcontroller, but also has an on board debugger/programmer (stm32 link/v2) so that embedded code can be directly uploaded (and debugged) via the USB port without an additional JTAG module.

If you had any previous interest on hobby electronics, you would have probably heard about Arduino boards. Arduino can also be considered as fast prototyping board. Due to its immense popularity among enthusiasts, there are significant amount of existing code samples on the internet. However, compared with the stm32f4’s capabilities, the Arduino boards are kind of simple toys. Therefore, I strongly suggest you not wasting your time with it.

The biggest problem with the STM32 is that there are not sufficient code examples on the internet. Therefore, it sometimes becomes quite a burden to read pages of reference manual to understand the function of certain registers, or to learn the efficient way of using a peripherals. There are some sample codes for STM32F1, however, these codes cannot be readily used for STM32F4 due to the differences between the F1 and F4 architectures. (By the way, STM32F4 is based on ARM Cortex M4 which is the newest pseudo-DSP family of the ARM microcontrollers.)

Currently, STM is the only manufacturer which produces ARM Cortex M4 based microcontroller. NXP is also going to start selling its own Cortex M4 family very soon. In fact, NXP has bigger user support and sample code base compared to STM. Furthermore, its application notes is more explanatory than the STM. Therefore, I think NXP may be a better choice for the beginners. On the other hand, STM32 has more peripherals than the LCP (NXP) which makes STM32 more favorable at least for me.

I have uploaded two STM32 sample projects for the I2C and SDIO peripherals. These peripherals are essential for the IMU designers as they are required to communicate with the sensors and then to record the sensor data to the SD cards. You can download these sample codes from the github page (here).

STM32’s I2C interface is a little bit problematic. One has to write different functions depending on how many read/write transaction is going to be performed. In order to stretch the clock properly or send NACK/ACK at the correct time, you have the read and learn each function of all registers. There is a considerable difference between reading a single byte and multiple bytes. In the sample codes, I added plenty of comments so that you can see how a proper read/write sequence can be performed with the I2C peripheral without using the DMA for different number of bytes.

STM32 uses 6 wire SDIO interface to communicate with the SD cards. SD cards themselves are also another pain to learn and to use. Because of it is a proprietary technology, there is no sufficient reference on the internet. Therefore, when your embedded code does not function as it is intended, it becomes hard to understand whether it is the code that has bugs or it is you who cannot understand the correct command/response sequence.

Most of the SD cards also support SPI interface. But, the SPI interface uses the same command and response protocol. As SPI uses the same line for data and command transmission, it becomes almost impossible to recover from an error. Therefore, I suggest everyone to use SDIO rather than SPI for the SD cards regardless of the data rate requirements.

The example codes that I uploaded have functions to perform single/multiple block write operations using the DMA. Again, I included plenty of comments to not only describe the codes but also the overall SD communication protocol. Therefore, I believe it will be quite useful for anyone who wants to record inertial sensor data to the SD cards for post processing.

The most problematic point about programming the SD cards is that the SD cards arbitrarily switch themselves into the so-called busy mode from time to time. During these busy modes, SD cards do not respond anything other than certain commands (in SPI mode, as the data line is the same as the command line, it does not respond to anything at all). Therefore, without using a DMA, it is almost impossible to use SD cards for projects which require strict timing specifications (such as periodic IMU sampling). The STM32’s data-path logic of SDIO takes care of these “busy-modes” without the intervention of the microcontroller when the DMA is used. (However, as I indicated in the comments of sample codes, one has to check the busy mode manually for the command-logic). In single block write operations, SD puts itself busy mode after every block. That is why, you should prefer multi-block write with an internal buffer structure if you want to use SD cards as fast as possible.

One problem with the STM32F4 discovery board is that another integrated circuit is connected to the microcontroller pins which are needed for the SDIO. Therefore, before using the SDIO interface you need to remove that component with a hot air gun. Otherwise that component will pull the lines high and block all the communication.

During my search for a better microcontroller, I have gladly noticed that microcontroller manufacturers have seriously started looking for an effective method to add inertial sensors among their standard interfaces.

It seems Atmel is currently leading in this field. They have already included a sensor library to their embedded framework. I quickly reviewed their code. In addition to standardizing the inertial sensor interface, they also try to introduce some high level sensor calibration interfaces. It seems they expect the sensor manufacturers to develop their own code compatible with Atmel’s high level library. Invense has already done that. Although I think that having some calibration interface for any embedded library is quite unnecessary, I do find their efforts worth to praise.

STM has also done some work in inertial (pseudo-navigation) field. It seems a small group is trying to develop some basic navigation functions for ST. The development board for their latest STM32F4 microcontroller has 3 accelerometers on it. Their “hello word” application is also using these accelerometers to turn on/off leds. I guess they are willing to promote their cheap (and also quite useless) inertial products via their famous STM32 family of microcontrollers. By the way their new STM32F4 family has floating point support which is great for any embedded navigation application. (They send free STM32F4 discovery kids to Canada and USA. If you are planning to deal with embedded programming any time soon, it can be a good opportunity to get a free development board from ST).

There is no news on the NXP side. Perhaps someday they will also consider adding some inertial flavor to their microcontrollers.