|
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:
|
All images and screenshots in this blog are from the actual designs. They reflect the status at the time of writing
Since previous post, I changed the data streaming approach. I was streaming doubles in readable format, because it's easy for a human to interpret the data. But that advantage didn't weight up against the issues I'd have to solve.
Because the readable format is variable in length (unless I'd allow for a silly length fixed string that could handle maximum positions before and after decimal sign), it becomes difficult to size buffer and make a nice cut in the data stream.
I've chosen (shabaz helped a lot while balancing the design options) to send the data in the Pi's microprocessor native 8 byte format. It makes the processing easier for both the C++ Instrument Service and the LabVIEW flow. I also found a way to help interpreting and validating the streamed data: I made a Dummy Instrument Service, that behaves identical to the real service I developed before, but mocks the data stream. Because I know how the stream is mocked, and what/how much data to expect, it makes validation at the LabVIEW side straightforward. It also allows for automated test of the whole integration.
|
Dummy Instrument Service I made a mockup MCC172 instrument service for 2 reasons: to help with stream validation, as I wrote before. But also because fellow element14 member martinvalencia is helping with advanced vibration data analysis. Martin doesn't have a MCC172 hat. The dummy service will be our mechanism to work together. We can mock up any data set and make the dummy stream it. LabVIEW doesn't have a clue wether it's talking to the Hat or to the dummy service. Currently, as proof of concept, the service streams the requested number of samples. The first value is the minimum range of the DAQ: -5.0 V. Each next sample adds 0.000001 V to it. void scan(DaqHatInstrument* dh, tcp::acceptor* dataacceptor, tcp::socket* datasocket, uint32_t samples_per_channel) {
dataacceptor->accept(*datasocket);
int num_channels = dh->scanChannelCount();
for (int i = 0; i < (int)samples_per_channel * num_channels; i++) {
double val = (-5.0 + i*0.000001);
boost::asio::const_buffer buff(&val, sizeof(val));
datasocket->send(buff);
}
}
This algorithm is simple on purpose. Easy to validate for precision, count, hick-ups, breaks and data loss. |
Switch from readable stream to binary flow, Mock Instrument Service
When I changed the data stream to binary, it had impact on the LabVIEW side. In my previous blog I used a common VISA connection to open the data port. In order to read the binary flow, I need to dip a level lower: the plain TCP LabVIEW blocks.
The 8 bytes double representation of a double isn't compatible with LabVIEW's binary format. I had to do some bit-fiddling to translate the binary stream into doubles (luckily, something I did before when writing a driver for a Multicomp Pro function generator).
First I had to translate the TCP chunk into 8 bytes.
Then translate that into a float. The bit order is OK, but bytes order is inverse.
Example Flow
The example flow proves the whole setup. It asks for a set of samples, collects the results and shows them on a LabVIEW waveform chart. I was able to keep the Producer-Consumer pattern that I tried in the previous post - turns out it's doing rather well. The image above shows how it's doing while running against the dummy instrument service. Below is how it behaves when the real DAQ hat is streaming data.
All software is available for download. Quality is beta. Functional, with known shortcomings: the example flow doesn't correctly show results if two channels are sampled (bug #18), flow fails in full-continuous mode (bug #17: solved). Beta should allow to firm current functions and fix the above 2. The video below is a preview of a sample of a linear rising signal from the dummy instrument service. I added a delay between each data read on purpose to see how the screen updates behave. The video at the start of this post is taken without waits, and with the real instrument and sensor.
