kriswiner
commented
6 years ago What is SMT?.
Sounds like you would be much better off with this https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution-mpu9250/ .
The EM7180 co-processor handles all of the sensor management and fusion calculations freeing the host from these tasks.
If you insist on using the host for sensor management and orientation estimation, I would recommend something like this https://www.tindie.com/products/TleraCorp/dragonfly-stm32l47696-development-board/ or even this https://www.tindie.com/products/TleraCorp/ladybug-stm32l432-development-board/, where you can get fusion rates > 50 kHz, not that you need to; 5 kHz fusion rate and 200 Hz gyro/accel rate is fine, but best results even for slow human motions are obtained at 1 kHz gyro/accel rate.
More info here https://github.com/kriswiner/EM7180_SENtral_sensor_hub/wiki/K.-Limits-of-Absolute-Heading-Accuracy-Using-Inexpensive-MEMS-Sensors .
On Wed, Jul 11, 2018 at 10:35 PM, EinSoldiatGott notifications@github.com wrote:
Hi, Kris thanks for all your work.
Currently, I'm using the MPU9250 on one CC26XX microcontroller from TI with included Bluetooth. It's an M3 with 48Mhz. I managed to get the DMP working but as you for sure have noted some functions from the mpl works and some won't (like the self-test).
I'd like to move to your code to have more control over what's happening, but I have some question before starting the migration. Also, I run out of memory and I'm not really using most of the functions from the MPL, like the android orientation, pedometer...
1.
Using the DMP I had some time between interruptions because it's supposed to be the idea of the DMP even when at the end we end up calling a lot of computing resources demanding calculations. With your implementation is it possible to perform an additional task apart from the orientation calculation? 2.
With SMT you get 4.8Khz with SMT@84Mhz, 2,1Khz with Teenesy@96MHz, and what was the update with the Arduino at 8Mhz? 3.
For the sensor fusion update rate of my last question, the best the better, but if my object is slow (Human body) where a 200Hz is enough, is it possible to still use your code for low update rates? This is important for me because my uC has the Bluetooth rom running at the same time, and the orientation will be obtained on "parallel" (time slicing) task. Mi uC is an M4 with floating point.
At the end what I want is to use your implementation (I have 30Kb available) in conjunction with mine (control the angle of an actuator) on the same chip running it's Bluetooth ROM.
Thanks, Kris!!!
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/295, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qlT-1Fhi8c12y3ybHPH6req6XKJFks5uFuAagaJpZM4VMO8Q .
EinSoldiatGott
Hi, Kris thanks for all your work.
Currently, I'm using the MPU9250 on one CC26XX microcontroller from TI with included Bluetooth. It's an M3 with 48Mhz. I managed to get the DMP working but as you for sure have noted some functions from the mpl works and some won't (like the self-test).
I'd like to move to your code to have more control over what's happening, but I have some question before starting the migration. Also, I run out of memory and I'm not really using most of the functions from the MPL, like the android orientation, pedometer...
Using the DMP I had some time between interruptions because it's supposed to be the idea of the DMP even when at the end we end up calling a lot of computing resources demanding calculations. With your implementation is it possible to perform an additional task apart from the orientation calculation?
With SMT you get 4.8Khz with SMT@84Mhz, 2,1Khz with Teenesy@96MHz, and what was the update with the Arduino at 8Mhz?
For the sensor fusion update rate of my last question, the best the better, but if my object is slow (Human body) where a 200Hz is enough, is it possible to still use your code for low update rates? This is important for me because my uC has the Bluetooth rom running at the same time, and the orientation will be obtained on "parallel" (time slicing) task. The uC that I'll be using now is an M4 @48Mhz with a floating point instead of my current M3.
At the end what I want is to use your implementation (I have 30Kb available) in conjunction with mine (control the angle of an actuator) on the same chip running it's Bluetooth ROM.
Thanks, Kris!!!