Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
2 contributors

Users who have contributed to this file

@jmfriedt @trabucayre
88 lines (66 sloc) 5.46 KB

PlutoSDR

BR2_EXTERNAL framework for Analog Device's PlutoSDR Zynq

This repository provides buildroot based support for ADALM-pluto board (based on Analog Device's plutosdr-fw).

At the moment, this repository provides support for rootfs, linux and bootloader.

It uses the BR2_EXTERNAL mechanism to add this support to buildroot.

This support has been tested with the latest stable release of buildroot (2018.11.1) and git master branch.

How-to use it

With PlutoSDR tag v2019.02

Download the tested buildroot tarball:

wget https://buildroot.org/downloads/buildroot-2019.02.tar.gz

Configure, build and install

Adding support for the PlutoSDR requires sourcing the sourceme.ggm file to add the BR2_EXTERNAL variable definition (alternatively, one might want to add export BR2_EXTERNAL=/somewhere/PlutoSDR to the .bashrc initialization file).

In the buildroot directory

make zynq_pluto_defconfig

will configure buildroot for minimal PlutoSDR support. More ambitious, after git cloning the latest release of buildroot,

make zynq_pluto_gnuradio_defconfig

will configure buildroot for PlutoSDR support in addition to GNURadio. The default configuration is to not support Python, yielding a 13.4 MB image. Activating Python requires going to Target Packages --> Interpreter languages --> python and then Miscellaneous --> gnuradio --> python support. We also activate gr-zeromq support to stream I/Q coefficients from the PlutoSDR to the PC. Do not attempt adding Python support after compiling an image without Python support: the gnuradio packages would not be compiled properly. Start from scratch from a clean output directory (rm -rf output). For the resulting image to be smaller than 32 MB, we remove wpa_supplicant and associated 802.11 packages as well as avahi.

Overall, make menuconfig allows for configuring additional settings of the buildroot environment, especially Target Packages, make builds the images to be found at the end of the compilation in output/images.

The output/images/pluto.frm file is then copied to the mass storage mounted from the PlutoSDR (in most cases /dev/sdb1) and then written after ejecting the associated mass storage root (in this example sudo eject /dev/sdb) as explained at Analog Device's PlutoSDR firmware information

In case of failure, DFU programming provides a backup solution. MAKE SURE TO POWER THE DIO PIN OF THE FTDI INTERFACE WITH 1.8V and NOT the default 3.3 or 5V (that will definitely destroy the Zynq)

PlutoSDR picture

Doing so does not necessarily require the FTDI USB to R232 converter, although this peripheral will provide a prompt to check what is happening on the PlutoSDR. Switching to DFU mode is achieved by mounting the first mass storage partition (let's say /dev/sdb1), modifying config.txt to set dfu = 1, and saving the change + rebooting the board with sudo eject /dev/sdb. Once the board is in DFU mode, the DFU image is flashed with dfu-util -D /tmp/pluto.dfu -a firmware.dfu.

GNU Radio on the PlutoSDR

Listening to an FM station demodulated by the WBFM block running on the Zynq PS requires activating the second CPU core, extending the AD9363 carrier frequency band to those of the AD9364, and compiling fftw with speed optimization. With such considerations, the following processing block runs on the PS of the Zynq to fetch samples from the AD9363 (local IIO connection), filter and demodulate the signal, and push to a 0MQ stream the sound signal at 24 or 48 kS/s. On the 0MQ receiver side, the following processing block is run on the PC to fetch data through a 0MQ socket and play sound on the PC speaker.

Here is a movie demonstrating the acquisition of a FM station in the commercial broadcast band, processing using the WBFM block running on the Zynq, streaming the data to the PC (at 24 kS/s rather than the >200 kS/s needed to demodulate FM) and using the PC as a sound card.

Activating hard-floating point processing is mandatory to achieve continuous FM demodulated sound stream: indeed, lacking the ~40% processing gain would result in discontinuous sound output due to insufficient computational power to run the WBFM block on the minimum 200-kS/s input stream.

Custom bitstream on the PL

Customizing the PL bitstream meets some requirement for full control of the PlutoSDR features: in this example, an ALSA-compatible audio output is added to make the PlutoSDR a fully autonomous FM-broadcast radio receiver. Adding such functionalities requires generating a new bitstream including the additional block, generating a new DFU image to send to the PlutoSDR, and telling GNU/Linux about the new reconfigurable hardware (devicetree entry). The documentation aims at describing all these steps.

You can’t perform that action at this time.