LinHT picking up M17 signal from a CC1200 hotspot.Close-up on the display. For direct M17 RF links, only one (upper) line is displayed, for Internet traffic over RF (hotspots transmitting ECD) two lines are shown.
By the way – we have some news from Vlastimil, OK5VAS.
PCBs (and stencils) are in Czech Republic, ready for assembly! Photo courtesy of Vlastimil Slinták, OK5VAS.
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.
LinHT’s simplified block diagram (Rev A)
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 grcccompiler 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.
After a long and painful process, gr-m17 now contains Codec2-mod blocks. The difference between those and the “stock” Codec2 encoder/decoder blocks is that ours are much faster and support internal state reset. They have been designed specifically for the LinHT. This is very important when you run a flowgraph and expect repeated streams (each received transmission – internal state reset, same with PTT key press event for transmission).
This is how M17 radio looks like, as defined with GNU Radio blocks. Easy peasy!
Andreas OE3ANC – thanks for helping me out with this.
Today, I decided to stress-test my LinHT Rev A prototype. The aim was to assess the battery life in the following conditions: minimal transmission time – mostly reception. I used a CC1200 hotspot connected to M17-KCW A as a solid M17 RF source (with stable traffic). The handheld’s backlight (including keypad) was kept on for the whole test duration. Stock Retevis C62 2S Li-ion battery was used, fully charged on the previous day (in the evening). A modified charger was used – I replaced the 0.47ohm resistor with a 0.33ohm one* (a stack of three 1ohm resistors) for increased charge current. Silicon thermal pads were used to allow the SoC to dissipate heat through the aluminum part of the chassis (see this entry for details).
I started the test by switching the volume knob at 9:17 LT. The starting battery voltage was 8.05V.
CPU slightly below 41 deg. C after 10 hours of continuous DSP work? I think this is a very good result. This would definitely not be possible without some DSP tweaks we introduced in the M17 GNU Radio flowgraph. I had to quickly reset the flowgraph in the first 30 minutes due to an unexpected segfault 🙂 The cause is yet to be found.
Last but not least – big shout out to the rest of our team – Andreas OE3ANC and Vlastimil OK5VAS, and every financial contributor out there. Let’s keep this up 🙂
*the values are taken off the top of my head – I believe they are correct. The idea is to slightly reduce the resistance to increase the current.
The Common Amateur Radio Interface (CARI) protocol has been updated with important clarifications and formal refinements. The update removed ambiguities in device selection, command framing, and supervision telemetry data transfer. The control and supervision planes are now explicitly defined. No functional changes were introduced, the update improves clarity only, therefore the protocol’s version number has not been incremented.
FOSM-1 is designed by an non-profit organisation Fédération Open Space Makers. This is a hamradio spacestation payload that should flight starting Q2. It has received IARU coordination.
