I’m a believer in true knob and button radio interfaces, and I’m not the only one. A small team, formed around Stu, K6TU developed the Contest Knob, which is now today manufactured by FlexRadio Systems under the name FlexControl. In this interview K6TU reveals the ideas behind the Flex-Control and describes in detail the steps from the design to the industrial production.

Shownotes

Interview

DH1TW: Hi everyone, this is Tobias, Delta Hotel One Tango Whiskey, with another episode of my SDR, Software Defined Radio Podcast. This is the place where interesting fellow hams come to talk about their projects, share their experience and knowledge with the goal to motivate you and to help you get started with your own project- even today. Over the past two years, I was working on PowerSDR-UI, a modified version of PowerSDR with the aim to improve the haptic- let’s say, the real knob user interface of FlexRadio’s SDRs. The way I took was to integrate an off-the-shelf DJ console which is available for little money but provides a lot of knobs and buttons. Almost at the same time, Stu, Kilo Six Tango Uniform, was working independently on a similar solution: The contest knob which is now manufactured and sold by FlexRadio Systems and in the name FlexControl. Today, Stu is here to talk about the FlexControl and the path he went from the first idea to an industrial manufactured product. So, without further ado, welcome, Stu.

K6TU: Hi, Tobias, How are you?

DH1TW: Thanks, I’m fine. Thanks for coming here on the show tonight. Before we get started, I always ask the same question to all of my interviewees: Who are you and how did you get started in Ham Radio?

K6TU: Well, I’m, Stu Phillips K6TU, originally from the UK, where I held my first call sign back in 1973. I got in to Ham Radio as an SWL many, many years earlier actually. And, it’s been a hobby that has

stuck with me. I was always fascinated by propagation, being able to talk to people in other countries and just the technical intricacies and, the opportunity to experiment with Ham Radio.

DH1TW: Good. Do you have any technical background? Any engineering degree?

K6TU: Yes, I am electrical engineer by training and I spent the bulk of my operating career actually running software development for organizations. The last one of those I actually ran all of the software development for CISCO Systems up until 1997.

 DH1TW: Cool. So, then a few years ago FlexRadio Systems brought out their contest. Well, actually, not only contest radio but the Software Defined Radio platform and there was something missing. We had to operate the radio with a mouse and the keyboard but somehow it wasn’t the same feeling than operating a radio with the knobs. And, tell us a little bit about how you came up with the idea to develop the Contest-Knob.

K6TU: Okay, sure. Uh, so, in the middle of 2009, I decided to upgrade my station. I had had a Kenwood Radio for many years and had found that I was hitting some of the limitations. Particularly, living here in Silicon Valley, it’s a pretty high RF environment, particularly in contests and the Kenwood would- the receiver in the TS-2000 would often be limiting for me. So I looked at a couple of different choices and decided actually to buy a FlexRadio 5000, which I did. And, one of the things that I had started doing- I had always been an active contester but I would say more on the sort of casual basis. And, a couple of my really good friends here in the Silicon Valley that encouraged me to take contesting a little more seriously and so that I began to do. So I operated one contest. Actually, the first contest I operated, I think with the Flex-5000 was the California QSO Party in 2009. And, quickly found that there was a real workflow issue. So, I use Write Log as my contest logging software and obviously if you’re trying to work a lot of stations quickly you really want to keep all of the window focus on the logging software, and really not have to move the mouse outside of the logging window. And so, at that time, I had no other way of tuning PowerSDR other than using the mouse. And so, I was obviously taking the window focus backwards and forwards between PowerSDR and Write Log. And, several times found myself typing into, typing for example a pull sign into PowerSDR. Which, if you have the keyboard shortcuts enabled you can suddenly find yourself 10 MHz off frequency and whoever you were working you just lost. And so, I decided that it really was critical to be able to have a way of separately tuning the radio independent of the mouse. And so, the window focus could remain solely on Write Log. So, that was the initial idea if you will. It actually developed a tuning knob some years earlier around a very expensive optical shafting coder. I’ve operated a remote control station for actually pretty close to the last 10 years now. And so, I was well familiar with what was needed but I decided that there was a much tighter integration needed on the PC side than I had done in the past. So that really was, if you will, the genesis of why I decided to build what ultimately became the FlexControl.

 DH1TW: Considering the user interface of a classical radio we have a lot of knobs. We have apart from the main frequency dial, we have volume, we have RF Power, we have the RIT, we have XIT, Noise Blanker, whatever. If I’m looking onto the FlexControl, it’s just basically one tuning knob and a few buttons. Was this always a design criteria just to have just one know or did you also play with the idea to include more knobs, more functionality?

K6TU: Well, from the very beginning, I wanted to keep it simple. I was very focused on trying to build something with a cost of goods, built of materials- if you will- that was something that could be economically manufactured if that ever became of interest. Being a product development guy by background, I’ve always approached these things, as you want the minimum in the product that you can sensibly use. And so the original concept when I started looking at contest operation is there’s really two different modes. There’s what a lot of contesters call a “run” mode, which is when you are running on a single frequency, and you’re calling CQ and people come to work you. The opposite is “search and pounce” where you are tuning up and down the bend looking for multipliers or people that you haven’t worked. So, I decided from the beginning that I wanted to be able to control a minimum number of functions using the knob. I actually enlisted the input from a very good friend of mine, Kevin, Kilo Six Tango Delta. Kevin has a lot of experience in contesting and in fact was the one who had persuaded me or encouraged me to take contesting more seriously. So, in the beginning we had focused really around a knob with a center push switch on it. And of using that pushing switch really as the way of being able to control backwards and forwards between different functions. So, we wound up with this initial specification that was jus the knob with the switch on the shaft encoder that senses the rotation. And, of using that switch to implement almost like mouse clicks. So, a single click, a double click and then a long click where you just press and hold the switch down. And, of using those to create two different modes. So, one mode for “running” and the second mode for “search and pounce” and then, being able to toggle between two different functions in each mode. So, for example, if you’re running a single Operator 2 Radio (SO2R) in a contest you actually want to be able to control, typically the RIT on the radio or on the frequency that is your primary run frequency. And then, be able to control VFOB or the second radio’s VFO on the radio that you are using on another band to find multipliers. And so, this idea of a mode and within it being able to toggle between two different functions was a way of with using a single knob to say, “Okay, now I was to tune the RIT” or “Now I want to tune the other VFO.” And so, the whole concept became around the very simple user interface with a set number of functions that would control the shaft encoder switch. So, the original knob actually did not have shaft encoder switches in the design at all.

DH1TW: Okay, so basically just the big knob?

K6TU: Yah, that’s correct.

DH1TW: Sounds pretty much like an Apple design…The Apple Philosophy.

K6TU: Yah, I guess Silicon Valley infects everybody with the same thoughts. I mean really, if you’re going to try and build a project and if you can keep it simple and intuitive, then it becomes much easier for people to adopt and use. And, the more complicated you build a product- I mean, if you think about a lot of the hand held radios that are on the market for Hams there are so many functions in them and they’re buried in menus, you almost have to carry the user manual around with you if you want to do anything other than normally change frequency. And so, the whole concept behind the tuning knob was just to keep it simple.

DH1TW: Yeah. I made exactly the same experience. I set up for the DJ console an email reflector where everybody who was interested and can join. And I’m quite often, I receive some requests for “Why couldn’t you add this functionality” and “If I press this button combined with the other one…” I mean, okay, this might satisfy the wish of one or two particular users but I think I don’t want to increase too much the complexity of the product because the DJ console itself is like; it’s like way more complex from an optical or a haptic perspective than the FlexControl.  And, I also believe that a certain amount of complexity is just to high it might be counterproductive. So, you don’t want to overload the interface either. And, I’m always admiring Apple for their great use of interfaces and, I also like the simplicity of the FlexControl. It’s like if you can bring down the basic, the most needed functions into one knob and three buttons you can really see that there were some serious thoughts behind the product.

K6TU: Yeah, that was very much the idea, was to keep it straightforward so that it was intuitive for people to use but at the same time the more functionality you add to a product, eventually you affect the price. And, from the beginning, Kevin K6TD, and myself we had both thought that there was an opportunity perhaps to turn this into a product. We certainly had enough interest from people locally, independent of whether they were using a FlexRadio or not in having a separate tuning knob. And so, right from the very beginning we were very focused on functionality because we had a particular price in mind that we wanted to be able to hit.

DH1TW: A funny story by the way. A friend of mine, Delta Fox Three Charlie Bravo, he developed his own remote control software for the Yaesu FT-2000 and he also started with the DJ Console. And lately, I think one or two months ago, he wrote me. And he told me, “Hey, do you know anything about this FlexRadio knob? Do you think I can use that in my software?” And I said, “ Yeah, sure.  It’s just opening, you just need a serial port and then you can implement it. And exactly for the same reason he just asked. I don’t need the other 25 knobs. I’m just fine with the main tuning knob and 3 functions. So, yea that’s right, your product the FlexControl is not only used on the FlexRadio Systems, it’s also used now on other platforms. Okay, so, you also had- if I understand this right- from the very early begin a production, a series production in mind. Is that right?

K6TU: Not entirely. The goal from the very beginning was to keep it simple and keep the design so that we could constrain the cost. Both Kevin and I had the experience of running a business out of our garage about 10 years earlier. We had built a business that was selling network time clocks. Now, if you’re familiar with the Internet network time protocol, we had a self-contained appliance that was a GPS receiver and a small microcomputer that provided a stand-alone and TV Strathmore box. And, we had sold a lot of them and eventually that business had got to the point where we were looking at one another going, “So, which of us is going to quit their main job to go run this company?” And, we decided that the market opportunity just wasn’t large enough in order to do that. And so, eventually we wound that business down. So, one of the things that was very clear, we had very much in mind that if there was ever anybody interested in enough of these we would find somebody else to undertake the manufacturing because we weren’t going to do it. Neither of us saw this as a- you know the FlexControl has turned into a great product and sells well. But, as a single product it wasn’t sufficient to build a company. And both K6TD and I have what we call day jobs. So, you know, we had in mind that there was likely going to be interest so we both- Kevin’s actually the VP of Engineering for a very successful company here in Silicon Valley we’ve worked together professionally for very many years and been friends now for a very, very long time. So, it was something we had in the back of our mind and its just kind of a basic disciplined approach to building something which is “Let’s keep it simple” and keep in mind that perhaps this thing winds up with other people wanting it. I think both Kevin and I have had a lot of experience with prototypes that became products. And often, with not very happy results. So we wanted to kind of do basic good engineering practice from the beginning.

DH1TW: Okay, so let’s come back to the Contest-Knob. And, let’s go a little bit inside the knob. What do we find inside? A microcontroller I suppose?

K6TU: Yes, it’s actually a microchip Pic. Microchip has a very wide range of different single chip microcontroller solutions and we chose one that had an integrated USB controller as well as all of the standard peripheral stuff like timers and digital IO pins. So it’s very much intended to be a stand-alone embedded single chip solution system with a shaft encoder. And, basically a crystal, you know, canned crystal oscillator. That’s pretty much the contents of the hardware design.

DH1TW: So when you started developing the software what kind of problems did you encounter? What did you have in mind? Like you collect- you just count the number of impulses from the rotary encoder and you translate that to a CAT command and send it to PowerSDR right?

K6TU: Well, not exactly. So, when we started this, obviously, although there is a USB hardware controller on the chip you actually have to have a software stack that implements the USB protocol layers and so the majority of the software that runs on the pick is actually to deal with the USB interface. We decided from the beginning we didn’t want to tie the knob to a particular CAT stream and there were a lot of reasons for that. And, we had in mind this was a design that could be used on things other than PowerSDR so the basic idea was to have a very simple serial protocol. The USB appearance to the system looks like a standard communications port. And so, we took the approach of using a very simple S Key command stream up and down the PC and the knob that does look like a CAT command insofar as its all in text and is delimited by a semicolon. But at that point it’s really its own basic command stream. So the software that’s on the pick aside from handling the USB interface, obviously it monitors the shafting code or it monitors the switches. It has capabilities- even the original design without the switches, has the LEDs on. So there’s- it’s timing and interrupt driven approach so the USB is all handled under interrupt control and all of the knob functions are handled based on timers.

DH1TW: Okay. And, when you connected the first prototype to PowerSDR what kind of problems did you encounter?

K6TU: Actually, very few. So the, when we started development I bought an off the shelf board that had the same pick processor on it that we were building into the design. And so, the very first prototype of the knob was actually the shaft encoder on a perforated board with a couple of ribbon cables coming out of it to this off the shelf development board. And I had contacted Steve, Kilo Five Fox Radio (K5FR), who is the designer of DDUtil the data decoder utility that is just a complete godsend in terms of doing station integration with the flex. So I had got to know Steve before I started the knob design actually. I had purchased a linear amplified and it was one of the ones that was on Steve’s list of things to support. So I had contacted him saying, “Hey, you know, I’ve got one of these amplifiers on its way. What’s it going to take to do the software support for it?” And Steve was very kind and said, “Well if you’ll help me debug it, I’ll put the software support in.” And so, he did it. And so, the two of us had got to know each other as we were going through that debug cycle of getting this amplifier supported by DDUtil. So when I had started the idea of the know I called Steve up and said, “Hey, what about the idea of putting the PC side support for the knob into DDUtil.”  And so, that’s actually how we started. So Steve was involved with the original protocol design of what messages went backwards and forwards between the knob. And he actually had a different version of a pick development board- fortunately with the same processor on it. So, he built again this kind of ribbon cable approach while Kevin, K6TD, began the stand-alone board development. So the actual software development was pretty straightforward. We had the initial prototype of the ribbon cable version of the knob actually up and working in about 3 weeks. It was very quick. And so, that was the point where Steve started the development of the knob support into DDUtil. So we got all of the software design done and we had the knob working. And, I think from the beginning the idea with DDUtil was DDUtil manages the CAT interface to PowerSDR and over the years Steve has done a lot of work to minimize the amount of commands that go backwards and forwards over the actual PowerSDR CAT port. In common with any radio, the servicing of the CAT stream has limitations to it because the radio has to do all of the other things it’s doing. And so, you really want to make sure that you’re efficient because otherwise what we were really focused on from the beginning was when you stop turning the knob you expect and you demand that the radio stops tuning. And so we really wanted to make sure that there was no lag. And, at the beginning we came very, very close. We had the original knob was actually did not have any lag to it. We basically- whenever we detected a rotation of the shaft encoder we would map that into a step up or a step down command to PowerSDR. But, one of the things that Kevin suggested from the beginning was that we sense acceleration on the knob. So, the idea was that the faster you turn the knob, the radio should tune faster. So, this was a capability I think that was in the ICOM 756 PRO3. Where as you tune, as you turn the knob faster, the radio would rather than tuning it whatever your current step size is, it would move the step size up. And so, I implemented an acceleration algorithm on the knob. And that will turn round to the PC and say, “In the last interval I saw the following number of steps.” And we use that in DDUtil to be able to dynamically resize the step size. And that required multiple CAT commands and that’s when we found ourselves with a cue. So, fortunately, over the years of development of DDUtil, Steve had got to know Bob Tracy who had done the original PowerSDR CAT design. And we were able to get Bob to implement some- two new CAT commands that allowed us to send a single CAT command into PowerSDR that said “Tune a different step size.”  And so, we were really focused from the very beginning on making sure that there was no cue. The whole idea here was: You turn the knob, the radio tunes, you stop tuning, the radio stops. And so, there was a huge amount of effort in terms of the acceleration algorithm, how the CAT commands were mapped in order to be able to do that.

DH1TW: Tell me a little bit more about the acceleration algorithm. In my simple mind, I would just count the amount of impulses over a defined period of time. Then, depending on the amount of impulses DDUtil looks up the corresponding frequency step in a table. So, for example, if we count let’s say 5 impulses within 50 milliseconds our table then might say this corresponds to a step of 10 kilohertz, which then will be sent through DDUtil to PowerSDR. Is that right?

K6TU: Yeah. That’s pretty much it. It is a, it’s a time based algorithm. I mean acceleration is really the rate of change of velocity over time, right? And so, we implemented a very, a very simple integration algorithm on the knob. And then, that’s why I said in the original description the USB is all interrupt driven and everything else is based off of a clock interval. And so, it was very simple to interface to that. One of the challenges of shaft encoders, particularly mechanical ones such as the one that’s used in the FlexControl is being able to effectively debounce the switch contacts. And so, all of that debouncing is done is software. There’s a fair amount of subtlety to it. I wouldn’t say that the code is especially complicated but there was a lot of learning- I mean I have a digital oscilloscope that will also serve as a storage scope. And so I was using that to monitor the contact bounce on the shaft encoder. And so, there were some particular cases where you’d see some pretty complicated bouncing patterns, particularly when the knob was being turned slowly. And so, the actual contact changes when the knob is turned quickly are actually pretty clean. The irony was that when you were tuning the knob very slowly –say, for example, you’re trying to fine tune a CW signal or something like that, so you’re moving the knob very slowly backwards and forwards, that generated some very interesting debounce problems. And so, there was a fair amount of thought that went into, “Okay, so what does the algorithm need to look like in order to be able to make sure that you don’t get false tuning effects?”

DH1TW: Yeah. These are the small but nasty things, which come up during the development. They’re not mentioned in the date sheet and it takes quite a time to first identify them and second to create the proper work around it. During university I worked on a similar project. I created the user interface for a frequency generator. And, after a few tests with various rotary encoders I decided to go with the optical encoders. And because of my experience, they bounced significantly less and therefore provided much cleaner signals. But of course, they were also much more expensive and I only had to create one prototype. But, I still remember the hours spending in front of the digital storage oscilloscope, debugging the systems and adopting the software and microcontroller. Because, under all circumstances what you want to avoid is to upset the user, right?

K6TU: Yeah, very much so. And, the vision that we had from the very beginning was, I think, best described, as we wanted the tuning to be quote-on-quote “silky smooth”. So, we wanted it to be exactly like tuning a regular radio. And, we got there. I mean, it certainly- it was- we got a lot of valuable feedback from folks and I’m actually very happy with how it turned out.

DH1TW: You already mentioned a couple of names: K6TD Kevin, K5FR Steve, and Bob Tracy. Who else was involved in the contest knob or respectively the FlexControl Project, in terms of development, beta testing, and etcetera? K6TU: Sure, so the development was done- so: Kevin, K6TD did the hardware design and actually took care of getting the initial PC boards produced. And then I assembled, well, I guess between Kevin and I; we assembled probably 6 or 8 of the initial boards. They’re surface mount parts so you know, microscope, and a magnifying glass at least and a very fine tipped soldering iron. We didn’t flow- we didn’t heat flow the boards. So, Kevin was responsible for the hardware, I did all of the knob software development and Steve did the integration of the PC side knob support into DDUtil. And so, it was the three of us initially. Steve had got some help from Bob Tracy that was really invaluable. And then, we decided that we would build probably 10 or so beta units. And so, we relayed the board. We had actually sent one of the original prototypes to Lee, W9OY, Whiskey Nine Oscar Yankee, who has an SDR Radio blog. And Lee actually, was the one who came back and said, “Gee, this is really great. But, man, it would be great if there were a couple of switches on it.” And so, I got this feedback from Steve and I groaned and like “Oh no! The next thing someone’s going to want the kitchen sink on this thing.” And so, we agreed that after a lot of discussion between Steve and Lee and myself they convinced me that it would be really great to have 3 switches so that it would be able to control other capabilities. So, the original support I added the three switches- the so-called auxiliary switches. And, the original implementation of them was “Okay so, somebody presses the switch… big deal.” So Steve used that to map different capabilities. So we sent this to Lee and Lee came back with, “Well, gee. This is great but could you implement the same click detection that you did on the shaft encoder so that with each button I could control 3 functions?” And, at that point it was like, “Oh no! The kitchen sink is really coming. I can hear it now.” So, I implemented the single double and long click detection on each of the auxiliary switches so that we had built about 10- I would say more- alpha units this time that were small boxes with a knob, with the 3 LEDs and the 3 switches. And, we had sent those to a number of different folks around the world who had given us really good feedback. I mean, I think by this point there really wasn’t anything that came back that affected the design or the concept. It was just really more comments to Steve in terms of what kinds of capabilities people wanted to be able to adjust using the knob. So, at that point I’d also sent one of the prototypes actually the original green board prototypes to Greg, the VP of Sales and Marketing at FlexRadio. And I said, “Hey, you might be interested in this.” And that was actually what had prompted the original discussion. So that was really the development team, you know. Kind of Lee was there as the initial sort of non development team guinea pig and came back with the switches and then ultimately the click detection for the auxiliary switches as well.

DH1TW: And, well, Kevin and you were both living in the Silicon Valley. And Steve, I think was living in Texas. Lee probably also not on the West Coast. How did you communicate with each other? Through telephone? Did you meet on the air?

K6TU: No, we didn’t meet on the air. In fact, it took a long time before Steve and I even had a QSO. That was the irony of it. I would say that the majority of it was done by email and the occasional Skype or phone call. Lee actually lives in Florida and I’ve never spoken to him. It was all email communication. So, email worked really well for “Here’s the spec, what do you think?” “Hey, this is what I’m seeing.” “What explains this?” So, I think Kevin, Steve and I had a couple of 3 way conference calls but to this day I have never met Steve in person.

DH1TW: Speaking about development tools, since the main FlexControl development team consisted of just Kevin and you, you didn’t have the necessity for any project management tool or centralized repositories, right?

K6TU: No, you’re correct. I mean, we weren’t really working with multiple people on the same code base. So we didn’t use an online repository. The source code is relatively small, in terms of its size. So I would email zip files basically of the project. I used the microchip integrated design environment really as the primary tool and then with a C compiler from Source Boost. So really, that was the development chain of emailing zip files to Kevin and to Steve if they needed to reprogram their particular units.

DH1TW: How long did it take you guys to develop the FlexControl? I mean from the beginning when you took the first time the soldering iron in your hand or respectively wrote the first line of code, to the moment you had done industrial fabricated product in your hand?

K6TU: So, from the very beginning I probably started in early January of 2010. And, by the April by- yeah by mid or late April of 2010 we had the majority of the units built and all of the software was working. Steve had done the integration with DDUtil. We built the alpha unit I would say probably around September or October of 2010 and it was about that time that I actually started the discussion with FlexRadio about whether they would be interested in manufacturing what became the FlexControl. So you know, this was a part time effort. I had actually used the original ribbon cable prototype I think for the RTTY WPX Contest in the early part of 2010. I can’t remember whether the WPX RTTY its either in February or March. So the original design was up and running I would say from the point where I started writing the very first code to having the first working knob was about three weeks. And again, you know this was sort of evenings and weekends kind of work.

DH1TW: Can you estimate the amount of labor, the amount of working hours the whole team put into the FlexControl Project? Just give me a rough estimate.

K6TU: Oh lord. Hundreds. Without any question. I mean, I know Steve spent a huge amount of effort designing the support into PowerSDR then ultimately coming up with the control tab that’s in DDUtil. Laying out printed circuit boards even with an order router is a time consuming thing even on a small board. Yeah, there’s several hundred hours worth of effort went into the design development of this.

DH1TW: That’s what I expected. Sometimes you wouldn’t expect this amount of work just by looking at the product itself. And I also think that sometimes we easily tend to underestimate the amount of work put into such a product.

K6TU: Yeah. Building a product, I mean, you can build one of anything in a few hours in your garage- and I’ve done that many times. But to build a product to the point where it can be manufactured, where it can be tested that it just goes together and works, even something that looks as simple as the FlexControl there’s a lot of design, effort and thought that goes into building a product.

DH1TW: So, after the first prototypes were built up, tested and were working you sent one of the prototypes to Greg, the VP of Marketing and Sales at FlexRadio Systems. By today, the FlexControl is obviously available for purchase as an industrial manufactured product. Tell me, what happened in between. So from the time you approached Greg to the time they shipped the first unit and, what was your involvement?

K6TU: Yes, I had contacted Greg with this idea and said, “Look this is something we had developed” and I had sent him one of the original prototypes and Greg is an active VHF contester himself and he’d wound up using one of the prototypes in a VHF contest. And said, “Oh wow, this really helps on the work flow.” And so, we had gotten into a discussion about whether it made sense for Flex to actually have this as a product. Kevin and I had decided right from the very beginning that we would not manufacture the product. It’s just taking orders, dealing with order fulfillment, projecting how many units you want to build and the whole order cycle of getting parts and boards built and put in to boxes. It was more logistics than we were prepared to undertake. And so, it was one thing for us to build a handful or a dozen prototype units for our own use and for the use of some people we knew had similar requirements but it was a completely different one. So, I had started this discussion with FlexRadio. You know, obviously they have their own development schedule, their own product plans and so on. So part of it was just getting to a point where Flex felt that they had the time and capacity to do this. And so, what we ultimately did was we sent them the schematics and the board layout and one of the guys at Flex- well actually two of the guys at FlexRadio got involved. One did the mechanical design of the box and we actually relayed the board in a different way. Again, primarily with a focus on manufacturability. And so, I worked with them to bring up that third revision- if you will- of the hardware design. And, it was actually, I would say, very much flawless. It’s a very- we had put a lot of effort in the very beginning into making this a very simple hardware design. And so, we never had any issues with any of the boards either, that we built, or, that flex built. They all came up and worked first time. So the process of working with Flex even remotely on the hardware design was actually really good.

DH1TW: Just by curiosity… do you know how many FlexControls have been sold by today?

K6TU: I don’t

DH1TW: Okay.

K6TU: I’ve seen a lot of them. So. But I don’t know what the numbers are.

DH1TW: Yeah. Maybe I should bring Greg here also on the podcast and ask him about the numbers. Okay, Stu, I think we are almost through the interview. I think it was a very fruitful one. And- but tell me, what are your future plans? Do you have any projects you’re working on?

K6TU: Not at the moment. My primary focus at the moment is on operating the contests. We’re right in the middle of the contest season and I wound up taking the role as the contest chairman for the Northern California Contest Club in the middle of this contest year. And so, we’re all just pretty busy keeping focused on competing in contests and operating.

DH1TW: Oh, me too, me too. I am currently preparing the CQ160 Contest and we want to put up a two element vertical array and four beverages for listening. And therefore, I am currently redesigning my beverage distribution box, which allows us to use to listen on the full beverages independently on the 3 lowbands 160, 80, and 40.

K6TU: Yeah. That’s really good. I envy you the space that’s required.

DH1TW: Yeah. That’s right. We are actually very fortunate at the station where I usually operate from Echo Delta One Radio (160m) that’s located in Central Spain about a hundred kilometers north of Madrid. We found an agreement with the farmer, with the owner of the fields close to the station and in winter time we are allowed to put up there all beverages. And, yes, it’s a significant difference listening on the vertical or being able to have full directional beverage system. And yeah, for transmission I am planning to put up a two element vertical array just to get 3dB more towards the United States. So we’ll see, maybe we’ll have a contact in the 160CW Contest. It would be cool.

K6TU: Well, I just got my 160 transmitter antenna back up literally yesterday so I will definitely take a listen for you.

DH1TW: Okay, Stu, where can the listeners find more information about you and your product?

K6TU: Well they can go to- I have a blog, if they look up K6TU through QRZ.com there is a pointer to my blog and there’s a lot of information on a variety of different technical topics on that blog including 3 kind of in-depth pieces on the development and evolution of the Contest-Knob.

DH1TW: Awesome. If they want to get in touch with you, if they have questions, how can they contact you?

K6TU: Then my email address is also available through QRZ.com as well.

DH1TW: Perfect! So, I want to thank you again very, very much, Stu, for coming here onto the show. For sharing your knowledge and, the experiences you made. And if you, my dear listeners, want to know more about the Contest-Knob called the FlexControl stop by at Stu’s blog and if you’re already using the Flex Control maybe drop him a little line to appreciate the time and the effort that he and the team invested into the development. So, thanks again and take care.

K6TU: My pleasure, Tobias.