Post Go back to editing

ADALM2000 as an ADC for continuous data sampling

Category: Hardware
Product Number: ADALM2000

Hi, is it possible to use Adalm2000 for continuous sampling of signals that will send raw data to the serial port, just like a microcontroller (but faster)?

If so, which is the easiest way to implement this? 

I would appreciate if anyone could provide any suggestions on this.

Thank you

  • Hello, 

    I'm not sure what you want to accomplish

    You want to acquire data from the M2k and stream data out a random GPIO of the adalm2000 in a UART format ? 

    You could probably write such a program using libm2k to acquire, encode each sample in UART format, and push each sample out the digital interface. You can run it on your machine, or you could cross compile it and run it on the adalm2000. I'm not sure if it would be faster than a microcontroller though - depends on microcontroller - but you are bitbanging UART so you are not using dedicated UART .

    Also, there is a dedicated UART interface on the ZYNQ, but that is used for a dedicated console to the embedded linux. I suppose that interface could be repurposed  (although you would have to recompile the kernel) and have a program use that interface to stream data out the m2k continously ...

    -Adrian

  • Hi Adrian, maybe I misformulated my question. Indeed, I wish to accomplish (~10Ksps or faster) continuous data acquisition from adalm2000 to a pc and continuously store data in a file.  

    I tried matlab with libm2k, but I have data loss between successive calls of getSamplesInterleaved_matlab. Is there a way to avoid this loss and have continuous data?

    Probably what you suggested is the solution, but goes beyond my knowldege/actual schedule. 

     Christos

  • The ADALM2000 should be able to handle saving 10ksps to a file. The ADALM2000 has a buffer mechanism which enables continous data if you are pulling data from the device fast enough.

    For more info 

    https://wiki.analog.com/resources/tools-software/linux-software/libiio_internals ,

    - especiially this chapter https://wiki.analog.com/resources/tools-software/linux-software/libiio_internals#high-speed_mmap_interface 

    - Search this forum for "kernel buffer"

    This mechanism should be enabled by default, so any example that does multiple refills should work.

    The matlab example https://github.com/analogdevicesinc/libm2k/blob/main/bindings/matlab/examples/analog.m  uses triggering and plots. If you remove setting up the trigger and change plot to a file dump, it should work.  Can you provide some code that shows discontinued signals ?

  • Hi Adrian, thank you for your answer. I managed to save in a .txt file, 1000sec (or more) of continuous data at 10Ksps, with 64 buffers and acquiring 2^10 samples per channel in every loop, with the following piece of matlab code: 

    fp = fopen('adalm.txt','w');
    ain.setKernelBuffersCount(64);
    ain.setSampleRate(10000);
    for k=1:10000
        data = ain.getSamplesInterleaved_matlab(2*2^10);
        data = data.double.';
        v = data(1:2:end);
        fprintf(fp,'%.8f\n', v1);
    end
    Nevertheless, the above code gives discontinuity between successive loops at 100Ksps. So I have 2 questions:
    1) Adalm2000 (latest firmware) seems to ignore all sample rates >10Ksps and <100Ksps (truncates them to 10Ksps). Is there a reason for this? Permissible sample rates should only be multiples of 10? 
    2) Is there a way to improve the above code in order to have continuous data at increased sample rates? 
    Thank you.
    Christos
     
     
  • Sample rates can only be set to multiples of 10 because there is some input filtering going on based on sample rate.

    You can always use setoversamplingratio() to further divide the sampling rate to the sampling rate that you want. A technique is to always use max sample rate, and then only set oversampling ratio to max_sample_rate/target_sample_rate. 

    Tested in C++ with libm2k calls we reached a few MSPS(2-4 MSPS) of data without discontinuities. I would imagine that the MATLAB penalty is not that great. 

    The code looks fine. You can try increasing the number of samples. Every transfer has some overhead, and the amount of data you are transferring here is quite low.