MPU 9150 on Sensor Hub Booster Pack - nuber of values that can be measured

Okay, that is good information Charles, i don't have much skills in microcontrollers.

I just saw  now in register map i found that for range of accelerometer need to change  AFS_SEL, which in code from examples is 2G => MPU9150_ACCEL_CONFIG_AFS_SEL_2G. 

In table down is shown  full range scale and AFS_SEL = 0,1,2,3

BUT does i have to change C code in CCSv6 to full range scale = +-2,4,6,8,16g OR  to AFS_SEL=0,1,2,3 to change range. I still don't have tools, else i will try it.

OR maybe to have more values for acceleration  i will need to change this code,  where i gues max frequency is 400 KHz:

//

   // Initialize the DCM system. 50 hz sample rate.

   // accel weight = .2, gyro weight = .8, mag weight = .2

   //

   CompDCMInit(&g_sCompDCMInst, 1.0f / 50.0f, 0.2f, 0.6f, 0.2f);

Do note that the use of 400KHz applies (only) to the I2C Master's "SCL" clock line - it is FAR from an effective, data transfer rate!

The actual transfer rate is likely to range between "one & two "orders of magnitude" slower" (closer to 2) - which is influenced greatly by the number (and data size/"number of bits") of data values you acquire during each I2C data transaction...

You may note that "I2C" is a "convenience" (due to reduced interface (2 connections)) - and is not recognized as, "Setting any land speed records - anytime soon."     (turtles have been seen "passing" I2C controlled hobby RC cars - usually after "high-beaming" the car (outta my way!...)

Hello cb1,  now i have my own connected launchpad and sensor hub, so i continued with measurements. Example with mpu_9150. Here is my measurement log file from teraterm:

mpu9150.rar

Hi there,

I'm not able to really interpret your log file as there are no labels which define/describe or bring order to the mass of data.

Here's how your first line of data appears - at my side:

"0.323 0.244 9.765 0.030 0.020 0.018 10.500 -8.099 54.900 -1.163 1.859 36.384 0.949 0.014 0.012 0.312 0.356 0.190 9.807 0.029 0.019 0.018 9.600"

Do note that neither firm/I have experience w/"sensor hub" - thus I've no "expectations" as what the data represents.     (of course it is sensor data - but, "from which sensor" - and what was the sensors' data, "time of arrival?")

You were seeking data flow-put optimization - you've (now) demonstrated data acquisition - but NOT data rate - nor the attachment of data to any particular sensor.

Is your data (likely) to be valid?      How do you know?      Far more detail is required.      (devil (always) lurks - such details...)

Hello Bruno,
I had some problems with compiler, now it is 5.2.9 and it okay.
Yes i know that sensors have some capability. I saw in MATLAB that there is option for I2C data transfer. Yes i need float numbers in matlab, because i want to calculate if it is possible linear velocity = integral(acceleration) and displacement with 2 times integral of acceleration. For now send timestamp with light sensor for every single data, but with MPU example i have only 1 timestamp in begin of measurment. What about my first protocol? :D
DK reports - is it something warning for microcontroler?
btw is this where is made config of range and frequency of acceleration - g_sMPU9150Inst.pui8Data[2] = (MPU9150_ACCEL_CONFIG_ACCEL_HPF_5HZ | MPU9150_ACCEL_CONFIG_AFS_SEL_2G);

In MATLAB data type transfer with serial port can be ASCII, binary and binblock. It is not 100 % must to do with MATLAB, i just have to find displacement - where senshub is moved if it is possible. 

And here are options in MATLAB:

Good day!

bode miller said:

now it is 5.2.9 and it okay.

I'm not sure about the compiler versions, but I prefer to use the LTS versions, as they are promised to be Long Term Support. Currently using 16.9.3LTS for my projects.

bode miller said:

I saw in MATLAB that there is option for I2C data transfer.

Good to know, but it does not appy in this case. You have your sensor connected to an intermediate board, which is connected to your PC(Matlab) via serial port. Your acquisition from the Matlab point of view will be serial.

What I meant by asking if Matlab can read IEEE floats directly is that you could send the float serial bytes directly to the Matlab receiver. An example of what I'd try would be a simple protocol where each package would have a fixed size of 20 bytes. The contents would be:

offset / format / description

0x00 / INT32 / Counter

0x04 / float / ACCX

0x08 / float / ACCY

0x0C / float / ACCZ

0x10 / float / LIGHT

Later I'd add some sort of header, content identification and CRC, as our internal protocols here have - but that will do the trick to start.

Inside Matlab, you need to tell it that which byte means what (there has to be a way to configure those offsets and formats). Voila, now you just have to start sending serial streams. Since it is too risky that the transmission will get lost and Matlab won't know what is byte 0, you might need to add either a fixed set of headers or a terminator... Matlab docs will probably show feasible options.

One note about the counter: most likely you will need to tell Matlab about little endian versus big endian, as the ARM mcu is contrary to PC's. This does not affect the floats.

bode miller said:

DK reports

No, this means "Digikey says that..." - look up that sensor code in Digikey, it shows up as obsolete. Nothing technical about it, nor related to the MCU!

bode miller said:

MPU9150_ACCEL_CONFIG_ACCEL_HPF_5HZ

Now, I'm not looking at the sensor library documentation, but this parameter DOES SUGGEST your sensor is reading 5 times per second, way less than you need/expect.

I'll be glad if you can share the progress later on.

Cheers

Bruno

I am not sure can i make protocol..maybe will need more time.

I change code of .c program to printf only acceleration X Y Z in this way:

UARTprintf("%3d.%03d", i32IPart[0], i32FPart[0]);

UARTprintf("%3d.%03d", i32IPart[1], i32FPart[1]);

UARTprintf("%3d.%03d", i32IPart[2], i32FPart[2]);

In tera term i see:

//accX  accY accZ// =>//accX  accY accZ// =>//accX  accY accZ// =>//accX  accY accZ//

I read data type ASCII and data format %c in matlab, so now i have data for 3 axis accelerometer, but it is char format. I use function str2num in MATLAB to make this char to numbers. To have single var for every axis i take every first/second/third collum of vector accXYZ. So now i have accZ and here i  made plot of it:

My accZ values are double.

Now i will need time var. Maybe i will try to count time with MATLAB, With C maybe will be more flexyble, but i gues it will be easier with MATLAB. However time always is not enough and i have to go, Any advice is welcome :)

Have a nice day :)

Hello, Bruno !

I try to print float type data, but i couldn't. After that i read some for timers but probably i couldn't do it also.

I gues this is IQmath.pdf

d1.amobbs.com/.../ourdev_582876DTQPBQ.pdf

Thank you for the help!

Hello Bode,

bode miller said:

I try to print float type data, but i couldn't.

WHERE did you try to print it?

Just a bit more on the subject, let's take the "human" value 9.80665 (your standard acceleration in m/s^2). When you store that in float, the 4 bytes will be 0x411CE80A. I am quite sure that Matlab has something that allows you to receive such value and use it internally.

If you want to have some fun "seeing bytes for numbers", take a look at this converter: www.binaryconvert.com/convert_float.html

One thing about Tiva's vs. PC's: the standard size in a Tiva, as you know, is 4 bytes. Hence, working with 4-byte variables in your Tiva code will be much more efficient. Further, that's also the size used by the integrated numeric processor, so calculations between two floats in your Tiva are "almost as easy" as a sum of two integers...

In your PC, the standard size is 8 bytes. All the operations that your Matlab does happen with Doubles. Our same human number in double is 0x40239D013A92A305 (just for illustrating).

What strategy is more efficient? Your first real number is obtained inside the Tiva, and given that your sensor does not have enough precision to generate doubles, a float is good enough - and it will be faster to process. At some moment, you will need to convert float to double - either inside Tiva or inside the PC. Inside Tiva, all it takes is valueDouble = (double)valueFloat; BUT this is not wise for two reasons:

1) If you convert to 8 bytes before transporting to the PC, your communication layer will have to carry 8 bytes for that value, instead of 4. Unwise, right?

2) The PC is much more powerful than your Tiva, so let it be the PC the one to waste energy on such conversion!

Conclusion: all you need to do is find the Matlab chapter that teaches you how to receive a float value via a serial port transmission.

One more for the road? have you tried Octave? Matlab is the program of choice inside universities and big companies alike, mostly because the vendors do an EXCELLENT job at educational level marketing. But it is really expensive for small businesses. Octave is supposed to be a decent open source alternative with a very similar interface and set of features. I tend to defend good paid software - but on this particular case, I still find ML a bit too high on an investment.

As for the IQMath fie that you linked, yes, that's the thing I was talking about - but note that your link points to a 2010 version, while the current document is from Feb 2017. It is available inside the /docs folder on your Tivaware installation. Wiser to learn from current sources.

Regards

Bruno

I try to UARTprintf float numbers from microcontroller to teraterm, but as ARM not support it i couldn't do it with iqMATH functions. I don't know how to write C code to printf trough UART float numbers. 

Yes your link for convertion decimal to binary, show very how many bytes we need.

bode miller said:

I don't know how to write C code to printf trough UART float numbers. 

I don't know that API you use for sending arrays to your UART.

We prefer to use sprintf to generate the text arrays, and only then output to whatever destination we want. Assuming some sort of UARTprint() function, this would work for the particular issue above:

	char stringArray[64];
	float value = 9.80665f;
	sprintf(stringArray,"This is a float: %010.6f",value);
	UARTprint(UART0_BASE,stringArray);

It would send "This is a float: 009.806650" to your serial port.

I did not understand the other part where you last mentioned iqMATH...

Robert

I have presented lots of arguments against the usage of integer, and you decide to write this to avoid sprintf issues...

Sorry but you are totally off.

The sprintf part of the conversation was just about poster seeing the values in a terminal program, possibly for debugging.

I won't repeat myself, but if you have time to spare, go back and read the whole story.

Bruno

Robert Adsett72 said:

I have, I stand by my statement.

Why have engineers bothered to incorporate a hardware floating point processor on their units??? They could just all go sell PICs...

No problem! I won't argue anymore. I had mentioned advantages on occupying less memory, using less processing, and more important, using less bandwidth for transmitting the values. Your argument is that integers "are simpler". You win!

Carriages are simpler than planes...

Bruno Saraiva said:

Robert Adsett72

I have, I stand by my statement.

Why have engineers bothered to incorporate a hardware floating point processor on their units???

Bruno, you are reacting to something I did not say or mean to say. It is not that floating point should not be used but rather that it is a problem in the interface.

Bruno Saraiva said:

I won't argue anymore. I had mentioned advantages on occupying less memory, using less processing, and more important, using less bandwidth for transmitting the values.

For the interface, at least, those are wrong. Using floating point, especially with printf variants takes more memory, more processing and more bandwidth. There are also re-entrancy issues. It does require less thought and design. And yes that's even with a co-processor.

I don't think there are reasons not to use floating point in the processing section of this code but I do think there are good reasons to avoid it in the interface.

Robert

There are some issues with floating point in the main code in general but they are secondary to the interface. The co-processor address more or less successfully the performance issue. A proper library will deal with re-entrancy. Interrupt overhead (and task switching) is still a potential issue but manageable if it's considered in advance. More subtle are numerical issues like catastrophic subtraction, and the lower precision afforded by floating point.

Robert Adsett said:

Bruno, you are reacting to something I did not say or mean to say.

Hey, Robert - no worries!

My reaction was to the blunt: "For this project integer is probably better."

I had been minding the original task: read sensors and send the values to a PC for Matlab visualization, while you were now focusing on the visual output of the values via terminal.

Of course, they are two completely different things - the only reason I'd see for poster to want to see the value on a terminal is debugging... otherwise, he should "look at the number" already inside Matlab.

Cheers!

Bruno