2025-10-10 — Why Manufacturers May Be Reluctant About VHF / UHF / Microwave SDR “Real Radios”, VARA FM Via FM (Analog) Repeater, Help Track Our Light Sail!, Jesse Alexander WB2IFS GRCon 2025 Keynote
One thing I forgot to mention in my email is an earlier action that didn't involve Part 97 but did have an interesting statement from Commissioner Carr:
He says that soon they'll move to "more substantiative whacks at the FCC rulebook". I think these will take the form of NPRMs rather than direct final rules and in fact one has already come out regarding Internet labeling regulations that is generating some new comments. Some things to realize here:
1. They are very obviously only doing deletions. I felt this was clear from the jump, but that didn't stop people from requesting all sorts of massive new regulations. With that in mind:
2. It might be worthwhile to comment again emphasizing the changes for Part 97 that can be accomplished with only deletions (symbol rate, 219, etc).
The takeaway is they are tracking (to the word level) how many regs they delete so adding to the pile of removals will get consideration.
Justin - That's an astute observation. It might be worth doing another comment to FCC with that very narrow focus - yes, JUST delete the troublesome parts.
Regarding VARA, I would like to try it but I cannot stomach the use of windows for such an application, I wish he would do a Linux version so we can run it on RPi's and other small platforms that do not demand the babysitting of Windows. Also now with MS imposing even more demands on using Windows it gets even more toxic to use.
William - "Windows" is a frequent plaint about VARA... but requests to port it to other platforms fall on deaf ears. That the author gets ample "business" from VARA running only on Windows probably doesn't motivate the author to consider other platforms. The easiest method I've heard to manage "the Windows issue" is to buy a small, inexpensive Windows box, update it once, unplug it from the Internet, and use it like a VARA / VarAC appliance.
Ahh, but I read on down ZR and found something called HUSH!! Maybe this is the solution. I just cannot leave a windows box unattended, even off network. It gets in trouble by it's self. I figured sooner or later someone would continue to push from the OpenSource side of the house, and looks like they are. I do not mind paying I just do not like the platform they run it on.
William - I hear you, and I've had similar bad experiences about unattended Windows boxes. But, some folks I trust, tell me that such fears are overblown and that there are (many) ways to "harden" (we called such techniques "robustifying" in a previous job) Windows. I haven't yet investigated such techniques for "real Windows". If you want to use VARA FM, but cannot bring yourself to trust "real" Windows, I've seen a number of references (which I cannot point to at the moment - will run all those down in an eventual chapter in my forthcoming book) to building "appliance" images of stripped down Linux + WINE to run VARA FM without the vulnerabilities of "real" Windows.
Steve (by the way most folks call me Chuck) I used to work in the glass container industry. The inspection machines (there were 3) used windows as the machine UI. The under the hood devices were PLC's and Linux based on all but the rotational inspector. That one the UI was also an ADC using some National Semiconductor board that was Windows only. We tried every which way to make those machines bullet proof, pulling all of the junk out of the windows installs, we had a whole department that was dedicated to keeping windows slim and as reliable as possible, but even then it would still go off in the weeds. The sidewall and sealing surface/base inspectors did not care as the windows machine was UI only, BUT the rotational inspector did and it was a nightmare. Then after getting a virus on machines in Spain and Portugal (same company all of the plant back ends were linked) while I was in Spain working in one of the plants. The virus just about drove us nuts. We would clear it out of the machines and it would come back. The virus was something called Conficker see https://en.wikipedia.org/wiki/Conficker
We contacted MS about it several times (no response) as it was riding in on Netbios packets, we were sent a cease and desist telegram from MS, great way to treat a customer. In the end the quick solution was to take the inspection machines off the network and have the hot end (where the moulding machines are) go on paper, meaning that someone would note the detected defects and get them to the hot end so they could fix or replace the problem mould.
After that I trust my pet rattlesnake more than MS, at least I know where it will bite me.
In general I have arrived at the place that I feel that proprietary stuff should not be in amateur radio if it can be avoided.
Now in the medical industry I see a lot of medical equipment using windows as the UI. But I still see it freeze up even on equipment that has more digits in the cost that I can comprehend. I have machines that are rock stable but for the Windows UI, they still have to be rebooted every once in a while to get them back to running normal.
But I see Open source solutions appearing even the one discussed in the latest ZR. So I know that there are others who can move things on down the road and I believe soon I will not have to think about it.
Chuck - I am no fan of the unreliability of Windows, especially past versions. But Windows IS a reality of life in Amateur Radio - many, many unique and useful apps in Amateur Radio are ONLY available as Windows apps. My personal approach is to have dedicated (inexpensive, often surplus laptops) boxes for specific Windows apps, update them once, and keep them off the Internet. It's not a perfect approach, but it works for me. Reasonable people can agree to disagree, especially about using Windows in Amateur Radio.
I shall have to try it, I ran across a script that lets you strip out all of the additional junk they heap in there, it is exactly for that. Will load one up and give it a try.
The items about VARA-FM are timely, and the repeater write-up has much useful information! That's exciting news, with a possible use case as a portable repeater for temporary deployment for events or emergency use (wildland fires, etc.)
This reading came after I finally got my N6AD AIOC (All In One Cable) PTT working with my Explorer QRZ-1 HT today, coupled to a portable tablet computer. This will be another arrow in my quiver, for a very portable WinLink and VARA-FM station!
It seems to me that the most flexible data repeater would be a 25 KHz linear transponder. Transmit up to the mountain on 70CM, it talks back on 1.2 GHz. Instead of going the whole way down to baseband/audio, just down convert to IF and run that into the up converter. There's a lot of precedent for such a system, the hardware is available and signals should be kept mostly intact -albeit inverted. Inject CWID using a local modulator at the IF stage. The major issue I would see is varying input levels, some sort of AGC would have to be developed to bring up fringe or QRP stations and attenuate high power signals, but satellites seem to make it work.
That way when a new mode comes along the repeater is ready for it. And I have a feeling there's about to be a lot of new V/UHF data modes come along.
Eric - Your suggestion keeps being made, of implementing terrestrial linear transponders... and that possibility seems to be routinely ignored. If cross-band is used as you suggest, I think that multiple 25 kHz segments could be combined for a wider bandwidth. And given the capabilities of Software Defined Receivers, the 25 kHz channels don't have to be adjacent.
I'll guess that it hasn't (often) been attempted because it's tough / expensive to do. But it strikes me that a linear transponder is a trivial task for a Software Defined Receiver and a Software Defined Transmitter, both with I/Q data streams, paired with a fast enough (I'll guess a RPI 5, or even RPi 4) host computer. Another reason that they haven't been attempted to date is that it's hard / expensive to generate signals narrower than typical FM, such as SSB. But such things are trivial with SDRs.
What we need is is more proof of concept testing AND DOCUMENTATION so that folks know that such things are possible.
Here in Kansas some of us did a quick adhoc test of Vara FM narrow over a UHF voice repeater with NO changes at all to the repeater timing or audio configuration. We were also getting 8 - 12 Kbps throughput. Very encouraging. Would make the changes to optimize if the repeater was to be used for data.
Would be great to have the VARA FM modem in a fixed-modulation format (per-user-defined based on path to the repeater, or agreed upon default level by local users) and a non-connected mode that could be used with JNOS or similar TCP/IP protocol stack and UI packets to allow multiple simultaneous connections to a converse bridge or FTP or mail server..... maybe the IP400 developments are headed in this direction.
Anyway, Vara is progress, and it works. Thanks to all involved, including the separate VarAC app.
I guess my "handle" was copied over from my substack login, I'm Jim - W0JPO in Salina, KS
Jim - Thanks for your feedback about VARA FM. My perspective on VARA FM is... "it is what it is". It may well be as optimized as the author wants it to be, with only bug fixes, or perhaps a very few improvements. One of VARA FM's strengths is that it is a connected mode, and apparently there's a handshake between the TX and RX stations about how well the TX station is being received by the RX station - need more FEC, can use max number of subcarriers, WIDE vs NARROW, etc. I think the primary value of VARA FM, besides what it can do as-is, is as an example to show what can be done with the application of multiple, layered techniques - OFDM, FEC, handshakes, sounding, etc. None of those techniques are exclusive to VARA FM. Rather, VARA FM is an admirable combination of all those techniques, in a way that no one else (in Amateur Radio) has attempted yet.
Is VARA documented such that independent implementations can be attempted by others, targeting different operating systems and UX? Seems like documenting the modulation scheme should be a minimum and perhaps whatever protocol/data formats are used as well.
While it would be wonderful if the software itself was open source, I can understand reasons that it wouldn't be, and respect the decision of the author to proceed. I think, however, that wide adoption by the amateur community, especially for emergency communications or other "embedded" uses would be easier if potential second sources were available, and if the protocol itself was open. This helps if at some point in the future the author moves on to some other project, or otherwise isn't willing/able to continue to support it. Even if only for Windoze version N+1 in the future.
Inside that ZIP file you'll see VARA Specification which is (as far as I'm aware) the only technical information on VARA. There's also a good primer presentation (slide deck) on VARA HF.
The folks working on Rhizomatica Mercury - https://github.com/Rhizomatica/mercury are the only ones working on an equivalent of VARA, and their focus is on an equivalent for VARA HF, not FM. I've heard both that Mercury is, and is not intended to be (ultimately) interoperable with VARA HF.
One thing I forgot to mention in my email is an earlier action that didn't involve Part 97 but did have an interesting statement from Commissioner Carr:
https://docs.fcc.gov/public/attachments/FCC-25-68A1.pdf
He says that soon they'll move to "more substantiative whacks at the FCC rulebook". I think these will take the form of NPRMs rather than direct final rules and in fact one has already come out regarding Internet labeling regulations that is generating some new comments. Some things to realize here:
1. They are very obviously only doing deletions. I felt this was clear from the jump, but that didn't stop people from requesting all sorts of massive new regulations. With that in mind:
2. It might be worthwhile to comment again emphasizing the changes for Part 97 that can be accomplished with only deletions (symbol rate, 219, etc).
The takeaway is they are tracking (to the word level) how many regs they delete so adding to the pile of removals will get consideration.
Justin - That's an astute observation. It might be worth doing another comment to FCC with that very narrow focus - yes, JUST delete the troublesome parts.
Regarding VARA, I would like to try it but I cannot stomach the use of windows for such an application, I wish he would do a Linux version so we can run it on RPi's and other small platforms that do not demand the babysitting of Windows. Also now with MS imposing even more demands on using Windows it gets even more toxic to use.
William - "Windows" is a frequent plaint about VARA... but requests to port it to other platforms fall on deaf ears. That the author gets ample "business" from VARA running only on Windows probably doesn't motivate the author to consider other platforms. The easiest method I've heard to manage "the Windows issue" is to buy a small, inexpensive Windows box, update it once, unplug it from the Internet, and use it like a VARA / VarAC appliance.
Ahh, but I read on down ZR and found something called HUSH!! Maybe this is the solution. I just cannot leave a windows box unattended, even off network. It gets in trouble by it's self. I figured sooner or later someone would continue to push from the OpenSource side of the house, and looks like they are. I do not mind paying I just do not like the platform they run it on.
William - I hear you, and I've had similar bad experiences about unattended Windows boxes. But, some folks I trust, tell me that such fears are overblown and that there are (many) ways to "harden" (we called such techniques "robustifying" in a previous job) Windows. I haven't yet investigated such techniques for "real Windows". If you want to use VARA FM, but cannot bring yourself to trust "real" Windows, I've seen a number of references (which I cannot point to at the moment - will run all those down in an eventual chapter in my forthcoming book) to building "appliance" images of stripped down Linux + WINE to run VARA FM without the vulnerabilities of "real" Windows.
Steve (by the way most folks call me Chuck) I used to work in the glass container industry. The inspection machines (there were 3) used windows as the machine UI. The under the hood devices were PLC's and Linux based on all but the rotational inspector. That one the UI was also an ADC using some National Semiconductor board that was Windows only. We tried every which way to make those machines bullet proof, pulling all of the junk out of the windows installs, we had a whole department that was dedicated to keeping windows slim and as reliable as possible, but even then it would still go off in the weeds. The sidewall and sealing surface/base inspectors did not care as the windows machine was UI only, BUT the rotational inspector did and it was a nightmare. Then after getting a virus on machines in Spain and Portugal (same company all of the plant back ends were linked) while I was in Spain working in one of the plants. The virus just about drove us nuts. We would clear it out of the machines and it would come back. The virus was something called Conficker see https://en.wikipedia.org/wiki/Conficker
We contacted MS about it several times (no response) as it was riding in on Netbios packets, we were sent a cease and desist telegram from MS, great way to treat a customer. In the end the quick solution was to take the inspection machines off the network and have the hot end (where the moulding machines are) go on paper, meaning that someone would note the detected defects and get them to the hot end so they could fix or replace the problem mould.
After that I trust my pet rattlesnake more than MS, at least I know where it will bite me.
In general I have arrived at the place that I feel that proprietary stuff should not be in amateur radio if it can be avoided.
Now in the medical industry I see a lot of medical equipment using windows as the UI. But I still see it freeze up even on equipment that has more digits in the cost that I can comprehend. I have machines that are rock stable but for the Windows UI, they still have to be rebooted every once in a while to get them back to running normal.
But I see Open source solutions appearing even the one discussed in the latest ZR. So I know that there are others who can move things on down the road and I believe soon I will not have to think about it.
Look for your note and keep up the good work.
Chuck - I am no fan of the unreliability of Windows, especially past versions. But Windows IS a reality of life in Amateur Radio - many, many unique and useful apps in Amateur Radio are ONLY available as Windows apps. My personal approach is to have dedicated (inexpensive, often surplus laptops) boxes for specific Windows apps, update them once, and keep them off the Internet. It's not a perfect approach, but it works for me. Reasonable people can agree to disagree, especially about using Windows in Amateur Radio.
I shall have to try it, I ran across a script that lets you strip out all of the additional junk they heap in there, it is exactly for that. Will load one up and give it a try.
The items about VARA-FM are timely, and the repeater write-up has much useful information! That's exciting news, with a possible use case as a portable repeater for temporary deployment for events or emergency use (wildland fires, etc.)
This reading came after I finally got my N6AD AIOC (All In One Cable) PTT working with my Explorer QRZ-1 HT today, coupled to a portable tablet computer. This will be another arrow in my quiver, for a very portable WinLink and VARA-FM station!
David - Glad that Zero Retries was of use. The NA6D AIOC / QRZ-1 combination is very cost effective.
It seems to me that the most flexible data repeater would be a 25 KHz linear transponder. Transmit up to the mountain on 70CM, it talks back on 1.2 GHz. Instead of going the whole way down to baseband/audio, just down convert to IF and run that into the up converter. There's a lot of precedent for such a system, the hardware is available and signals should be kept mostly intact -albeit inverted. Inject CWID using a local modulator at the IF stage. The major issue I would see is varying input levels, some sort of AGC would have to be developed to bring up fringe or QRP stations and attenuate high power signals, but satellites seem to make it work.
That way when a new mode comes along the repeater is ready for it. And I have a feeling there's about to be a lot of new V/UHF data modes come along.
Eric - Your suggestion keeps being made, of implementing terrestrial linear transponders... and that possibility seems to be routinely ignored. If cross-band is used as you suggest, I think that multiple 25 kHz segments could be combined for a wider bandwidth. And given the capabilities of Software Defined Receivers, the 25 kHz channels don't have to be adjacent.
I'll guess that it hasn't (often) been attempted because it's tough / expensive to do. But it strikes me that a linear transponder is a trivial task for a Software Defined Receiver and a Software Defined Transmitter, both with I/Q data streams, paired with a fast enough (I'll guess a RPI 5, or even RPi 4) host computer. Another reason that they haven't been attempted to date is that it's hard / expensive to generate signals narrower than typical FM, such as SSB. But such things are trivial with SDRs.
What we need is is more proof of concept testing AND DOCUMENTATION so that folks know that such things are possible.
Great article, thanks.
Here in Kansas some of us did a quick adhoc test of Vara FM narrow over a UHF voice repeater with NO changes at all to the repeater timing or audio configuration. We were also getting 8 - 12 Kbps throughput. Very encouraging. Would make the changes to optimize if the repeater was to be used for data.
Would be great to have the VARA FM modem in a fixed-modulation format (per-user-defined based on path to the repeater, or agreed upon default level by local users) and a non-connected mode that could be used with JNOS or similar TCP/IP protocol stack and UI packets to allow multiple simultaneous connections to a converse bridge or FTP or mail server..... maybe the IP400 developments are headed in this direction.
Anyway, Vara is progress, and it works. Thanks to all involved, including the separate VarAC app.
I guess my "handle" was copied over from my substack login, I'm Jim - W0JPO in Salina, KS
Jim - Thanks for your feedback about VARA FM. My perspective on VARA FM is... "it is what it is". It may well be as optimized as the author wants it to be, with only bug fixes, or perhaps a very few improvements. One of VARA FM's strengths is that it is a connected mode, and apparently there's a handshake between the TX and RX stations about how well the TX station is being received by the RX station - need more FEC, can use max number of subcarriers, WIDE vs NARROW, etc. I think the primary value of VARA FM, besides what it can do as-is, is as an example to show what can be done with the application of multiple, layered techniques - OFDM, FEC, handshakes, sounding, etc. None of those techniques are exclusive to VARA FM. Rather, VARA FM is an admirable combination of all those techniques, in a way that no one else (in Amateur Radio) has attempted yet.
Is VARA documented such that independent implementations can be attempted by others, targeting different operating systems and UX? Seems like documenting the modulation scheme should be a minimum and perhaps whatever protocol/data formats are used as well.
While it would be wonderful if the software itself was open source, I can understand reasons that it wouldn't be, and respect the decision of the author to proceed. I think, however, that wide adoption by the amateur community, especially for emergency communications or other "embedded" uses would be easier if potential second sources were available, and if the protocol itself was open. This helps if at some point in the future the author moves on to some other project, or otherwise isn't willing/able to continue to support it. Even if only for Windoze version N+1 in the future.
Louis - See VARA Documentation - https://mega.nz/file/bS503Bba#HAM8eVZjly4DILMHOn32RCG720D4yDh_OR1gMgMXO4Y
Inside that ZIP file you'll see VARA Specification which is (as far as I'm aware) the only technical information on VARA. There's also a good primer presentation (slide deck) on VARA HF.
The folks working on Rhizomatica Mercury - https://github.com/Rhizomatica/mercury are the only ones working on an equivalent of VARA, and their focus is on an equivalent for VARA HF, not FM. I've heard both that Mercury is, and is not intended to be (ultimately) interoperable with VARA HF.