Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sample at regular intervals #7

Open
erichiggins opened this issue Feb 20, 2019 · 1 comment
Open

Sample at regular intervals #7

erichiggins opened this issue Feb 20, 2019 · 1 comment
Labels
accelerometer Issues relating to the open-source accelerometer project.

Comments

@erichiggins
Copy link
Contributor

As of today, acceleration data is collected as fast as possible. This means that sometimes there's a 1ms gap between samples, and other times it's 2ms. Ideally, samples should be evenly spaced.

Note: Other performance changes may be required before this is implemented. The unit could be configured to run faster, at which point, adding delays between samples will be a luxury feature.

@RipVW
Copy link

RipVW commented Feb 21, 2019

@erichiggins On p.34 of the data sheet there are several sampling rates listed, one of which is 400 Hz. It might be that this is fast enough if you're just visually inspecting the graph for pre-shot flinches. If so, then priority could be shifted to buffering data while the SD card is busy. You could set up an interrupt when the data is ready (every 2.5 ms) and while waiting for the interrupt you could empty out the buffer if the SD card isn't busy, and still have time for a nap.

Personally, I think using the interrupt scheme would surely work for the 1.25 kHz rate and very likely work for the 1.6 kHz rate. I think there is also a good chance of setting the rate for 5 kHz and reliable capturing ever other reading, for an effective rate of 2.5 kHz. I have no hope of getting to 5 kHz with the Cortex MO clocked at 48 MHz.

To get to 2.5 kHz I think there are two strategies to try. The first and probably the easiest is to ignore every other interrupt. Secondly, in addition to the accelerometer sending an interrupt when data is ready, it also sets some bits in a status register indicating that new data has over written previous data that was never read by the Cortex. Seeing that data has been over written would indicate that at least one a sample has been skipped. I suppose 5/3 kHz is also a possibility by ignoring two interrupts and then acting on the third one.

In the interest of yak shaving, I have opened an issue on how to talk directly to the accelerometer.
I think you'll find talking directly to a device's registers will be helpful with a wide range of devices. Later on I think it'll be interesting to compare reading data directly from the accelerometer compared to having the library do it for you. Anyway, it seemed like a good time to shave that yak before getting into how to set up an interrupt when data is ready.

@erichiggins erichiggins added the accelerometer Issues relating to the open-source accelerometer project. label Apr 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accelerometer Issues relating to the open-source accelerometer project.
Projects
None yet
Development

No branches or pull requests

2 participants