Ludger Breil

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

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