Wolfram.T

Hello John, thank you very much for the information. I think that explains the issues we're having. Best regards, Wolfram

Hello again, we're currently checking our wiring. Is there any preference as to how the 4 ground pins on the device should be used or are they all the same? I'm talking about the left side pins 15 and 19 as well as the right side pins 29 and 38 - not the analog ground on pin 9. On our device the ground pin 15 is labeled in a greyish color instead of white like all the other pins, but the manual doesn't mention it as being special. Best regards, Wolfram

Hello John, thank you for your input. I'll check the wiring and try a different trigger source. Maybe having a look with an oscilloscope won't hurt either. Best regards, Wolfram

Hello everyone, I've got a problem with the triggered analog readout of the DT9816. I'm using the C# DotNET API and usually it's working fine, but sometimes the device stops reacting to the trigger and doesn't aqcuire any more data. This behaviour happens arbitrarily, sometimes after a few 100 trigger pulses, sometimes after a few thousand, and sometimes I can capture tens of thousands of measurements without any issue. The delay between triggers is usually about 40 mS. When the device is in the non-working state, I need to either unplug and replug the USB cable or restart the entire PC. Just a restart of our software doesn't solve the issue. Our software doesn't report any runtime errors either, there are just no more data packets arriving. We've already tested this on another PC running a different operating system (Win10 / Win11) with the same results. Any ideas as to why this could be happening? Thank you very much for your time, Wolfram

Hello John, thank you for the heads-up. This way I can stop looking for the error in my code. Best Regards, Wolfram

Hello again, out of curiosity I tried the DotNET C# example "ReadBufferedDataAsRawDigTrigger" and it works just fine with trigger type "TTLNeg". Problem is, our whole code base is C/C++ so I can't just switch to C# with DotNET. Could this be a version problem with my Win32 libraries and DLLs? I downloaded them just a couple of days ago. Best regards, Wolfram

Hello John, sadly, no change (just as the queried capabilities in my first post suggest). olDaSetTrigger(AD_Handle, OL_TRG_THRESHNEG); // ==> 36 (Not supported) olDaSetTrigger(AD_Handle, OL_REFERENCE_TRG_THRESHNEG); // ==> 36 (Not supported) Maybe this has something to do with the "OLSSC_NUMEXTRATRIGGERS" capability? Best regards, Wolfram

Hello John, thanks for your suggestion. When I run the CExample (in Visual Studio) it doesn't allow me to select the external trigger. When I try to enable it in my code (in Qt - MinGW compiler) I get ECODE 36 (Not supported). HDEV Board_Handle; // Initialized elsewhere. HDASS AD_Handle = nullptr; olDaGetDASS(Board_Handle, OLSS_AD, 0, &AD_Handle); // ==> 0 (No Error) olDaSetDataFlow(AD_Handle, OL_DF_CONTINUOUS); // ==> 0 (No Error) olDaSetTrigger(AD_Handle, OL_TRG_EXTERN); // ==> 36 (Not supported) Only in QuickDAC (3.7.0.49) I can select "External TTL Neg Edge" as trigger source (which then works as expected). As far as I understand QuickDAC uses the DotNet SDK, whereas the CExample and my Code use the Win32 SDK. Is this possibly a limitation of the Win32 SDK? Best regards, Wolfram

Hello everyone, I've got a question regarding the DT9816. I'm accessing it via the DataAcq Win32 SDK in C++. I want to trigger a readout of the analog input channels using a pulse on the "Ext Trigger" input. I've got it working for normal continuous operation (without the trigger) by using olDaSetDataFlow(OL_DF_CONTINUOUS) and a callback function to receive the data via olDaSetNotificationProcedure(). In the manual for the DT9816 (page 77) it states the AD unit has "External Negative TTL Trigger Support" for acquisition start, and I can see it working that way in the QuickDAC 3.7.0 software. But when I try to setup the trigger in my software (using olDaSetTrigger()) I always get "Not supported". Querying the AD unit capabilities using olDaGetSSCaps() seems to confirm that it doesn't support any trigger except software trigger: OLSSC_NUMEXTRATRIGGERS 1 OLSSC_SUP_SOFTTRIG 1 OLSSC_SUP_EXTERNTRIG 0 OLSSC_SUP_THRESHTRIGPOS 0 OLSSC_SUP_THRESHTRIGNEG 0 OLSSC_SUP_ANALOGEVENTTRIG 0 OLSSC_SUP_DIGITALEVENTTRIG 0 OLSSC_SUP_TIMEREVENTTRIG 0 OLSSC_SUP_TRIGSCAN 0 OLSSCE_MAXRETRIGGER 63 OLSSCE_MINRETRIGGER 64 OLSS_SUP_RETRIGGER_INTERNAL 0 OLSS_SUP_RETRIGGER_SCAN_PER_TRIGGER 0 OLSSC_SUP_CONTINUOUS_PRETRIG 0 OLSSC_SUP_CONTINUOUS_ABOUTTRIG 0 OLSSC_SUP_RETRIGGER_EXTRA 0 OLSSC_SUP_SV_POS_EXTERN_TTLTRIG 0 OLSSC_SUP_SV_NEG_EXTERN_TTLTRIG 0 OLSSC_SUP_EXTERNTTLPOS_REFERENCE_TRIG 0 OLSSC_SUP_EXTERNTTLNEG_REFERENCE_TRIG 0 OLSSC_SUP_THRESHPOS_REFERENCE_TRIG 0 OLSSC_SUP_THRESHNEG_REFERENCE_TRIG 0 OLSSC_SUP_POST_REFERENCE_TRIG_SCANCOUNT 0 OLSSC_SUP_SYNCBUS_REFERENCE_TRIG 0 What am I missing here? Thank you very much for your time, Wolfram