December 2016
Modern MEMS accelerometers are amazing, and cheap enough that nearly anyone can mess around with them. Lately I've been playing around with this 'accelerometer dongle' from Sparkfun (now retired). It contains a 3-axis, 1.5g accelerometer (MMA7361) with analog output, which is digitized by an ATMega328 microcontroller and streamed as ascii over RS232. Trying to find something to test it on, I wedged it against the top of my refrigerator. The measurements turned out to be a lot more interesting that I expected.
At the maximum sample rate (250Hz), a one second acceleration sample from a single channel looks something like this:
Let's take a look at what frequencies it contains, by taking a Fourier transform of a longer sample (5 minutes):
There are some peaks in here, but it's not obvious what they correspond to. So far, this still doesn't seem very interesting. But now let's go one step further and record several 5 minute samples over the course of about 10 hours. With this we can build an image plot of frequency vs. time (aka spectrogram):
Every column in the image corresponds to one Fourier transformed 5 minute accelerometer sample, and the colour denotes intensity (white=no signal, black=strong signal). This being a mains AC powered refrigerator in Europe, it seems reasonable to guess that something will be happening at around 50Hz. So lets zoom in:
Cool! You can see a vibration peak every time the compressor turns on to drag the temperature down. The compressor is turning on and off every 10 minutes, so probably the seals need replacing. We just measured the thermal insulation of a refrigerator by using an accelerometer - this qualifies as Stupid Metrology.
We could call it a day at this point, but if you look closely at the zoomed in spectrogram above, several questions might occur to you:
Why is the frequency varying on long time scales?
Because the frequency of mains AC is not perfectly stable. It is apparently managed such that the long term average is 50Hz (reference), but small variations are completely normal. You can see this in real time here. Alternatively, you can use your multimeter for a local measurement. I measured the secondary coil of an old 9VDC wall adapter, since it didn't seem wise to just jam some probes into the wall socket and leave it overnight. A 7 hour sample using an HP34401 multimeter looks like this:
The variation is approximately ±0.1Hz, well above the specified meter accuracy of 6mHz. It's clear that the level of variation in the vibrations could be accounted for by mains drift. To make that even more obvious, we can measure both simultaneously:
Why is the vibration not 50Hz?
Either the vibration really is slightly slower than mains, or the accelerometer dongle is not measuring accurately. For example, if inaccurate timing produced a sampling frequency of 253.6Hz instead of the nominal 250Hz, a true 50Hz vibration would appear as 49.3Hz. Is it plausible that the microcontroller clock rate is about 1.5% faster than it should be?
Since Sparkfun is diligent about making product details available, it's easy to discover that the microcontroller on this board is clocked by an 8MHz resonator. Typical frequency tolerances are 0.5% (crystals give 0.005%). This is loose, but it's not the 1.5% we need to account for. A too-fast clock source could be part of the reason, but it can't be the whole story. It's also possible that the firmware introduces timing errors ... SparkFun make the code available, but I won't dig that deep because there's a much more likely explanation.
Is it plausible that the vibration is about 1.5% slower than mains AC? If, like me, you don't know a lot about AC motors or refrigeration compressors, some research is required. Most household refrigerators operate on a piston-style compressor (which is the source of the vibrations), driven by a single phase induction motor. Induction motors are fascinating devices, and importantly for us physics dictates that to develop any torque they must spin slightly slower than the frequency of the AC source - typically by 1-5%. Case closed!
So although it would have been obvious to an expert or to anyone who read the refrigerator manual, we independently discovered that the compressor motor must be an induction type.
Why are there sharp 'tails' down to lower frequencies each time the compressor starts?
A higher resolution spectrum (2 minute samples) will clarify what we're talking about:
Every time the compressor starts, there is a sharp rise of about 0.45Hz, followed by a small increase of about 0.015Hz/min.
At this point we cross over into speculation (please email me if you know the answers!). The fast initial rise could result from the startup process of the motor. A simple single phase induction motor has zero torque if the rotor is not moving, so some extra circuitry is required to get things moving (reference). A typical configuration is to send some of the drive current through a series capacitor to a second set of coils in the stator. The capacitor causes a phase shift, simulating a second AC phase and enabling the motor to start spinning. Once started, it's preferable to revert back to single phase operation. This is commonly achieved with a series PTC thermistor - here's a schematic from a refrigerator service manual:
After a few seconds the PTC heats up, becomes highly resistive and most of the current is redirected to the main coil. But big mains PTCs can take up to 30s to trip, so there is a period of a few seconds where the motor drive current is ramping up to its final value and therefore the rotor is accelerating. In our 2 minute sampling window, this would show up as a frequency streak.
Why does the frequency slightly increase on short time scales?
We established that induction motors have some frequency lag compared to the AC excitation. The magnitude of the lag depends on the motor loading: decrease the load and the lag decreases. So it seems from the data that the compressor has slightly less work to do the longer it runs. Is that plausible? It seems to naively make sense: ultimately the motor is doing work to pump heat out of the refrigerator. As the internal temperature reduces, less heat flow is possible, so you'd expect less work for the motor. But exactly how and why? I'm no refrigeration expert and my thermodynamics is pretty rusty, but let's try to go into a little more depth.
Since we want to know about how much work the compressor is doing, it would be helpful to look at a pressure-volume diagram for a reciprocating compressor:
In a P-V diagram the total work done is given by the area of the process loop. What can reduce the area of this loop? Points 1 and 3 are fixed by the properties of the compressor (piston volume and valve settings). But point 4 can move right if the refrigerant pressure increases at the inlet, and point 2 will move left if dP/dV decreases (i.e. it takes more of the piston stroke to reach the final pressure). Differentiating the ideal gas law suggests that dP/dV is proportional to temperature, meaning that if the incoming refrigerant is colder, the compressor will have less work to do.
Now look at what's happening in the evaporator coils in the refrigerator:
The liquid-vapour refrigerant mix running through the evaporator coil stays at a constant temperature by undergoing a phase change (liquid boils off). But once all the liquid has evaporated, the refrigerant solution can and does increase in temperature as it continues to absorb more heat. So now we have all the pieces for a theory:
This is some prime-grade Stupid Metrology: in an extremely convoluted way we are getting information about the internal temperature of a refrigerator by measuring how it's shaking.
Vibrational analysis is more broadly applicable than refrigerators, so maybe this discussion inspires you to try something similar, in a car for example. It can be surprising how much information you get out. Sparkfun and adafruit sell accelerometer breakout boards, but not complete modules like the one used here - you'd need to take care of the interfacing microcontroller to get information to a computer.
(All analysis and plotting was done in Igor Pro)