Building an Amplifier Test Set with Analog Discovery 2 and Raspberry Pi 4 Part 4: Final Touches and TestingFollow article
How do you feel about this article? Help us to provide better content for you.
Thank you! Your feedback has been received.
There was a problem submitting your feedback, please try again later.
What do you think of this article?
Software to control the amplifier test set and some example test results.
In part three of this series, we took a look into the hardware construction of the amplifier test set. In this post, we’ll be looking at making all the controls work under Linux on the Raspberry Pi, and revisiting the SDK previously covered, then using it to produce a sample test case and graphs of an amplifier’s performance.
Setting up Linux
As the front panel of the test set features a rotary encoder, this means that there are two input devices which need to be handled by the Raspberry Pi — the encoder itself, and then the button on the shaft of the encoder.
The easiest way to achieve this is using the Linux “devicetree” which is a way of describing the hardware connected to a computer in a structured way. The device tree requires overlays, which are files that contain hardware descriptions. For our use case, the default Debian image built for the Raspberry Pi contains device tree overlays that are suitable for interfacing with the rotary encoder and the push button.
To enable the rotary encoder overlay, one line needs to be added to
/boot/config.txt. This instructs the bootloader to load the compiled overlay which is then picked up by the kernel, and the correct hardware driver loaded.
In particular, the rotary encoder overlay needs at minimum a definition for the “A” and “B” pins of the rotary encoder. Additionally, we configured the axis which it will control under Linux by specifying the additional
Just as with the rotary encoder, an overlay is included that allows GPIO pins to be connected with a key press in Linux. This requires the GPIO pin to be set, and then a key to be mapped to — a list of which is found in the Linux source here.
With both overlays configured, the Pi was rebooted to apply the overlays, then we could test the inputs using “evtest”.
Both input devices are visible, and can be tested to ensure they are reporting events correctly.
The same was then done for the DS18B20 temperature sensors, using the provided
w1-gpio overlay. Alternatively, this can be turned on from “raspi-config” on the command line, or using the GUI based “Raspberry Pi Configuration” utility.
Both temperature sensors then show up under
/sys/bus/w1/devices/, and can easily be read by reading the appropriate “temperature” file under the device folder. This returns a temperature value in millicelsius, so a simple division by one thousand is appropriate to get temperature in celsius.
With all the devices now configured in Linux, we moved on to writing the test software. As we are using a fresh install of Raspbian we needed to set up all the necessary components to be able to interface with the Analog Discovery.
Installing WaveForms is easy enough, only requiring downloading two .deb packages from the Digilent website and then installing using the command
sudo dpkg -i with the package name. WaveForms itself initially failed to install due to missing dependencies, but this is easily fixed with
sudo apt -f install.
With WaveForms successfully installed, we ran the application to ensure that all our hardware was detected and working as expected. This consisted of generating a sine wave using the “Wavegen” tool and then observing it using the “Scope” tool.
WaveForms also has a lot of useful built-in features, such as the ability to perform an FFT on an observed oscilloscope waveform. In the above screenshot, an amplifier turned up to full is being driven with a sine wave, and as the amplifier is clipping peaks at the harmonics of the sine wave can be seen.
As the hardware worked as expected, we moved on to looking at the Python examples provided by Digilent, and then looking at how an example could be modified to implement further functionality.
Running one of the Python examples showed that some dependencies were missing, including “matplotlib”, “numpy” and a handful of others. Matplotlib was installed with
pip3 install matplotlib — note the use of “pip3” as Python2 is now deprecated, and thus should not be used. With the matplotlib dependency satisfied, Numpy has to be upgraded to the latest version with
pip3 install -U numpy, and then further dependencies for matplotlib installed with
sudo apt install python3-gi-cairo, which provides bindings for Cairo.
With all dependencies now satisfied, we ran the “AnalogOut_Sweep.py” example which generates a swept tone and graphs both of the channels. As can be seen, this produces a graph with two traces, one of either input channel.
To build upon this, we combined this example with the “AnalogOut_Sine.py” example which produces a fixed frequency sine wave and then included the FFT function from Scipy. This gives a graph that shows the energy distribution in the measured input. The ability to use Python to control the instrument significantly lowers the barrier to entry for building custom test setups, as Python includes lots of libraries such as Scipy that can take care of complex mathematics — in this case generating an FFT.
This example merely dipped our toes into the applications that are possible, and could be built upon to have the plot use frequencies rather than samples. Another worthwhile improvement would be to express the readings in decibels or another suitable measurement unit. The example could also be expanded to generate multiple tones to see if distortion (and thus harmonics) are generated at certain frequencies.
This project demonstrates the versatility of the Digilent Analog Discovery test instrument, and how it can be used as a flexible analysis tool, with the ability to write custom code to control the instrument.
Other parts in this series include: