Category: LinHT

While many people already know what LinHT is, not many are aware how it works. Yes, it’s an SDR radio – but what’s inside?

The core of the device is a System on Module running carefully crafted Yocto Linux image. It offers all the Linux things, including a file system, GPIO/ADC ports, beloved ALSA, and many other higher-level goodies, such as Python3 and gcc with make/cmake. The SoM uses the NXP i.MX9352: dual-core ARM Cortex-A55, clocked at 1.7GHz. There is also a quite powerful Neural Processing Unit available, but we are going to pretend it;s not there for now 🙂

The system can run GNU Radio. Along with ssh/scp, it creates a powerful tool for amateur radio enthusiasts and RF engineers. This is definitely the best part, as the combination basically gives you a pocket computer with a full-blown SDR. It is no longer a black-box FM-only radio. This is actually a true, user-defined SDR. And it comes with a battery! Obsolescence is not an issue anymore. If a new protocol shows up in 5 years, it will most likely be possible to implement it on the LinHT. As GNU Radio blocks. It is that simple.

Let’s take a look at the internal structure of the device.

The GNU Radio flowgraph (as defined by a .grc file) can not do much on its own. The flowgraph has to be translated into Python code first. This is what the GR built-in grcc compiler does. So: after the flowgraph is prepared, it can be turned into an executable Python file (.py). The python code can be spawned by the Interface Daemon.

What the hell is that daemon for? Well – as a user, you need a way to tell the radio what to do. It is also good to know what the radio is actually doing, and if it’s aligned with the user’s intentions 🙂 You can not just turn the radio on (by turning the volume knob) and expect the OS to know what you want. This is what the daemon handles – your intent (by reading the keypad, PTT, etc.). It also uses the display to tell you want the radio is up to. But its function is not limited to that – it also controls the SX1255 RF front end chip and selects which flowgraph to run. It pre-configures the front end based on whatever settings are in the YML configuration file.

The daemon also communicates with the flowgraph and ALSA. The flowgraph is a mere state machine – it needs to know what to do and when (state transitions). Which mode are we using? Are we transmitting? Are we receiving? Has an M17 packet with a text message arrived? Or are we going to reply to it? The daemon tells the flowgraph what and when to do it. The flowgraph can not just simply stay free-running all the time.

Linux makes things easy here – the daemon works as a system service.

Now the ZeroMQ Proxy. Since ALSA can be a pain in the rear to configure and work with, we decided to put a very simple additional layer between the SX1255 (again – disguised as ALSA sound device) and the GNU Radio flowgraph. There is a simple C code doing the proxy work: bi-directional ALSA-ZMQ bridge for baseband samples. Now, instead of using Audio Source/Sink blocks to access baseband (that did not work) we can now do the same task with ZMQ PUB/SUB Sink/Sources, connected to a pair of IPC sockets using very little CPU resources. Clever, right?

The flowgraph can notify the daemon that it received something – this can be anything – in our case it’s an M17 packet reception. The flowgraph uses ZeroMQ with an IPC socket (again) to announce RF events. This path is used for non-audio streams (data). Audio streams are routed directly to ALSA through an Audio Sink.

Microphone signal is handled by ALSA as well. It is sampled by the flowgraph directly.

PTT signal handler is simple as well – we use the daemon here again. In an infinite loop, we read the keypad state (and the PTT). PTT press and release events trigger a ZeroMQ message transmission from the daemon to the flowgraph. The state machine in the flowgraph (M17 Coder/Decoder blocks have appropriate handlers built-in) reacts to the message and either starts reception or transmission. SX1255 (and the rest of the RF front end) is configured in the same way – by the daemon, upon user input.

I hope this article is understandable and clarifies how LinHT works under the hood. It is not very detailed, as I did not want it to be too long. I just wanted to cover the core idea.

Have fun experimenting!