The Design Philosophy of the CFT1: From concept to product

Many thanks to Jonathan KM4CFT who shares this article with us.  If you have an article in your head and want to have it posted here, let’s keep this community going while our friend Thomas continues to help his neighbours. Draft up your story in an email with reference points to the pictures you want embedded and their captions, attach photos to the note and send it my way to vincedeon at gmail dot com and note QRPer in the subject line to get my attention.

By: Jonathan Kayne, KM4CFT

About 10 months ago, I took the plunge to design my own Morse Code transceiver. It was a crazy idea, and this was certainly a massive undertaking, but somehow, I managed to pull off this monumental task. The result of the project was the CFT1, a 5 Band CW Field Transceiver specifically tailored for POTA and SOTA operations. Doing this project was a great learning experience and despite the monumental effort and work I put into it, I really enjoyed getting to design a new product. There is something special when you see something you love and put effort into appear in the hands of others and seeing them enjoy using said product.

The purpose of this article is to outline some of the thoughts I put into when I designed the CFT1. It is not meant to go into the meat and potatoes of RF design work as there are plenty of resources out there that go over that stuff. I have yet to see much discussed on design philosophy of a transceiver so I thought it prudent to document these things. That is; what I took into consideration when putting together the radio. And as I learned in this project, when pulled off correctly, can result in a great product.

Lets begin our discussion with a little background about myself, since it might help better understand my perspective on why certain design choices were made. As of writing this article, I am 25 years old and have been a ham for 10 years. My educational background is in RF Engineering at Virginia Tech. I live in an apartment complex where the noise floor is S9 making HF operation from my QTH impossible, making POTA and SOTA my only real method of HF operation. My first CW QSO was made in October of 2022, so I had a little over a year of CW experience when I started work on the CFT1.

Photo from one of my first ever CW QSOs

I think that last part is of particular importance: I am a newer CW operator. This means that my knowledge of CW is lacking compared to other operators in the hobby by a large margin. In the case of the CFT1 I think this worked to my advantage since I was only aware of the core feature set of most CW radios. For a radio that is touted to have a simple UI that was quite useful!

Before I discuss the start of the design process I want to go over what I think is the most important aspect of designing a transceiver. Its important to mention because it was what helped me come up with the core feature set for the radio.

Try many radios, form opinions!

The year prior to me starting on the CFT1, I purchased a lot of different radios and like any ham, formed my own opinions on the radios I used. And more importantly, I figured out what aspects I liked and disliked about these radios. I could then use that information to help me spec out my dream CW radio.

Another thing I looked at was other people’s opinions. Being a new CW operator, I found it to be important to ask and research other people’s thoughts on radios. Since I was hoping to sell the radio, I needed to know other people’s opinions on the radio because otherwise nobody would want to use the radio.

The radios I tested out were the following:
• ICOM IC-706MKII
• ICOM IC-705
• Yaesu FT-818nd
• Yaesu FT-891
• Elecraft KX2
• Elecraft KH1
• QRP Labs QCX mini
• QRP Labs QMX
• Xiegu G90
• Xiegu X6100
• Venus SW-3B
• MTR-3B LCD
• trusdx

Being that I am primarily a POTA/SOTA operator, I came up with the following opinions:
CW Message Playback is incredibly useful – when operating POTA or SOTA, you are saying “CQ POTA DE KM4CFT” and “RR TU ES 73 EE” a LOT.
◦◦◦ I particularly liked that with the IC-705 you could easily program messages and initiate playback with a single touch.
◦◦◦ I also liked how you would program messages with the QRP Labs radios.
◦◦◦ I did not like how certain radios required you to use the paddle to record your message. I kid you not, it took me over 20 minutes to program “CQ POTA DE KM4CFT” into my KX2. (I
later realized you could use the PC software to program in the messages which is a far better method for me)
Battery Voltage requirements – I found that certain radios had a maximum voltage that they could handle. These included the MTR-3B and the QMX. I own multiple different batteries and it is annoying when a radio will not accept a voltage over 13 volts, which means I have to exclude my LiFePO4 batteries. In the worst case scenario this can even ruin an activation if I pack the incorrect battery. Being able to accept a wide voltage range is an awesome feature.
PIN Diode QSK – although relay clicking does not bother me, it is certainly more enjoyable when you have full break-in and its done with a PIN diode. Full break-in is nice for the activator because it lets you ensure that you aren’t sending over someone.
Paddle Reverse – So I am a bit of a weirdo in that I prefer to send paddle reverse. I played around with CW paddles in high school but in 2016 there was nobody to tell me, “hey, the left lever is dit and the right paddle is dah”. My only radio at the time was the IC-706MKII and it didn’t specify the direction as “Normal” and “Reverse” but as “L” and “R”. I made a guess, and obviously I guessed wrong. The mountain toppers and SW-3B do not have a paddle reverse and its inconvenient that I have to custom make a cable for that radio.
Electronic Keyer Quality – this one I am a stickler for. It important that a CW keyer feels comfortable to send on, because otherwise it removes the main reason why I activate POTA or SOTA in the first place – fun! This was the main reason I got rid of my Xiegu x6100 and shelved the QMX for a very long time.

When I started out designing the radio, I did a lot of brainstorming. I thought up a feature set that I wanted and then used that as the foundation of design work going forward. The features I wanted in this transceiver were as follows:
• Wide Input Voltage Range
• Single touch message memory playback
• PIN diode QSK
• Paddle reverse
• Electronic keyer that is comfortable to send on
• Preferably, a UI that is as simple as possible to use.

Using this as my core design requirements, I got to exploring different components of the radio. I was hoping I could turn this into a kit that people could buy so I also had a requirement to make the build of the radio just difficult enough to make it fun but not so difficult that someone needed an engineering degree to successfully build it. I also knew that people seem to have a hatred of winding toroids so I wanted to use the absolute minimum number of them in the build.

This brings up the next aspect of the design philosophy: Keep the finish line in sight.

When you design something it is really easy to get sidetracked or pulled off into a tangent. It can sometimes be beneficial but often it can present a common pitfall that designers encounter, known as “feature creep”. Seeing that I wanted this radio to have the bare minimum without making major sacrifices, I was extra careful not to add extra features that weren’t needed. For me, the bare minimum was: Key speed, key type, sidetone and paddle reverse. There were very few features that I added to the radio afterwords. The only two that were added later were XIT and the transmit LED. To be honest, I only added RIT to the radio because it was the one feature that literally every radio in my collection had, even the MTR-3B which was the most bare bones of all my radios.

The other aspect of keeping the finish line in sight is remembering that it will be a kit. When I was considering different transmitter designs, I really wanted to go with class E for efficiency, but decided against it, because the output filter of those amplifiers requires a lot of fiddling to get right, which would make it difficult for a kit builder to calibrate. I learned this from building the trusdx. I ended up settling on a class D amplifier based of the Penntek radios since it only requires a power meter and a multimeter to set the PA drive level.

Other things I considered since this was a kit was the implementation of PCB design features that would help make soldering easier. These included enlarging the pads so that soldering was easier and/or didn’t need a fine tip iron and using multi-colored enamel wire for the transformer and labeling the pads “R” and “G” so that there wouldn’t be a need to fuss around with a multimeter to ensure the wire polarity was correct. This is all stuff I learned after many years of PCB design and kit building.

Once I had a working prototype radio, I was ready to move onto the beta test. This brings me to the third and final design consideration: Do a proper beta test!

When I was at four days in May in Dayton Ohio, I met a lot of people I had only communicated with virtually. I knew that a beta test would be essential for this radio, because I have seen what happens when radios do not go through that aspect and I did not want my radio to have those pitfalls. More importantly, from a software aspect, that means I can have a mature firmware loaded on the radio without bugs that I can release on day one. I really wanted to avoid having users update the firmware at all costs.

When I was at Four Days in May, I asked a group of ten people to join me in the beta test. I made sure that these people had a range of skills in different areas and a range of skill levels. All of them were QRP enthusiasts though! I brought on Thomas, K4SWL as my lead beta tester since I was aware that he has tested products for other manufacturers and I thought that insight would be helpful. Keep in mind that I have never beta tested a product before, nor have I ran a beta test before. I also brought on people who make QRP products like myself, in hope that they might help build an ecosystem for the CFT1 and give insightful and creative ideas when they gave feedback (N6ARA and N5FY).

Charlie, NJ7V and myself at Four Days in May
Dave, W8XAL and RadioDan, W7RF

When I started the beta test, I wanted to ensure that the radio UI was intuitive. The minimal number of features meant that I didn’t think there would be any excuse for the radio to be confusing, so to make extra sure it actually was simple, I put waited a while before publishing the owner’s manual with my beta testers. I told them, “I want you to try out the radio without a manual. If you need a manual then I need to reconsider my UI design”.

I often see reviewers unbox a product, and when they remove the instruction manual, they often will chuck it across the room as a joke. Even if its in jest, it does point to the fact that people do not like to read manuals. So if the radio doesn’t need a manual for someone to pick up and operate then that is a rare feature that people will enjoy. Luckily, the UI was intuitive enough that everyone was able to operate without the manual. About the only feature on the CFT1 that people might need the manual is on how to clear the message memories, which is done by long pressing the VFO knob when entering edit mode.

I honestly thought a beta test would be a lot more involved but ultimately, you are giving a group of people a radio and telling them to go to town on the radio. I pretty much wanted them to do whatever they wanted with the radio short of running it over with a truck. Try different batteries, different paddles, on POTA, on SOTA, in extra hot weather, in direct sunlight, with bad antennas, etc, etc.

Dave, W8XAL operating the CFT1 on top of Horsetooth Mountain

The beta test was incredibly fruitful, because we found a few bugs in the code, one of which would have been a massive issue had it not been caught. Evan, K2EJT found an issue where he was having trouble sending certain letters and since he is an instructor with the Long Island CW Club was better at sending than I was, so it was difficult for us to find the issue. I was eventually able to find it though – it was the difference between “=” and “==” in the C++ code for the iambic B algorithm. The dah side had it correct but the dit side didn’t.

This beta test was worth its weight in gold. Because of it, after the official launch there has only been a few incredibly minor hiccups. And for the beta testers who are reading this, I can’t thank you enough!

To wrap up this discussion, I want to thank everyone who was supportive of this endeavor. This was only possible because of everyone who helped mentor me in radio homebrewing, including Don ND6T, Alan W2EAW and the folks on the SolderSmoke podcast. I also want to thank the regulars on the #pota-cw channel of the POTA discord server, who were super supportive of my design journey.

Most of all, I want to thank my grandfather, Steve Kayne, who passed away last March. He was the reason I pursued Engineering and was incredibly supportive of my ham radio hobby. His love of teaching and the pursuit of knowledge will always play an important role in my life!

72,
-Jonathan Kayne, KM4CFT

Editor’s note: you can purchase this radio via HamGadgets.com at the following links:

CFT-1 Kit only

CFT-1 Fully Assembled

3 thoughts on “The Design Philosophy of the CFT1: From concept to product”

  1. Nice article, Jonathan – really interesting to hear the journey. I am truly enjoying my CFT1 and hope that my assembly video helps people too. Honored to know that my content has helped along the journey as well. (Maybe you/Vince/Tom could correct my callsign in the post (A & E got transposed).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.