For my portable operations I picked one of Qualcomm Snapdragon powered Lenovo 5G Windows PCs. The multi-day battery life is more than impressive. After upgrade to Win11 it now runs most of the x86 apps and drivers including WSJT-X, but I suspect there is some performance to be gained from the code running natively.

Does anyone here have the toolchain setup to compile WSJT-X for Windows/ARM from source code? I think more and more hams will pick these ARM PCs for their mobile ops.

*it's still not efficient but acceptable for smaller files.

https://github.com/freerainboxbox/JS8File/tree/main

I have made a post on modifying the UV-K6 to pass baseband signals, allowing a flat response on TX and RX. This requires hardware modification to remove the low-pass and high-pass filters in the audio path. And it required that I modify the firmware to add a new digital mode which disables emphasis, sub-audio HPF, 3000Hz LPF, ALC, and mic AGC. These changes allow the UV-K6 to be used for 9600 baud GFSK and M17's 4-FSK mode. There is a link to pre-built firmware with these features enabled in the article linked below.

It is not perfect as there is an impact to Mic sensitivity after the HW change. And it seems to take some time to calibrate the TX frequency.

With this and an external device such as a Mobilinkd TNC4 or a NucleoTNC, the radio can do M17 data modes.

With the still very hacky M17-Kiss-HT app, it can also send and receive M17 digital voice. The app does audio in/out and Codec2 encoding/decoding. The TNC does baseband modulation/demodulation. The HT provides the RF component. Currently only USB connections between the phone and TNC works reliably.

http://www.mobilinkd.com/2024/06/25/hacking-the-uv-k6-for-digital-modes/

Lot of buzz about how the Quansheng UV-K5, UV-K6, UV-K5(8), and UV-5R are the most modifiable radios available..

Is there anyone working on this or any other digital mode, or specific forum I should pay attention to?

​

​

They say a little knowledge is dangerous. We know what we need but lack some php, sql knowledge to enable this. Ham radio rewards programme to take all logs adif format from people out in the field and create stats for the activator and hunter based on this. Any help for our fellow hams would be really appreciated. Happy to PM for more info.

Another great, open source hardware design by the M17 Project - a Remote Radio Unit for M17/FM repeaters. This device will greatly reduce feedline lengths required, as it is intended to be mounted close to the antenna. This solution also dramatically reduces RFI and improves RF signal's quality, as the communication between the RRU and the controller goes through an optical fiber.

Technical specs:
Nominal RF output power - 60W
Frequency range - 420..450MHz
Frequency error - <0.5 ppm over -40 to +85°C range
Supply voltage - 13.8V DC
Power consumption - ~150W at 60W RF out
Load mismatch immunity - continuous over the whole VSWR range (built in RF isolator)

rru-rf board is released under CC-BY-SA-NC license on the Project's GitHub page:
https://github.com/M17-Project/rru-rf-hw

Edit: This is WIP!

M17, the cutting-edge amateur radio project, is supported by Amateur Radio Digital Communications (ARDC) and Deutscher Amateur-Radio-Club e.V.

Remote Radio Unit - RF board, front view

About 4 years back, I had an idea for a project that would run on 9cm band (~3.3 GHz), but the FCC decided it was more valuable to be auctioned and told the part 97 people to prepare to exit usage (or something to that effect).

For various reasons, including the pandemic, the project got put back on the shelf, and nothing further was done. Now I am discovering the plethora of 2.4 GHz SoC parts and wondering if that (under part 97 rules) would be the way to resurrect this project.

The project was to make a very short range precipitation radio-location unit that has no moving parts. It would send pulses in various directions (and elevations), then use the return signal strength and delay to determine the direction of a rain cloud and how much moisture it contained. The big systems use 2.9 GHz (e.g. WSR-88D) and significant amounts of power. But they need to get an echo back from distances of way beyond 100 miles, and altitudes of up to 50K feet. I’m setting my sights on something much more mundane (3k-5k feet) in the hopes that keeping it simple may get more deployed locations. The existing WSR-88D systems are all limited by curvature of the earth … they lose roughly 1k-feet of vertical visibility for every 10-miles from the transmitter site. My QTH is about 90-120 miles from the four nearest sites. So anything below ~9K feet could be missed.

The most important question I have has to do with round-trip signal strength. Pretty much all the SoC are putting 20 dBm to the antenna terminals. For a pulse signal, and assuming I’m using a directional antenna with 10 dB forward gain, how far out can I get a detectable round-trip return ? I understand that there are many variables like path humidity, path rain/snow, and the moisture content of the cloud. There is also a difference between tropical rain and non-tropical (mostly droplet sizes).

At this point it’s an idea, with various pieces still coming together. Obviously whatever I end up with would have to ID (presumably CW) every 10 minutes to stay within regulations.

Most of the original research in this area was done between 1945 and 1960. Much of it can be found in archives of the American Meteorological Society. That research is where they determined that 2.9 GHz was the more optimal frequency. 3.3 GHz would have been 0.4 GHz on the high side, while 2.4 Ghz is 0.5 on the low side.

Any suggestions or thoughts ?

Hello All,

I want to set a time delay between two commands that I am sending through FLRig's "Send Command" Option.

Example CAT Commands : FA; FB; Successfuly Returns My Rigs : VFO-A Frequency, VFO-B Frequency

I want to do something like this : FA;<User-defined Time Delay>;FB;

Is this even possible? Any help would be appreciated.

Thanks in advance.

Hi Reddit!

This is Woj from the M17 Project. We are about to finish the design of our new handheld transceiver, a TR-9 successor, the OpenHT. I'm sure some of you still remember our first attempt that didn't really take off (due to some f-ups in the RF PA design etc. - mea culpa). Well, we didn't give up and are still in business. As the protocol is mature and sees a lot of implementations worldwide, we decided to focus on the handheld radio. In the meantime, we are also working on a new revision of the Module17 modem board, so stay tuned. We hope to have both designs ready before HAM Radio Friedrichshafen (Germany, June 23-25), where we want to showcase them.

OpenHT - Proof of Concept - an F469I-DISCO shield

The OpenHT, at least in its Proof of Concept stage, is a complete QRP SDR handheld transceiver. It's built around the STM32F469I-DISCO board. Morgan ON4MOD designed an awesome RF shield for it. Some technical details behind the design:

• duobander: 389.5 - 480, 2400 - 2483.5MHz (RX, TX frequency ranges are limited by your local laws)
• low RF power output: <14dBm (<25mW)
• complete I/Q transceiver allowing for virtually any mode (including M17 and FreeDV)
• the radio uses the AT86RF215 low-cost I/Q transceiver chip by Microchip/Atmel
• use of an FPGA (Lattice LIFCL-40) as the AT86<->STM32 interface allows to offload the MCU (FPGA does the DSP heavylifting, all the way from RF stream to baseband)
• the radio will run a port of OpenRTX on it
• hardware is TAPR licensed

Supported modes so far

• Analog: FM, AM, SSB, OOK (CW)
• Digital: M17, FreeDV, crude "4FSK", SSTV, 16QAM, BPSK/QPSK/DQPSK, OFDM, AFSK, APRS

Github repos:

• RF board design: https://github.com/M17-Project/OpenHT-hw
• FPGA VHDL code: https://github.com/M17-Project/OpenHT-fpga
• firmware for the DISCO board: https://github.com/M17-Project/OpenHT-fw-test

The project is being documented on YouTube, follow the M17 Project's channel: https://www.youtube.com/@M17Project/featured (see the OpenHT playlist).

All questions are welcome! The project will be developed further, expanding the device's capabilities. We'd like to thank Amateur Radio Digital Communications for making this - all M17-related goodies - possible!

EDIT: Our homepage is at https://m17project.orgWe have Matrix/Discord chats linked together: https://m17project.org/get-started/community

I've started something silly - porting Codec2 to a non-fpu sub-1$ microcontroller. The idea would be to minimize the number of external components by using PWM to generate audio + integrated ADC as an input. In theory, this could be a tiny 25 x 25 mm board (roughly 1 x 1 inch for the non-metric folks). Would there be any interest in actually using this or am I simply doing a fool's errand? :)

The goal is quite simple - to create a decoy which would be detected as a radio/EM source by the bad side in a currently ongoing war. The decoy would be legal in the country that this is operating. If it would run on a common frequecy used on quadcopters/drones such as 2.4 GHz then that would be even better still. The goal is to make the enemy waste their time and anti air resources while improving the safety of on the ground operatives.

The ideal device would be small, light, weatherproof and would emit a signal that is powerful enough to be picked up by sensitive EW equipment of a particular army. This may or may not be mounted on a balloon (no jokes inspired by latest events).

I was personally thinking something like a bluetooth item tag, but Im not sure if this is the right type of thing.

Do you guys have any good ideas? I have the means to buy and deliver them to the operators and I have confirmation that this would VERY likely attract fire.

I just wanted to tell my favorite ham radio developer community that we got version 1.60 out a few days ago and it is really awesome.

For those unfamiliar, wfview is free and open-source software which allows for local and remote control of Icom radios, including streaming full-duplex audio and CI-V control. wfview works with the native OEM network protocol built into modern Icom transceivers, and can also create its own compatible server for radios lacking this functionality, such as the IC-7300.

​

wfview 1.60 with the IC-7610 over LAN

We support three platforms – Linux, macOS, and Windows – as well as three audio systems (Qt Audio, RT Audio, and PortAudio). For radios, we’ve got 27 radios with a good level of support, and about 6 of these are what you might call the “core” support radios with the most features: IC-705, IC-7300, IC-7610, IC-7850, IC-R8600, and IC-9700. But we also support a lot of older rigs like the IC-718, IC-7100, IC-7200, IC-736, etc. The older rigs lack some of the more interesting commands, but it is fun to get an older rig set up for remote operation.

This latest version has an enormous amount of work that went into the audio back-end. Phil, M0VSE, re-wrote most of the audio device handling code, which should lower confusion on audio setups and of course eliminate a lot of annoying bugs (for example, issues with foreign characters in device names from some APIs).

We also added a new (and growing) page on our site for radio builders (companies, DIYers, whatever) that may be interested in running wfserver inside the radio, for a very integrated network connection to wfview. We will try and outline the process of connecting wfserver to the radio’s internals and list the core commands needed for good functionality. We call it “Built for wfview”.

Feature-wise, we’ve added a lot of features our users asked for, and some new features that nobody asked for but we found to be very nice.

New features people asked for:

• USB Controllers: That’s right, we support some hardware controllers for those of us that enjoy the feeling of real knobs and buttons. We support the Icom RC-28, Contour Shuttle Express, Contour ShuttlePRO V2, and Xbox. Once you use this feature, you will never, ever, go back. I have the ShuttlePRO V2 here and it’s very visceral experience. You can select any of the 50 or so available commands for any button. We even let you assign a different command to button release (versus press), so you can emulate a traditional hand mic or desk mic PTT if you want (PTT on when pressed, PTT off when released). The tuning is buttery smooth too, thanks to a PR from Dawid, SQ6EMM, who also helped with the RC-28 details (we don't actually have an RC-28 yet).
• CW mode: I’m not much of a CW op, but many people expressed desire to use the radio’s built-in keyer, which takes a stream of text and sends out very nice CW. I was a bit surprised people wanted this as it didn’t seem to fit the “purist” image I had of CW ops. We’ve implemented this feature, along with CW macros and even a “counter” for contests that use it. Of course, everyone immediately asked “Where’s the sidetone” and we will work on that for verison 1.7 or so. The radio does not stream the sidetone over the LAN connection (but it can over USB audio for those running their own wfview server). We will see if we can generate one locally that matches the cadence of the radio.
• Split and Custom Repeater Offsets: We added basic repeater mode long ago (plus and minus and simplex basically), but we have taken it further with version 1.60. You can now define your own repeater offset for radios that support such things (such as the IC-705 and IC-9700). For radios that have split, we have you covered. wfview can enable split mode, track the main-to-sub VFO offset as you tune, sync the modes, and also sync the tone (for CTCSS repeater access on FM). We also have a checkbox for “quick split” for radios that support it, which should handle the tracking for you. This one feature (split) looked so simple but it ended up being almost a thousand lines of code. I gained a little sympathy for the at times difficult code in hamlib that deals with VFO swapping and splits. (wfview does not use hamlib; we have our own implementation of CI-V in c++.)
• Improved rigctld support: wfview has its own rigctld-compatible server inside it, which can be used to connect programs like WSJT-X and fldigi to wfview, thus sharing radio control. We’re always chasing down the latest commands and adding support for them.

New Features that nobody asked for:

• Pass band visualization: wfview shows the receiver passband overlaid upon the spectrum, similar to some other SDR software. When you adjust the IF Width or the Pass Band Tuning, the visualization shifts to show this change. You can also use the right mouse button and drag the visualized passband to fit the spectrum of the signal being received and displayed! It’s a very, very natural adjustment and you will instantly find yourself adjusting these controls much more than before. If you prefer to adjust the knobs (sliders) instead of grabbing the passband rectangle, press “Show More” under the Receive Filter combo box to bring up the sliders for IF Width, IF Shift, and the twin Pass Band Tunable Filter controls. As usual, this was a bigger box on the inside than the outside. The Icom radios don’t actually accept continuous 8-bit values for these settings (unlike most other settings on the radio); rather, the values have to be a specific set of implemented ones. It’s further complicated because the unit conversion shifts around quite a bit. Phil spent countless hours making sure the passband was represented accurately!
• DX Cluster: You can overlay dx cluster callsigns on the waterfall view. This is a feature I didn’t think I’d use much, but now I leave it on all the time and it is fun to see what pops up.
• “Out of range” notification when the selected scope span doesn’t cover the selected frequency. This also bit us because I didn’t write it quite right initially and broke the scope for every 7300 user as well anyone else using scope over USB or forcing “chunk” mode for the spectrum data. Woops. It was an easy fix though. We may implement a feature in the future to automatically attempt to select a range that includes the current frequency (why the radio lacks this I’ll never know).

wfview is available today for download on Windows and macOS. For Debian-based linux (Debian, Ubuntu, Mint, and others), there is a build script provided that will download the required packages and compile the source code. Arch users can find the “wfview-git” project on AUR. We don’t maintain it and you may need to install some dependencies prior to using it. Various version of wfview are available in repos, such as apt and mac ports, however, the latest version is only available via source. But it’s easy to build, don’t worry!

I’d like to thank the ham radio community for their never-ending support for wfview. We would not be doing this without all your suggestions and bug reports. It’s quite a thrill to be part of what I hope is an enormous wave of open source programs and standards for what I see as “the original” open source hobby.

As always, wfview is a team effort. Our core team is Phil (M0VSE), Roeland (PA3MET), Jim (PA8E), and myself, Elliott (W6EL).

73,

--E

de W6EL

Some links for you:

• Website: https://wfview.org/
• Manual (read it! It can't hurt!): https://wfview.org/wfview-user-manual/
• Developer’s Corner (for you folks!): https://wfview.org/developers/
• Support Forum: https://forum.wfview.org/
• Source Code (of course!): https://gitlab.com/eliggett/wfview
• Patreon for behind-the-scenes development drama and more! https://www.patreon.com/wfview

There is probably something already written that will do everything I want but... I was wondering if there is any place with information on programming commands for ICOM? The project I have in mind is rather simple. Dump or load the channels with text data in a comma del format. The radios I'm playing with are rather old stuff T81A/E for one. I've tried to google a list but keep coming up empty. Yaesu CAT codes I have from an old project which was a pretty crude project from long ago but just must be looking in the wrong places or not calling them what they really are?

Hello all. I am looking to home brew a new HF amp for my 705. I have been looking at currently produced ldmos chips and ran into this one. BLP5LA55S. Has anyone played with this? Any thoughts or comments?

Ps. I am looking for around 50 watts and fairly flat gain over all HF bands.

Hello fellow devs,

I am interested in creating a Python script to interact with the APRS network by sending and receiving messages.
I have been able to authenticate and successfully read messages from the network, but I am unsure of how to properly format a message for sending and, more importantly, how to send an ACK message in response.
I came across this paper but am having difficulty understanding it.
Any guidance or assistance would be greatly appreciated!

Let's look back at some memorable moments and interesting insights from last year.

Your top 10 posts:

• "I've been working on an open source OFDM-based ham radio modem. It's meant to compete with VARA. Nowhere near ready for use, just want to show that it's something that's being worked on" by u/pongo000
• "wfview 1.5 is out!" by u/w6el
• "Sharing a small set of aprs-is command line tools" by u/rycolos
• "I created a small digital mode to send picture in python !" by u/pongo000
• "minimodem - general-purpose software audio FSK modem" by u/StoutBeerAndPolitics
• "I made a program for simple radio control on Windows. Its all over an audio interface like a signalink or digirig. Has the option to pre-record messages, generate live tts, schedule messages, and more. It's Windows only, but I need testers if anyone's willing!" by u/pongo000
• "We just had the 1000th user on DMR QRZ after going live 9 days ago" by u/brianjester
• "Reverse engineering "Morse Runner" source code and porting/rewriting it?" by u/pongo000
• "Released some code to measure the audio response of your transmitter, you can generate an audio file, transmit it, receive it, record it and compare the spectrograms between the original and the recorded audio." by u/vk6flab
• "TARPN network setup in Colorado Springs" by u/pongo000

Been browsing for an hour now and am loving what i'm seeing, great job everyone!

I need help with interfacing the FT-891 USB CAT to Arduino USB Host shield, because it has CP2105 instead of CP2103, and it presents two serial ports over the USB instead of one. I can choose the "enhanced" port in a windows or linux PC, which is connected to the CAT interface, but i didn't find them means of selecting the other port in the "USB Host Shield Library 2.0" documentation. There are some mentions of interface counts and it supports a hub for more than one device, but the device selection is unknown to me. Found some details here but no solution: https://groups.io/g/SoftwareControlledHamRadio/topic/does_anyone_have_software/27108835 Thank you for help.

Hey everyone,

Does anyone know of resources for learning about the digital signal processing involved in something like a VNA, or a frequency response analyzer? I'm curious about making a rudimentary one of my own with an FPGA, but am not sure where to begin on the DSP side of things.

Thanks!