Using SDK function FDwfAnalogInStatusData16() in C++

[AbbyM]

Hello!

I am having some trouble using the function FDwfAnalogInStatusData16() in C++. The host PC I'm using is a Raspberry Pi 4 with Debian Linux.  I am using record acquisition mode. The function call works great for me in Python, I can see an expected sine wave input signal.  But I get all zeroes in my buffer when doing the same thing in C++. The buffer is defined globally as a static array. For now I am working with just 1 channel, but the goal is 3 channels.  My code is attached, can you help me determine what I am doing wrong?  

Thank you,

Abbytest_adpro.cpp

test_adpro.py

[attila]

Hi @AbbyM

 

[attila]

Hi @AbbyM

Please take a look again on the provided WF SDK examples.
test_adpro.cpp: the FDwfAnalogInStatus FDwfAnalogInStatusRecord should be outside of channel loop, read up to cAvailable samples in FDwfAnalogInStatusData16

[AbbyM]

Ok thanks, I actually ended up finding the bug, I was setting false instead of true in FDwfAnalogInStatus () so the device wasn't actually reading data XD

On a related note, I have noticed that cAvailable varies which I assume depends on a number of factors.  But I am planning to interleave 3 channels of data in the same output file.  Is there any way to get a more constant number of valid samples?  is there perhaps a minimum I can use?   I also do not want to have invalid or zeroes in the data file.

Thanks

[attila]

Hi @AbbyM

The prints in your script can slow down the process/loop significantly causing device fifo overflow.

[AbbyM]

OK so I should normally expect to see a constant number for cAvailable?

When I called FDwfAnalogInBufferSizeInfo() it returned 32768.  Is this the maximum number of samples that can be read at one time?

[attila]

Hi @AbbyM

It depends on how many samples were collected since the last call.
Normally the maximum is the device buffer size but with ADP3X50's DDRam buffering it can be up to 4Mi chunk.

[AbbyM]

OK interesting. I have been attempting to keep it constant.  It does fluctuate but not a crazy amount.  

Is the DDRam buffering automatic, or do we have to configure it?

thanks, 

Abby

[AbbyM]

Hi there,

One followup question to this thread.  I went to look for the DDRam setting under the Waveforms options but cannot find the window that was referred to in your linked thread.  The only thing I could find was a speed test under Options->Device.  it says "4 MiB" at the end of each sentence so I wonder if that is the equivalent DDRam buffer setting?

[attila]

Hi @AbbyM

The DDRam buffering improves recording for ADP3X50 in standard mode, otherwise it is transparent to the user.
In your screenshot an AD2 is used.

 

You may want to try using some newer sw version:

https://digilent.com/reference/software/waveforms/waveforms-3/start

 

Edited November 14, 2022 by attila

[AbbyM]

OK, so I am using the Discovery Pro 2 software and not the ADP3450?  I remember selecting ADP3450 when I downloaded Waveforms.  Just to double check, which OS version do you recommend for a Raspberry Pi with 64-bit OS?   I used the 64-bit Debian ARM image and Adept libraries.

Edited November 14, 2022 by AbbyM
misspelling

[AbbyM]

I am now trying to install the new 3.18.58 software but I can't figure out how to do that on the Raspberry Pi. Which executable file do I run to install?  

Thanks 

[AbbyM]

Ah never mind, I just realized its an executable *.deb file 

[AbbyM]

I am confused as to which version to use for the Raspberry Pi using the 64-bit OS. 

It seems that the only installers that actually run without errors are the ones with "arm" in the name.

I just installed 3.18.19 "armhf.deb" but when I rebuilt and ran my script it gave this error:

pi@raspberrypi:~/verde $ ./adpro 
./adpro: error while loading shared libraries: libdwf.so: wrong ELF class: ELFCLASS32
pi@raspberrypi:~/verde $

The Waveforms GUI works fine but not my script which is my end target.

Edited November 15, 2022 by AbbyM

[attila]

 

[AbbyM]

thank you!