Post Go back to editing

Optimizing Data Acquisition and Transmission for Long-Duration FMCW Radar Frames Using the CN0566 Phaser and ADALM-PLUTO Platform

Category: Software
Product Number: CN0566

I want to create a MATLAB program that uses the CN0566 to create a frame that lasts for 15 seconds and sends 100 chirps during that frame. Now I know the CN0566 has an ADALM-PLUTO evaluation board with 512 MBytes, of which only 128 MBytes are allocated for Rx. In that case, I want to fill the 128 MBytes of the Rx before sending the information from the ADAM-PLUTO to the PC through the USB 2.0 connection. Speed is not an issue here, it takes a minute for the whole process to happen is fine. I want to know if this is possible with the CN0566 since I have tried to get 10 seconds of data but the most I could push was for 1.4 seconds with these values for the FMCW radar mode:

maxRange = 3;

fc = 10e9;

lambda = physconst("LightSpeed") / fc;

rampbandwidth = 500e6;

nPulses = 100;

tpulse = 0.2;

tsweep = 0.1311;

sweepslope = rampbandwidth / tsweep;

fs = 0.8e6;

fmaxbeat = sweepslope * range2time(maxRange);

nSamples = 1.0485e+06;

  I'm using the fmcwDemo from the Phaser-Control-with-MATLAB-main as a base code for this.

  • Hi Jose,

    Can you send me the parameters that you are using for the TDD engine?  You can see their explanation here:

    https://youtu.be/KBFYzVOuhmI?si=SRRSWRE6LtSBf4X7&t=545

    Also, probe the "Vtune" pin of the Phaser board with an oscilloscope.  How many chirps to do you see, and what is the timing of them?  

  • Hi Jon,

    Sorry for the late response. I managed to make it buffer up to 8 seconds which is pretty close to what I needed but now I'm having problem with the chirp synchronization. My first 100 chirps are fine, but after that every 100 chirps or so the place where the chirp should be starts to move. For example:

    The first chirp is the 101th chirp out of the 1000 and the next one is the 200th chirp, as you can see there is a movement of the chirp itself (to the right) even thought the values should not change during the whole receiving part, it can be said that the PRI is not constant. I'm getting 1000 chirps in one frame, here are my values:

     

    sample_rate = 1e6
    center_freq = 2.1e9
    signal_freq = 100e3
    rx_gain = 20   # must be between -3 and 70
    output_freq = 10e9
    default_chirp_bw = 500e6
    ramp_time = 500      # ramp time in us
    sdr_pins = adi.one_bit_adc_dac(sdr_ip)
    sdr_pins.gpio_tdd_ext_sync = True # If set to True, this enables external capture triggering using the L24N GPIO on the Pluto.  When set to false, an internal trigger pulse will be generated every second
    tdd = adi.tddn(sdr_ip)
    sdr_pins.gpio_phaser_enable = True
    tdd.enable = False         # disable TDD to configure the registers
    tdd.sync_external = True
    tdd.startup_delay_ms = 0
    tdd.frame_length_ms = ramp_time/1e3 + 1.2    # each chirp is spaced this far apart
    num_chirps = 1000  
    tdd.burst_count = num_chirps       # number of chirps in one continuous receive buffer

    tdd.channel[0].enable = True
    tdd.channel[0].polarity = False
    tdd.channel[0].on_ms = 0.01
    tdd.channel[0].off_ms = 0.1
    tdd.channel[1].enable = True
    tdd.channel[1].polarity = False
    tdd.channel[1].on_ms = 0.01
    tdd.channel[1].off_ms = 0.1
    tdd.channel[2].enable = False
    tdd.enable = True
    What I need to do is to get those 1000 chirps from that one frame and take the fft of each of them and then use them for some processing. I don't want to manually select each chirp from the frame. I wanted to use the rx_bursts that you had in your python program to get just the linear part, but its seems the chirps are not synchronized. Is it maybe a problem with any of the variables? And to make the radar work with one receiver I only need to change this variable no?

    my_sdr.rx_enabled_channels = [0, 1]  # enable Rx1 and Rx2
    into
    my_sdr.rx_enabled_channels = [0]  # enable Rx1 and Rx2
  • Hi Jose, yes I think I see the same problem too.  We are working on a new rev of Pluto firmware that should fix this timing error.  I should have an update for you next week.  

  • Hi Jose,

    We did release that firmware a few months ago.  I just want to make sure you are aware of it.  It is rev 0.39 of pluto.  Found here:

    https://github.com/analogdevicesinc/plutosdr-fw