Re: [QRPLabs] Software extensions

Jack, W8TEE


I have the protocols used for Icom, Kenwood, and Yaesu which probably should give us a good starting point. We need to ask ourselves: Do we want to really create a unique command protocol, or do we want to take an existing protocol and make the "rig end" fit the radios we're interested in? In other words, write it in such a way that it can be used by the existing software base (e.g., Ham Radio Deluxe, Fldigi, etc.). I wrote a simple CAT program for the X1M xcvr years ago, but never went anywhere with it. The X1M used the same protocol that was used for the Icon 718, which could then be used with Ham Radio Deluxe. I was writing a PC program in VIsual Studio using C# so the user could avoid spending $100 on the PC-end software. Personally, I think it makes sense to work with at least a subset of one of an existing protocol, as that would give us software that we can use as a test bed. Personally, I don't use CAT right now, so I don't know what the "most popular" protocol is, but it can't be that hard to find out. That would simplify the "out" end of the link. My ultimate goal is to do away with the PC and have the output controlled by a TFT display and perhaps a 5" or 7" color display. (I don't want to have to take a tablet with me if I want to operate from a canoe.)

The "in" end would depend on the code that is to sit on the microcontroller. That code needs to be as skinny as possible and still do the work. Truth be told, that microcontroller will likely have other work to do, so we need this code to co-exist with the other code in the program. That suggests a library approach to the problem. While this won't be a requirement, I will be doing my work within the confines of the Arduino IDE since it uses C-C++,  is free, but supports multiple processors. Personally, I don't see a member of the Arduino family being up to the task. That leaves the STM32F, ESP32, and Teensy families from which to choose. My Projects book uses all three, but I'm losing interest in the ESP32, mainly because its boards and pin layouts are all over the map. (Some boards have 30 pins, others have 36 or 38 pins which makes it hard on the reader to buy the "right" one.) That's sad, because the ESP32 has great resource depth. The STM32F series are cheap, yet are markedly more powerful than the Arduinos. Hans chose the STM32F4 series for the QSX. The Teensy is an h-bomb for the task, but costs $20 for the T4. Rock...hard place...

I think the first task is to determine what software can work with which protocols. You guys doing CAT work already can help here. The next thing we need to do is determine the "must have" commands and get those working first. Once those work, extensions are easy. Then I would see the group working on an Application Programming Interface (API) that is generic enough to use with different controllers. That way, even if the code is not Open Source, someone like Hans might take our API and compile it into their code. We could then use those API hooks to control their xcvr.

Finally, I would suggest moving this thread either to a new group or the softwarecontrollerhamradio group, as someone has already suggested. (BTW, I own that group and started it several years ago, so moving this discussion to that group is fine with me.) There's no reason to clog Hans' group. If you want to participate in this discussion further and are not a member of that group, I hope you'll join it.

Let's close the thread here and consider it moved to the softwarecontrollerhamradio group.

Jack, W8TEE

On Friday, December 20, 2019, 6:06:03 AM EST, jmh6@... <jmh6@...> wrote:

Hi Jack,

    I would consider code size and simplicity for any protocol we consider.

    Lots of fun :).

On Thu, 19 Dec 2019, jjpurdum via Groups.Io wrote:

> We may have to start a separate group for this topic.
> Jack, W8TEE
> On Thursday, December 19, 2019, 2:26:51 PM EST, Jim Manley <jim.manley@...> wrote:
> Hi Jack, et al,
> I would love to contribute to this effort and will start perusing the links provided to get up to (some?) speed during the holiday break, while trapped at my in-laws for
> nearly two weeks in the place with the coldest average temperatures in at least the lower 48.  There isn't even skiable snow, although drifts can get to around 24 feet that
> allow skiing from upper-story windows ... assuming you're in a multi-story building!
> 73_Animated_GIF.gif
> Jim  KJ7JHE
> Lame Deer High School Amateur Radio Club  KJ7JKU
> On Thu, Dec 19, 2019 at 11:46 AM Arv Evans <arvid.evans@...> wrote:
>      Jack
> This might be interesting.  It is open-source and readily available.
> This has been around in UNIX and Linux systems for many years.  It is easy
> to use and is customizable for various rigs by simply linking to the appropriate
> Hamlib library.   Resistance to it may be because there is no glory in using
> already available methods. 
> Arv  K7HKL
> _._
> On Thu, Dec 19, 2019 at 9:17 AM jjpurdum via Groups.Io <> wrote:
> OK. We'll keep looking around...
> Jack, W8TEE
> On Thursday, December 19, 2019, 10:45:49 AM EST, <jmh6@...> wrote:
> Hi Jack,
>     The only docs I have are a very old product manual that does not have
> the whole thing. Gotta get into some 6502 and 8052 code and then do some
> writing.
>     Most stuff will be re-discovered once an open CAT protocol is being
> used.
>     Works well. It is still being used by a dual 3.25 inch floppy IBM PC
> Clone for automated product testing. PC code was written in Power Basic.
>     Very old stuff!! lol!!
>     Lots of fun :).
> On Thu, 19 Dec 2019, jjpurdum via Groups.Io wrote:
> > I'll start collecting stuff as I can. If you have docs on your NIWire, I'd
> > like to see it. If anyone else has related docs, please send them to me.
> >
> > Jack, W8TEE
> >
> > On Wednesday, December 18, 2019, 6:29:55 PM EST, jmh6@...
> > <jmh6@...> wrote:
> >
> >
> >
> > Hi Jack and All,
> >
> >     I think a new simpler open CAT type interface is all that will really
> > work? Right now there is a very confusing mess of different protocols all
> > of which seem radio-centric rather than CAT centric.
> >
> >     Since you are into writing documents, how about doing a first crack at
> > an 'open' CAT centric standard that we can all comment on?
> >
> >     Our products used a 'simple' protocol we called NIWire that worked
> > pretty well, had a small software footprint and seemed to work reliably. I
> > doubt that it would be suitable as a 'standard', but it was simple both as
> > to signals on the wire and code complexity.
> >
> >     Lots of fun :).
> >
> >
> > On Wed, 18 Dec 2019, jjpurdum via Groups.Io wrote:
> >
> > > Arv:
> > >
> > > I agree. I know there are products out there being sold that use Open
> > Source software, including my own. Still, I made that decision when I made
> > it Open Source. My theory
> > > is that, if someone stands on my shoulders and makes something I started
> > better for everyone, we all win. However, I do get a little miffed when
> > someone takes something
> > > that is not Open Source and either sells it (M0NKA's SDR transceiver) or
> > gives it away (my books on torent sites).
> > >
> > > I do think the CAT interface does offer a way to extend the software
> > without making all of it Open Source. It appears that we are slowly
> > standardizing the CAT protocol. I
> > > would like to see the community pull together and formalize a CAT
> > interface. It would require support from The Big Three and that could
> > dissolve into a pissing contest. If
> > > that happens, I say screw 'em and we as users form our own CAT standard
> > interface. (If this is all Greek to you, check out
> > for a
> > > simple way to specify a series of CAT commands.)
> > >
> > > For CAT to work, processors need to be on the "radio end" and the "user
> > end" of the CAT connection. For Hans QSX, the radio end will be a processor
> > in the STM32F4 family.
> > > On the user end, it could be whatever the user wants. Me? I plan on having
> > a touch screen waterfall display that doesn't rely on a PC. It will be a
> > self-contained SDR a la
> > > M0NKA or the G-90. For others, write a PC program in your favorite
> > language that can read ASCII data from a port and do whatever you want with
> > the data you get via CAT.
> > >
> > > All of this could be super cool stuff. I know Al and I are going to dig
> > into it when the dust settle a bit.
> > >
> > > Jack, W8TEE
> > >
> > >
> > > On Wednesday, December 18, 2019, 3:45:59 PM EST, Arv Evans
> > <arvid.evans@...> wrote:
> > >
> > >
> > > Jack
> > >
> > > Well-said.  You made it very clear what the pro's and con's are regarding
> > giving away
> > > intellectual property versus securing said property.   Micro-controller
> > based systems are
> > > particularly problematic because some of the micro-controller chips can be
> > read back
> > > and copied at the bit or byte level.  The AVR is one of the
> > micro-controller chips that
> > > does have fuse bits that can be used to help protect the device from being
> > copied. 
> > >
> > > We are seeing some of this problem over on the BITX discussion group,
> > where individuals
> > > have made their own junk-box variations of the hardware, modified the
> > open-source software,
> > > and now seem to expect that Farhan will troubleshoot their mistakes. 
> > >
> > > Micro-processor ICs that do not have built-in copy protection have to rely
> > on "mouse-
> > > traps" that use hidden code to erase or mutilate the code if it is
> > tampered with. 
> > >
> > > Since recent trends seem to indicate that even homebrew rigs need to
> > support some form
> > > of CAT control, maybe that is where the user customization needs to
> > reside.  If there
> > > is an adequate set of basic functions, then maybe user code in the CAT
> > software could
> > > allow those who want something else could add that feature or function?
> > >
> > > Arv
> > > _._
> > >
> > >
> > > On Wed, Dec 18, 2019 at 7:58 AM jjpurdum via Groups.Io
> > <> wrote:
> > > Everything I've written since I retired is Open Source and, for me at
> > least, doing so is a true dilemma. That is: Two choices, both bad. I'll bet
> > Hans has waded
> > > through the same decision-making process.
> > >
> > > If you make your code Open Source, you lose control of it and it does end
> > up being stolen, sometimes for profit. Even worse, some people will attempt
> > to modify your
> > > code and, when it doesn't work, they actually have the audacity to ask you
> > to fix it...for free! Not good...not fair.
> > >
> > > On the other hand, if you don't make it Open Source, some people think
> > you're a Grinch because they can't make your code do exactly whatever it is
> > they want it to
> > > do.  They, too, want you to add such-and-such a feature, but fail to
> > realize there are not a lot of deaf, blind, people who only speak Latin.
> > (The Grinch Factor, to
> > > me, is a myth. It's my don't like it, write your own.)
> > >
> > > So, what's the answer? First of all, given what Hans has managed to stuff
> > into a Nano, there can't be more than a few bytes left. So, my guess is that
> > putting
> > > something in means taking something else out. For most of us, that means
> > "Leave it alone." However...
> > >
> > > The QSX is going to be another beast altogether, since it will be using
> > the STM32F4 series of microcontroller. Hans has some headroom there because
> > of the memory
> > > resource depth and a faster clock. Yet, from Hans' perspective, how does
> > he address the dilemma of lost control versus the Grinch factor? I think the
> > best solution is
> > > an API--Application Programmer Interface. An API provides entry points to
> > methods that allow you to extend the functionality of the program in much
> > the same way that
> > > libraries allow you to extend the Arduino core. The downside is that it
> > takes a lot more effort on Hans part to provide an API for us.
> > >
> > > So...what's the correct answer from everyones' standpoint? I don't have a
> > clue.
> > >
> > > Jack, W8TEE
> > >
> > >
> > >
> > > On Wednesday, December 18, 2019, 9:23:11 AM EST, R. Tyson via Groups.Io
> > <> wrote:
> > >
> > >
> > > Hi,
> > > As pointed out in another post I doubt there is sufficient memory left.
> > The radio has a remarkable set of facilities and Hans has done a brilliant
> > job on it.
> > >
> > > Someone suggested that the software should be open source... that would
> > enable others to produce cloned versions of Hans' work - in effect he does
> > the work and
> > > someone else steals it and profits from it.
> > >
> > > Tuning up and own the band is good exercise - I remember when we had to
> > get out of our chair and walk across the room to change T.V. channels and
> > there were only 2 or
> > > 3 of them.
> > >
> > > The facilities available from these little radios is amazing but there is
> > not the infinite capacity to keep adding stuff from "wish lists".
> > >
> > > Reg              G4NFR
> > >
> > >  
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >

Jack, W8TEE

Re: Flrig and uBitX not connecting

Jay - WS4JM

I loaded the latest yesterday, no joy. I thought it would be an easy way to do rig control with a Raspberry Pi. On to something else.

73 de WS4JM

Re: For Sale new uBITX kit with additional uBITX board plus display


Would you share the repairable aspect?  Either piublically or by private response.  Thanks in advance, as I've got a few to resurrect if possible.

- Ted

Re: For Sale new uBITX kit with additional uBITX board plus display

Patrick Pelletier

Hi Jim,

It was actually the other way around.  But I changed my mind and decided to play with my raduino and some of my own circuits.



On Thu, Dec 19, 2019 at 8:26 PM Jim Sorenson <kjsorenson@...> wrote:
Hi Patrick, 

I sent you a reply this morning by private messaging on this board. Perhaps you did not receive it. 

Jonus needs the board only. Perhaps I could send it to him directly and then work out something with you for the new kit. 



Re: ubitx v6, refactored code


Rick, are you using the KD8CEC software in your V5? If so, using his Memory Manager program will allow you to plug in "typical" values for the VFO and BFO numbers and that should get you where you can hear stuff, then you can adjust as needed. I'd give you what I have on mine, but as it is a V4, it will not work on a V5 machine, so be sure you get some V5 numbers.


Re: V6 radino on V5 board?

Evan Hand

There are also differences in the "CONTROL" connector.  This means you need to rewire that connector as well.  The only connector on the v6 Raduino that has not changed from the v4/5 is the "OSCILLATORS" connector.


Re: Flrig and uBitX not connecting


No, the need never came back up. I could use WSJT-X if I wanted to control and the Flrig was basically for fun and maybe use Fldigi at some point. I see the fl*** programs get updated a lot, so maybe something more recent has fixed the problem.


Re: V4 TX problems and new finals #ubitx-help

Don - KM4UDX

Jerry -- thank you for the clever application for my excess 510 and thermal switches. Love it.


Re: V6 radino on V5 board?

Jerry Gaffke

I had previously written:

>  hopefully the new display can plug into that same old connector with no soldering necessary.

Wrong.  The connector from Raduino into the display is different, has 14 pins instead of 16 for starters.
Power and ground have moved so attempting to plug a 2.8" TFT into the old Raduino will smoke something.

The new v6 Raduino is a differerent PC Board layout to accommodate the different display connector.
Using the new TFT display with the old Raduino might be possible, but will require a dozen or so wires 
from old Raduino to display. 


On Thu, Dec 19, 2019 at 08:46 AM, Jerry Gaffke wrote:
From Farhan's post of
>  The V6 is just an easier to assemble v5. No difference at all but for the touch display.
>  You can buy the tft off ali express for about 5 dollars and upgrade the firmware.

So the answer is yes, you can update a v5 to have a v6 style display.
No need to swap out the entire Raduino, just the display itself.
Then burn the v6 firmware into the Nano.

I believe the Raduino board has not changed since first introduced for the Bitx40,
except that now a socket is used on the Nano to make it easier to replace.

The old 2x16 display just plugs in, hopefully the new display can plug into
that same old connector with no soldering necessary.

In the past, it has been possible to buy a Raduino separately from hfsignals for about $30.
I don't see that as an option on now, the only items to buy are the complete v6 uBitx and the Antuino.
But if the display is easy to swap out, and the Nano is socketed and thus easy to replace if it fails,
that covers most of why you would want a new Raduino. 
About the only other stuff on the Raduino is connectors, LM7805 regulator, and the si5351.
If you really do need a new Raduino there have been third parties posting to the forum
offering their own version for sale, some of them with significant enhancements.

Jerry, KE7ER

Re: V6 radino on V5 board?

MVS Sarma

On Fri, 20 Dec 2019, 2:52 am Jim Sheldon, <w0eb@...> wrote:
Yes.  V6 doesn't use an LCD at all.  It uses one of the 2.8" TFT color
screens and the pinouts go to a 14 pin connector that's mounted down the
right side of the V6 Raduino board.  V6 Raduino is the same size and has
the same mounting holes as the 2.8" ILI9341 display they (and we) use.

If his schematic for the V6 is right, the pinouts for the Display  (they
are all available on the old 16 pin LCD connector)

I can't get a NANO (with Farhan's factory code) to boot to the 2.8"
display (same one they used).  Your code doesn't boot to the display
either either in a Teensy 4 or NANO.  I tried it on both a Raduino clone
of ours and a real Raduino (the one from the V5 board you gave me). 
Neither work.


Signals from the display and where they are supposed to go according to
the Raduino schematic:
1 -- VCC +5V to +5 on the Raduino
2 -- GND  to GND on the Raduino
3 -- CS to D10 on the NANO or Teensy
4 -- RESET tied to +5
5 -- D_C to D9 on the NANO or Teensy
6 -- SDI/MOSI to D11 on the NANO/Teensy
7 -- SCK to D13 on the NANO/Teensy
8 -- LED to +5 for full brightness or through 22 ohm resistor for less
9 -- SDO/MISO to D12 on the NANO/Teensy
10 -- T-CLK (parallel with SCK) to D13
11 -- T_CS to D8 on NANO/Teensy
12 -- T_DIN parallel with MOSI
13 -- T_DO parallel with MISO
14 -- T_IRQ not used leave open

Re: Flrig and uBitX not connecting

Jay - WS4JM


I know this is an old thread, did you ever get this to work?


Re: For Sale new uBITX kit with additional uBITX board plus display

Howard Fidel

Do you still have the two boards, and the blown out Raduino, they are repairable.


On 12/19/2019 9:45 AM, Jim Sorenson wrote:
I have a new uBITX kit and a spare uBITX board for sale. 

The uBITX board without the Raduino was part of a working system till I blew out the Raduino. 
The uBITX kit is new in the box and was purchased within the last 5 months. 
I'll include a display and various part from the first kit. 

$150 for both kit and additional board, parts and display
PayPal to my email and I can ship today CONUS - shipping on me. 

I enjoyed using the uBITX while the Raduino was OK, but am moving house and would not get back to this project for some time. 

Many thanks, 

Jim Sorenson

Re: µBITX & QRP labs 50W PA

Alex Netherton

Is there a cost effective way to add band switching? The scope trace showing on the page seems pretty good.

On Wed, Dec 18, 2019 at 12:36 AM wnpauls via Groups.Io <> wrote:
That would work, but it will need band pass filters and the
associated band switching.  The same amp is available (unassembled)
for about 38 to 40 US dollars shipped. 

Paul K0ZYV 

From: <> on behalf of Alex Netherton via Groups.Io <>
Sent: Tuesday, December 17, 2019 9:06 PM
To: <>
Subject: Re: [BITX20] µBITX & QRP labs 50W PA

On Thu, Dec 12, 2019 at 11:49 AM Arvo W0VRA via Groups.Io <> wrote:
Anybody considering using a QRP Labs 50W PA with their µBITX?

There's no band switching yet.

Re: For Sale new uBITX kit with additional uBITX board plus display

Jim Sorenson

Hi Patrick, 

I sent you a reply this morning by private messaging on this board. Perhaps you did not receive it. 

Jonus needs the board only. Perhaps I could send it to him directly and then work out something with you for the new kit. 



Re: V4 TX problems and new finals #ubitx-help


RD16HHF1 and heatsink out - is much better than RF510 inside the room.

Re: V4 TX problems and new finals #ubitx-help

Jerry Gaffke


So you have temp sensors that turn off when they get hot, and a bunch of extra IRF510's?
An excellent opportunity to better understand what an IRF510 does!

Here's the data sheet:

Assume we tie the SOURCE pin of the IRF510 to ground, the DRAIN pin to one side of your fan, and the 12v line to the other side of the fan.
When the IRF510 conducts from DRAIN to SOURCE, the fan will be working.

How do we tell the IRF510 to turn on?
We raise the GATE pin from zero volts (measured with respect to the SOURCE pin, which in our case is the same as ground)
up to maybe 12 volts.  You want 5 volts to turn it on good, anything over 20 volts on the GATE can destroy the IRF510.
So if we tie a 1k resistor between the 12v power supply and the GATE, the IRF510 will turn on and the fan will spin up.

How do we get the IRF510 to turn off?
We can now just short that GATE pin to ground with a wire, that puts 12 volts across the 1k resistor and we waste a measly 12v/1k = 12 milliamps of current.

How can we use your normally closed thermal switches to short the gate to ground when the thermal sensor cools off?
Just tie the thermal sensor between the IRF510 GATE and ground.
When the the thermal sensor gets hot, the switch inside opens up, the GATE is no longer shorted to ground
and so the wimpy 1k resistor can pull the gate up to 12v, which turns on the IRF510, which allows current to flow through the fan.

As a bonus, if you ever blow the IRF510's in the uBitx main board, you know where you can find a couple spares.

30 Watts out?
That's way too much.
The rig is probably distorting badly, and you are seriously in danger of destroying your uBitx.


On Wed, Dec 18, 2019 at 09:14 PM, Don - KM4UDX wrote:
Then I moved up to +15V on the brown wire. I got more power. Then +20V.  And I got even more power. I was mad with power! How much power you ask? 30W on 80m. And the spectral purity is only sort of marginal. hahaha.  I keep it below 30w...mostly...I try to keep it down...really I do...but sometimes...I ...just...can'

I felt like Dr. Frankenstein..."it lives!!!"

The hormonally excessive large heat sinks got thermal switches to drive fans. The case got cut to hold the fans. Power was supplied to the fans. I was ready to conquer the world!

Except the fans didn't really work.  The thermal switches were "on" all the time, the fans even with soft mounts made a racket, and the stupid fans would clog every time I hit TX.  And then they died. Maybe cause I paid $1.99 per fan?

So I need to redo all the fan business.   And I didn't think to test the thermal switches ahead of time. Normally open? Normally closed? hun? what? Such an idiot.

Re: Audio Buzzing


I am also having the same buzzing as described. I am using the uBitx with a 5" nexion screen, the base package including the audio amp. I have tried 2 different power supplies for the touch screen, same hum on both.

The hum is constant, that is always at the same level regardless of the volume control.

Re: V4 TX problems and new finals #ubitx-help


Using variable speed fans by running them at 5V for 12V fans and using
temperature sensing to speed them up  works well.   Save for you cannot 
touch the heatsinks as they are RF hot so they must be grounded and
use mica or ceramic (alox) pads to isolate the  MOSFETS.

You want to keep the fans on during RX to get the heatsinks cool again
or the next sill start warmer and get hotter still. If done on PTT a timer
on the fans may work.  

With any approach a air tight case is going to result in problems.
You need to get the heat outside either by air flow in the case or
by using the case (aluminum) as part of the heatsink with finned
surface outside.
No direct email, it goes to bit bucket due spam

Re: V4 TX problems and new finals #ubitx-help



Running  at 175C is way too hot for any reliability.
Keep it cooler.  That means more heatsink as you pay a
2.5degreeC/per watt of heat dissipated price for the part.
At over 100C you need to seriously derate the part of it 
so it will survive.

Reminder at 10W out you doing about 10W of it as heat.
Its not a lot but you have to get it out of the part and that
is harder.  SSB its not that bad for acerage power but at
FT8 full bore, fans!

So to stay cool you need a heatsink that stays much cooler
say under 45C (about 112F) measured as then you have
a bit of headroom.

No direct email, it goes to bit bucket due spam

Re: V4 TX problems and new finals #ubitx-help


Yep I'm sure,

If you read his article about the amp, you can see OM Kosser is a really careful designer that worked very hard to make that amp a nice reliable design.  So he was being prudent and recommending to keep the transistor within recommended temp range of the datasheet.  He did mention that it might be safe running to a maximum junction temperature of 175C which means a heatsink temperature max of 57C.  So that seems to be what some here may be doing.

I was mostly posting the info for users wanting to do digital modes and giving them an idea of what to watch out for.  In that regards, the choice of a turn-on temperature of 35C is not a bad choice at all.  The same thermal switches could be kept and just use a relay or power switching transistor to reverse the mode.

Personally, I think just operating the fans on PTT is a good way to go as long as a larger diameter/lower speed fan is chosen to keep it quiet while keeping the air flow up.