RoadTest: Sound and Vibration Measurement Hat for Raspberry Pi - Industrial Sensing
Author: shabaz
Creation date:
Evaluation Type: Test Equipment
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: This product is fairly unique; comparable products would either be sound cards, or audio analyzers.
What were the biggest problems encountered?: Nothing to speak of. There were very minor things addressed in the Appendix in this RoadTest review.
Detailed Review:
Contents
Measurement HAT - What is it?
What makes this Different to a Sound Card?
Measurement HAT Frequency Response
Measurement HAT Noise Performance
What can it be used for?
Accelerometer
What are IEPE Sensors?
How Does the Measurement HAT Work?
Standalone Operation and Coffee Machine Maintenance
Working with Small Vibrations; Watches and Clocks
Signal Generation
Analyzing Audio Amplifier Distortion
Frequency Response Measurements
Summary
What is it?
The MCC 172 Measurement DAQ (Data Acquisition) HAT board from Measurement Computing (let's call the board the Measurement HAT for short) has two connections for AC signals (1 Hz upwards) and captures them at up to 51.2k samples per second.
The Measurement HAT can be plugged on top of a Raspberry Pi to build a multi-channel data acquisition system with direct interfacing into Linux.
Multiple HAT boards can be stacked, with each one containing two channels. The channels are synchronized from board to board (there is a shared clock).
Here it is plugged onto a Pi:
Capturing data is easy because the board is supplied with plenty of example applications. For instance, within five minutes (provided you have a Raspberry Pi set up as usual), you can connect up a signal source to either of the two analog inputs (I used a 1kHz sinewave in this example below) and run the supplied logger application which shows this view in real-time, at the full 51.2k sample/sec rate:
This is fantastic, because it shows two of the most valuable displays (the time-domain view, and the frequency-domain view), in real-time, while capturing every sample to a log file.
Unlike oscilloscopes, the resolution is 24-bit, and you can customize the views or functionality because the code is open source. The code is easy-to-follow and of good quality, it worked well. I only found one minor bug that wasn't a showstopper. I was able to modify the supplied applications to create my own applications. The supplied code is written in both C and Python, so there are plenty of options to do what you like.
This RoadTest review makes use of Matlab in order to process the data, and control some of the tests. It is a convenient tool for working with signals and data. My fellow RoadTester Jan Cumps Jan Cumps , has developed LabView integration, so together, there are two powerful tried-and-tested software solutions (or combine them into one!) for working with the Measurement HAT if you wish to go beyond using it with the supplied code. I have also placed many sample data captures from the Measurement HAT at my mcc-daq-tools GitHub link, in case anyone wishes to analyze the data. The files are in CSV format, but some are in the tens of MBytes (Excel will likely be unsuitable, but you can use Python for exploring them, or Matlab of course, amongst other applications).
What makes this Different to a Sound Card?
Quite a lot! In some ways, a sound card can be a low-cost way to perform some data acquisition, but the costs rise rapidly as higher performance is needed. A lot of sound cards only provide specifications that are weighted toward human ear characteristics (A-weighting), which is not ideal when working with non-audio quantities. High-end audio codecs can still have higher noise in parts of the spectrum where it matters less for audio. For instance, high-end audio ADCs can have higher noise in the tens of Hz range, where it is harder for a human to detect it by listening. The ADC used in the Measurement HAT is the TI ADS1271 which has low noise in this range, in fact, all the way down to almost DC, making it more versatile for measurement applications. The chart here is from the ADS1271 PDF datasheet:
Comparing with a high-end audio ADC, the PCM4220 (the PDF datasheet only shows from 20 Hz upward):
In terms of harmonics, the THD+N chart for the ADS1271 is almost entirely flat regardless of frequency or input signal amplitude (charts below are from the ADC datasheet).
Here you can see the harmonics visible with a very large input signal, but at -20dB from full scale, they are not visible with the granular FFT:
Another big difference is that sound card drivers are intended for functioning with the audio pipelines for Windows or Linux, and so all manner of manipulations like gain adjustment may occur in-between the signal source and the application code. Some drivers can bypass the normal audio subsystems within Windows or Linux, but such drivers are usually only available for certain higher-end sound cards.
The measurement HAT uses a Serial Peripheral Interface (SPI) which bypasses Linux audio processing. Furthermore, there is on-board buffering, so that the application can accept the data at a slower rate, provided the buffer size is sufficient for the measurement or test being performed. At the fastest data rates, up to 0.5 seconds of buffering are available per channel, so it is possible to easily develop solutions that will capture all data with zero loss.
I really like that what is measured is precise, and there's no messing about manipulating sample amplitudes and adjusting software volume controls, which is what you'd normally need to do with a sound card, and still not be sure that everything is set up correct. The input range is very practical for a lot of measurements, without requiring any additional amplifier or attenuator. Those could be added if you want the best performance to suit particular tests of course.
The screenshot below shows a test where a maximum 10Vp-p signal was applied to channel 2 (blue), with channel 1 (red) shorted with a 50-ohm terminator (it doesn't need to be 50 ohms, this was just a convenient way to almost short it), and captured at the top sample rate (51200 Hz). The capture is on GitHub. The 'mess' around the peak in the FFT is in reality small, since it's a dB scale of course, and will almost entirely be caused by the limitations of the signal generator.
Anyway, long story short, the discrepancy between what was applied, and what was measured, for this 10Vp-p signal, was just different by 5.1 mV (I used an accurate multimeter, a Keysight U1282A , to measure the input signal). The conclusion was that the Measurement HAT values can be relied on, and in fact, makes a useful AC measurement meter.
Measurement HAT Frequency Response
I ran some measurements at spot frequencies and confirmed that the Measurement HAT is usable for most normal purposes, from 6 Hz upward. At 1 Hz, there is a -2.8 dB drop in measured amplitude. Note: for this chart, I relied on the signal generator (Keysight AFG31052 ) reported value for the input level.
Measurement HAT Noise Performance
The Measurement HAT combines an amplifier along with the ADC, and so comes with its own datasheet PDF specifications. According to that, the user can typically expect 207 nV/root Hz noise density, which means that if we are interested in observing in the frequency domain, the FFT noise floor can be as low as -153 dB from full scale (5Vp-p). In practice, the noise floor will appear higher with faster (fewer sample) FFT rates, but it clearly shows the Measurement HAT can provide high dynamic range spectrum measurements unlike an oscilloscope ever could. At practical real-time display FFT settings, you can easily obtain a noise floor below 130-140 dB from full scale (below 140 dB at 16384-length FFT, which will still provide an update refresh several times per second).
In the time domain, the noise will appear with a level of about 33 uV RMS. You can reduce the noise through digital filtering if you know your signals of interest do not use the entire 23 kHz bandwidth.
The power supply connected to the Pi can make a difference. For this test, I connected the Measurement HAT to a 50-ohm termination (this was just a convenient way to approximately short the input), and the Pi was powered using a Stontronics supply that was advertised as suitable for the Pi 4 and obtained a capture. I then repeated the test with an Anker mobile phone charger and the results below are clear. The Anker charger provides a slight performance advantage, however, it might not be able to sustain the peak current that the Pi 4 can demand, since it is intended to be used as a phone charger, not a Pi 4 power supply. I would say if you're integrating the Measurement HAT into your solutions, then spend some time choosing a good power supply source and USB cable. Fortunately, it is easy to see the effects of the power supply to evaluate it, as done here.
What can it be used for?
For this RoadTest, the Measurement HAT came with a vibration sensor (part code 603C01), known as an accelerometer, and this is intended for bolting to machinery, typically in order to understand if vibrations from the machine are healthy or if parts of it need maintenance. The sensor could also be attached to walls or the ground if there were digging operations nearby.
Another use-case for the Measurement HAT is to perform audio measurements, such as AC RMS as just seen, and also additional measurements, some of which will be covered in this RoadTest review. Since there are two simultaneous-sampling ADCs on the Measurement HAT, you could also use the board for measuring the phase difference between signals; this enables the HAT to be used as test instrumentation for impedance measurement for instance.
The Measurement HAT is also useful for data acquisition for machine learning purposes, where the Pi could be used to record events as well as the acquired signals, for easy labeling of data.
As I used the Measurement HAT more and more, I decided I really liked it as a general-purpose test instrument. If you want to quickly fire up the Pi and observe some data, a bit like an oscilloscope or spectrum analyzer, then appending the following to your .bashrc file is handy:
alias logger_gui='cd /home/pi/daqhats/examples/c/mcc172/data_logger/logger;./logger'
With the above entry, you can then just type logger_gui at any time to bring up the graphical view as shown in the introduction and start capturing and observing the oscilloscope-like and spectrum-analyzer-like views of signals within seconds.
In normal use I do not have an HDMI monitor or keyboard attached to the Pi; I use Windows Remote Desktop. There seems to be a long-term issue with Pi OS builds, in that the 'pi' user cannot use Windows Remote Desktop Connection. The quick fix is to create a new user – you'll have to assign i2c, spi and gpio group permissions for the new user:
usermod -a -G i2c shabazusermod -a -G spi shabazusermod -a -G gpio shabaz
Another option is to use VNC, but Windows Remote Desktop always performs faster/better (it seems to me).
Accelerometer
The photo here shows, from left to right, a BNC-to-MIL-C-5015 connector, the accelerometer itself (model 603C01 see the PDF datasheet from IMI Sensors), and a 1/4-28 UNF set screw. The set screw sticks out so it can be used as a stud to attach to the desired machinery.
The accelerometer is powered from an inline constant current source which the Measurement HAT can supply under the control of the Raspberry Pi.
I tapped the required 1/4-28 UNF hole into a block of aluminium, and superglued a magnet onto one side of the block for attaching to metal machines. There are more stringent requirements than this for effective coupling, especially for high-frequency vibrations, and so for a proper machine test in a factory, you'd want to spend more time designing the way to physically connect your machine to the sensor. The sensor PDF Product Manual discusses this in a little more detail.
The constant current source can be switched off if the accelerometer is not used, and the Measurement HAT can then be used with all sorts of other signal sources.
What are IEPE Sensors?
Although it's not important to know in order to use the Measurement HAT, it is worth briefly exploring how the accelerometer functions and what IEPE is all about. In a nutshell, the accelerometer consists of ceramic or piezoelectric elements connected to an amplifier, all enclosed in a metal shell. The connector only has two pins, so power needs to be delivered on the same pins as the signal will appear on. The sensor expects to see a constant current supply of about 4 mA, and the sensor will set its DC bias such that about 10V or slightly more will appear across it. Any vibrations will cause an AC signal to be superimposed, and depending on the sensor and the stimulus, that AC signal can be large (10Vp-p can be expected). The benefit of the IEPE interface is this large dynamic range and that it supports a frequency response beyond tens of kHz, as well as the ability to operate over long distances in noisy environments because the output impedance is low. The disadvantages can be the sensor's large power consumption (50-100 mW is typical) and the inability to provide a response down to DC (the response can be down to a fraction of a Hertz though).
The dynamic range of the sensor is very large – about 97 dB. To put this in context, a typical accelerometer IC may only have a 50 dB dynamic range. Combined with the performance of the Measurement HAT, you can pick up the slightest vibrations (measurable in the thousands of g, i.e. acceleration measurable in cm/s2), as well as large vibrations (up to +-50g, which is +- 490 m/s2), from 100 Hz upward (with more noise at lower frequencies). In practice, touching and releasing a tuning fork will provide enough vibration for the sensor to detect (actually tens of dB higher than the FFT noise floor), for tens of seconds after the fork was touched.
How Does the Measurement HAT Work?
There is a block diagram in the documentation, a simplified view is shown here. Both ADCs sample simultaneously, and the clock and trigger logic can be used to synchronize multiple boards. The constant current source can be switched off. When enabled, it supplies current to power IEPE sensors.
A photo of the board is shown below, and it is possible to decipher some of the main functionality from that.
Underside of the board:
The Raspberry Pi pins used by the board are shown below in red text. Pins with black text are free to use for other purposes. The Measurement HAT can be integrated into solutions with additional Pi-attached hardware.
Standalone Operation and Coffee Machine Maintenance
One thing that was bugging me was how could I use the Measurement HAT as a practical instrument if I couldn't always have a network connection available, for example on-site. It's not practical to have a keyboard and monitor attached to the Pi. Fortunately, VIKI came to the rescue. I had a spare VIKI printed circuit board, so I assembled it in a cut-down form, with only the 40-way connector and the buttons and display circuitry. The board needed a couple of quick modifications to re-wire the buttons to the free pins on the Pi, and it meant that with just an hour of work, I had a physical user interface for the Measurement HAT. The coding took a bit longer, but not too long because I just copied the Measurement HAT code and just tweaked it from there. The code is on Github, but in brief, it uses an I2C library to talk to the display (the I2C pins were free on the Pi, as can be seen in the diagram above), and two buttons are wired to GPIO pins on the Pi. A menu is implemented, where the user can cycle between the following pages:
• Start Logging
• Stop Logging
• Select Sample Rate
• Set IEPE Current
• Shutdown
There are two scripts, install_service.sh and remove_service.sh, that make the code run automatically when the Pi boots, or disables that.
The basic concept is that I wouldn't need to attach the Pi to a display or to the network, just a power supply (could be a 5V USB Power Bank for completely mobile use), and the Pi would automatically run the code once it had booted. Then, the user could perform the data acquisition/logging operations entirely with selections with the LCD screen and buttons and select a controlled shutdown afterward. The data would be stored in CSV files on the Pi, for later analysis on a PC. The CSV filenames auto-increment and are displayed on the LCD screen, so the user can make offline notes of which file is which if multiple tests are run.
I used this standalone operation mode to test the performance of a coffee machine pre- and post-maintenance. The maintenance operation was descaling!
I didn't know what to expect, but the difference was significant. The chart below shows the time domain view of the vibrations from the pre-maintenance first coffee (blue), and the second coffee (red) which was immediately post-maintenance. There is a difference in the start and stop times, but at least partially it is likely because the water pump took some time to prime itself, and so the absolute time may not align, but the amplitudes are noticeably different. The datasets are on GitHub if anyone wishes to examine them, they are 50 Mbyte CSV files (too large for Excel, although they could be easily split – using the aptly-named split command in Linux for instance).
I used Matlab's Signal Analyzer to examine the frequency domain. In some parts of the spectrum, the vibrations from the second coffee (red) were larger, however at low frequencies, the first coffee (blue) generated larger vibrations, and that has made a significant difference.
The frequency-domain view shown above is zoomed in to a time portion near the beginning of the espresso cycle. The resolution bandwidth is 50 Hz. The view below shows later in the cycle:
A persistence spectrum view from the Signal Analyzer is shown below. It would be nicer to animate this but I've not figured out how to do that yet. With the first coffee, it can be seen how the spectrum changed as the espresso progressed, I arbitrarily annotated three positions in time as A, B, and C for the first coffee. With the second coffee, the difference is less between the stages and more difficult to separate out; an animation would be better here.
I found the persistence view of the spectrum to be highly useful, and I used it throughout the RoadTest as a result.
In summary, it is feasible to make a portable standalone instrument with the Measurement HAT. Another option could be to control the Measurement HAT from a mobile phone (using Bluetooth for instance, since the Pi supports that). The data obtained was very valuable for rapidly providing insight that if machine learning were to be employed for coffee machine descaling operation optimization (obviously less relevant for a consumer machine, but more important for the larger coffee shop machines), then it is immediately apparent which area of the spectrum to focus on so that data is sampled at a more sensible rate for both machine learning and for classification.
Note: Although the Pi supports WiFi, it should be avoided for the absolute best performance; the 24-bit ADCs will pick up tiny electrical variations, and WiFi consumes a lot of current in bursts, which are noticeable if you drill down into the microvolts.
Working with Small Vibrations: Watches and Clocks
As mentioned earlier, the combination of the IEPE accelerometer and the Measurement HAT is sensitive enough to pick up the tiny vibrations when a tuning fork is merely touched. I examined a wristwatch to see what kind of detail could be resolved; it could be interesting to see if this could reveal that watches need maintenance for instance. I placed the sensor on the watch, and vice-versa, experimenting to see what sort of signal I could receive.
The result was interesting, but it didn't solve any secrets, it just made me realize how sophisticated the underlying mechanism must be in watches.
Using a 2-year-old Seiko 5 watch (mechanical with a wound spring, there are no electrics inside), I was expecting to detect an oscillation at 6 Hz, because that is the rate at which the second-hand sweeps. However, there is a ~ 4.3 kHz vibration, and three times a second the amplitude of this vibration is higher. The events are not evenly spaced either, they are in groups of three.
What's more curious, is that on one test, the results looked different; there are shorter bursts of the higher amplitude 4.3 kHz vibration interspersed in a strange sequence, and the lower amplitude of it at that frequency has disappeared. It could be that the watch does different things at different times (it has a date mechanism that kicks into effect at some point in the evenings). I don't have the knowledge to unlock this mystery, however, the experiment showed that even delicate mechanisms can be probed with vibration sensors. You can also see there is a very low amplitude vibration at around 2.2 kHz, it's just faintly visible.
Next, I took a look at a clock, called Westclox Travalarm. It is probably from the late 1950s, and it still functions and keeps time reasonably well to a couple of minutes per day (it has an adjustment to improve that).
I used a clamp to press the sensor against the clock; not a great technique, but I wasn't going to drill holes in it.
Here the vibrations were very spread out, across a broad range of frequencies.
I compared it with a second Westclox Travalarm, which might be from the early 1960s (it is slightly less faded). The vibrations were spread out a lot more. I don't know what that means, perhaps this clock is less healthy than the first. I believe that the vibrations are more spread out than the wristwatch, because wristwatches have jewel bearings to conserve as much energy as they can, and so the 4.3 kHz vibration was perhaps the 'squeal' of the spindles against the jewels, whereas a desk alarm clock won't have such refinements, and you get what you get. I think the very faint 2.2 kHz vibration was simply another jewel in the watch. I am guessing that as the wristwatch ages, the squeals will change. All of this is pure speculation however; any comments are welcome.
Signal Generation
In some cases, it will be highly desirable to have signal generation capabilities when working with the Measurement HAT. The Pi is quite handy for this since it supports audio output; it would be possible to connect the headphone output from the Pi to become the stimulus for the circuit-under-test and then use the Measurement HAT to obtain the response from the circuit.
An alternative (not better, just different) method discussed here, and perhaps overkill, could be to use a Digital Signal Processor (DSP) chip. I didn't feel it was very overkill, primarily because it can cost about the same as a low-cost audio DAC, and would simplify things for users like me that are not experts with Linux audio.
The DSP board is easy to build – I'll write a separate blog on it at some point (it has general-purpose use), the schematics and PCB files are on GitHub.
The DSP board can run with a separate Pi, or it can use the same Pi as the Measurement HAT since the HAT has stackable header pins.
To use it is simple; I wrote some code called dspgen (at the GitHub link). If you wish to (say) generate a sine wave signal of frequency 1 kHz, you'd type the following from the Pi command line:
./dspgen -f1000
The amplitude is changed to 0.5 of full scale, by typing:
./dspgen -a0.5
Different apps can be run on the DSP. The sinewave app is called tone_app.bin, and it is first loaded onto the DSP board by typing:
./dspgen -ptone_app.bin
To create new apps, free-to-download software called SigmaStudio can be used (it is a graphical building-block system, so no actual coding is involved).
The photo below shows the prototype DSP board that I used (I have not built it on a PCB yet). It communicates to the Pi using I2C (which doesn't clash with the Measurement HAT, which primarily uses the SPI interface). The DSP board powers itself from the Pi.
So, to summarize, the DSP board can be used to generate signals under command of the Pi, and the Measurement HAT can be used to sample the signals. Together, the two boards can turn the Pi into a kind of audio analyzer. For instance, the Device Under Test (DUT) could be an audio amplifier or filter, and you could measure the frequency response, or you could measure harmonics or noise (for instance). Since the DSP board is under the control of the Pi, it is easy to make it perform a frequency sweep. In theory, the DSP could be configured to just generate white noise too.
Analysing Audio Amplifier Distortion
In a book of Ancient Circuits, I dug up a circuit diagram for a Class AB amplifier.
The circuit originated from Ferranti (very interesting history if you've not heard of the firm before), I modified it a bit, and the simulation revealed that I could expect 1% total harmonic distortion with a 32-ohm load, providing about 135mW of output power, and quiescent current of 1.9 mA. This seemed totally fine for its intended purpose (intercom).
I constructed the circuit fairly closely to the simulated design, except that because I used what I had, I used BC547 transistors instead of BC549, and the output capacitor was 330uF instead of 470uF.
I wanted to use Matlab to analyze the circuit because it contains a lot of mathematical functions. Although it could have been done offline by taking the log files from the Measurement HAT and transferring them to Matlab running on the PC, it would be nicer to do it in a real-time manner.
Googling revealed that Matlab supports WebSocket. WebSocket is a very nice way to transport data in real-time and it is supported by web browsers, JavaScript, and Python. I wanted to do it in C however and located some code to help me. I used the code to build a simple application available on GitHub called daqstream, that would send the data via WebSocket.
With that code on the Pi, I could just type:
./daqstream
And the Pi would start streaming measurements as soon as any WebSocket client connected.
On the PC, I wrote Matlab code to stream in the data in bursts, because Matlab can't process huge volumes of data in real-time (it can handle massive volumes of data, but not fast enough on my PC). The Matlab code was designed to send an instruction back to the Pi, whenever it had enough data to process. That way, Matlab can speedily process chunks of data and then grab new data periodically, i.e. it throttles the data source. This allowed me to get a real-time display that updated every second while reducing the data that needed to be sent over the network. To keep the packets small, each value is sent as 8 bytes encoding 'double' (floating-point) format, and Matlab reassembles the bytes back into that format.
This was the screenshot of the result (it updates every second) and it displays the THD value at the top of the chart and shows the fundamental tone and harmonics on the chart in blue and red respectively:
The THD of -54 dB is approximately 0.2%. which is better than the simulation, however, I had to tweak the input level to achieve this. I was able to make the circuit adjustments while watching the display on Matlab. It was pretty awesome being able to adjust the circuit in this way!
The code for daqstream, and the THD Matlab code is on GitHub.
The circuit is not a very good amplifier for any purpose other than an intercom, however. The distortion increases if the level is not just right, and it is noticeable, the audio just does not sound listenable for long periods. Therefore, I guess the human ear is very uncomfortable with Class B distortion down to single-digit percentages, but it would be good to hear about other people's opinions.
Frequency Response Measurements
A really great feature is that the two ADCs on the Measurement HAT are synchronized. This allows for easy phase measurements. In addition, having two channels means that stimulus signal amplitude can be normalized easily, in case the stimulus is not flat across the entire frequency range. Both these features together make for great frequency response measurements.
The diagram here shows the setup. I used the DSP board, but it could be replaced with any signal generator provided it can be controlled remotely. In this case, the Rasberry Pi sends instructions to perform a frequency sweep, and the DSP board sends the tones to the device-under-test, which in this case was the amplifier circuit described earlier.
The DSP output, and the amplifier output, are both connected to the Measurement HAT on channels 0 and 1 respectively. The simultaneous sampled measurements are captured by the Pi.
Instead of performing on-board processing on the Pi, I streamed it to Matlab, same as before, using the WebSocket connection and daqstream code discussed earlier.
I added some code to implement a simple REST endpoint – it's about a dozen lines of Python, that calls the dspgen software whenever Matlab commands it to change frequency. As before, the code is on GitHub. Matlab natively supports REST, so it was a convenient choice. Basically, Matlab sends an HTTP message to any URL of choice. In my case, the URL looks like:
http ://192.168.1.88/dspgen/f1000
where 1000 represents the desired frequency in Hertz. The Python code merely sends back a 200 OK response, and issues the dspgen command line as discussed before:
./dspgen -f1000
The Matlab code was used to normalize the input, and to plot the amplitude and phase. The freq_chart Matlab code will run through a range of spot frequencies, issuing the REST commands, and plotting the results.
The chart below shows the results for the earlier Class AB amplifier, for spot frequencies in the range of 10 Hz to 20 kHz. The blue curve is the amplitude, and the orange curve shows the phase.
If you're curious how the phase is calculated, the trick is (there may be better/more efficient ways) to calculate the FFT for both the stimulus and the output from the device-under-test, and then look at the part of the FFT that corresponds to the peak for both of the signals. The FFT data points are complex numbers, and taking the peak, from there you can obtain the direction (angle) of the vector. Subtract the angle that corresponds to one signal from the angle for the other signal, and the result is the phase difference between the two. See the mcc-daq-tools GitHub link to examine the Matlab code to do all this. Everything is then repeated for the next selected frequency and so on, and plotted on the chart.
Summary
The Measurement HAT provides reliable data acquisition that opens up a lot of possibilities because the data is of high quality; accurate, and with a wide dynamic range so you don't need to overly be careful about sensor signal levels to get good usable results. This makes it especially ideal for handling unknown, say unusual or new scenarios or conditions. With machine learning, you might not know for sure what elements of a signal will be important, and so the ability to capture with good resolution at high speed is highly attractive. The Pi will be of benefit here because you can capture additional inputs (for instance logic level inputs) at the same time, to classify the data easily.
The performance is good enough for audio measurements down to about 0.003% THD, I don't have the ability to test better than that, but this is still practical for many audio test scenarios.
Together with the IEPE sensor, the Measurement HAT provides a large dynamic range for vibration measurements, and it is possible to pull out a lot of useful information using FFT and persistence traces to show how the frequencies of the vibrations change over time.
The Measurement HAT is an exciting product because of the possibilities it has opened up. I love that I can fire up the Pi and be looking at signals within a minute, in ways I cannot with a conventional oscilloscope or spectrum analyzer, and I really like that the quality, resolution, and speed of the measurements make it very practical to see the useful spectrum and other processed charts or measurements in either real-time or very close to it.
I just wish the Measurement HAT was slightly lower cost (or perhaps if an alternative version with IEPE current disabled was available, as a differentiator for those who don't need that) so that many more people could experience this product.
I hope to write more code for the Measurement HAT, and also look forward to integrating with other test tools with Jan's Labview integration.
Thanks for reading!
Appendix: Bug List
None of the bugs are showstoppers, they are pretty minor. I was very surprised at the good quality of the code.
1. If two users use it, it is very common for one user to get locked out of using any of the applications; this occurs because the SPI interface gets locked and the user does not have the permission to unlock it. The only workaround I have is to reboot the Pi, to remove the lock. Granted it could on the face of it sound unlikely that two users will use the Measurement HAT, but I had a good reason to use two users, so I hit the problem. I'm sure there is an easy code fix that could be done, I just don't know how to do it. Also, the error message was very general, it just specifies a resource lock issue, but doesn't mention it is SPI-related.
2. Probably a good idea for the data_logger application (it is open source, so anyone can make the change and submit it for approval) to prompt the user each time if the IEPE supply needs to be enabled or not. It is very easy to accidentally leave the IEPE supply accidentally enabled, which could cause damage if it wasn't required. I did accidentally leave it on, luckily I didn't damage the test equipment.
