Behind the scenes in building a SIGINT Linux distro

Introduction

Back in October 2021 I was interested in building a SIGINT platform. I logged my journey and published an article on HVDN at that time. Little did I know that journey would have led me to build and maintain a SIGINT build tool for Linux called SIGpi for the past two years with 28 releases during that time.

Inspiration

As the saying goes, "Necessity and is Mother of invention." It started with Steve K2GOG wanting to run the latest release of SDRangel on the Raspberry Pi. SDRangel is an awesome Open Source SDR and signal analyzer tool written by Edoaurd Griffiths F4EXB. If your a long time fan of the HVDN notebook, you already know Steve is a huge fan of SDRangel.

Often your Linux distribution of choice may not have the latest version of your favorite software whether available as a distro package, Snap, or Flatpak. In fact it could be many versions behind. Some authors will have package releases on their GitHub sites ready to download and install. If not and if its open source, you will be able to download the source could from their GitHub repo source and compile yourself. While authors may provide compiling instructions, you will find yourself down the rabbit hole addressing all the dependencies the software has first - libraries, drivers, specific versions, etc. The advantage in using packages that came with distros is the package manager will take care of auto-installing dependencies and their correct versions.

Fortunately SDRangel is well-documented providing detailed compile instructions. Once I mastered that I canned the instructions into a Bash script. and shared that with Steve. After getting rid of some bugs with my script we achieved success

Crawl

Compiling code and writing shell scripts was something I had done in the past but not to the degree of calling myself a developer. But working with SDRangel inspired me to expand on that Bash script and create a script that would install a series of drivers, libraries, and applications to create a SIGINT platform for my needs and anyone who had similar one - SIGpi 1.0 was born.

SIGpi 1.0 was really just one big bash script named SIGpi_installer.sh. SIGpi 1.0 installed drivers for RTL-SDR, HackRF, and PlutoSDR SDR devices and the Soapy SDR platform which provides a vendor-neutral API for SDR applications. With my compiling and scripting skills leveling up, I could confidently choose whatever latest SDR application I wanted for SIGpi and compile and package myself as long as it was open source and the source code available. But the cost of using the latest software versions is it could take up to four hours for SIGpi to install on a Raspberry Pi.  For Amateur Radio related applications I stayed with the releases available from the distro since little changes with them.

Walk

Less than thirty days later I released SIGpi 2.0. Besides support for LimeSDR and additional applications, it introduced a text-based menu system allowing you to pick and choose what applications and SDR drivers you want installed. The menu uses Whiptail - a dialog box tool for shell scripts which is included in most if not all Linux distros. It is used by raspi-config.

Adding applications requires ensuring their dependencies are installed as well. Since many applications have same dependencies, I broke SIGpi install into stages where the dependencies for all applications would be installed before installation of the applications themselves. The stages were:

• Run OS update
• Setup directories and desktop menu skeleton
  
• Install devices
• Install dependencies
• Install Libraries
• Install Applications
• Install Desktop Menu
• Reboot system
  

The staging model continues to this day but evolved from functions within a single install script to nested scripts called by the install script starting with SIGpi 3.0.

Run

To end users, the evolution of SIGpi from 3.0 to 4.1 varied in the applications supported. But much of the development was focused on the underlying architecture of the SIGpi build to facilitate ease of updates. First step was to simplify the development process in producing releases. The second step was to extend that so end users can perform application updates themselves through a simply command line process.

For SIGpi 5.0 I created a package management system akin to APT as used by Debian and Ubuntu. SIGpi management differs in that it is source neutral. Source could be a distro package, local package, Snap, FlatPak, or download/compile/install from source code.This started with maturing application specific nested scripts used by the SIGpi_installer into "SIGpi Package Scripts." The package scripts would be used by SIGpi_installer and a new command-line script called SIGpi - a front end to the package scripts.

Usage: sigpi [ACTION] [TARGET]
          ACTION  
                 install   install TARGET from current release
                 remove    remove installed TARGET
                 purge     remove installed TARGET and purge configs
                 update    check to see if new TARGET available
                 upgrade   upgrade TARGET to latest release

          TARGET
                 A SIGpi package

The update command checks the SIGpi repo if there is a new release. If the response is "update is available" then you can run the upgrade command and the target will be updated to the new release.

SIGpi update sdrangel

Update is available 

SIGpi upgrade sdrangel 

Fly

Compiling applications like SDRangel and GNUradio on the Raspberry Pi contributes to more than half of the install time for SIGpi. Time is the price you pay to run the latest versions. To improve the install time I realized I needed to uplevel my skills again with the ability to create Debian packages. After some research I discovered the checkinstall tool as a simple way for creating Debian packages from compiled source. For SIGpi 6.0 I created a number of Debian packages starting with GNUradio and SDRangel that could be download and installed as part of the SIGpi installation process. I had now significantly reducing the install time to just over an hour.

I updated SIGpi package management with hidden developer options to build Debian packages of supported applications.

Usage: sigpi [ACTION] [TARGET]

          ACTION  
                 build     compile and install TARGET from current release
                 package   compile and create Debian package only

          TARGET
                 A SIGpi package

SIGpi 6.0 also saw the deprecation of 32bit for 64 bit.

Idling

SIGpi started with support only on Raspbian OS (32bit) for the Raspberry Pi 4. When 32bit support was deprecated, SIGpi not only migrated to Raspberry Pi OS (64bit) but expanded to include Ubuntu on x86-64/AMD64 architecture. The change was not only in response to the RPi hardware "famine" that was out there, but RPI pricing was reaching the point for serious consideration of low-end Mini PCs. While we test for those platforms, know SIGpi should be able to run on most Debian-based AMD64 and ARM64 systems.

Throughout the journey I kept considering whether SIGpi should continue as the build kit it is or be a full distro where you download and install a full OS image like DragonOS or DigiPi. What I kept coming back to is releasing a distro image may be easier for me to support and develop but it would be at the expense of limiting end-user experimentation integrating SIGpi into their own creations.

Another consideration has been whether to start using Docker and create docker images for complex SDR applications like SDRangel. Again what may be easier for the developer would be at the expense of experimentation by end-users. Docker adds overhead that the end-user would need to be familiar with.

Land

Many open source projects come and go for a variety of reasons. The best reason for closing a project is when similar projects merge and leverage the best of each. But often a project owner loses interest or support and refers people to other open source projects.

It makes me happy to see all the stars and forks the SIGpi project has received to date. It keeps me thinking on what more I can do with the project that delivers the most value in ease of experimentation for SDR while minimizing efforts for end-users in building a platform that supports it. This is the goal as I begin development for SIGpi 7.0

Areas of improvement considered include:

• A better TUI menu system for installation and SIGpi package management.
• Documentation on the SIGpi package management system for end-users to add applications requiring compilation for using latest versions
• Continuous development/release rather than point release model
  
• Hardware Certification metrics for SIGpi
  

I hope this article serves as an inspiration for your own projects and helps with decision points in your own journey.

73,

Joe, NE2Z