PyTrack's Accelerometer sampling rate

[Nikhil parashar]

Hi,
I am working with Fipy, PySense and using function acc.acceleration() to read the acceleration sensor.
It is sampling 30 samples in a second at max which is very low for my project.
Please tell me how to increase the sampling rate of the acceleration sensor of the PyTrack.

[Gijs]

Hi,
Im not sure what sampling rate you're looking to achieve, but the default sampling rate of the accelerometer is set at 50Hz (see the LIS2HH12 source file, method self.set_odr(ODR_50_HZ)). You should be able to change that to increase the sampling rate

[Nikhil parashar]

Thanks Gijs for reply. I am considering sampling rate as number of accelerometer values in 1 sec. in my case it is giving me around 30 values in a second. Thanks for the method self.set_odr(ODR_50_HZ). I have done this but it is also not working. I have also changed the const(0x60) in the CTRL1 register but same result.
Please suggest me anything.

[jcaron]

@Nikhil-parashar The implementation in LIS2HH12 library is pretty basic and reads each of the 3 axis in turn, one by one, which probably isn't very efficient. Not sure if that's the limiting factor here, but if you want to receive data at high data rates, you probably need to:

• Activate one of the FIFO or stream modes (see section 5.3 of the datasheet)
• Read larger amounts in one go. You can read all 6 bytes in a single I2C command, and you can even read multiple sets as the address counter will loop back to the first output register (see section 5.3.8 of the datasheet).

This has been discussed here and here, though apparently not very successfully, with I2C bus issues.

Also micropython is probably not the most suitable environment to read realtime data in this fashion. The FIFO is quite small and is easy to overrun if you use the higher update rates.

What are you trying to achieve with high sample rates?

As much as possible, you should let the accelerometer do things internally (e.g. detect if acceleration goes over a threshold, for wake-on-motion, tap detection, pedometers, etc.), and only get interrupts when the conditions are met.

If you are trying to do dead reckoning / inertial navigation then I'm afraid this is probably not the right combo to get any decent results unless you have a relatively stable environment (i.e. device fixed in a car on a highway as opposed to someone walking and holding the device in their hand). A real integrated IMU (which does the integration on-chip) will probably get you better results (and you're lacking a magnetometer and gyroscope anyway), within the limits of inertial navigation of course (after a few minutes you'll be meters away even in the best conditions).