LabCat (Tobias DL3MHT) uploaded his interview with the LinHT development team: Wojciech SP5WWP, Vlastimil OK5VAS, and Andreas OE3ANC. Check it out 🙂
Category: LinHT
-
LinHT Rev B status: what works, what broke, and why Rev C is next
Before Friedrichshafen, we want to put the current LinHT development status in one place. We have published many short updates over the last months, and the project moved through several phases: Rev A proof-of-concept testing, Rev B design, manufacturing, first boot, RF tests, audio bring-up, GNSS debugging, and now Rev C planning.
This post summarizes that progress. It starts with what Rev A proved, then goes through what we changed in Rev B, how we built the first boards, what worked during testing, what failed, and what we need to fix before Rev C.
If you want the longer background, start with my older text about the first LinHT prototype: LinHT – Open SDR Handheld for Radio Amateurs. That article describes the Rev A board, the Retevis C62 donor-radio approach, and the basic idea behind LinHT: a Linux-based SDR handheld transceiver, open enough that the radio can be changed in software, not only programmed from a vendor tool.
Rev A was our proof of concept. It showed that the architecture made sense and that the device could work the way we imagined. An i.MX93 system-on-module could boot Linux inside a handheld radio body, run a Yocto image, expose USB networking, talk to the display, run GNU Radio flowgraphs, and use the SX1255 IQ RF front end. We decoded M17, tested TETRA receive, displayed spectrum data on the small screen, and ran enough hardware and software tests to be sure that the concept was valid.
Rev B is the revision where we tried to turn that proof of concept into a much more complete handheld.
(more…) -
LinHT Rev B – GNSS antenna issues
Vlastimil OK5VAS recently tested the GNSS module. Unfortunately, the module used (Quectel LG77L) does not obtain a fix, even when enabled for 30 minutes, outdoors.
The most suspicious part, and likely culprit, is the path between the antenna and the module:
GNSS module (lower left-hand side, 7x7mm rectangle with pads) and the antenna (top, center) with a copper keep-out zone. When measured, S11 (from the GNSS module’s perspective) looks like this:
S11 plots for setups with cover (chassis) removed and held in place. Note the approx. 200 MHz difference between L1 frequency and where the dip actually is. Many thanks to Martin OK1WPM, who helped measure the antenna path both with the cover removed and with the chassis held in place.
A quick ad hoc fix before Friedrichshafen ham fair is to place an additional capacitor along the coplanar waveguide:
Proposed fix using a 0.75pF series capacitor. Some more experimentation is required. Keep your fingers crossed! See you in Germany!
-
LinHT Rev B – hardware testing status
It took us some time, but here’s a quick update on where we’re at with the LinHT Rev B hardware tests:
What‘s working?
- Variable RF input attenuators
- RF switch – switching between TX/RX paths
- RF PA (Power Amplifier) – functional, delivering about 4.5 watts (CW)
- GNSS connection – UART interface (NMEA)
Still requires testing
- GNSS receiver’s antenna path
- PMU (Power Management Unit) – battery voltage measurements
Known problems
- Audio codec IC – reset and I²C communication issues needing a bit of investigation
- The button below PTT not triggering USB boot sequence correctly
-
LinHT Rev B update
We finally have the first fully assembled LinHT Rev B PCB.
The board powers up correctly, the ATTiny power-management firmware is working, and the PMU logic now controls the startup/shutdown sequence as intended.
USB-C charging is also working as expected, and the whole device can be powered on with the rotary ON/OFF switch.
We also confirmed debug UART from the SoM is available on the Kenwood connector and works with common Baofeng-style USB serial adapters.
There is still a lot of work ahead: update the Linux device tree for the new Rev B pinout, validate all new peripherals, and fully test GNSS, the RF power amplifier stage, and the rest of the hardware.
Stay tuned.
-
LinHT boards have arrived!
Today, we have received a set of three Rev B boards. They will be tested in the coming days. Stay tuned!
What’s new in Rev B:
– redesigned power supply
– internal RF power amplifier (~5W at 435MHz, CW)
– improved RF receiver path (added variable attenuation)
– GNSS receiver
– battery charging through USB-C
– cleaner layout and grounding
Photo courtesy of Vlastimil, OK5VAS.
-
LinHT – Yocto image update
News from Andreas OE3ANC:
I just uploaded a new image for Rev A
- Latest versions of LinHT repos
- Removed gr-bokeh (this removes nodejs dependencies which makes build faster)
- Updated raylib (new lic hash)
- Changed default sample rate to 125k
- Creating /var/lib/linht folder for gui_test sqlite
The new image can be downloaded here: https://m17project.org/linht/experimental/
Flashing instructions: https://wiki.m17foundation.org/index.php?title=LinHT
This is how the display looks like now:
LinHT Rev A running gui_test in M17 mode. Rev B is still in the works. Stay tuned for more updates.
-
LinHT + CC1200 HAT combo
More photos (and maybe even videos) soon!
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. -
LinHT – its internal structure and a quick explanation on how it all works
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 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!
