HackRF Shell Update, Explanations

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?

  • Toddlers
  • 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.

Advertisement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s