Jump to content
  • 0

DT9836 data overrun errors


Ludger Breil

Question

We use DT9836s for our products. Our measuring software, written in C++, runs under Windows 10 and 11.

Recently, data-overrun errors have been occurring more frequently in some installations. A lot of other installations running flawless.

Unfortunately, it is not entirely clear where exactly the error occurs or what causes the error. We initially rule out a defect in the ADC itself. There are two entries in the Windows event log each time the error occurs:

INPUT_FIFO_OVERFLOW_MSG c:\oldawdm6.0\dt9836\wdmdriver\dt9836device.cpp(846)

followed by 

DT_DATA_OVERRUN c:\oldawdm6.0\dt9836\wdmdriver\dt9836ainsubsystem.cpp(1404)

As I understand it, the driver is not retrieving the data from the ADC via the USB bus fast enough. Is that correct? Then we might have to look for the error in the USB bus. 
Or is the error in our user program, which does not read the data from the driver fast enough? We work with three buffers, each of which has the size for 1 second of data. 

with regards

Ludger Breil

Link to comment
Share on other sites

3 answers to this question

Recommended Posts

  • 0

Hello @Ludger Breil.

Are you using the same PC model and configuration for all installations or are the problematic systems using a different PC configuration?  

Is the error predictable or sporadic?

Are there background processes, i.e. virus scan, running during the acquisition?

Are Windows hibernation/sleep options enabled?

How many input channels are used?

What is the sampling rate?

Try adding more buffers and/or increasing the buffer size.

 

Regards,

Fausto

Link to comment
Share on other sites

  • 0

Hello Fausto,

the PCs are all different. The hibernate/sleep function is disabled because the measuring devices normally run 24*365.
The error sometimes occurs only once a day, but sometimes two or three times. But not always at a certain time (AV run ...) On one machine the DT9836 driver even caused BSOD's.

Normally, no other large background processes, expcept AVs, should be running in addition to the measurement software. All PCs have an antivirus program. No organization allows a PC on the network without its own AV.  And indeed, some of the machines seem to have the same AV. This is one of our suspects. One test could be to disconnect the PC from the network and switch off the AV. 

We use the two analog channels with 16 bit and one digital channel, we using DMA transfer and the sampling frequency is 640000 sample/s.

Increasing the number of buffers has also occurred to us, but I think that if the error is caused by the transfer ADC -> driver, for example, this won't help either.

Again: can the error message, which even contains the line numbers in the driver code, be used to determine whether the error is more likely to be in the ADC -> driver or driver -> measurement program data transfer?


 with regards

Ludger Breil

Link to comment
Share on other sites

  • 0

Hello @Ludger Breil.

What is your buffer size?

Is it (2AIN + 1DIN) * 640,000 samples/sec = 1,920,000 samples/sec?

Is the data processed on a different thread during the acquisition?

Is the acquisition running continuously 24*365 or does the acquisition stop and restart periodically during each day?  If the acquisition stops periodically during the day, is restarting the application an option?

It is not possible to determine the root cause of your issue, since the error is sporadic.  Based on the error message, the buffers are not cleared fast enough before the new data comes in, hence the overrun.  Try increasing the number of buffers to 10.

 

Regards,

Fausto

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...