|
For the Sound and Vibration Measurement Hat for Raspberry Pi road test, I'm reviewing Measurement Computing's IEPE Measurement DAQ HAT for Raspberry Pi.
I listed set a set of goals before the start. They are all implemented and working. LabVIEW driver has gone through refinement. Pi software now runs as services.
|
Alpha release available on github.
1.0.2 release available on github.
Since the Beta, nothing has changed on the Pi code. It behaves decent. I have created systemd service wrappers, and the software now starts automatically. All enhancements are with the LabVIEW driver and example flow. I called it "Beta" when the complete process was able to run constant scans for hours reliably. While the blocks for connectivity and configuration were simple, the scan and data acquisition flow was complex and convoluted. It took time and revisions to structure it to what it is now.
1.0.2 release has proven to be stable under difficult network conditions and when connecting over WiFi.
The Scan Start block now also deals with initiating the data queue and the remote data socket. The Producer loop (the thread that retrieves scanning stream) has simplified spectacularly. Closing the data queue and the data socket connection has moved into the Scan Cleanup block. To show the difference between the first functional iteration, and how it turned out after refactoring, see the image below:
It's not only structurally better. It's also easier for a user to adapt this flow as desired. For a single channel flow they'll only need to adapt the Consumer loop. Turning it into a dual channel design is also straightforward.
Below is an image of the process dialog. This isn't intended as a real instrument front page. It represents a visualisation of input, output and data acquisition.
Why alpha? The design isn't error free yet, there's a known issue with the first VISA commands. They sometimes contain extra data. I don't know yet if that is a dirty buffer, timing/timeout issue, or something else. It's not hampering the functionality because it happens when trying to start the process. Closing the error message and restarting solves. I'll analyse that one later. Other than that, this is a stable, fast and reliable end-to-end solution.
Here's a small action capture of me tapping the table, with the mcc172 set to 128 samples per second, and 128 samples per channel.
I'm now switching to the build of the vibration test device. Then I can try to get vibration specs in real world setup.
