FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

How can I log LSM6DSOX sensor data and timestamps at < 1ms resolution using the SensorTile.Box at 6666Hz?

Go to solution
OlaBola
Associate II

‎2022-05-18 05:57 PM

Hello, I recently got a SensorTile.Box and wanted to log accelerometer and gyroscope data from the LSM6DSOX along with the time at which the sensor output was recorded. Importantly, I want to do this at the highest frequency possible (6666Hz) with microsecond and possibly nanosecond time resolution.

To attempt to accomplish this I used the "ST BLE Sensor" app from the Google Play Store. I entered expert mode and configured the following inputs:

  • IMU Accelerometer sensor (6666Hz)
  • IMU Gyroscope sensor (6666Hz)
  • RTC (Time)

I configured the app to output to the SD card.

After uploading the app to the SensorTile.Box and logging some data on the SD card I took a look at the logged data. There were two problems:

  1. I calculated the data rate of the sensors by dividing the number of samples in the log file by the time it took to capture the data. The calculated data rate was ~1600Hz! Much less than the 6666Hz I configured. Why am I not able to log data to the SD card at 6666Hz?0693W00000NqEBxQAN.png
  2. The timestamps in the csv log file were in "hh:mm:ss.ms" format. For example: "12:18:27.854". Is it possible to capture microsecond and nanosecond data from the sensors? At higher data rates many timestamps are the same since the data is being logged at a higher rate than the time log can change. I want to be able to know exactly when the sensor output was made.

I looked into some STM32CubeFunctionPack_STBOX1_V1.3.0 code to see if there were any solutions.

In the "DataLogExtended" project I was able to stream data via a USB cable and view it via Unicleo-GUI. The logged time there had microsecond accuracy but I am unsure if that time is coming from the SensorTile.Box or from my PC. Which is it? Also, when I calculated the true frequency of the logged data it was 4280Hz when I had configured it to be 6666Hz.

0693W00000NqECHQA3.png 

In the "SDDataLogRToS" project data is logged to the SD card every 10ms. When I changed the code to make the logging period 1ms and recompiled it and uploaded it to the SensorTile.Box it would not log data at all.

0693W00000NqECMQA3.png 

In conclusion:

  • What is the highest possible time logging resolution I can have when logging to {SD card, usb cable}.
  • Is the highest possible time resolution different if I use the ST BLE Sensor app or if I write a custom program and compile it.
  • Why am I not able to log at the configured data rate of 6666Hz? Why is the true data rate always lower?

I would appreciate any help and assistance with these problems. Thank you very much 🙂

Kind regards

1 ACCEPTED SOLUTION

Accepted Solutions
Go to solution
niccolò
ST Employee

‎2022-06-09 02:01 AM

Hi @OlaBola​ ,

let me try to answer your questions

the difference between expected data rate and the one that is saved on sdcard is high, but keep in mind that the default fw for sensortile.box is not as accurate as a custom firmware made for logging.

mainly because it is built with so much feature embedded, that a precise log at 6kHz is not its target.

there is also a problem with FreeRTOS, on which the firmware is built: the smallest timing set at 1 ms, so it is hard to work on timings lower than that (ODRs > 1kHz).

while the accelerometer and gyroscope data is buffered to be written at a higher speed, I don't think that the RTC data is buffered too.

so, on this topic, it is not possible to see the EXACT timing of the data.

your best option, is to develop a custom firmware to log the data.

starting from STM32CubeFunctionPack_STBOX1_V1.3.0, as you did, is the right way to go, in my opinion.

remember that you can check the difference in percentage of the effective ODR (and Timestamp Rate) with respect to the typical by checking register INTERNAL_FREQ_FINE (63h).

in the DataLogExtended project, the timestamp should be the one from the board, so the microseconds are right.

there can be a problem in both ODR accuracy and usb optimization in the code, you can check that with the register I mentioned above.

using SDDataLogRToS is not easy, because, as with the default firmware, a RTOS is involved.

in conclusion:

  • What is the highest possible time logging resolution I can have when logging to {SD card, usb cable}.
    • I'd say that the limitation is in the firmware itself, and the precision of the ODR (I'd say 6500Hz at the lowest)
    • the precision of the ODR can be checked
    • the firmware should be developed using FIFO, bufferization, and right timings to write without losing data
  • Is the highest possible time resolution different if I use the ST BLE Sensor app or if I write a custom program and compile it.
    • yes, the resolution is different, mainly because of the limitations of a fw developed with a wider set of tasks to perform in mind
  • Why am I not able to log at the configured data rate of 6666Hz? Why is the true data rate always lower?
    • as I wrote, the problem could lie both in the fw and in the precision of the sensor's ODR

hope this helps

Niccolò

View solution in original post

0 Kudos
1 REPLY 1
Go to solution
niccolò
ST Employee

‎2022-06-09 02:01 AM

Hi @OlaBola​ ,

let me try to answer your questions

the difference between expected data rate and the one that is saved on sdcard is high, but keep in mind that the default fw for sensortile.box is not as accurate as a custom firmware made for logging.

mainly because it is built with so much feature embedded, that a precise log at 6kHz is not its target.

there is also a problem with FreeRTOS, on which the firmware is built: the smallest timing set at 1 ms, so it is hard to work on timings lower than that (ODRs > 1kHz).

while the accelerometer and gyroscope data is buffered to be written at a higher speed, I don't think that the RTC data is buffered too.

so, on this topic, it is not possible to see the EXACT timing of the data.

your best option, is to develop a custom firmware to log the data.

starting from STM32CubeFunctionPack_STBOX1_V1.3.0, as you did, is the right way to go, in my opinion.

remember that you can check the difference in percentage of the effective ODR (and Timestamp Rate) with respect to the typical by checking register INTERNAL_FREQ_FINE (63h).

in the DataLogExtended project, the timestamp should be the one from the board, so the microseconds are right.

there can be a problem in both ODR accuracy and usb optimization in the code, you can check that with the register I mentioned above.

using SDDataLogRToS is not easy, because, as with the default firmware, a RTOS is involved.

in conclusion:

  • What is the highest possible time logging resolution I can have when logging to {SD card, usb cable}.
    • I'd say that the limitation is in the firmware itself, and the precision of the ODR (I'd say 6500Hz at the lowest)
    • the precision of the ODR can be checked
    • the firmware should be developed using FIFO, bufferization, and right timings to write without losing data
  • Is the highest possible time resolution different if I use the ST BLE Sensor app or if I write a custom program and compile it.
    • yes, the resolution is different, mainly because of the limitations of a fw developed with a wider set of tasks to perform in mind
  • Why am I not able to log at the configured data rate of 6666Hz? Why is the true data rate always lower?
    • as I wrote, the problem could lie both in the fw and in the precision of the sensor's ODR

hope this helps

Niccolò

0 Kudos
Top