Andras

Szia @attila, Thank you, it works now! Just for the record: I incorrectly installed the 32-bit packages (digilent.adept.runtime_2.27.9-armhf.deb and digilent.waveforms_beta_3.20.13_armhf.deb) to my 64-bit Raspberry OS. WaveForms worked, but DWF didn't. To fix this I first needed to remove those two packages: sudo dpkg --remove digilent.waveforms:armhf sudo dpkg --remove digilent.adept.runtime:armhf And then - as you suggested - I installed the digilent.adept.runtime_2.27.9-arm64.deb and digilent.waveforms_beta_3.20.13_arm64.deb packages, and DWF came alive! Thank you! Andras

I'm trying to run a .NET application on Raspberry Pi 4 using the DWF library. It runs on Windows and I could make it work in Raspberry OS before (I just can't remember exactly how 🙈). It's a fresh installation, so first I installed the Adept Runtime (digilent.adept.runtime_2.27.9-armhf.deb) and WaveForms (digilent.waveforms_beta_3.20.13_armhf.deb) without any issues, and WaveForms sees the AD3 correctly. When I run my app and I call the FDwfGetVersion method, and I get this exception: Failed to get DWF version. System.DllNotFoundException: Unable to load shared library 'dwf' or one of its dependencies. In order to help diagnose loading problems, consider using a tool like strace. If you're using glibc, consider setting the LD_DEBUG environment variable: /home/pi/Work/bbd-p08-body-monitor/Source/BBD.BodyMonitor.API/bin/Debug/net7.0/runtimes/linux-arm64/native/dwf.so: cannot open shared object file: No such file or directory /opt/dotnet/shared/Microsoft.NETCore.App/7.0.7/dwf.so: cannot open shared object file: No such file or directory /home/pi/Work/bbd-p08-body-monitor/Source/BBD.BodyMonitor.API/bin/Debug/net7.0/dwf.so: cannot open shared object file: No such file or directory /home/pi/Work/bbd-p08-body-monitor/Source/BBD.BodyMonitor.API/bin/Debug/net7.0/runtimes/linux-arm64/native/libdwf.so: cannot open shared object file: No such file or directory /opt/dotnet/shared/Microsoft.NETCore.App/7.0.7/libdwf.so: cannot open shared object file: No such file or directory /home/pi/Work/bbd-p08-body-monitor/Source/BBD.BodyMonitor.API/bin/Debug/net7.0/libdwf.so: cannot open shared object file: No such file or directory libdwf.so: wrong ELF class: ELFCLASS32 /home/pi/Work/bbd-p08-body-monitor/Source/BBD.BodyMonitor.API/bin/Debug/net7.0/runtimes/linux-arm64/native/dwf: cannot open shared object file: No such file or directory /opt/dotnet/shared/Microsoft.NETCore.App/7.0.7/dwf: cannot open shared object file: No such file or directory /home/pi/Work/bbd-p08-body-monitor/Source/BBD.BodyMonitor.API/bin/Debug/net7.0/dwf: cannot open shared object file: No such file or directory /home/pi/Work/bbd-p08-body-monitor/Source/BBD.BodyMonitor.API/bin/Debug/net7.0/runtimes/linux-arm64/native/libdwf: cannot open shared object file: No such file or directory /opt/dotnet/shared/Microsoft.NETCore.App/7.0.7/libdwf: cannot open shared object file: No such file or directory /home/pi/Work/bbd-p08-body-monitor/Source/BBD.BodyMonitor.API/bin/Debug/net7.0/libdwf It looks for dwf and libdwf files. I have a libdwf.so in /usr/lib which is a link to libdwf.so.3.20.13 in the same folder. I tried to copy the file into my app's folder, but no luck. I suspect that the library can't be loaded for some reason. Is armhf the right architecture for the 64-bit Raspbian OS? Does WaveForms use this library to connect with AD3? (Because then I can rule out the architecture issue.) Should this work or am I missing something?

Alright, that was it! I added a few more lines to make sure that we always have a big enough buffer. if (cAvailable > voltData.Length) { _logger.LogWarning($"The data available on the device is more than our local buffer size ({cAvailable} > {voltData.Length}), so we double the size of the buffer."); voltData = new double[voltData.Length * 2]; } Thank you @attila!

Szia @attila Yes, I think I have the proper array size, but could you take a look? _ = dwf.FDwfAnalogInBufferSizeInfo(dwfHandle, out int bufferSizeMinimum, out int bufferSizeMaximum); bufferSize = Math.Min(bufferSizeMaximum, (int)acquisitionSamplerate); logger.LogTrace($"Device buffer size range: {bufferSizeMinimum:N0} - {bufferSizeMaximum:N0} samples, set to {bufferSize:N0}."); voltData = new double[bufferSize]; This means that voltData is a 32768-sized double array when I open AD3 with the second configuration. Then later I call FDwfAnalogInStatusRecord to get the number of samples available and I call FDwfAnalogInStatusData to get them. _ = dwf.FDwfAnalogInStatusRecord(dwfHandle, out int cAvailable, out int cLost, out int cCorrupted); ... _ = dwf.FDwfAnalogInStatusData(dwfHandle, 0, voltData, cAvailable); But as you mentioned the shared scope buffer, I realized that it might be possible to have a situation when cAvailable > bufferSizeMaximum with AD3? I'll test this and get back to you! Thank you for the details!

I started testing the new AD3, and I got access violation errors when I tried to start a data acquisition at 1000k samples per second. I don't get this error when I do it at 500k SPS with AD3 or at 1000k with AD2. Running AD3 at 1000k SPS: In my data acquisition loop I call the FDwfAnalogInStatusRecord and FDwfAnalogInStatusData methods. The access violation happens at the FDwfAnalogInStatusData call. Interestingly if I change the sampling rate to 500k SPS then the acquisition works fine. AD2 can handle 500k SPS without any problem, and although at 1000k SPS I start losing some data, it never causes access violation. Running AD2 at 1000k SPS: Both devices are opened with their second configuration, so with 16k scope buffer for AD2 and 32k scope buffer for AD3.

This topic has ~2200 views, but no discussion since 2014. Could you unpin it, so we don't click on it expecting something useful? Thank you!

Szia @attila, Thanks for the tip, I'll check that SDK sample out! I made a few small modifications to my code yesterday, including the removal of the Thread.Sleep and now I could go up to 500 kSPS without any major issues, and I had a 8-hour long recording session at 250 kSPS with only ~25 packet losses, which I think is acceptable. Thank you again for your input!

Szia @attila! Thank you for the explanation! I would need your help. I have been writing my own C# tool to control my AD2 and capture data from its scope. It got better over the past months, but I still occasionally get corrupted data even at reasonably low rates, typically at 250kSPS. It looks like WaveForms has no trouble at all even at higher rates. Here is below how my data acquisition loop looks like, could you take a quick look? I use DWF v3.18.55, the loop thread runs with the highest priority, and I use AD2 with the 2x 16 Ki scope setting. The samplesBuffer is a shifting buffer implementation. int i = 0; while (!terminateAcquisition) { while (true) { i++; if (i % 100 == 0) { if (availableBytes != totalBytes) { logger.LogWarning($"Data acquisition device reported some errors! Good: {(availableBytes / totalBytes).ToString("0.0%").PadLeft(6)} | Corrupted: {(corruptedBytes / totalBytes).ToString("0.0%").PadLeft(6)} | Lost: {(lostBytes / totalBytes).ToString("0.0%").PadLeft(6)}"); } totalBytes = 0; availableBytes = 0; corruptedBytes = 0; lostBytes = 0; } Thread.Sleep(5); dwf.FDwfAnalogInStatus(dwfHandle, 1, out byte sts); if (!((samplesBuffer.TotalWrites == 0) && ((sts == dwf.DwfStateConfig) || (sts == dwf.DwfStatePrefill) || (sts == dwf.DwfStateArmed)))) break; logger.LogWarning($"Data acquisition device got into an unusual state! sts:{sts}"); Thread.Sleep(500); } dwf.FDwfAnalogInStatusRecord(dwfHandle, out int cAvailable, out int cLost, out int cCorrupted); if (cAvailable == 0) { logger.LogWarning($"Aqusition error! cAvailable: {cAvailable:N0}"); Thread.Sleep(500); logger.LogTrace($"Reseting device..."); dwfHandle = ResetDevice(); bufferError = false; samplesBuffer.Clear(); continue; } int cTotal = cAvailable + cLost + cCorrupted; if ((cLost > 0) || (cCorrupted > 0)) { bufferError = true; } totalBytes += cTotal; availableBytes += cAvailable; lostBytes += cLost; corruptedBytes += cCorrupted; dwf.FDwfAnalogInStatusData(dwfHandle, 0, voltData, cAvailable); // get CH1 data chunk if (bufferError) { samplesBuffer.Error(cAvailable, cLost, cCorrupted, (int)cTotal); bufferError = false; continue; } double[] voltDataAvailable = new double[cAvailable]; Array.Copy(voltData, voltDataAvailable, Math.Min(cAvailable, voltData.Length)); samplesBuffer.Write(Array.ConvertAll<double, float>(voltDataAvailable, v => (float)v)); } If you don't mind sharing, I would be very interested in your data recording loop in WaveForms. Does it use DWF as well to communicate with the device? Thank you, Andras

Szia @attila, I just wanted to share the news that I could make AD2 work with Android. Kind of :) I connected AD2 to my Android 10 phone by using an OTG cable. I installed VirtualHere USB Server on my phone and the VirtualHere USB Client on my Windows 11. After some basic configuration I could see my AD2 as "Digilent USB Device" on my Windows machine while it was connected to my phone only. I selected "Use this device", I opened WaveForms and I was able to start the Scope. VirtualHere USB Server costs $25, but it's probably worth it for someone who needs the extra mobility.

Szia @attila, When you say "support network devices" do you mean something like a USB emulation over IP solution for AD2 on Android, or you mean another Digilent/NI device that supports network connection natively and works with Android out of the box?

Hi @attila, I know it's kind of an old question, but I wonder, do you still think that Android support for Analog Discovery 2 is not going to happen? I have Android 10 at the moment, but I know that Android 13 is coming soon. Is the USB device driver problem still an issue? Even if the WaveForms software would not run, could the DWF SDK libraries theoretically work if the USB driver works fine on newer Androids? I ask it, because I have a .NET 6 application that uses my AD2 and it could run on Andoid, if DWF would work.

Szia @attila, Thank you for your explanation, I definitely learned something again! :) I didn't know about the window function, but it makes perfect sense now!

Alright, thank you! I'm just curious: is this an expected behavior? Do I understand it correctly that the screen mode would mean that the source of the FFT are the samples that are currently visible on the screen? If so, and you look at the video I attached, why is this hump in FFT only there at a certain point? The array of samples look continuous on the screen after the first round-trip.

I use WaveForms 3.17.18 on Windows 11 with Analog Discovery 2. The wave generator output (W2) is directly connected to scope input CH1. W2 is set to 123.4567 Hz Sine wave with 500 mV amplitude. I set the Scope to 1kHz and its rage to 200mV/div. I use the built-in FFT in the range of 120 - 130 Hz with the Peak(V) setting. It normally looks good but periodically I get a strange reading like this: I'm not sure what is happening here, could you help me find out? I also made a screencap of this and uploaded here: https://drive.google.com/file/d/1Bxn0S0H6SM2J9r3cXOgJ3lleH5cPN6v7/view?usp=sharing

I got this error after running c:\Program Files (x86)\Digilent\WaveFormsSDK\samples\py\Enumerate.py.