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

Filter non-motion data #5

Open
erichiggins opened this issue Feb 20, 2019 · 6 comments
Open

Filter non-motion data #5

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

Comments

@erichiggins
Copy link
Contributor

As of today, the unit records data as long as it's powered on. For the purposes of firearm acceleration, the resulting dataset also includes time between shots when nothing is happening. This non-motion data isn't particularly useful, and wasteful in other ways:

  • Takes up more space on the SD card
  • Requires more write-ops
  • Slows down data analysis (filtering is required)

Ideally, the sensor could keep, say, 10-30 seconds of data in a FIFO buffer, That data won't be written to disk until it contains motion.

Keep in mind:

  • At least one axis will always detect Earth's gravity.
  • The sensor is full of noise (e.g. it won't always read zero when there is no motion)
@RipVW
Copy link

RipVW commented Feb 21, 2019

I think this would be very hard to do in real time. Your 3DH does have a FIFO buffer, but only a few samples worth. I doubt even the Cortex can store 30 seconds of data at 1+ kHz. (I tried storing 500 lines of csv data in an array and things started getting really weird.) On the other hand I think it would be easy to write a script that would sort through a huge data file, identify the shot events, take an excerpt of the huge data file starting a few seconds before the shot to a few seconds after the shot, then save that excerpt as a csv file with a filename such as dateTime_shot_xx.csv

@erichiggins erichiggins added the accelerometer Issues relating to the open-source accelerometer project. label Apr 12, 2019
@jasza2
Copy link

jasza2 commented Jun 15, 2020

Great project, thanks for sharing. I will try port it to the teensy3.5 chip which is super fast at writing data to SD card, I also regularly use arrays to store GPS and other sensor data so i think it would be possible to buffer the data and then dump it to the SD card after a shot.

I logging data against an actual time of day is important, as well as easy and live downloads to mobile devices , I can port this code to an ESP32 chip to which you can connect your phone over wifi or bluetooth.

@erichiggins
Copy link
Contributor Author

@jasza2 That's great! I'd love to see the results!

@jasza2
Copy link

jasza2 commented Jul 13, 2020

@erichiggins FYI I had a sparkfun Razor IMU on hand: https://www.sparkfun.com/products/14001 so I wrote a data logger similar to yours, with the addition of a small OLED screen that displays the accelerometer chart and max. G. force experienced immediately after the shot.
It sits dormant, logging a few seconds of data in memory, and discarding it, until it gets a G force of over 2.0G and then it logs for a set period and keeps it, and displays it on screen.
This same code could be re-written on your hardware but I dont have your hardware on hand.

Apart from compactness, There is no compelling advantage of the sparkfun Razor over your design , but the Sparkfun Razor does have bulit in battery support for small LIPO batteries, plus its all in one neat package (excluding the OLED dispay which needs to be soldered on).
The disadvantage of the Razor is its more expensive, and a few more steps are needed to get it setup initially (documented on sparkfun).

I will test my unit on my boy's air-rifle, and when i next go to the range, on my big boys rifle. In the meantime, can you tell me what the max G force is that you expect to log, and also how many readings over what time period must I log.
image

@erichiggins
Copy link
Contributor Author

@jasza2 Cool!

I loaned out the unit that I built and the people who are using it have it set to the 16G setting. Going from memory, the issue is that the higher G settings trade off resolution. So, it depends on what data on which axes you hope you track. For example, if you just want to track the trigger and recoil, you only need one axis and it could be fairly coarse. However, if you want to track the slight movements left/right up/down in the firearm while the trigger is pulled, then you need it to be both fast and precise, but not as high of a G rating.

Hope this helps!

@erichiggins
Copy link
Contributor Author

Hello! I wanted to make it easier for folks building these units to chat with and support each other, so I setup a Discord!

https://discord.gg/KvmKmK

This link expires in 1 day to keep out spammers, but feel free to contact me directly if you'd like an invite.

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

3 participants