Recommendation for hardware options on long-term audio recording and processing
huggybearikf wrote 10/08/2018 at 03:38 • 2 pointsHi guys! I'm a developer by trade and I'm looking to make a I'm currently building a device that will analyze drill bit efficiency/wear-and-tear via audio and raise a warning when its over a certain threshold, and I'm planning to put the whole thing on a arduino/rasberry pi board. I was hoping to get recommendations on hardware set-up for that will support the recording and later analysis logic.
I was able to run analysis of the data relatively easily on small segments of recordings that I got via a recorder pen, and am now looking to test and record over a longer term (~1 week). I am looking for a set up to either store large amounts of audio files or set it up to stream/audio files onto cloud storage in the testing phase, and then run the processing/analysis logic in the long-term.
Any help would be welcome!
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
A long time ago I worked in machinery management and we'd always take a tacho signal from rotating machinery so as to make it possible to do synchronous averaging. If you are able to fit an opto sensor to obtain the rotational speed your signal processing could get much more ambient noise rejection.
Are you sure? yes | no
Assuming your are comparing variations of spectral signatures over time, you might consider performing an FFT on your audio data in real time, and then storing the analysis results in the frequency domain at whatever time resolution you actually need. Should you need non-deterministic spectral data as well, there are methods for extracting that in real time as well. Depending on the time resolution necessary, this could drastically reduce the amount of data that needs to be stored in the first place.
Are you sure? yes | no
Hmm good idea on storing FFT, I was doing similar analysis on it anyway but had concerns whether raspberry pi would be able to handle the calculation in real time. Will definitely give it a try!
Are you sure? yes | no
Storage: 1 day of data is only about 7gb at 48khz/16bit mono. That means 1 week is only about 54gb of data, you can easily buy 64gb usb pendrives. Or you can use raspberry to stream to remote server. Look at vlc, that often is enough. Otherwise you can just write some script which will split your data into segments. These days 7gb daily is small amount of data. And if you really wanted speed, you can use ssd drive, connect it to rpi via cheap sata-usb case, then when you have more data, connect it to your computer for analysis. At 500MB/s your data could be analysed at 14s/day, or 98s for full week.
Recording - for testing any cheap soundcard should be enough, but on raspberry it STILL often happens that you will get stalls and pauses in data due to usb handling.
Are you sure? yes | no
Good shout on the VLC! I've been planning to do most of my analysis on the board so I've been looking at either recording/chunking/upload, but I might try to set up VLC streaming as a stopgap first. Much easier to set up.
Are you sure? yes | no
The sound will vary based on the speed of the drill, material being drilled and ambient sound/echos. You would be better off looking the current draw compared to the RPM. It would be different enough between materials that you likely determine what's being drilled.
Are you sure? yes | no
Thanks for the tip! Ambient noise and echo is definitely a factor, but I found it relatively easy to control for that through software. I'll definitely look into draw/RPM, but I'm trying to not interfere with the machinery in question for now, so I should be able to measure current draw from socket but RPMs might be difficult.
Since the machines in question is/will be dedicated to milling particular metals I think I would be ok by sound, as the change in pitch is very obvious when the bit is "worn down.
Are you sure? yes | no
If your script had enough smarts, it could automatically detect that it's other material or drill bit by sound. If analysis is going realtime and continuously, you could inventarise bits by looking for drastic changes between machine runs and just look at samples at start and end of machine run.
Are you sure? yes | no