I thought I had the data rate solved by changing it from the default LSM6DS_RATE_104_HZ to LSM6DS_RATE_833_HZ Problem is when I up my sample rate from 100hz to 250hz, I start to see duplicate entries in the data. The same value well be logged 2 or 3 times. At 100hz there was never any duplicate data.
Is a hard limit?
What does the specs say about the rate of internal measurements? Reading more often than that will obviously give the same answer until a new internal conversion is done.
Up to 1.6 KHz ODR
It looks like You're within specs, provided You got the right parameter.
This is beyond my ability for the moment. Tomorrow calls for entering the horizontal position.....
Are you sure you changed it correctly? The accelerometer and rate gyro have independent data rates, and the allowable rates depend on the selected operating mode.
I wrote a device driver for its bigger brother, the LSM6DSL, and the proper way to handle higher ODR is use the built-in FIFO buffer in the device. The LSM6DS33 apparently has 8 KB. You set it up to "buffer" the acc and gyro data, and signal an interrupt when it's 1/2, 3/4, etc full. You then do a bulk fetch of the data in a single I2C transaction.
...and that is something I missed. fixed and thx
I've managed 400hz. The data logger won't handle much more on a Mega. I'll look at the buffering method if switch processors. thanks for the info
When I say buffer, it's the LSM's own FIFO buffer. The LSM accumulate the data in it's own buffer, and when it reaches a configurable threshold, it signals an interrupt to the MCU. The MCU then retrieve the data at once in a single I2C transaction. This will actually improve the performance since you'll have less overhead in fetching individual acc/gyro datasets (12 bytes total if in 16 bit mode).
Yes, I was aware of this. Currently the project I'm working on uses one Accel/Gyro breakout. It's a prototype-proof of concept and we get some data to play with. Next version will have to measure the 7-DOF of the arm + measure movement in the forefinger-thumb. I was include the middle finger to have a 'complete' pen holder's grip but I think finger-thumb may be sufficient.
Having an 8k FIFO will decrease the processor load at the expense of memory. We need to 'sync' all events and log them for post processing. Merging 5 data streams will be a challenge.
thanks again.
HI,
I have been fooling with the Arduino WIFI UNO Rev 2 which has the LSM6DS3 inertial module on board. Since I ultimately want to transmit sensor readings by UDP at a high rate, I looked for a library to use. One such is the SparkfunLSM6DS3.h which I downloaded:
(GitHub - sparkfun/SparkFun_LSM6DS3_Arduino_Library: Arduino library for the LSM6DS3).
I have adapted the "FifiExample.ino" offered in the library. This works once you modify the initialization to: LSM6DS3 myIMU( SPI_MODE, 30 ). I'm also running it on VSCode on a Mac.
In addition to the separated data rates as noted above, there is also a "FIFO Sample Rate" setting and I am confused as to how this plays with the individual sensor (Accelerometer, Gyro) rates. I too have experienced garbage data as I experiment with the parameters.
I failed to mention that the Sparkfun_LSM6DS3 library does not handle the UDP socket routines. I selected this library for the routines that access the on board FIFO buffer on the module.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.