You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
@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.
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.
The text was updated successfully, but these errors were encountered: