I am planning on starting my next fun project (hobbyist thing). This is not for sale and nobody except me will be using it. It is basically a dash mountable box that uses 12V power from the car. The goal is to show accelerations along the X, Y and Z axis using either a bar graph or 7 segment displays (or maybe both) along with a microcontroller. Thus when you are going around a turn or just accelerating from a stop light. The display will show your actual acceleration in real time along all three axis.

The question: I am fairly certain that an IMU module would be best for this application, but I think a GPS receiver module could also do the job. I have worked with GPS receiver modules and they are very easy to use. Cannot say I have worked with IMU modules, but the datasheets I have looked at seem to indicate they are also very easy to use and interface to a microcontroller. Which is better an why for this type of application?

 

I am planning on starting my next fun project (hobbyist thing). This is not for sale and nobody except me will be using it. It is basically a dash mountable box that uses 12V power from the car. The goal is to show accelerations along the X, Y and Z axis using either a bar graph or 7 segment displays (or maybe both) along with a microcontroller. Thus when you are going around a turn or just accelerating from a stop light. The display will show your actual acceleration in real time along all three axis.

The question: I am fairly certain that an IMU module would be best for this application, but I think a GPS receiver module could also do the job. I have worked with GPS receiver modules and they are very easy to use. Cannot say I have worked with IMU modules, but the datasheets I have looked at seem to indicate they are also very easy to use and interface to a microcontroller. Which is better an why for this type of application?

Yes, a GPS module could possibly do the job but a good accelerometer based IMU sensor fusion would more precise.

Can a GPS module deliver the needed data for this in a single 3.3vdc chip like the BMX160 IMU?
https://forum.allaboutcircuits.com/...2210-on-linux-with-libusb.179080/post-1691231

 

Yes, a GPS module could possibly do the job but a good accelerometer based IMU sensor fusion would more precise.

Can a GPS module deliver the needed data for this in a single 3.3vdc chip like the BMX160 IMU?
https://forum.allaboutcircuits.com/...2210-on-linux-with-libusb.179080/post-1691231

Thanks! The BMX160 appears to now be 'obsolete' and no longer being manufactured. But it appears there are so many choices for the IMU it is a little overwhelming. I see over 400 possibilities on Digikey.

https://www.digikey.com/en/products/filter/motion-sensors/imus-inertial-measurement-units/567

 

For a pure accelerometer I've used the BMA400 for a general motion sensor and the SCL3300-D01-10 as industrial application sensor.

A 9DOF with sensor fusion makes for a much better data source as it blends the strengths from each type of sensor.

I'm looking at this IMU for a future project. SPI is my preferred device interface because it's fast(but only 3MHz on this device) , simple and can use DMA transfers on most 32-bit controller platforms.
https://www.adafruit.com/product/4754

Four point quaternion output for accurate data manipulation

https://www.ceva-dsp.com/product/bno080-085/
https://www.ceva-dsp.com/wp-content/uploads/2019/10/BNO080_085-Product-Brief.pdf

 

For a pure accelerometer I've used the BMA400 for a general motion sensor and the SCL3300-D01-10 as industrial application sensor.

A 9DOF with sensor fusion makes for a much better data source as it blends the strengths from each type of sensor.

I'm looking at this IMU for a future project. SPI is my preferred device interface because it's fast(but only 3MHz on this device) , simple and can use DMA transfers on most 32-bit controller platforms.
https://www.adafruit.com/product/4754


https://www.ceva-dsp.com/product/bno080-085/
https://www.ceva-dsp.com/wp-content/uploads/2019/10/BNO080_085-Product-Brief.pdf

Nice. Thanks! In that case I may go with the 9DOF being more general I could use it for other purposes without the need to write different interfaces. SPI, I2C or UART is ok with me, being I don't need a super high speed device. So SPI is fine for me but the higher speed again may better support my next application where I have no idea what that might be. Thanks again for your help!

 

Nice. Thanks! In that case I may go with the 9DOF being more general I could use it for other purposes without the need to write different interfaces. SPI, I2C or UART is ok with me, being I don't need a super high speed device. So SPI is fine for me but the higher speed again may better support my next application where I have no idea what that might be. Thanks again for your help!

Now there are chips like the BNO085/086 that have on-chip controllers to handle the sensor fusion task, 9DOF is much easier to use. I have my own libs but theirs seems to be very good.
https://www.ceva-dsp.com/app/motion-sensing/

I always like to run I/O as fast as possible with hardware to help reduce processor resources.
This board with a SCL3300 chip for gesture and movement detect runs on a 9V battery, so between I/O and processing, it can sleep while doing a shutdown of the screen when idle.

 

I am planning on starting my next fun project (hobbyist thing). This is not for sale and nobody except me will be using it. It is basically a dash mountable box that uses 12V power from the car. The goal is to show accelerations along the X, Y and Z axis using either a bar graph or 7 segment displays (or maybe both) along with a microcontroller. Thus when you are going around a turn or just accelerating from a stop light. The display will show your actual acceleration in real time along all three axis.

The question: I am fairly certain that an IMU module would be best for this application, but I think a GPS receiver module could also do the job. I have worked with GPS receiver modules and they are very easy to use. Cannot say I have worked with IMU modules, but the datasheets I have looked at seem to indicate they are also very easy to use and interface to a microcontroller. Which is better an why for this type of application?

From what you describe, I think IMU is better suiting your needs.
Pros with IMUs:
- straightforward (GPS does not give you acceleration values directly)
- higher rates possible,
- more responsible
- no dead signals which GPS suffer from
- drains less power from the batteries
- also fairly easy to use (recommend to use some breakout boards or full sensor kit such as Nano 33 BLE Sense etc).

 

Ever the one poking at the question; why do you want X, Y, Z axes? Acceleration and braking would need to be positive and negative compatible or have some pre-"offset" so that you can reference the difference between accelerating and braking. Same would be necessary for cornering. Left turns could be positive going while right turns could be negative going inputs. Z axis would be for vertical acceleration. Unless you're going over some extremely hilly territory personally I don't see much value in a Z axis report. Shock absorbers new or worn would likely change that value to some unknown to me value.

 

Ever the one poking at the question; why do you want X, Y, Z axes? Acceleration and braking would need to be positive and negative compatible or have some pre-"offset" so that you can reference the difference between accelerating and braking. Same would be necessary for cornering. Left turns could be positive going while right turns could be negative going inputs. Z axis would be for vertical acceleration. Unless you're going over some extremely hilly territory personally I don't see much value in a Z axis report. Shock absorbers new or worn would likely change that value to some unknown to me value.

Almost every modern IMU will have the X, Y, Z axes data because they are designed to operate in 3D space and to provide the needed data for 3D calculations. Gravity is vertical acceleration. That's important to understand why/how/where things react to changing forces on/inside the car during changing accelerations.

https://www.phys.hawaii.edu/~morse/P170Fa15-7.pdf

Using + or – signs is not always sufficient to fully describe motion in more than one dimension
Vectors can be used to more fully describe motion: displacement, velocity, and acceleration

 

Almost every modern IMU will have the X, Y, Z axes data because they are designed to operate in 3D space and to provide the needed data for 3D calculations. Gravity is vertical acceleration. That's important to understand why/how/where things react to changing forces on/inside the car during changing accelerations.

https://www.phys.hawaii.edu/~morse/P170Fa15-7.pdf

Oh HESH up! Smartypants. Yeah, I concede, there is more to be understood in vectoring of forces. Y'all can disregard my comment (post # 8).

 

Smartypants? This is like, AP 101 stuff. Really, it's a good question as to why we sometimes need to drive by the seat of our pants, (hand/car reference) <-> (fanny/mass for 3D acceleration forces detection).

 

Oh HESH up! Smartypants. Yeah, I concede, there is more to be understood in vectoring of forces. Y'all can disregard my comment (post # 8).

It is a good question, nevertheless. I worked with some IMU's when I worked for Raytheon in Tucson with Missile Systems. Not sure about COTS IMU's, but one of the ones I was working with were so accurate it measured the angular rotation of the earth at 15 degrees per hour! In one of the testing, it picked up an earth quake in California that was a few hundred miles away.

 

It is a good question, nevertheless. I worked with some IMU's when I worked for Raytheon in Tucson with Missile Systems. Not sure about COTS IMU's, but one of the ones I was working with were so accurate it measured the angular rotation of the earth at 15 degrees per hour! In one of the testing, it picked up an earth quake in California that was a few hundred miles away.

You won't see super high resolution, low drift and low noise in a consumer MEMS based IMU. With good sensor fusion you don't need it for most personal applications.

I do have some Industrial units with much better spec's.
https://ctisensors.com/mems-imu/

The table below summarizes the performance-grades, cost, and applications of IMUs:

Grade​	Cost​	Application​
Marine​	$1 million​	Military ships, submarines, intercontinental ballistic missiles, and spacecraft​
Aviation​	~$100,000​	Military ships, submarines, intercontinental ballistic missiles, and spacecraft​
Intermediate​	$20,000-$50,000​	Small Aircraft and Helicopters​
Tactical​	$2,000-$30,000​	GPS compensation used in guided weapons and UAVs​
Industrial​	$500 to $2,000​	Robotic, drones, agriculture and construction​
Consumer​	~$10​	Smartphones, Pedometerspedometers, and antilock braking systems (ABS)​

I just designed (waiting for the JLC prototype to arrive) a new board spin using the ~ $20 BNO086 as a option to two other units on the board. I just need to write a C driver that's compatible to my existing IMU api using their canned data reports.
https://learn.adafruit.com/adafruit-9-dof-orientation-imu-fusion-breakout-bno085/report-types

 

Some basic IMU info of the modern (IMU on a chip) concepts of what's needed and why sometimes old math concepts are used.

https://www.allaboutcircuits.com/te...lost-in-deep-space-understanding-quaternions/
https://forum.allaboutcircuits.com/threads/pic32mk-mc-qei-example.150351/post-1560143
The nice thing about the BNO085/6 is that is does all the messy sensor fusion quaternion math for you.

 

Some basic IMU info of the modern (IMU on a chip) concepts of what's needed and why sometimes old math concepts are used.

https://www.allaboutcircuits.com/te...lost-in-deep-space-understanding-quaternions/
https://forum.allaboutcircuits.com/threads/pic32mk-mc-qei-example.150351/post-1560143
The nice thing about the BNO085/6 is that is does all the messy sensor fusion quaternion math for you.

I was studying the datasheet for the BNO08x device and comparing it with other IMU's. I plan on using the SPI interface. I noticed it uses something called SHTP (Sensor Hub Transport Protocol) that rides on top of the hardware interface. What caught my eye: It seems like an overly complicated protocol for something as simple as reading data from a sensor. Other IMU's seem to have it very straight forward with SPI having simple read/write registers for working with the IMU (at least one other that I looked at without all the overhead protocol complications.
I am using a PIC32 microcontroller that can send/receive at most 32 bits at a time over SPI. Normally I set up SPI with synchronous /CS. Allowing the SPI module to handle the framing. I am thinking I can change that and set the chip select low using an IO output. Transfer all the bytes for the message via the SPI and clocking mechanism and finally just set chip select back high again. Hoping to avoid the need for partial messages.

What is your take on SHTP and have you used it before?

 

I've not used the SHTP but it seems less complex than the software needed for the equivalent sensor fusion functions using the raw data. I'm building a 8-bit SPI transfers framework for some simple init and read one type of data routines using the BNO chip interrupt as the rate for data captures. I don't have any hardware to test yet.

There are a few driver examples I'm looking at as the basis.
https://lore.kernel.org/linux-iio/20220616103634.vkb7nkn555a5evlw@uno.localdomain/T/#u
https://os.mbed.com/users/MultipleMonomials/code/BNO080/
https://os.mbed.com/users/MultipleMonomials/code/BNO080/docs/tip/

It's pretty complex in total capability because it's designed to the Android API but pretty straight forward if you just want X type of data, at X data rate.

If all you need is raw data from registers then a device like the LSM9DS1 might be worth a look but processing the raw data from registers to stable sensor fusion values is not a simple process.
https://learn.adafruit.com/adafruit...yro-plus-magnetometer-9-dof-breakout/overview

https://forum.allaboutcircuits.com/threads/pic32mk-mc-qei-example.150351/post-1559735
https://forum.allaboutcircuits.com/threads/pic32mk-mc-qei-example.150351/post-1560795
https://forum.allaboutcircuits.com/...icrocontroller-programmes.173300/post-1560077

Some example PIC32MK code that worked a few years ago with the LSM9DS1.

https://github.com/nsaspook/vcan/tr..._pic32mk/apps/clock/clock_config/firmware/src
https://github.com/nsaspook/vcan/tr...k_config/firmware/pic32mk_mcj_curiosity_pro.X
https://github.com/nsaspook/vcan/tr...apps_pic32mk/apps/clock/clock_config/firmware

 

I've not used the SHTP but it seems less complex than the software needed for the equivalent sensor fusion functions using the raw data. I'm building a 8-bit SPI transfers framework for some simple init and read one type of data routines using the BNO chip interrupt as the rate for data captures. I don't have any hardware to test yet.

There are a few driver examples I'm looking at as the basis.
https://lore.kernel.org/linux-iio/20220616103634.vkb7nkn555a5evlw@uno.localdomain/T/#u
https://os.mbed.com/users/MultipleMonomials/code/BNO080/
https://os.mbed.com/users/MultipleMonomials/code/BNO080/docs/tip/

It's pretty complex in total capability because it's designed to the Android API but pretty straight forward if you just want X type of data, at X data rate.

If all you need is raw data from registers then a device like the LSM9DS1 might be worth a look but processing the raw data from registers to stable sensor fusion values is not a simple process.
https://learn.adafruit.com/adafruit...yro-plus-magnetometer-9-dof-breakout/overview

https://forum.allaboutcircuits.com/threads/pic32mk-mc-qei-example.150351/post-1559735
https://forum.allaboutcircuits.com/threads/pic32mk-mc-qei-example.150351/post-1560795
https://forum.allaboutcircuits.com/...icrocontroller-programmes.173300/post-1560077

Some example PIC32MK code that worked a few years ago with the LSM9DS1.

https://github.com/nsaspook/vcan/tr..._pic32mk/apps/clock/clock_config/firmware/src
https://github.com/nsaspook/vcan/tr...k_config/firmware/pic32mk_mcj_curiosity_pro.X
https://github.com/nsaspook/vcan/tr...apps_pic32mk/apps/clock/clock_config/firmware

I understand what you are saying. Agreed the Fusion of multiple sensors for more accurate data is worth the extra complexity for the SHTP. I would prefer better accuracy but not at the expense of the extra communications complexity. It is ashamed they don't have an IMU with Fusion and not require the more complex interface. But being the chip is not that expensive for a one time thing. I think I will build a simple test board first and perfect the communications with the device that way. Maybe I am old fashioned in that I prefer to create my own 'drivers' using the appropriate datasheets instead of using someone else's or COTS's drivers. You are probably right though being all I want is the X,Y and Z acceleration data and the Gyro data, and it would be nice to have the fusion data not the raw data. Thanks for your input.

 

I've not used the SHTP but it seems less complex than the software needed for the equivalent sensor fusion functions using the raw data. I'm building a 8-bit SPI transfers framework for some simple init and read one type of data routines using the BNO chip interrupt as the rate for data captures. I don't have any hardware to test yet.

There are a few driver examples I'm looking at as the basis.
https://lore.kernel.org/linux-iio/20220616103634.vkb7nkn555a5evlw@uno.localdomain/T/#u
https://os.mbed.com/users/MultipleMonomials/code/BNO080/
https://os.mbed.com/users/MultipleMonomials/code/BNO080/docs/tip/

It's pretty complex in total capability because it's designed to the Android API but pretty straight forward if you just want X type of data, at X data rate.

If all you need is raw data from registers then a device like the LSM9DS1 might be worth a look but processing the raw data from registers to stable sensor fusion values is not a simple process.
https://learn.adafruit.com/adafruit...yro-plus-magnetometer-9-dof-breakout/overview

https://forum.allaboutcircuits.com/threads/pic32mk-mc-qei-example.150351/post-1559735
https://forum.allaboutcircuits.com/threads/pic32mk-mc-qei-example.150351/post-1560795
https://forum.allaboutcircuits.com/...icrocontroller-programmes.173300/post-1560077

Some example PIC32MK code that worked a few years ago with the LSM9DS1.

https://github.com/nsaspook/vcan/tr..._pic32mk/apps/clock/clock_config/firmware/src
https://github.com/nsaspook/vcan/tr...k_config/firmware/pic32mk_mcj_curiosity_pro.X
https://github.com/nsaspook/vcan/tr...apps_pic32mk/apps/clock/clock_config/firmware

I just read the details of UART-RVC mode. For my automotive application that seems the simplest and very easy to use at 100 Hz. The data is simple to decode. I don't think there is any 'drawbacks' to that, unless you can think of any for my application?

 

I just read the details of UART-RVC mode. For my automotive application that seems the simplest and very easy to use at 100 Hz. The data is simple to decode. I don't think there is any 'drawbacks' to that, unless you can think of any for my application?

Sweet, that should work out perfect.

I have options for UART or SPI on my board but I'm thinking maybe I should have added a UART-RVC config option for initial testing. Either way it looks like fun ahead.

 

Sweet, that should work out perfect.

I have options for UART or SPI on my board but I'm thinking maybe I should have added a UART-RVC config option for initial testing. Either way it looks like fun ahead.

Fun? Absolutely! I am working on the first schematic/board layout with this part using KiCad. Plan on having both UART-RVC and SPI configurable via some simple jumpers on this first board. Basically just a test board. Sending data to PC using simple USB-UART for verification. Have not decided yet, what processor to use. Either the PIC32MX (not that it is any better than any other but simply because I am familiar with it) or a nice Artex-7 FPGA module (CMOD A7-35T). I love that device, a little expensive but you can implement a soft processor and handle all high speed stuff with your own custom configurable logic which glues seamlessly with the soft core processor.