Sensor TileBox Pro

[Smithson]

We want to use the Sensor TileBox pro to measure temp pressure and acceleration in structures.  

We have been using some of your boards the MKI versions and they will run at a maximum of 1400 time steps per second when configured for about 2000.  

I have the tilebox pro exporting on the USB and picking it up with a new C# program.   See below. 

It is reading at 18 cycles per second, I need to adjust the freq output, I thought I had a higher rate. 

it is really easy to use, but I have the Android Program setting 75 from pressure and temp and 480 for acceleration and getting 18 time steps per second.  Is this your board's limitation on exporting via the USB cable.  

Where am I supposed to post this?

[Federica Bossi · Accepted solution]

Hi @Smithson ,

The USB data transmission limit for the Sensortile.box PRO is approximately 100 samples per second.
Try creating a flow with a Bluetooth output (instead USB), then plot the accelerometer data in the app, and check that it runs at 100 Hz.
Then switch the output flow to USB and test your system again.

[Smithson]

Dear Federica:

Thank you for your response, I appreciate the effort.

I have looked at the matter based on your idea and it helped me find the cause of the error.  

I need data that will stand up in court, so being able to explain the data in the simplest possible terms is important. 

Your cli_example program works fine.  I like my version, but that is personal preference and the fact that I am matching other data from other accelerometers both ST.COM and no-ST,com, means that we want a standard form of output. 

The gold standard of accelerometers is the CX1, but they are very expensive, Your david.reynoldson@st.com

so kindly introduced me to the MKI series, we have used them for about 3 years.  We have sorted out most of the issues but not all, but as a backup to the CX1 they are useful.  

The Sensor TileBox pro is a neat step forward in technology, but the software is challenging.

The dat format was a bit of a math puzzle, but I am sure we have that sorted out, I even understand your basic time stamp algorithm.  I have no doubt I am getting from my C# program the correct acceleration output and time. 

But your CSV file format has been a real challenge from the MEMS Studio. 

Problem 1, you try and upload all of the different sensors to one csv file using a common time signal.  That is not possible in a applied mathematics sense.  Your sensors can run at different rates and the flow of information  also adds timing errors.  

Problem 2 you cram all of this data into a single csv file.  If run the accelerometer at about 1800 Hz, it runs fine using your main program over a USB cable at this speed.  It just saves the dat files.  But the other devices are running at 4 times the 1800 Hz for the gyro and other speeds. So MEMS Studio is trying to cram all of this data into a single time signal.  I now understand how it works, can I say simply it is a very bad idea.  

Looking at the time signal from a run this morning of 19.1 seconds.   You have steps that are not a standard distance apart, this is your algorithm adjusting for the varying measurement rates.  A sample output is shown. 

If I look at the differential timing, you can see the pattern and it is not what one expects, nor is it explained in your manuals.  This is the timing steps.  

If I look at the acceleration output,  your method has introduced a pseudo flat step and triangular step into the time signal, this will show up in any post FFT analysis of this data.   And it will play with the numerical integration, so beloved of engineers.  You fill up the gyro time steps with the last acceleration data and create a flattish spot. See example.  Like determining volumes from contour data, one has to make a decision, I understand this decision, I think it would be easy to improve.  

I cannot use your mems studio, but I do not need it.  I was using it to check my program, but I am sure my program is correct, I am happy it runs at 1800 Hz over a USB cable,  I would like to get the code for the three dll's so that I can switch from g++ to Intel, I really like MSVC and I really hate using batch files to compile a program.  I know there are a lot of Linux users who love g++ and make files, but really that is so 1980's.  The datalogging code, I would like to make so it just outputs constantly, yes, there is auto-mode that is the next step.  

Great device, great support, but the csv is challenging.  You should explain it somewhere so it can be understood.   

Separate csv files would be best at constant timing intervals.  

Thanks for all the help, been a lot of fun. 

John

[Smithson]

Dear Federica:

The quick solution to the CSV gap problems is Hermite Polynomials. Quick, dirty and rather useful, but it would be a better smoothing solution than linear. 

Regards

john.