Post Go back to editing

ADALM-Pluto: How to change settings with quick settling


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:


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.


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:


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:


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?


Best regards,


  • The larger time comes from the fact that the set_param method updates 10+ parameters on the radio even if only 1 is changed.

    You could try adding a method to the class that only updates a single parameter per call.  I added an example to the source blocks that does this here: GitHub - analogdevicesinc/gr-iio at single-param 

    This would allow you to do a LO change like:

    pluto = iio.pluto_source('', 2400000000, 2084000, 20000000, 0x8000, True, True, True, "manual", 64.0, '', True)


    In terms of LO changes you can get the part down to ~25ns if required.


  • Thanks a lot Travis! Customer is greatly helped with your feedback and the new example.

    Best regards,


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


  • EDIT: Not to worry, I've worked it out now!


    Hi Rob,

    I appreciate it's been quite some time since you had this discussion, but I was wondering if the solution worked for you?



  • 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,



  • This functionality has been replaced by the attribute sink block. That allows you to update one attribute at a time.


  • Travis,

       Thanks a ton for the quick response. I am able to run the attr_sink.grc from the iio_examples directoy of gr-iio code base. However, when I try to update the TX_LO_frequency by setting the following:

    Attribute Type: Channel

    Input/Output: Output

    Channel Name: altvoltage1

    Attribute Name (from attribute updater): to any of "frequency"/"lo_frequency"/"LO_frequency"/"TX_LO_frequency"

    the update to the attribute fails with:

    Attribute write '<value>' failed to ad9361-phy:altvoltage1:TX_LO_frequency

    My belief is I am using the wrong attribute name - but I am not sure.

    Will be of huge help if you could shed some light on my mistake, so, I can correct the same.

    Thanks and regards,


  • My mistake. I had not tried all the combinations of the channel name and the frequency value. Using altvoltage1 and frequency as the combination worked for me. Now, I do not see any error being spit back. Thanks a ton for all your help.



  • While quick change of frequencies in close vicinity seems to work, if I try to switch frequencies that are wide apart, the change does not seem to take effect. Any pointers on what I am doing wrong? Thanks a ton for all your help.



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