Acquisition of PCB 352C33 (IEPE) sensors using the DT9837A

[adrimaths]

Hello,

We have purchased the DT9837A-OEM and now I have started to learn how to develop a software for acquiring accelerations from two IEPE sensors (PCB 352C33) in Ubuntu 22.04. We are a bit stuck with the understanding of the UL for Linux. Specifically, for the AInScanIepe program, I have the following questions:

1. If I exit the program using 'ctrl+c' instead of 'enter', I cannot execute it again as the resource of the DT9837A seems freeze. This lasts until I unplug the USB and plug it again or do a shutdown of the PC and then turn on again. I observed that exiting with 'ctrl+c' doesn't execute the line with the ulReleaseDaqDevice function, so I think this is the main reason. Is there any way to recover from this status without unplugging & plugging the USB or doing a shutdown of the entire system? I've tried to call ulReleaseDaqDevice(1) or something alike but didn't succeed.

2. I can see that the device DT9837A only supports BIP1VOLTS and BIP10VOLTS ranges. I supposed that the correct one was the BIP10VOLTS ranges, but my supplier of the piezoelectric accelerometers (PCB 352C33) said that they are expected to return a -5 to 5 voltage (as they have a sensitivity of 100 mV/g and range +- 50 g's peak). So, how can I read them? Should I use the BIP1VOLTS option and then multiply the values by 5? Should I use the BIP10VOLTS option and expect the values to be always in the range of the A/D converter that matches the -5 to 5 V values? This is very important as we have ordered a big amount of piezoelectric sensors similar to the 352C33, as your commercial team told us these sensors are compatible with the DT9837A.

Thanks in advance. Best regards,

[Fausto]

Hello @adrimaths.

DT9837A Series support in UL for Linux was added after MCC acquired Data Translation.  MCC devices do not have the freezing issue highlighted in your first question, because they do not need to be explicitly shut down to be available again.  Unfortunately, for DT9837A users with Linux, the DT9837A Series boards must have a clean release between the driver and API.  Otherwise, a user will need to cycle the USB connection.  The DT board issue is only visible in Linux, because there is no mechanism to stop the device handler after an unexpected interrupt.

With regards to the input channel range, set it to BIP10VOLTS, if your application expects the readings to go beyond a +/-1 V range (10 g).  If your readings are less than that, then you can set the input channel range to BIP1VOLTS.

Regards,

Fausto

 

[adrimaths]

Hello,

1. So, the only solution is to shutdown the system (rebooting doesn't work too) or cycle the USB connection... Ok, I think we can adapt the system to overcome this problematic issue.

2. Then, if the output voltage of my IEPE sensor is between -5 and 5 V, then I would have to put the DT9837A input channel range to BIP10VOLTS, and then expect the readings to be always in the -5 to 5 V range. Right? I am trying to shock the accelerometers while executing a test program I wrote (mixing your examples) but the min and max values obtained in the acquisition are +0.015999 and -0.007123 V, but they should be close to -5 and 5, I think. I have attached the code here.

Thanks in advance. Regards,

SimpleAdq.c

Edited May 19, 2023 by adrimaths
Forgot to specify something

[Fausto]

Hello @adrimaths.

Your code is incomplete to acquire data.  Please reference the 'AInScanIepe.C' example included with UL for Linux (libuldaq).

Are you able to confirm that a 50 g force is applied to the accelerometer, with a third-party instrument?

Regards,

Fausto

[adrimaths]

Hello @Fausto,

Why is it incomplete? Maybe for IEPE sensors the ulAIn function doesn't work and you must use the ulAInScan function?

We used to read the accelerometers using the PCB 485B39 signal conditioner. If I use that device with the same accelerometers and third-party software, I can see the readings saturate when I shock them with the table. This behavior doesn't seem to reproduce with the DT9837A and the code I shared. If I execute the AInScanIepe program, the readings are still too low when I shock the accelerometer. How the BIP10VOLTS configuration affect to the readings? Is it just used to scale the ADC readings? Or has it electronic implications too?

Regards,

Adrian

[adrimaths]

Also, I have another doubt with the UL:

What is the meaning of samplesPerChannel? If I configure the rate, for example, to 8000, I expected the device to acquire 8000 samples per second and channel, that is, one new sample per channel each 1/8000 seconds. Are these samplesPerChannel samples acquired at the same time so that you could compute the mean or similar? Or are they equally distributed in time between the 1/8000 s intervals?

Thanks in advance,

Adrian

[Fausto]

Your example does not react to any keys pressed, after it displays "Hit any key and then ENTER to continue" and no data is displayed.  I have to use CTRL-C to exit the example. 

The 'AIn' example (as is) works with a DT9837A.  Why are you performing a single value acquisition with the 'ulAIn' function instead of using the 'ulAInScan' function?  Samples per channel is used for continuous scan acquisitions.

After enabling the IEPE and AC coupling modes for the DT9837A input channels, a user should allow a few seconds (time decay) for the circuits to stabilize prior to an actual acquisition run.  A user can do this by performing a continuous acquisition for a few seconds and then discarding the data.  

The PCB 485B39 signal conditioner reads a signal from an accelerometer, just like the DT9837A module.  Do you have a calibrated instrument which outputs signals with respect to force and frequency values set by a user (to simulate an accelerometer), i.e. Endevco 4830B?  

https://www.pcb.com/products?m=4830B

https://www.pcb.com/ContentStore/mktg/Downloads/EDV-DS-4830B-0523.pdf

 

[adrimaths]

Oh sorry, I forgot to say that. Yes, in my example, the first scanf is for the index to choose between BIP1VOLTS and BIP10VOLTS. The second scanf is the 'enter' to start the acquisition but, due to C issues, you must type any different key before pressing enter, otherwise it doesn't work (I don't know why). I have written a new coded based on the AInScanIepe.c script.

I had observed what you said, the first readings are always larger and after few seconds it stabilizes. Thanks for the additional information about this.

No, unfortunately we don't have a calibrated instrument to do that... But thank you for the reference, I think we should purchase one of that instruments for the workshop.

I have attached a new code using the ulAInScan function and also the output I obtained. This code shouldn't have the problem with the enter key, it works as your examples. You can see the maximum obtained value to +9.9999 V, that is due to the issue you commented.

Regards,

SimpleAdqScan.c

[adrimaths]

Hello,

I have tested the DT9837A using QuickDAQ software in Windows, here is the image displaying configuration and output. I have shocked the accelerometer with the table twice and you can see the signal saturation. I think the key configuration was the "Current Source" checkbox (what would be the UL configuration for this?), if I disable it, the values keep in a very small range, but enabling it makes the values to reach the 100 g. Although I think this values are not correct at all as the maximum range of the accelerometer is 50 g, so the saturation should occurs in that value, right?. I still have the doubt that a +-10 V input device (DT9837A) can read +-5 V output piezoelectric accelerometers.

 

Also, again, what is the meaning of samplesPerChannel in the ulAInScan function? Are they measured at the same time or how?

Thanks in advance. Regards,

[Fausto]

Hello @adrimaths.

UL for Linux Help link:  https://www.mccdaq.com/PDFs/Manuals/UL-Linux/c/index.html

To set the current source in UL for Linux, a user must enable IEPE.

ulAISetConfig(daqDeviceHandle, AI_CFG_CHAN_IEPE_MODE, chan, IEPE_ENABLED);

To set the coupling to AC, reference the following parameters.

ulAISetConfig(daqDeviceHandle, AI_CFG_CHAN_COUPLING_MODE, chan, CM_AC);

The 'samplesPerChannel' parameter is used to determine the buffer size for the continuous acquisition.

 

On 5/19/2023 at 9:06 AM, Fausto said:

With regards to the input channel range, set it to BIP10VOLTS, if your application expects the readings to go beyond a +/-1 V range (10 g).  If your readings are less than that, then you can set the input channel range to BIP1VOLTS.

 

The first decay from 20 g would be the shock to the accelerometer.  The second larger decay from 100 g would be an accelerometer sensor's connection issue with the input channel.  Please check the sensor connection and wiring. 

Since the input channel range is +/-10 V and the sensitivity is 100 g, then it makes sense that the time decay would start at 100 g.

Regards,

Fausto

[adrimaths]

Hello @Fausto,

Yes, of course I know the online documentation of UL for Linux. But it has very short descriptions of variables and functions, so it is sometimes difficult to understand the meaning of them. I cannot also find many examples on the internet.

The first decay from 20 g is a little shock I did to the accelerometer previously to the bigger one. The second larger decay is also due to a shock I did. The sensitivity of the accelerometer is 100 mV/g but the sensor range is +- 50 g, so 100 g values shouldn't be reached. Maybe I just have to divide the values by 2 to scale in the -50 to 50 g range instead of the +- 100 g.

I found a scientific article on the net: https://www.mdpi.com/2076-3417/13/4/2622. In the article, the scientists said "The vibration signals of the bearings are sampled by a vertical PCB352C33 acceleration transducer and a DT9837 dynamic signal sampler;" so it is theoretically possible measuring that accelerometers using the DT9837 series. I suppose that they divide the +10 V gain by 2 to get correct measures...

It would be very useful for me if you could show me the equation(s) that involves the BIP10VOLTS parameter after recording the A/D value, I suppose it will be similar to following: value_volts = value_adc/(2^23-1)*BIP10VOLTS, right? If so, then divide by two does the trick...

Regards,

Adrian

[Fausto]

Hello @adrimaths.

You do not need to divide the values by 2.

Repeat you test with QuickDAQ.  Create a little shock for the accelerometer.  While still acquiring data, disconnect the acceleromenter and then reconnect it.  Please reply with the plot results.

Regards,

Fausto

[adrimaths]

Hello @Fausto,

Here are the plot results:

Does it say something to you? Thanks in advance.

Regards,

Adrian

[Fausto]

Hello @adrimaths.

I am able to reproduce similar results (full scale saturation) if I hold the connector, of a PCB 355B04 accelerometer, with my fingers and strike an object.  The accelerometer should be secured to a surface and the shock applied to the surface, not directly onto the accelerometer.  

Also, I see similar results to your second half of the plot, when I cycle the connection between my accelerometer and the analog input channel.

Please check your wire and its connections.

Regards,

Fausto

[adrimaths]

Hello @Fausto,

So you were able to measure correct values using a PCB 355B04, which has an output voltage of +- 5 V (as its range is +- 5 g pk and its sensitivity is 1000 mV/g), using the DT9837A with gain configured to BIP10VOLTS, right? If so, that is the thing I wanted to read. Because the PCB 352C33 has the same output voltage and my only doubt was if the values obtained with gain=BIP10VOLTS were correct.

I think the wire and connections are ok as the wire, connectors and devices are new.

Regards,

Adrián

[adrimaths]

Hello @Fausto,

I'm a bit stuck with a new problem. I want to develop a program that do the following:

1) Configure DT9837A as IEPE mode with sample rate 10 kHz and two analog input channels 0 and 1.

2) Wait for external trigger from a microcontroller to measure 1 value per channel, then dump them into text file. Wait for next trigger signal to measure 1 value per channel again, them dump them into text file, etc...

3) When user press 'enter', exit program and close text file in order to review it.

I do not want the trigger to be only for starting the first acquisition, I want it to control all the acquisitions at 10 kHz due to synchronization issues (we have a lot of different sensors from different nature and we want it to be synchronized). I have tried with SO_SINGLEIO flag and samplesPerChannel = 1, but all the values acquired remain the same...

Have you got any example for this?

Have you got a more detailed description of SO_ flags and the behavior they produce in the acquisition?

Regards,

Adrián

[adrimaths]

Hello,

I could develop a simple C program that starts when external trigger signals and then acquires given N seconds at given R rate. I create a buffer of size chanCount*seconds*rate*sizeof(double). After acquiring, the buffer is copied to a text file with columns "nseq,acc0,acc1". Then I plot results using Python. Everything is ok if I use two channels with 10 kHz sample rate per channel.

If I use the SO_SINGLEIO flag, I notice that data mess up when sample rate is greater than 10 kHz, as you can see in the following pictures:
Acquisition at 20 kHz:

Acquisition at 15 kHz, you can observe the exact moment when the order is messed up:

I am sure that the buffer is internally messing up the values of the two analog input channels. If I use the SO_CONTINUOUS flag, I can not reproduce this. But for my application the correct flag is SO_SINGLEIO, as I want not the buffer first values to be updated when buffer end is reached but finish the acquisition.

Another issue: the product manual says that the device can acquire at more than 50 kHz/channel. I can do it if I use SO_CONTINUOUS flag but with the SO_SINGLEIO flag, it gives me an error (Error Code: 18) with FIFO overrun and then a Segmentation Fault. I have attached my scripts for reference.

AdqTrig.c AdqTrig PlotPiezos.py