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.

What Rev B added

Rev B is still an experimental board, but it is a large step forward from Rev A.

The hardware changed a lot. Rev B has a redesigned power system, an ATtiny-based power-management controller, USB-C battery charging through a BQ25792 charger, an integrated GRF5604 RF power amplifier, RF TX/RX switching, two PE4312 programmable RF attenuators in the receive path, a GNSS module, and a cleaner layout with improved grounding. The board is still designed to fit inside the Retevis C62 enclosure and reuse selected donor parts from the original radio.

We also registered linux-radio.eu and pointed it at the current LinHT hardware documentation. The page contains the hardware overview, generated manufacturing data, schematics, firmware links, and other project files. The hardware repository remains here: M17-Project/LinHT-hw.

Some parts of Rev B were tested before they were integrated into the main board. For the GRF5604 PA, we designed a separate development board and measured it first. The earlier PA tests are described in the first amplifier tests and part II. On the software side, gr-m17, Codec 2 blocks, GUI work, lower-CPU receive flowgraphs, and updated Yocto images continued while we were waiting for PCBs and assembly. Some of that work was described in the Codec 2 block update, the LinHT internal structure article, and the Yocto image update.

Rev B board became much more complex, with many new features and components, and it is assembled on both sides. It brought together the parts needed for a practical radio: power sequencing, charging, RF output power, receive-path control, GNSS, Linux integration, and a manufacturing process we can repeat.

Building the first Rev B boards

We originally expected to build the Rev B prototypes in China, as we did with Rev A. The prices were high, customs and import handling were cumbersome, and importing the Compulab’s SoM into China and getting the boards assembled there was quoted at a price that did not make sense for a small prototype run.

Since we already wanted future LinHT revisions, especially larger runs, to be manufactured and assembled in Europe, Rev B simply moved that plan forward. The first Rev B prototypes were assembled locally in the Czech Republic, and we plan to use the same assembly path for Rev C.

The production work itself was normal hardware development: PCB manufacturing, stencils, component sourcing, substitutions, and checks before assembly. The BOM is large enough that sourcing is not trivial. Some parts were only available from specific suppliers, some had to come from Mouser and others from LCSC, and two parts escaped our attention until late because they were already obsolete or difficult to source. Rev C has to replace them.

We ordered 10 PCBs and stencils from JLCPCB in late January. The assembled boards were ready near the end of February, and the first public post went out as LinHT boards have arrived!.

We assembled three Rev B prototypes and split them between us for development. One board died quite early. That is part of prototype work, especially with a dense board, manual handling, and unfinished firmware. The remaining boards were enough to bring up the main subsystems and find the important Rev C fixes.

Manufacturing notes from the first run

The local assembly was a success, especially considering the density of the board and the small number of units. We want to repeat that route for Rev C.

We also have several things to improve.

One SoM was visibly shifted. It did not show an obvious short, but the margin was too small for comfort. Some 0402 passives tombstoned and had to be fixed manually, especially near heavy copper and grounded areas. These are normal prototype-manufacturing issues, all fixable in the next version.

First power-up

The first power-up went better than we expected for a board this complex. In the first smoke tests we checked the basics:

• battery input produced the 3.3 V rail for the ATtiny,
• USB-C charging worked in a quick test,
• the ATtiny could be flashed,
• the ATtiny could control the 5 V and 3.3 V rails,
• the display physically fit,
• USB data from the SoM worked,
• UART from the SoM was available on the Kenwood connector,
• the board could show up as an NXP USB boot device.

The first problems also appeared immediately. The GNSS ceramic antenna was too close to the aluminium chassis and in some positions touched it. The ATtiny firmware needed fixes for the on/off switch pull-up and shutdown sequence. Flashing the SoM with uuu first failed because of a bootloader/DDR configuration issue. CompuLab, manufacturer of the SoM, helped quickly, a fixed bootloader was prepared, and full eMMC flashing became reliable.

We published the first short status in LinHT Rev B update. At that point we had power, charging, PMU control, and basic access to the SoM. That was enough to continue with proper subsystem testing.

First boot and the first real hardware bug

The first Linux boot came a few days later. Andreas got Rev B to boot after working around the USB boot logic. After that, Wojciech SP5WWP and I also got our boards running after fixing flashing and boot-mode details. The public note is here: LinHT rev B – first boot.

The first serious Rev B hardware bug was the side button / USB boot circuit.

The SoM enters USB boot mode through one GPIO that has to be held at the correct level during power-up. Our idea was to connect this function to the lower side button, so the user could hold that button while powering the radio and force the SoM into USB boot mode. At the same time, we also connected that button to the ATtiny, because the ATtiny handles power management, graceful Linux shutdown, and the correct sequencing of the 3.3 V and 5 V DC/DC converters.

The idea is still good and we want to keep it in the next revision, but Rev B implementation was wrong. The shared pins are in different voltage domains, and the ATtiny pull-up created an intermediate state that confused the SoM logic. The result was that the SoM could fall into USB boot repeatedly when it should have continued to normal boot.

The workaround for Rev B is firmware change in the ATtiny. We disabled that side-button USB-boot behavior in the ATtiny firmware and used other methods for flashing: interrupting U-Boot over the Kenwood connector and using ums 0 mmc 0, or manually driving the SoM USB_BOOT pin during development.

For Rev C, this must be fixed in hardware. The side button and USB boot path need explicit level handling and a clear owner. If the signal goes to both the ATtiny and the SoM, it needs proper buffering or level translation.

RF testing: the good news

By May, Andreas OE3ANC had enough Rev B software support in place to test the new RF hardware. This was the most important part of Rev B after first boot.

The tested RF path included:

• receive-side PE4312 attenuator control,
• RF switch control between RX and TX paths,
• GRF5604 PA enable/control,
• liblinht-ctrl support,
• a simple test UI for exercising the hardware,
• baseband forwarding from LinHT over SSH into GNU Radio on a development machine.

The setup was still a lab setup, with wires, scripts, and a radio in pieces on the bench, but the RF path worked.

In one test the PA produced about 4.5 W CW. In another M17 transmit test the measured output was around 3.5 W. Andreas was able to open the distant OE3XOR repeater from his desk using LinHT over RF. That is a major milestone. Rev A showed that the SDR architecture could work; Rev B showed that the integrated RF path can output enough power for real over-the-air tests.

The public summary from that phase is LinHT Rev B – hardware testing status. At that time we listed these parts as working:

• variable RF input attenuators,
• RF switch between TX and RX paths,
• RF PA, around 4.5 W CW in the test setup.

Audio codec: one missing reset line

The Rev B audio codec is a TLV320AIC3100. The board powered it, Linux could see the bus, but the codec still did not behave correctly until Andreas went back to the datasheet and the power-up behavior.

The codec needs a proper hardware reset after power-up. On Rev B, the reset pin is only pulled up, and the SoM cannot drive it. Andreas tested a wire workaround to a SoM GPIO, and the codec started to work as expected. Later he fixed the clock-divider table issue in the Linux driver for the 12.288 MHz MCLK used on Rev B. By June 14, playback and recording worked, and M17 RX/TX with audio worked on Rev B.

For Rev C, we have to route the codec reset line to a SoM GPIO in the correct voltage domain. We also need to decide what to do with the codec clock. The 12.288 MHz oscillator can be supported with a kernel patch, and it now works for useful rates including 48 kHz. For the next revision, we would prefer to have the codec running without board-specific hotfixes and driver patches if a simple hardware change can avoid them.

GNSS: UART works, RF does not

GNSS is the largest open Rev B hardware problem.

The GNSS module is a Quectel LG77L. After fixing the device-tree pin assignments, the digital side worked and we received NMEA data over UART. The failure is on the RF side. During an outdoor test of roughly 30 minutes, the module still had no fix and did not report usable satellites. Later antenna measurements showed the feed/antenna shifted by about 200 MHz away from the L1 frequency.

Martin OK1WPM helped me measure the GNSS antenna. We measured it both outside the enclosure and in the actual chassis, and the result pointed to the antenna/feed/mechanical design rather than software or module configuration alone. The public write-up is here: LinHT Rev B – GNSS antenna issues. The temporary experiment is to add a 0.75 pF series capacitor in the feed path. That may help us for a demo or a quick test, but Rev C needs a proper antenna fix.

For Rev C, the antenna should move to the other side of the PCB, toward the plastic part of the chassis instead of the aluminium part. We also need to revisit the keepout, feed geometry, ground reference, matching, and mechanical clearance. GNSS antennas are sensitive to their real environment, so the final fix has to be measured in the assembled radio, not only on an open PCB.

Power management, battery reporting, and shutdown

Rev B’s power system is much better than Rev A. The ATtiny PMU can sequence rails, the board can charge over USB-C through the BQ25792 charger, and the graceful shutdown concept is in place. There are still integration details to finish.

Battery voltage reporting changed between revisions. In Rev A we used a simple ADC reading from the SoM, VOL_BATT. In Rev B we removed that path and plan to read battery voltage, charger state, and related power information from the BQ25792 over I2C. That software support is not finished yet.

The RTC also needs testing and Linux support. It is not a separate external RTC, but part of the SoM. What Rev B adds is always-on power for the SoM RTC pin. The ATtiny is always powered as well, so it can react to the switch and buttons while the main SoM system is off. That keeps the off-state current low while still allowing controlled power-up. We still need to enable and test RTC support in Linux.

The shutdown path works in principle, but it needs tuning on the Linux side. When the user turns the radio on, the ATtiny enables power for the SoM and then brings up the 3.3 V rail with the small delay. When the user turns the radio off, the ATtiny sends a signal to the SoM. Linux should react by starting a normal shutdown sequence, stopping processes, closing network sessions, and protecting the filesystem. When Linux is ready, it sends a signal back to the ATtiny, and the ATtiny disconnects power. If the feedback signal does not arrive within about 30 seconds, the ATtiny cuts power anyway.

That is the behavior we want. The ATtiny firmware already generates the required signals and timing, but Linux still needs to be checked and adjusted so the full sequence is reliable.

TL;DR: what works now

As of mid-June 2026, Rev B has proven these major items:

• Linux boots on the Rev B hardware.
• The display and GUI work.
• USB networking and development access work.
• ATtiny-controlled power sequencing works well enough for bring-up.
• USB-C charging works in basic tests.
• The RF switch works.
• The programmable RF attenuators work.
• The integrated GRF5604 PA produces real output power.
• M17 over RF has been transmitted from Rev B hardware.
• GNSS UART/NMEA works.
• Internal audio playback and recording work after the reset workaround and driver changes.
• M17 RX/TX with audio works on Rev B.

That is a great result for the first complete prototype revision.

What Rev C must fix

This is the current Rev C checklist.

Hardware fixes

• Fix the side button / USB boot level-domain problem.
• Route audio codec reset to a SoM GPIO.
• Revisit the audio codec MCLK choice or carry the driver patch deliberately.
• Redesign and measure the GNSS antenna/feed/matching path.
• Move the GNSS antenna toward the plastic part of the chassis.
• Update obsolete/substituted BOM parts, especially L4 and L5.
• Review footprints, thermal reliefs, and assembly notes to reduce SoM placement and tombstoning risk.
• Validate PA thermal contact to the chassis.

Software and integration fixes

• Read battery voltage and charger status from the BQ25792 over I2C.
• Enable and test RTC support in Linux.
• Finish Linux/ATtiny shutdown handshake verification.
• Finish external mic/speaker tests, jack detection, volume handling, and default ALSA mixer state.

Validation before the next run

• Measure GNSS in the real chassis.
• Measure PA harmonics and efficiency with a clean, filtered source and known-good RF test chain.
• Test shutdown, charging, boot, flashing, and audio

Who is working on it

LinHT is still a small-team project.

Wojciech SP5WWP drives the M17 side of the project, RF/DSP direction, public updates, gr-m17/libm17 work, PA interpretation, and a lot of the technical review. Andreas OE3ANC works on Yocto, Linux integration, device tree, drivers, GUI integration, and much of the Rev B hardware testing. I, Vlastimil OK5VAS, work on the PCB design, manufacturing preparation, assembly coordination, first bring-up, ATtiny PMU work, GNSS tests, and Rev C hardware fixes.

There are more people around the project than just three of us. Martin OK1WPM helped with GNSS antenna measurement. Jacek SQ5BPF helped with SoM thermal management using silicone thermal pads and with TETRA testing. LolloDev5123 has been helping with UI work. Many others have tested, reviewed, commented, or simply asked the right questions at the right time. If we missed someone here, tell us and we will update the post.

Come talk to us in Friedrichshafen

We will be at HAM RADIO Friedrichshafen, June 26-28, 2026, at booth A1-690.

If you are there, come talk to us. We can show you Rev B hardware and the other parts we are working on. You can also ask us in person why it is taking so long.

If you cannot make it to Friedrichshafen, the best entry points are:

• project page: linux-radio.eu,
• hardware repository: M17-Project/LinHT-hw,
• firmware images and documentation linked from the project page,
• M17 Discord, channel #linht.

LinHT is still experimental hardware. With a bit of luck, Rev C will be the first version that works well enough to go beyond the core development team and into the hands of testers and enthusiasts.