Sound Measurement and Vibration Measurement with the MCC 172 and the Raspberry Pi

Table of contents

RoadTest: Sound and Vibration Measurement Hat for Raspberry Pi

Author: Jan Cumps

Creation date:

Evaluation Type: Evaluation Boards

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?: At this range, I couldn't find comparable solutions. There are a number of other solutions, with industrial housing and higher specs. They start at a price 2 orders of magnitude higher than this solution, but offer out-of-box integration with industrial (MathLab, Scada, LabVIEW) applications

What were the biggest problems encountered?: Skilling up. DAQs and vibration analysis are niche skills.

Detailed Review:

Goal

My objective for the road test is to evaluate the kit in a real world situation. I’m building a vibration test jig to analyse the behaviour of little devices when they are shaken. And I’m developing software for the Raspberry Pi host, a dedicated LabVIEW driver and example flows to use with this test set.

The end result is a test instrument that can be controlled via LabVIEW over the network, and that can stream high volume data over that network. It can play along in a complex flow with several lab instruments (in this case a function generator). Data can be shown real time on screen, processed, stored into a spreadsheet – or a combination.
The road test report is a summary of activities that are documented in 20 blog posts. They are listed and linked at the end of this report.

Hardware

The road test kit had these components:

  • MCC172 vibration / sound data acquisition HAT

  • PCR 603C1 Piezo acceleration sensor

  • cables and adapters

  • Raspberry Pi 4

This is a complete set that allows you to build a vibration monitor. You only need to add a power supply. What’s common with all the parts of the kit is that they are of high quality. The DAQ HAT has state of the art analog and analog-to digital components. The Piezo sensor is suited for hazardous environments. The adapters are industry strength.

MCC172 HAT

The MCC172 IEPE DAQ is a data acquisition HAT for the Raspberry Pi family. A 2-channel ADC design made to retrieve data fast and precise. It’s part of a DAQ product family, aiming at measuring vibrations and sound.
It accepts signals up to 5 VPP AC, with a virtually flat (52 millidecibel) bandwidth of 20 Hz to 23 kHz. The low end -3dB cutoff is at 0,78 Hz. High side cutoff is depending on sample frequency: maximum 51.2 kS/s x 0.453.

The software and Pi are able to run both channels at maximum sample rate. There’s a dedicated microcontroller on the HAT that deals with sampling and on-board sample buffering. The Pi only has to deal with configuring before sampling, and then downloading buffered data over a fast SPI bus. It can easily cope with two channels active (also a Pi 3 would be fast enough for that). Multiple boards – up to 8 boards, 16 channels – can be stacked. The max throughput can be sustained with up to 6 channels in use at the same time.


image source: MCC 172 IEPE Measurement DAQ HAT for Raspberry Pi®

The analog side is a 3-stage setup: the input signal is first buffered, then converted to a balanced signal and sent to the ADC.

  • Input buffer: 2 channel OPA2277U OpAmp.
  • Signal balancer: THS4531A differential amp per channel.
  • ADC: a differential ADS1271 per channel

The channels are 50 Ω, connection via SMA coax or screw terminals. Each channel can inject utility power for IEPE type sensors. They are suitable for measurement microphones and piezo sensors with or without external power requirement.

PCR Piezotronics 603C01 sensor

The PCR acceleration sensor just by itself would be sufficient material for a separate road test. It’s a IEPE type piezo device that’s made for hazardous jobs. Its natural habitat is pumps, gearboxes, engines, factories, inside wind mills.

It’s heavy, 55 g. And sensitive. I’m using it for low acceleration indoor experiments. I received the right photo from . He uses this type of sensors on pumps, motors and gearboxes in the mining industry in Peru.

The sensor needs an external power supply. The DAQ HAT’s IEPE supply is compatible. Here’s an extract of the product specification:

When using it in my road test, the sensor was detecting vibration before I could feel it. They measure acceleration via a mechanism embedded inside the sensor. A mass is attached to the piezo element. Vertical acceleration generates electricity in that element. That’s conditioned and amplified inside the sensor, then sent along to the DAQ.

Software

MCC172 library

MCC has published all software for its MCC DAQ family on GitHub. The core is a library with an API to configure the document and retrieve data. The API for the MCC172 is about 20 functions, split up in parameter setters/getters and sampling functions. There are functions that are channel specific, like setting the IEPE output and sensitivity. Clock related functions are across channels.

The sample API is very simple. 3 calls to control execution. Two you’ll always use: to start and to clean up. A 3rd one will stop an active sampling process. The API creates a separate thread while sampling is active. This will collect data from the HAT and buffer it.

Then there’s a function to read data from those buffers while the scan is active. Because the scan is filling the buffers in its own thread, you can use the main thread in your code to fetch the data and process it. In the custom software I wrote for this device, I’m using an additional thread that reads those buffers and streams them over a network socket. I’ve reviewed the C library and used it in C and C++ programs. The granularity of the API is good – I adapted it for the custom LabVIEW driver design. Each function is well documented. There’s also a Python library. I didn’t review it, but used it when running the MCC examples.

MCC172 examples

There’s a rich set of Python and C programs that exercise the board. From the Python set, I used the web server regularly. It’s a program that turns the Pi into a web server that shows the samples real time on a graph.

It’s an easy enty point for the first exercices. Immedite feedback of what’s happening with the sensor. I’ve reviewed the C examples more closely, because I wanted to make a custom C/C++ daemon for the instrument, as part of its LabVIEW integration. There are examples focusing on acquisition & speed, on analysys & transformation. And on a combination of those.

If you are running Linux with GUI, make sure to also check out the data logger example. It runs sampling at maximum speed and shows waveform and FFT in real time.

Road Test

That’s it for the review. The remaining part of this report documents my experience with the device and software. I’ll first describe the custom server software and LabVIEW driver I made. Then I’ll go over the test jig and test automation flows.

Build remote controlled DAQ with LabVIEW integration

The software component of this road test is the one I was serious about all the time. It had to be functional, industrial grade, maintainable. I chose for a set of Linux deamons on the Pi side, to control the DAQ HAT and provide SCPI functionality. On the LabVIEW side, I created a Virtual Instrument style driver. These were my objectives:

  • remotely accessible Instrument service

  • remotely accessible SCPI wrapper service

  • runs as daemon service on the Pi

  • LabVIEW driver with example

  • support for all configuration parameters except trigger

  • support for finite and/or continuous data logging from LabVIEW or other remote application

  • LabVIEW blocks in right abstraction level

On the Pi, this resulted into two services. A low level instrument service that turns the MCC library into a network callable API. It can set and get parameters, and efficiently stream the data buffers over the network. Then a SCPI service that delivers an industry standard API to the instrument. You can use the DAQ HAT in a LabVIEW flow just like you’d use a commercial oscilloscope or power supply.

The development of these services showed me that the MCC library granularity is well balanced. I often struggle when translating a C API into services or objects. This time I did both (the SCPI lib is C, the instrument service C++ with an API object wrapper). Instead of fighting to get the API fit into my work, I could use it as guidance for the structure of my own design. 
When I did the LabVIEW development, it was a similar experience. The driver layout virtually matches the MCC library calls – and the Virtual Instrument paradigm:

I’ve made drivers for several other instruments. A DAQ is more difficult. The controlling side is familiar, but you have to deal with loads of fast data samples. You have to be able to eat and process them. In this road test, that was my biggest learning: how to deal with a fast data stream, over a network, in LabVIEW. Real time. LabVIEW has a pattern for this: the Producer / Consumer. It’s a multi-threaded design where one loop (producer, the high speed one) reads data and pushes it to a queue. This loop has to keep up with the DAQ HAT’s data stream. A second stream (consumer) can pick data of that stream and “deal with it”. You can see this as a design strategy: the queue serves your business logic the data. You can plug in any strategy that processes that data.

In my examples, I’ve tried three strategies:

  • show the wave form real time on screen

  • log the samples to a file

  • collect a set of samples (in my case 32K) and analyse them (I calculated RMS, AVG).

My LabVIEW driver provides an example flow, where you can plug in your own data processing strategy (maybe FFT? (edit:done). In my final Road Test design, I put an “aggregation and then RMS per frequency” strategy inside the consumer flow.

The individual posts for the road tests describe this in detail. Here are some examples: 
A real-time waveform display

A graph of a flow that loops over a frequency range, taking 32000 samples at each frequency, then calculating and saving the RMS value to a spreadsheet.

The LabVIEW driver and examples can be used in real world situations:

  • preventive maintenance: monitor a device and alert when its parameters get out of the normal. LabVIEW has a white paper that explains how you can use data acquired from accelerators to spot issues. My driver delivers that data, ready to be used by the algorithms in that paper.

  • Design validation: will my automotive control board survive in a real automobile? For how long? Where are the limits? Again, the driver and its ability to be included in a wider process, allow for this kind of analysis.

The LabVIEW and Linux Services sources are available on my GitHub.


image: dual channel sampling LabVIEW driver example

Build Test gizmo

It’s a prototype for a vibration platform. A shaking device you can use to analyse how a “thing” behaves under vibrations. This was obviously a side goal of my road test. A story hook to be able to show how the DAQ HAT and my software behave. The base is a subwoofer with built-in amplifier. A platform is built on top of the speaker. That platform serves as the mounting point for devices you want to specify or long-duration-test. The input for the shaker is a sinusoidal signal from a function generator. This is where two initiatives come together: I wrote the LabVIEW driver for that function generator too. This design proves that both drivers are up to the job.

I made the jig with material I could get to. The subwoofer is part of a Logitech PC-audio 2.1 audio setup. Small, 15 Watt – but good enough for this pilot. The adaption to a vibration test jig was done by  at the Ingegno maker space in Drongen. The usable range for this jig is from 30 to 90Hz. Below that, the subwoofer’s audio filter cuts off the signal. Above 90 Hz, the device is difficult to control. Resonance over-tunes useful data. But the end result is impressive. This is a real useful range to learn about vibration and analysing its data. And you can learn how to compensate for non-linearities.

Build automation flow

I made a LabVIEW flow to automate the vibration test jig. It controls a frequency generator and the DAQ HAT. You tell it to sweep over a range of frequencies. The function generator lets the test jig shake at a given amplitude. At each stop, the DAQ takes 32,000 samples, then calculates the RMS value of that set. It writes the results to a spreadsheet and continues. Until the whole range is covered.

I’ve made two flavours. A simple one that sweeps and collects the output. A second one that compensates for the non-linearity of the test jig – a simple coherence corrector.

The coherence flow uses the output of a simple flow as its correction guideline. You first run a sweep on the empty table, collect the jig’s behaviour, and feed that in to the next run with the test device mounted. The test flow will try to compensate for the base jig’s non-linearities (physically force the jig to be linear) while testing your gizmo. As indicate before, I managed to achieve this in the 30 – 90 Hz range.

Specs & Results

If you are looking for measurements that show accuracy of the DAQ HAT, I’m going to point you to Shabaz’ road test. He validated the behaviour related to specs – next to measurements on several devices. In my road test and accompanying blogs, you’ll find measurements related to the test device I’ve built. It’s showing the DAQ HAT and sensor in use. I did verify if data was within specs along the way. Both the sensor and HAT complied with their own specs. The DAQ, and the Pi that controls it, can keep up with the maximum data rates. I’ve run this setup for hours, collecting millions of samples. It was an exercise to prove that my software was reliable, but in parallel it showed that the road test kit didn’t miss a beat.

Both DAQ HAT and sensor are able to detect movements that I could barely feel, and single step changes in those movements. The analog front end performs very good. The ADC modules and software keep up just fine. When running in maximum speed and rate continuous sampling mode -with my service software streaming data over the network – the load on the Pi 4 was at 22% of CPU. Memory requirements can be easily calculated. The software needs virtually no memory. Buffer requires a long double (4 bytes) per sample per channel. That’s about it.

Summary

I love these unusual element14 road tests. Devices that you don’t typically own or have experience with. They give you the most opportunities to learn new things. This one allowed me to learn niche skills: how to measure vibration. How to analyse the data and derive decisions from it. How to deal with a DAQ. How to build a LabVIEW driver for a DAQ. I learned about IEPE acceleration sensors and their use.

I also think that this is a road test that gives.  and I got a kit and C / Python software. We both turned it into a design that can be used in academic and industrial settings. You’ve read about my LabVIEW driver here. Shabaz designed the integration with MatLab. The user community has a new set of choices.

Thank you for following along.

references
DAQHATS software
DAQHATS documentation
DAQHATS Digilent product home page
DAQHATS electrical specifications
DAQHATS manufacturer home page
Piezo sensor product home page
Piezo Sensor datasheet
Piezo sensor specification sheet
Differential ADC Burr-Brown ADS1271
OpAMP 2 channel OPA2277U
Differential Amp THS4531A

related blog
MCC172 DAQ Hat for Raspberry Pi - FFT test
MCC172 DAQ Hat for Raspberry Pi - C development
MCC172 DAQ Hat for Raspberry Pi
Instrument Network Service for LabVIEW Pt1: Software Components
Road Test time management with GitHub Project Beta
Instrument Network Service for LabVIEW Pt2: Pilot phase of functionality - Instrument Configuration done
MCC172 DAQ Hat - analogue front end
Instrument Network Service for LabVIEW Pt3: a LabVIEW Utility block
Instrument Network Service for LabVIEW Pt4: Data Stream Functionality - analysis
Instrument Network Service for LabVIEW Pt5: Beta phase of functionality - Acquisition Data stream to LabVIEW works
Instrument Network Service for LabVIEW Pt6: Build the Services from source on the Pi (or BB)
Instrument Network Service for LabVIEW Pt7: Service Wrappers - run the instrument services as Linux Daemon
Instrument Network Service for LabVIEW Pt8: Alpha phase of functionality - Service and LabVIEW Development done
Instrument Network Service for LabVIEW Pt9: Write a Custom LabVIEW flow: data logging to disk
Instrument Network Service for LabVIEW Pt10: example with FFT
Automation Flow for Vibration Test Jig
First Demo of the test jig
Field Trip to Enrico and the Ingegno Maker Space
Frequency Band analysis of the test jig - is it linear?
Frequency Band analysis of the test jig - can I make it linear?
Does the Pi 4 power adapter choice influence analog HAT noise?
Piezo Electric Accelerometer PCB 603C01
Calculate Acceleration Energy
Custom Software on GitHub (Instrument Services, LabVIEW driver + example, Service wrappers)

Link to all posts.

Anonymous
Parents
  • FFT is working. The video shows how it behaves on low sample counts and fast updates. I disturb the vibration by putting some loose items on the test jig table.

    This image shows a transform based on 10 K samples at 1KS/s

    Each time, the frequency of the shaker table was 90 Hz.

Comment
  • FFT is working. The video shows how it behaves on low sample counts and fast updates. I disturb the vibration by putting some loose items on the test jig table.

    This image shows a transform based on 10 K samples at 1KS/s

    Each time, the frequency of the shaker table was 90 Hz.

Children
No Data