I've made a basic reference design in GNURadio based on the FM Radio receiver example design. I added a QT GUI and a GUI entry to set the LO tuning frequency. When I reset the LO tuning, the QT waterfall plot and FFT plots reset to reflect the new value, but the FMCOMMS source block does not tune to the new frequency (I've confirmed this by visually inspecting the spectrum results and looking at the IIO device files). I'm fairly certain I'm doing the data conversion correctly as it tunes to the correct value on initialization. I've used the same process on an rtl-sdr design to tune it to new frequencies, so I believe the method is valid.

My question then is, can you re-tune the LO of the FMCOMMS source block mid-flow-graph execution? I have found that I can't change the gains either using the method described above. In short I'm trying to figure out if it's a known issue in the FMCOMMS block or with the way I'm trying to tune it.

Thanks for the quick response! I pulled the updates and updated my IIO blocks, but my flow graphs still can't update the FMCOMMS2 block parameters at runtime. Do you think you could put up an example flowgraph with the FMCOMM2 source that is modifiable at runtime?

Attachments

I'm afraid that did not work. I've done some debugging since I posted last, and I found that how I was attempting to tune things would work fine if I just had say a signal source going straight to a GUI without any FMCOMMS2 sink or source block in the flow. It seems, though, that as soon as I add the FMCOMMS2 sink or source, nothing becomes tunable. For example, I had a basic sine signal feeding the sink block and checked the output to FPGA fabric with chipscope. As I'd expect, the signal worked great on startup, matching the correct commanded amplitude and frequency, but when I tried changing those at run-time in my GUI, nothing happened, the signals didn't change going to the fabric. When I remove the sink block, but leave the source block, I can easily alter the signals and seem them change at run-time by tapping lines to the GUI.

I've tried this running both remotely and on localhost. The IIO device interfaces all require sudo privileges on the Zedboar itself, could that be the issue? I've been able to go in and manually reset gain values and see it change while I'm running a flow-graph, so I know it's possible at least...

To reiterate, I did follow the recommended instructions in setting up the SD card/file system/kernel/devicetree/BOOT file. I ran the update scripts, but it certainly doesn't behave exactly like the original SD cards that shipped with the FMCOMMS module. I have made alterations to the devicetree and FPGA design, but those are additions and don't touch anything that I think could affect whether or not I could change settings at run-time.

I attached the GRC file I used to test. Changing any of the parameter gives me the expected output on my scope.

We had an issue reported lately, that the programs using libiio (this include the GnuRadio blocks) would not work correctly with non-US locales. If you're using a non-US locale, try to export LC_NUMERIC=C before you execute GnuRadio.

Alternatively, you can update libiio to the latest version available in our git repository.

Attachments

I'm using it in a US locale, and I used the ADI update scripts to install libiio, which I had assumed would be the latest version.

So maybe a better question should be how you configured your SD card/FPGA image? I followed the instructions from the FMCOMMS2 wiki page, but I've always found that what I end up with from those instructions does not well match the filesystem/setup from the SD card shipped with the FMOCMMS2 board (what I take to be the ADI "good" image). For example, the stock linaro build I end up with has a completely different method for trying to update the NTP time and my versions never seem to have audio enabled. I've also noticed some issues with the newer version of the ADI IIO-Oscilloscope build that can't set the Tx attenuation levels properly.

So is there a way for me to clone the SD image you have or what might be more appealing to me, is there a different set of instructions you used to build the SD card filesystem/kernel/devicetree/FPGA build?

I ran a pull, and followed the steps listed on the wiki to just re-install the IIO blocks (is this the correct procedure to update my IIO blocks?). I reran both my own flow-graphs and the one you sent along, and I still cannot reconfigure parameters at run-time. No errors cropped up, in the case of your flow graph I just got:

Using Volk machine: neon_hardfp

For my own I got:

Using Volk machine: neon_hardfp

WARNING: High-speed mode not enabled

Buffer destroyed (after I closed it)

These were just the normal messages I would get. I found that while the flow-graphs are running, I can use a terminal to navigate into the iio device for the RFIC and just reconfigure settings while the flow graph is running. In that case I can see the changes happening, so I know it is physically possible.

So one thing is that I can't run any GNURadio design I make without root privileges, is that expected behavior?

I'm convinced the issue here is just that my file system (mostly vanilla Linaro) is different from the file system you're using/the good file system shipped by Analog Devices. So I followed all the instructions on the FMCOMMS2 wiki page to make my SD card, but again the resulting mostly Linaro system behaves differently than the file systems on the SD cards shipped by Analog Devices with the FMCOMMS2 card. I followed the following instructions to make my file system/SD card, could you/(anyone) look these over and let me know if there was a step you might have taken that I didn't:

With the exception, I needed to make my swap file 8 GB and ran all the commands remotely over SSH to prevent it from crashing.

So some key differences between what I end up with vs. the stock ADI images:

1. NTP time - the stock ADI cards come on with update NTP time right away on boot, but my version needs to be manually updated.

2. Audio - I've never gotten the stock Linaro build to come on with audio port enabled. The ADI image has audio working, and I've been able to run the iio-fmradio program to prove that.

3. Terminal styles - the Linaro build highlights file types in the terminal as one would expect form a typical ubuntu build, but the ADI stock image does not highlight files in different colors in the terminal.

If this process is correct, the only other thing I could think is that somewhere, I messed up how I was using permissions during my initial build process on that first page.

So I tried updating my kernel, I was using the 3.14.0 kernel, and I updated it by rebuilding from the head of the Linux repo on ADI's github. The new kernel is reporting version 3.17.0. Is this the correct version?

I ask because the newer version causes some serious issues with running GNURadio locally on the ARM (tries to use >250% of the processor). I did get some useful results running remotely, though. After I upgraded my laptop's IIO blocks, I now get errors when I try to tune parameters at runtime using the stock .grc you sent me:

File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/forms/forms.py", line 247, in _handle

def _handle(self, event): self[INT_KEY] = self._text_box.GetValue()

File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/pubsub.py", line 52, in __setitem__

sub(val)

File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/forms/forms.py", line 138, in _translate_internal_to_external

That did it! Sort of, so the issue was that I was exactly following the instructions from the ADI GNURadio wiki page, and there's a slight issue there. When you first install GNURadio on the ARM, you run:

which sets the iio build directory to /usr instead of /usr/local. I rebuilt my IIO blocks changing the install prefix to /usr/local and I can configure parameters at runtime as advertised. I'm not sure if that was a minor mistake in the directions or if that was intentional.