AD2 scope oversampling with ext trigger: communication error

[wna]

When using Oversampling in the scope instrument with external trigger source there is a communication error "invalid data count provided" as soon as the trigger occurs (beta 3.13.19 amd64 on Linux, but also with earlier versions).

[attila]

Hi @wna

Thank you for the observation.
It will be fixed in the next version.

[CeeKay]

@attila Is this fixed?

I am running a bunch of custom python scripts for data acquisition with AD2, where I use the record mode to take N samples when triggered at a set sampling frequency (1-2.5 MS/s). My script works flawlessly on both my macbook pro and another windows PC, but the samples get messed up when running on two different linux machines and this error message is presented. 

 

Since the system I'm designing will use a linux machine to run it all, It would be really great if there is some sort of fix for this :) 

[attila]

Hi @CeeKay

Have you used USB or Ethernet connection?

Please try the latest WF beta version:

This brings some improvements for recording over Ethernet with Standard boot mode and further optimizations if less channels are used.

 

If this doesn't help try the Linux boot mode.
The Standard is a baremetal app with USB and Eth (LwIP). The Linux is a bit slower but it could provide better network support.

 

[CeeKay]

@attila I'm using USB and wasn't even aware that an ethernet interface was possible on AD2. For my use, i guess swapping to ethernet interface is possible since I have a port free on the linux machine. (EDIT: I guess you were referring to Analog Discovery Pro regarding ethernet interface :) )

But, after further testing I have found out a bit more about my issues, which might hint to that my problems are unrelated to the issue in this thread, but please take a look: 

My python scripts set the AD2 analog in sampling frequency when started and the rest of the data acquisition uses this fs to record N samples on both analog in channels when triggered. On my macbook pro and on a windows machine, changing sampling frequency to ranges I use (0.8MHz to 2.5MHz) works fine, i.e. the sampling frequency is correctly set and data acquisition works as expected. Sometimes samples are lost and/or corrupted due to the amount of samples I'm acquiring etc and the error message "invalid data count provided" occurs when samples are lost. This is not actually a big issue, since my acquisition-script then retries sampling the N samples until the sLost or sCorrupted values are both zero and no error messages are produced from the AD2 (GetLastError is empty). This works just fine in the system. BUT, when I use the same scripts on linux machines (tested with two different machines with different specs), something weird happens. The error message "invalid data count provided" occurs sometimes just as with the other machines, so this issue itself is maybe not the main cause since the script only plots the data when the AD2 gives no error messages. What happens is that the samples themselves are wrong when the sampling frequency is higher or lower than 1MS/s. So if Analog In sampling frequency is 1MS/s, it works just as fine as the other machines. But if i set fs to e.g. 0.8, 1.5, 2 or 2.5 MS/s, the samples are simply wrong even if no error message occurs. So that when the error message does not occur, then the data acquisition has "succeeded", but plotting of the data proves that it's wrong. 

I have attached 4 pictures. Ignore the upper plots on the images, as this input was not connected. The signal that is connected to the other channel is a sine burst signal with burst interval of 2ms. As seen in the correct signal image (the last image), which is what I get with macbook or windows machines, the signal is sampled correctly (whatever fs i use, 2.5MS/s in this image). The 3 other images are from the linux machine running the same script with fs = 0.8, 2 and 2.5 MS/s. 

Do you have any clue to why the samples are wrong when the AD2 does not produce any error message? We are suspecting issues with the linux drivers for the AD2, but would be great to get some verification from you guys on this. 

 

 

Edited October 8, 2021 by CeeKay

[attila]

Hi @CeeKay

Sorry but I thought this post is about ADP3450 :)

The "invalid data count provided" is when index + count is higher than the buffer size or negative.
See the AnalogIn_Record.py AnalogIn_Record_Trigger.py or the other examples.
How many samples are you capturing? are you using trigger? if so where is the trigger position?
Could you post or send me your record loop code?

This is ok:

 

The device buffer overflow, like here at 5MHz, results is similar data corruption:

 

At higher rate or latency also results in loss of samples:
 

[CeeKay]

@attila Yea my scripts essentially redo the acquisition if samples are lost or corrupted, so the data that is saved and plotted is only when no error messages are produced.  I have pasted in snippets from my code which includes the parts needed to understand the acquisition I perform. I want to re-state that the issues only occur on linux machines :) 

Also I guess the acquisition is not triggered as I may have said earlier. Recording is initiated when configured in the script, and it triggers the AWG to transmit (no issues here). In the images I attached previously, I just set it to do the acquisition like this and record 10000-16000 samples based on changing the fs and range parameter.

Here is the main loop snippet which calls the record function and only plots data if the acquisition is without any error codes: 

 

 

### Echosounder acquisition  ###

fs = 2.5e6

Range = 5 ## Meter range

c = 1500 # Speed of sound
SampleTime = Range*2.0/c # How long should we sample for to cover range

nSamples = int(fs*SampleTime) # Number og samples to acquire/record per ping

tVec = np.linspace(0, SampleTime, nSamples) ## For plotting samples vs time of returned echo 

 

           

### Enable both scope channels and set voltage range ##
dwf.FDwfAnalogInChannelEnableSet(hdwf, c_int(-1), c_bool(True))
dwf.FDwfAnalogInChannelRangeSet(hdwf, c_int(-1), c_double(5))

### Set AD2 to record mode, unsure about buffer size  ###
dwf.FDwfAnalogInAcquisitionModeSet(hdwf, acqmodeRecord)
dwf.FDwfAnalogInBufferSizeSet(hdwf, c_int(50000))

### Set sampling frequency ###
dwf.FDwfAnalogInFrequencySet(hdwf, c_double(fs))
set_fs = c_double()
dwf.FDwfAnalogInFrequencyGet(hdwf, byref(set_fs))
print("Set fs:", set_fs.value)

 

# Wait at least 2 seconds for offset to stabilize
time.sleep(2)

sLost = 1
sCorrupted = 1

while sLost or sCorrupted == 1:
''' Sampling data (removed some communication-parts here for simplicity'''
               
    CH1_Samples, CH2_Samples, sLost, sCorrupted = sampleData(dwf, hdwf, nSamples)
    print("sLost = ", sLost, "sCorrupted = ", sCorrupted)

    szerr = create_string_buffer(512)
    err = create_string_buffer(512)
    dwf.FDwfGetLastError(err)
    dwf.FDwfGetLastErrorMsg(szerr)
    print("Error:", str(szerr.value))
    print("Errorcode:", str(err.value))
           

#Signal processing and plotting raw data only if no errors have happened during acquisition
 

 

Here is the recording loop: 

def sampleData(dwf, hdwf, nSamples):
    ''' Samples N samples from the two scope channels
        on the AD2. Returns arrays with samples 
        and error messages (sLost / sCorrupted).
    '''
    CH1_Samples = (c_double*nSamples)()
    CH2_Samples = (c_double*nSamples)()

    # Variables
    cAvailable = c_int()
    cCorrupted = c_int()
    cSamples = 0
    fLost = 0
    fCorrupted = 0

    # Configure scope chanels (Starts acquisition)
    dwf.FDwfAnalogInConfigure(hdwf, c_int(1), c_int(1)) ## Begins data acquisition and initiates the Analog Out to transmit 1 pulse 

    sts = c_int()

    while cSamples < nSamples:
        dwf.FDwfAnalogInStatus(hdwf, c_int(1), byref(sts)) ## Check state, read data
        if cSamples == 0 and (sts == DwfStateConfig or sts == DwfStatePrefill or sts == DwfStateArmed) :
            print("Acquisition not started")
            continue

        dwf.FDwfAnalogInStatusRecord(hdwf, byref(cAvailable), byref(cLost), byref(cCorrupted)) ## Read status

        cSamples += cLost.value

        if cLost.value :
            fLost = 1
        if cCorrupted.value :
            fCorrupted = 1

        if cAvailable.value==0 :
            continue

        if cSamples+cAvailable.value > nSamples :
            cAvailable = c_int(nSamples-cSamples)

        # Get samples from AD2 and store in array
        dwf.FDwfAnalogInStatusData(hdwf, c_int(0), byref(CH1_Samples, sizeof(c_double)*cSamples), cAvailable) # Get Channel 1 data
        dwf.FDwfAnalogInStatusData(hdwf, c_int(1), byref(CH2_Samples, sizeof(c_double)*cSamples), cAvailable) # Get Channel 2 data

        cSamples += cAvailable.value

    if fLost:
        print("Samples were lost! Reduce sampling frequency or optimize loop.")
    if fCorrupted:
        print("Samples could be corrupted! Reduce sampling frequency or optimize loop.")

    return np.array(CH1_Samples), np.array(CH2_Samples), fLost, fCorrupted
 

[CeeKay]

@attila Issue still happens with latest waveforms beta. Samples are only correct on linux machine when sampling frequency is set to 1MS/s. 

[attila]

Hi @CeeKay

Probably under Linux the USB transfer rate is lower or the latency is higher and this result in lower sustainable streaming rate.

Suggestions to improve the script:
1. I suppose you are using trigger position zero (default) (FDwfAnalogInTriggerPositionSet) or no trigger (also default when not configured at all).
This way the streaming will start only when triggered (or immediately), reducing the change of device buffer overflow.
2. Specify the required record length (FDwfAnalogInRecordLengthSet) 10-16k instead of constant 50k.
This way the recording will stop after the needed samples are collected, reducing the chance of overflow.
3. For AD2 you could try to use the 2nd device configuration with double analog-in (Scope) device buffer. Note this will reduce the analog-out (Wavegen) buffer size (resolution).
dwf.FDwfDeviceConfigOpen(c_int(-1), c_int(1), byref(hdwf)) 

The improvements in the latest beta are for the ADP3X50.

 

[CeeKay]

@attila I'll try out your suggestions and experiment more during this week. Thanks for the help so far! :)