ShakeFinder: A vibration sensor for stop-motion scanners

For my ReelSlow8 scanner one of the problems I’ve been running into is blurry frames caused by general movement anywhere near (or not that near) the machine.

I couldn’t think of any way to eliminate the vibration so I decided a workaround might be to detect any shaking during a capture and just keep retrying the frame until shaking wasn’t detected.

One cheap way to detect small vibrations is to use a piezo disc. This blog post from 2014 started me down the path of designing my own.

The final result turned out quite nice and useful. So I’d like to share it here for anyone with a stop-motion machine that might need something like this, too.

This is more of an electronics/design explainer video (and not required to build or use the sensor) but the first and last couple minutes include some nice demonstration clips:

Click for video:

Everything you need to build one yourself: ShakeFinder GitHub repo.

I paid special attention during the design to make sure it would work with Raspberry Pi’s 3.3V pin voltage limits because you RPi folks are the majority around here. :smiley:


@npiegdon - that is actually a very neat idea and a cool representation. Indeed, I encountered the very same problem with my scanner, house and kids (“solved” it by scanning mostly during the night). The grain of the film somewhat covers this shaking, but as soon as you degrain/enhance a film, it shows up as quite visible vertical wobbles on the footage. Will try your approach on a breadboard!

One tiny comment: The large mass of your setup acts as a fixed reference in space for one side of the piezo. Because the inertia of this mass is large, neither the mass nor this side of the pizo basically do move in space. Of course, the other side of the pizo tends to move with the table. That gives you your strong signal.

And finally: what a fantastic github documentation! You even included the .stl-file for the pedestal!


@npiegdon Well presented project, and documentation Nick.
Certainly a great tool to add to the arsenal of DIY scanning, well done.

Very cool design! Out of curiosity, did you consider a mems accelerometer like the ones found in cell phones? They’re widely sold in the form of a cheap module you can easily integrate with an arduino or other microcontroller.

A MEMS sensor would probably be another good, viable choice. I’m guessing you could shrink the final design down quite a bit, too.

Really, that blog post with the piezo discs piqued my curiosity enough to just head down one path without looking back. I’ve had a handful of them in my electronics bits box for years and was always curious what sort of V-I characteristics they produced. This was a good excuse to investigate and, like, bang on them with hammers and stuff. :rofl:

1 Like

Yep, makes sense! Fun project and very cool. Appreciate that you documented and shared!

Interesting question, as it touches on an old topic: analog vs. digital. The unit @npiegdon designed is doing most of the processing in the analog domain. A typical MEMS sensor does this mostly in the digital domain.

Let’s compare @npiegdon’s approach to a MEMS-based approach of an old MEMS acceleration sensor I have in my part bin, the Bosch BMA180.

First, by design, the piezo-based sensor is measuring only deviations of the standard g-force near the scanner. Technically, you see something like a derivative of the z-component of g(t). The BMA180, as any other sensor of its kind, is however supposed to measure the real vector components of g = (g_x,g_y,g_z). On earth, and given a proper orientation of the sensor, you can rather be sure that two of these three components are close to zero and the third one will be close to 1g. This creates a dilemma for your shake sensor design: in my example, the BMA180 features a 14bit ADC. You need to set the working range of the MEMS to at least 1g (to cover the earth environment) - so the resolution for tiny movements in the z-axis is limited. Indeed, the BMA180 features a 14bit ADC, which gives you a resolution of 0.25 mg in its 2g-mode.

Note that this MEMS-signal is g(t), not the temporal derivative (that is: the shaking signal) we are interested in. The MEMS-signal will most certainly be quite noisy, due to the quantization level of the MEMS’ ADC - so good luck to compute a reliable derivative signal out of the incoming data. Also, the further signal conditioning @npiegdon nicely describes in his video (handled basically by a few passive analog components) needs to be handled by the processor driving/reading the MEMS-sensor at a fast pace (Arduino/RP2040/Raspberry Pi might be the usual suspects). Implementing this processing consumes resources on the processing unit and yourself (during implementation) - you might end up in allocating an exclusive processor just for the signal conditioning purpose, with quite a handful of parameters to be tuned in the process. Not something I would go into…

Of course, you could make your life easier and simply switching the MEMS-sensor into it’s “Tap sensing” or “Slope detection” mode (if available). Indeed, the BMA180 would in fact do all the processing for you and just trigger an interrupt if it detected the specified event. But: you’d loose the easy adjustment to your environment (table, house, kids) @npiegdon’s analog approach features. Furthermore, you do not really have much insight into the specifics of the algorithm the MEMS-manufacturer implemented - besides the information he is willing to share with you in the datasheet.

So summarizing the above thoughts: a MEMS-sensor would initially not measure the signal we are after and thus require more compuational resources on the processor side. The digital signal conditioning needed to arrive at a usable “shaking” signal demands an elaborate processing pipeline. Even then, due to the limited signal resolution available with a MEMS-sensor, we might not get the sensitivity we’re after in this application. The latter challenge will also exist if the computing capabilities of the MEMS sensor are used, instead of an external processor unit. In summary: I think for the application we are discussing here, the old-fashioned analog way wins in many respects.

1 Like