What is the (current) goal of the HackRF Shell project?
I aim to provide a free software program which sets up a Guile Scheme shell, allowing lisp-style control of the HackRF Software Defined Radio (SDR). The shell will provide procedures for (1) controlling the HackRF, including pulling from and pushing data to the radio, (2) Digital Signal Processing (DSP) e.g., frequency modulation, and (3) some i/o interfaces, specifically to the file system and to PulseAudio.
Why does this project exist?
Partly to help me learn about SDR and DSP. Also, I want to be able to code applications for HackRF SDR in Scheme, rather than in Python (Gnu Radio).
Wouldn’t it be better to use Guile FFI than embedding Guile in a C program?
Erm, well, maybe. But the embedded approach seems easy to understand, develop, and troubleshoot.
Shouldn’t you make something modular to work with any SDR?
I wanted to focus on getting somewhere practical with the SDR I have and the code I already wrote. But I believe it would be possible to expand the shell by adding or swapping in osmocom bindings instead of just the libhackrf bindings.
What have you done so far?
- Created the C program with libhackrf bindings
- Set up autotools files for development
- Created Guix package definitions for HackRF Shell as well as the hackrf and liquid-dsp libraries.
What are you working on now?
Adding liquid-dsp bindings.
Where is the code?
git clone git://git.librehacker.com/pub/git/hackrf-rkt.git
Why has it taken you so long to make progress on this project?
- Moving to a new apartment.
- A job with no PTO.
What makes Guix such an awesome development environment?
Once you’ve made package definitions, which isn’t very hard, you can set up your development environment (exposed packages and environment variables) quite easily. Right now, for HackRF I simple
cd into my source code and run
guix environment hackrfshell --ad-hoc liquid-dsp
The I run ./configure, make, etc. In the next iteration of the hackrfshell package definition, I will add liquid-dsp as a dependency, so then it would just be
guix environment hackrfshell.
Not all my package definitions have made it into the official Guix git repository yet, but I’ve added them to my local Guix channel for the same effect.
Also because of Guix’s functional package management approach, I can use any verions of libhackrf, etc. I want, and not have to worry about wrestling with base system dependencies.