ADALM-Pluto: How to change settings with quick settling

Hi,

One of our users of the ADALM-Pluto is applying it in labs for their communication course. Extending on the possibilities in the lab, they want to change the settings of the receiver quickly. Using GNURadio they encounter 1 sec stall / blank time after doing a change. 

I myself checked with SDR# and e.g. a frequency change seems to be immediate. 

Below the description (without pictures) and attached a pdf with the same description and the pictures:

===

The software package we currently use is GNURadio. This package communicates with the PlutoSDR by using the LIBIIO library (over usb). Below you will find a straight-forward block diagram to transmit and receive a single sine wave with the same device:

[BlockDiagram]

As you can see, I also implemented a numeral input variable for the local frequency (ID: carrier). When this block diagram is compiled into the corresponding python code, the following GUI is created, which allows us to change the local frequency 'on the fly':

[FFT plot]

 

In the waterfall display below, we can see the FFT plot over time where the amplitude is represented by a color. I think this is where the miscommunication happened; Whenever the local frequency is changed, the device cannot transmit or receive any samples to or from the device for ~1 second (between ~5.1 and ~5.2 seconds in the graph below). We called this a 'reboot' in our previous e-mail because the device is unresponsive for a noticable amount of time, but we probably should have called it an 'unavailability' since the device is not actually rebooting, but merely changing the local frequency attribute.

[Waterfall]

Our purpose is to have many adalm plutos communicate with each other over a set of carrier frequencies. For this to happen, each unit needs to claim an available (unused) frequency and do a frequency sweep to find other devices transmitting on other frequencies. If we need one second to switch per frequency, the sweeping process will take too long. We need to get this 'transition' time down to a few milliseconds - preferably even less - otherwise the device won't be usable for our purpose.

 

I looked through the code and found the following:

 

The python function that we get from GNURadio to change the local frequency is this:

[python def set_carrier]

 

The 'set_params' method above calls the following C function from the gr-iio library: https://github.com/analogdevicesinc/gr-iio/blob/85cf3200691ddf57f84001f0489f0a0ce4c34532/lib/pluto_sink_impl.cc#L66

 

If I follow the chain of all functions that call each other, the C function linked from the gr-iio repository above links back to this command from the libiio repository: https://github.com/analogdevicesinc/libiio/blob/560027bfa271c7c994ca5c383c9030f26a5b1d88/examples/ad9371-iiostream.c#L95

 

Assuming I observed this chain of functions correctly, does that mean that since GNURadio is directly writing the lo_fr (local frequency) attribute to the ad9371 chip using the libiio library, that there is no more optimal or faster way of doing this? Does this mean that we are stuck with the delay of 1 second to change between frequencies? Is this a limitation by the method of communicating between the petalinux mcu with the ad9371 chip inside the adalm pluto or a limitation from communicating with the device externally over usb? Is there other software we can use (than GNURadio) that allows us to do a frequency sweep at a higher speed?

===

 

Could you please help with how to getting the settling of settings for the Pluto fast?

Thanks!

Best regards,

Rob

ADALM-Plutochangingsettings.pdf
Parents
  • Just a quick edit, I meant 25us not 25ns.  But I still think that is in a range that works for you.

    -Travis

  • Hi,

       I am a newbie to the use of adalm-pluto. I am trying to frequency hop over multiple frequencies, but the frequency change takes about 500ms to execute. Searching for the reason of this issue, I stumbled upon this old post and thought this could be the reason for the time it takes the Pluto to switch TX frequency - trying to save all params instead of just the out_altvoltage1_TX_LO_frequency.

       I could not find this single paramter update (for source or sink) in the latest gr-iio code. Is this functionality not checked into the main branch?

       Thanks for all your help,

    Regards,

    -Arijit

  • Are you changing to an LO within range? What values are you using?

    -Travis

  • Hi,, 

      I am trying to switch between 1.7, 1.8, 1.9 and 2.3 GHz.

      Thanks for your help.

    Regards,

    -Arijit

  • Do you get any errors that show up? Can you read back the LO you set to see it updated to the new value?

    -Travis

  • Travis,

       I do not see any error.

       Used an iio attribute source (with update interval set to 1 ms) to spit out the TX_LO frequency and here are the observations:

       1. When the frequencies that I am changing to are within 80MHz, and my update interval in iio attribute updater is set to 10 ms, the iio source shows updates happening about every 2 seconds. This freq update speed slows down to about once in 4 seconds, if I ramp up the updater update interval to 2 ms.

       2. When the frequencies that I am changing to are wide apart (1.7, 1.8, 1.9, 2.3 GHz) and my update interval in iio attribute updater is set to 10ms, the iio source shows updates happening about every 16-20 seconds. This freq update almost stops if I ramp up the updater's update interval to 2ms. Once I set the update interval to 20ms, the updates start showing up in about 4 seconds. And once I set the update interval (for attribute updater) to 500ms, I see the updates happening in about 2 seconds.

       Is the iio attribute source not updating the freqs fast enough? You had informed that with the use of single attribute change (iio aatribute updater and iio attribute sink), the changes are expected to happen in about 25ns and not take seconds.

       Thanks for all your help.

    Regards,

    -Arijit

  • I'm a bit confused as you mentioned the LO was not updating at all... maybe that is fixed now.

    My guess what is happening is that you are generating so many write and read requests is that it's flooding the USB 2 interface. Changing the LO is a complex process for the hardware and drivers as it must recalibrate the device. If you need to frequency hop I would recommend looking at the fastlock control of AD9363. Otherwise, increase the time between updates.

    -Travis

Reply
  • I'm a bit confused as you mentioned the LO was not updating at all... maybe that is fixed now.

    My guess what is happening is that you are generating so many write and read requests is that it's flooding the USB 2 interface. Changing the LO is a complex process for the hardware and drivers as it must recalibrate the device. If you need to frequency hop I would recommend looking at the fastlock control of AD9363. Otherwise, increase the time between updates.

    -Travis

Children