Vlastimil OK5VAS has just offered a PR with his magnificent work on the Rev B – https://github.com/M17-Project/LinHT-hw/pull/39
Note: please do not order anything yet – the design is not production ready.
The design requires a review – we encourage everyone to take a look at it. The GitHub repository holds a complete KiCAD project (we love KiCAD!). The full schematic is here.
Board preview (click to enlarge):
Great job, Vlastimil!
We’ve just got LinHT to work as a complete M17 transceiver – able to transmit and receive RF signals without the need to use SSH to issue any commands. This was not as easy as we expected, due to ALSA-related problems (Linux users probably know what I mean).
The issue was GNU Radio not allowing us to use SX1255 baseband source and sink within a single flowgraph. Just to remind you – the SX1255 is seen by the OS as a sound device. I and Q baseband branches are disguised as Left and Right audio channels 🙂 Andreas OE3ANC proposed a simple workaround – daemonized ZeroMQ publisher/subscriber proxy for both directions. Then, instead of using GNU Radio’s Audio Sink/Source blocks, the baseband is accessed through ZMQ PUB/SUB blocks. PTT signal is handled as GNU Radio’s native “Message PMT”.
Right now, using LinHT for M17 is as simple as turning the device on and a PTT press. The GUI daemon loads all the RF front-end and M17 settings from a YAML file. There is still a lot of work to do, especially to improve the receiver path, as the SX1255 is really sensitive and gets saturated easily. This is why we added a variable RF attenuator in Rev B.
None of the achievements or work mentioned above would be possible without our core contributors: Andreas OE3ANC and Vlastimil OK5VAS. Working on LinHT with you is an amazing journey!
A demo video will be shared later, while LinHT’s Revision B is still being prepared, so stay tuned!
Edit: this is how our M17 transceiver looks like, defined with a GNU Radio flowgraph. Two upper signal paths define the receiver, the last one (bottom) is the transmitter. Big shout out to Jean-Michel Friedt for all the help with gr-m17 development.
This is how the Rev B board looks like (WIP). PCB designed by Vlastimil OK5VAS.
There is still some more work to do, so stay tuned. Big shout out to everyone who donated to our Foundation. Every dollar counts: your donations help us do magnificent things.
Vlastimil OK5VAS will be presenting LinHT at OpenAlt 2025 in Brno on Sunday, November 2, at noon.
Update:
Vlastimil’s talk was streamed live:
After receiving a new 10W 40dB attenuator, I decided to give the GRF5604 a spin again. I connected it to my LinHT prototype (Revision A hardware, for the record) and supplied with 5.1V. I’ve set the SX1255’s DAC gain to 0dB and mixer gain to -13.5dB, to prevent the power amplifier from saturating.
Here’s a spectrum plot showing harmonics with the fundamental at 36dBm (M17 signal at 433.475MHz):
Harmonics are below -60dBc, which I would call a good result (the output filter is a MiniCircuits LFCN-490+). The peak to the left is the PLL reference leakthrough (32MHz).
Stay tuned for more news.
We are making headlines again, this time with the LinHT – our revolutionary, open-source handheld radio running Linux. Make sure to grab CQ DL issue 11-2025 🙂
Please donate to keep our projects alive: https://www.paypal.com/donate/?hosted_button_id=4HTHZCS8UYPU6
Thank you!
Of course it does. We knew that a while ago!
While I’m trying to marry M17 text message decoder with SQLite database and Vlastimil OK5VAS is preparing a test PCB for the upcoming Revision B, Andreas OE3ANC prepared a nice fbDOOM demo. This is an important step, demonstrating the SoM’s capabilities. Stay tuned for more news regarding M17 support in our amazing device.
Extra: quick teaser – M17 message preview. This is not the final design.
Recently, Jacek SQ5BPF performed a very nice experiment. The question that we had was this: how does the SoM behave, thermal-wise, under heavy CPU loads? Is any form of cooling required?
Jacek plotted a temperature vs. time graph after logging its values for a while, using a simple bash script. It read the CPU’s thermal sensor at a fixed interval, while the machine was stressed with sysbench1:
#!/bin/bash
#just get the temp from linht --sq5bpf
while : ; do
echo -n "$SECONDS "
echo "scale=2;`cat /sys/devices/virtual/thermal/thermal_zone0/temp`/1000" | bc
sleep 1The values were used as-is (the sensor is not calibrated). CPU stress was relieved after 10 minutes. Two test setups were examined: without thermal pads and with pads applied. Thermal conductivity reported by the manufacturer is 6 W/m⋅K.
The results are shown below.
The CPU clearly runs at much lower temperatures with the pads applied. The test has been conducted at ambient temperature of about 22°C. The CPU idles at 36.5°C with pads applied, which is over 5°C cooler than the baseline.
Thank you a lot for performing this experiment!
sysbench --time=600 --threads=2 cpu run ↩︎Here’s a quick preview of a GUI based on Lollo‘s original design shared on our Discord some time ago.
GRF5604 test boards finally arrived. I tested one of them using an HP E4436B RF signal generator. The datasheet mentions gain value of 37.5dB at 460MHz and 5V supply, so I used 0dBm signal to find out if we can get anywhere close to the reference value.
Right after measuring about 34dBm of CW power, I decided to take a look at the 10W 40dB attenuator used in the test setup. It turned out that its attenuation changes dramatically (5dB or so) upon applying mechanical stress (bending) to its SMA connectors. Since the attenuator is malfunctioning, I will have to perform the test again after getting a reliable, new part.
For now, let’s focus on the amplified signals. Here’s a set of spectrum plots and eye diagrams for both M17 (4FSK) and TETRA (pi/4-DQPSK):
The “step” effect at the sides of the TETRA signal will hopefully be mitigated by applying digital predistortion at GNU Radio level. Here’s a sample 2nd order polynomial DPD block for GNU Radio. There’s a good chance that the device will be able to apply predistortion in real-time, based on the measured output signal (feedback loop). A similar approach could be possibly used for IQ imbalance and DC offset correction.