Currently I have an application which runs on Android and interfaces with a MPU9150 over bluetooth. The application reads in all data output by the MPU and can correctly parse quaternion packets, data packets and debug packets. However, I only ever receive quaternion packets, I believe this is all the MPU outputs by default. I have an out stream which I can use to write to the MPU in byte arrays. What do I need to ouput to take the MPU out of sleepmode or to simply turn on other data types such as the accelerometer or compass?
For example, the input stream is configured in 23 byte sequences, starting with a $, is it something along those lines to output requests to the MPU?
- Log in to post comments
phpbb Topic ID
15360
Re: Re: Bluetooth Communication
I've tried writing the commands given for the python application out to the MPU, but these don't seem to work over bluetooth. I'm simply taking the 'inva' and converting it to a byte array, and writing out to the device. Is there something deeper I should be doing, like targeting specific registers on the MPU, or should this be working?
Re: Re: Bluetooth Communication
The "inva" interface over the BT COM port should be the correct result. You may try the r n to verify the string is the same as a terminal application, which should also be able to trigger the change in output.
Re: Re: Bluetooth Communication
Just needed to add a wait statement in between bytes, thanks so much for your help!
Re: Re: Bluetooth Communication
Aha! Just found this. Woke me up to the fact that you need to send one character at a time at the hardware "stream" level, i.e. not fprintf(fid, "invg") but rather fprintf(fid,"i");pause(1);fprintf(fid,"v");pause(1); etc.
This resolves a lot of the mystery for me with a recent post
https://invensense.tdk.com/developers/forum/viewtopic.php?f=3&t=365
I have been trying to get the right source code for my hardware version for both the sending side and receiving side.
In this case the issue was at a very fundamental level requiring a little wake up on my part. So now I get the following from Realterm at turn on.
2402003F0F573B016D311DFF6E53F1F52DE60600000D0A
2402003F0F58E3016CF52FFF6ED8DEF52DE33B00000D0A
2402003F0F583F016D2366FF6F27BAF52DE12200000D0A
2402003F0F5C7E016CCCFBFF70B837F52DD82A00000D0A
2402003F0F5B87016CC319FF7015EDF52DDC0E00000D0A
and this after "i","n","v","g"
2402003F0F5943016D3DB4FF734E4EF52DB2DF00000D0A
240301FFFFFE3A00000A6A000006400000000000000D0A
2402003F0F5E73016C3ADBFF728731F52DB8BA00000D0A
240301FFFFFE3AFFFFFACA000006400000000000000D0A
2402003F0F60B4016BDF2CFF729599F52DB8C900000D0A
The good news and purpose of this reply is that the MP430 in my SDK is finally responding with the data I want, at least in Realterm. Why it alternately returns data type 2 as well as 3 is the new mystery. Simple realtime engineering plots with Octave or matplotlib (absent a working PC Demo) is the next objective before tearing into a new application of the MPU9150.
Thanks for the wake up!
Re: Re: Bluetooth Communication
I'm not sure which library or SDK you are using from Invensense. The following may help you to resolve the issue.
The second byte indicates the packet header.
In EmbeddedMotionDriver_5.1 msp430 sample application,
0x24 = '$'
0x02 = PACKET_TYPE_QUAT
0x03 = PACKET_TYPE_TAP
In MotionFit SDK v5.1 msp430 sample application,
0x24 = '$'
0x02 = PACKET_TYPE_QUAT
there is no packet header which produces 0x03
If yours is custom firmware application, then you need to provide additional info to debug this problem.
Re: Re: Bluetooth Communication
Thanks. I am certain about the above Realterm data but I am confused about the source code for my SDK purchased a few months ago. Any clarity would be very welcome.
Specifically to your response I do not find any of the code segments quoted, rather I find:
"MotionFit SDKv5.1.zip/MotionFit_With_eMPL511_Release/sample_apps/mp430/mllite_test.c" as a possible "main.c" source for my current SDK firmware. Alternatively, sectionbest has suggested:
"MotionFit SDK v5.1.zip/MotionFit_With_eMPL511_Release/core/eMPL_hal/eMPL_outputs.c"
Thanks
Technical Section/"MPU 9150 Output Data"
Found above post that confirms the alternating data format (type2/type3) for direct serial data capture from SDK c. Dec 17th 2012 per Yorisimo. He identifies mllite_test.c as the source for the SDK511 firmware. (I have corrected my reference above to match.)