ADP3450 effective sample rates

[AbbyM]

Hello,

I have been using the ADP3450 with a Raspberry Pi 4.  I am running a C++ script to pull data from 3 channels at a target sampling rate of 6 MSPS, using 16-bit signed data type. Using the record acquisition mode and reading in a loop. But I am getting effectively about 1 MSPS no matter how fast I set the ADP's sampling rate.   I am using a USB cable which I have measured is getting 38-39 Mbps.  This should equate to ~5 MSPS maximum, so I don't know what is happening to get a much slower rate.  My code is pasted below, the initialize function and the querying function. 

Also, when setting the sample rate to 1 MSPS just to verify, I noticed the USB transfer rate is only 8 Mbps.  But at or above 4.5 MSPS, the USB transfer rate is maximized at 38-39 Mbps.   At 8 Mbps, this only equates to 0.5 MSPS, so why does the device send data at half the desired rate in this instance?  

e.g. the file size at 6 MSPS is 830 MB per channel.  but for 1 MSPS it is 190 MB when it should be 600 MB

Thank you,

Abby

Code:

void initOscope(void) {
    char szError[512] = {0};
   
    cout << "Entered initOscope()\n"; //DEBUG
   
    printf("Open automatically the first available ADPro device\n");
    // if(!FDwfDeviceConfigOpen(-1, 1, &hdwf)) {
    if(!FDwfDeviceOpen(-1, &hdwf)) {
        FDwfGetLastErrorMsg(szError);
        printf("ADPro device open failed\n\t%s", szError);
        return;
    }
   
    //enable channels
    for(int c = 0; c < NUM_CHANNELS_USED; c++){
        FDwfAnalogInChannelEnableSet(hdwf, c, true);
    }

    //set pk2pk input range for all channels
    FDwfAnalogInChannelRangeSet(hdwf, -1, 5);
   
    //acquisition mode
    FDwfAnalogInAcquisitionModeSet(hdwf, acqmodeRecord);

    //sample rate
    FDwfAnalogInFrequencySet(hdwf, SAMPLE_RATE);

    FDwfAnalogInRecordLengthSet(hdwf, 0);

    // wait at least 2 seconds with Analog Discovery for the offset to stabilize, before the first reading after device open or offset/range change
    Wait(2);

    // start
    FDwfAnalogInConfigure(hdwf, 0, true);

    cout << "Exiting initOscope()...\n"; //DEBUG
}

...................................

 while (stopRecord == false && newFileFlagRf == false) {      
            // get the samples for each channel
            for(c = 0; c < NUM_CHANNELS_USED; c++) {      
                if(!FDwfAnalogInStatus(hdwf, true, &sts)) {
                    cout << "FDwfAnalogInStatus() error\n";
                }
                if((sts == stsCfg || sts == stsPrefill || sts == stsArm)){
                    // Acquisition not yet started.
                    continue;
                }
                FDwfAnalogInStatusRecord(hdwf, &cAvailable, &cLost, &cCorrupted);

                if(!cAvailable) continue; //only get data samples if there are any available

                if (c == CH1_REF) {
                    FDwfAnalogInStatusData16(hdwf, c, sampleFileBuf1, 0, cAvailable); 

                }
                else if (c == CH2_REF) {
                    FDwfAnalogInStatusData16(hdwf, c, sampleFileBuf2, 0, cAvailable); 

                }
                else if (c == CH3_REF) {
                    FDwfAnalogInStatusData16(hdwf, c, sampleFileBuf3, 0, cAvailable); 

                }

FDwfDeviceClose(hdwf); //close the device

}

[zygot]

The point of my last post was to suggest that Ethernet performance on one platform may not be the same as on another. I also happen to like Ethernet as a pipe for transferring data between devices. You can control timing as well as efficiency. Some hardware platforms come with complications, especially when you have 2 or three high demand elements sharing one resource. I was responding to the discussion concerning Ethernet performance for a device like the ADP3450.

It's possible to stream 40 MB/s over USB 2.0 and 350 MB/s over USB 3.0. These are user payload data rates. System software issues can reduce this. In my experience CPU architecture can have a negative impact on those values. ARM in particular, whether on a Broadcom devices designed to be used on lower cost set top boxes, Nvidia SOMs or even ARM based FPGA devices. Cost has a lot to do with it. [edit] There's nothing inherently wrong with "ARM" architecture as Apple has made clear with their Mn chip-sets. Clearly ARM on a uC or embedded in an FPGA is a different animal compared to those beasts. My experience with ARM is strictly with the older embedded ARM hardware implementations.

What Ethernet provides verses USB or most other serial interfaces, at least theoretically, is flexibility on packet size without incurring a performance penalty or excessive software overhead. It's possible to DMA data between memory and and Ethernet PHY but not USB due to the protocol. USB needs software support. Transferring data using only hardware clearly has performance advantages.

Really, the basic question that this thread asks, as I understand it, is this: I want to do x using y/z platforms; is it a realistic to expect that I can do this? In the case of Raspberry Pi 4 and the ADP3450 neither vendor is particularly interested in providing all of the details needed to answer that question; or when they do provide answers to particular questions the answers might not make sense absent of other information.
Edited November 24, 2022 by zygot

[AbbyM]

In reply to zygot's last paragraph, that's exactly right, though at first I didn't realize it.  From all the input so far, it seems the core issue is in my Raspberry Pi 4 and its Ethernet setup, or drivers, or something. The ADP3450 seems quite capable and when I connected it to a Windows 10 laptop via Ethernet, it was getting 71 MBps.  I will keep researching for any tweaks that need to be made or if anyone else has had slow performance with that setup of RPi 4 <--> ADP3450 via Ethernet.  

Thanks to everyones generous help so far!