How my Homebrew SO2V Digital Interface Project ... turned into the Microham Microkeyer MKII

 Searching for SO2V Nirvana

After 27 years QRT, my first home-brew project was a digital interface. At that time my CW was rusty and I wanted to try out PSK to fill a bit of time until my CW could improve.   In addition, I always had a sweet spot in my heart for the diddle-diddle of RTTY.  So an interface of some kind was needed. 

Over time, that interface box project expanded to provide a central switching function for quite a few miscellaneous switching needs including antenna direction, tuner, amp standby as well as housing an external keyer.  Pictures of that project may be found here.   

In the last couple of years, the station configuration has changed quite a bit and most of the interface tasks have been moved to other control units.  Remaining needed functionality is now mostly limited to the digital interface and keying functions alone.

 Solutions and Decisions

Initially I had planned to build a replacement unit based around a keyer chip, a simple opto-isolated and transformer buffered rig interface - and a Atmel AVR to handle the digital display and management functionality.  The PC's Realtek sound card would continue to provide the ADC/DAC functions.

And in working up the basic design for the new interface system, I looked at the market offerings to get ideas. What other features or functions had I not thought of - but that would be a good idea to incorporate into the design.  While having the AVR uP in the system allows for a lot of flexibility for adding functions and features later, I wanted to see what good ideas may be floating around that I had not considered.

One key feature that I had in mind was a digital display showing the WPM speed of the keyer chip.  This is hold-over from my early days in radio where the keyer function to the shack was provided by the Accukeyer.  The Accukeyer's clock fed a frequency counter which was calibrated to provide WPM indication.  I'm not sure why, but I have thought since building the first interface, if I ever "did it again, I would be sure to have the WPM indication."  Call it retro-eye-candy!

While there are a few indirect work-arounds for the WPM indication, the optimal would be to get some underutilized pin reassigned with a clock output that I could scale in the AVR to determine WPM. Simple code change, right? Ha ha ha - none of the 4 guys I talked too thought so... And in the end, none of the keyer chip makers were willing to provide a clock-out signal for the purpose.  , and that got me to looking closer at the advantages of using something like the K1EL Winkey chip.  The AVR could write and read the speed very easily.  And the Winkey has a ton of other features that were attractive including a simple to use interface.

In looking at the other offerings, I especially noticed the Microham Microkeyer MKII - it already had this digital-display of CW speed function as part of it's standard offering.  And that box then became the "standard" to compare my new homebrew design with as I proceeded.

Unfortunately, as I began to understand more about the capabilities of the MKII, I began to appreciate more the simplicity of having the sound-card functionality built into the unit.  To duplicate this in a home brew design, this would require some kind of PC-side USB interface capability and I had no interest in working up a PC driver and control function for the task - it's been 25 years since I wrote code for the PC and was not eager to learn a new IDE for the purpose. Especially considering that the AVR coding would be enough programming work for my appetite.  

As the months dragged on, and the wish-list grew as I found more features of interest, the MKII tended to have all of these functions already incorporated. 

In the end, I abandoned the home-brew project and ordered the MKII from the US distributor. 

 First Impressions

Normally I have not posted equipment "reviews" on the web site - and this is not one of that type.  I wanted to document the MKII and my SO2V experience for two reasons - 1) because most of the information is more geared to the SO2R user environment - there just does not seem to be that much SO2V operation as far as I can tell.

And 2), I am impressed with the refinement of the MKII overall - the box works as advertised and has no significant functional or user problems. I find the latter to be pretty rare as the general complexity of ham gear rises over time.  So it's remarkable and needs to be stated as so.

The MKII arrived a couple of days after ordering, and was nearly plug and play on the shack's XP system and with the Yaesu FT-2000 rig. 

The only problems I had with the installation were related to some errant legacy COM port settings hanging around in the registry - after killing those off with a bit of registry surgery, the PC host software (Microham calls this the ROUTER application) went smoothly and has functioned perfectly. 

There are several configuration settings internal to the MKII. However, the only hardware change required was to enable an internal jumper so that the MKII would source it's power from the prefab cable connection to the rig's 12V output.

NOTE:  The cable is wired to supply power from the FT-2000, however, the manual cautions against this. The reason that Microham cautions against sourcing power from the FT-2000 because the rig's output is 200 mA - and some configurations of the MKII will draw more than this.

The shack PC has a Delta 1010LT and Infrasonic Quartet cards as well as the Realtek motherboard chip as well as a PCI-E serial expansion card and 2 graphics cards.  So I was very pleased to see that the MKII had no compatibility problems with these other cards - everything seems to (so far!!!) coexist very FB.

The MKII has provisions for amp sequencing, preamp switching and an extensive digital voice recording.  As a CW/RTTY op, I don't use the DVR features - and the sequencing capabilities are well handled by the FT2K and the Alpha.  But it's nice to have these functions at hand as future needs may find them very useful.  

 SO2V vs. SO2R

Functionally, the time that the SO2V comes to benefit is when the Q-rate is slowing down in a contest.  As a single VFO station as I had been running, I was always faced with the choice of stopping the run to go and hunt for mults. That of course works fine if you have a bandmap filled with mults - but that's not often the case. Runs seem to come and go - and a good amount of time is spent calling CQ without answer especially on less popular contests where the number of participants may be limited. I always tend to break to S&P too soon and the backward looking Q-rate never looks as impressive as I thought it would be.  My thought was that SO2V was an easy way to pick up the Q-rate - not to mention it looked like a technically cool project and I finally could put my FT-2000 sub RX mods into proper service!

The key benefit of SO2V is 1) it takes advantage of the gear you already have and 2) gives you the flexibility to go S&P hunting while the run station is resting between CQ calls. And that brings us to the major difference between SO2V and SO2R operation.  In a true SO2R station, you ideally want to be able to listen on the S&P rig 100% of the time and you want to be able to work on bands other than the one you are running on with the hopes of catching that brief but productive 10m opening, for example. 

The trouble with this ideal version of SO2R is that a lot of switching, filtering and isolation is involved.  Not to mention dual everything...  I've not given up the thought of running SO2R someday - even at this QTH - because I have an unused feed line and certain combinations of bands would be workable (say, 20m run and 10/15 S&P) - but this would require a 2nd rig that I don't have. 

So it's back to reality here - one amp - one rig - one antenna at any one time.  And that means SO2V - at least near term.  :)

  SO2V at AC0C

Successful implementation in SO2V requires several parts to inter-operate properly.  The rig needs to support an independent VFO function at least on the same band which the FT-2000 does quite well.  The log program needs to understand SO2V - I use N1MM here and it's SO2V integration while somewhat recent, is completely up to the task.  Finally the digital interface needs to supply the two rig VFOs with signals as well as manage the overhead and other tasks.

Some interesting configuration notes include:

• The sub RX 2nd on VFOB does not support RIT, so SO2V with the FT-2000 really requires the "run" function be handled by the main RX under VFOA. However, N1MM resets the RIT after each Q is entered sidestepping the need to manually zero the RIT each time which is great of course.
  
  
• N1MM ties into my antenna system and that allows for automatic direction setting.  The F/B on the antennas here is in the 10-15db range which is about ideal for contesting - I've always thought that fantastically high F/B systems are great for DX work but you tend to miss a lot of off-axis Qs.  A great case in point is the omnidirectional 160m antenna matched with the beverage.  More details on the shack antenna configuration here.
  
  
• N1MM supports both CW and RTTY modes very smoothly (once the MMTTY configuration is completed). Thanks to some of the interface tweaks Dave AA6YQ has made, that task is simpler now than in the past.  I run RTTY under AFSK although a lot of hard core ops will debate for weeks the superiority of FSK.  MMTTY does not need a dedicated COM port for the FSK function when running AFSK.  While the MKII provides a lot of flexibility on establishing virtual COM ports, if you don't' need to use one - don't build one.
  
  
• I typically use dual speakers rather than headphones especially in RTTY operation.  Main run VFO on the left side - and the sub S&P on the right. As long as your head is lined up between the two speakers, it works out pretty well. I just never got used to using headphones and instead prefer to crank up the volume instead.
  
  
• That means there is quite a bit of AF gain tweaking done over time. To minimize the amount of gain riding needed, I have installed a 3-way foot switch with an outboard speaker amp and filter unit.   The center switch controls PTT and is used only for my occasional SSB operation.  The left and right most foot switches mute the other signal when pressed - for example, pushing the left switch mutes the right speaker so I can focus on the left speaker feed.  It's faster than turning the knob and gives my feet something to do other than falling asleep!
  
  
• Even with the foot switch, a lot of AF gain adjustment is still needed in SO2V operation - especially if I'm using the the receiving loop.  Another tweak specific to the FT-2000 which works fantastic is to switch the center knobs of the two AF gain pots with the two DSP shift/contour knobs. The result is that the AF gain controls are easier to use because the swapped knob has a larger diameter. And as an added benefit, frequent adjustments of the DSP width control are less likely to bump the DSP offset because the center control is now smaller.  The best part of this mod is that it's fast, 100% reversible, and does not require any rig surgery!
  
  
• This FT-2000 sub RX has some serious mods which greatly boost it's suitability for contest operation (at least in my opinion) including the 3KHz FT-9000 roofing filter swap and AF spectrum shaping - both of which greatly enhance the pleasure of using the rig in SO2V operation. 
  
  
• The FT-2000 monitor function sounds crisp and fantastic - but it feeds the monitor output to the main RX speaker feed at all times. In SO2V operation, that tends to confuse me a bit - especially if I'm a bit tired. I would prefer to have the monitor function feed lines tied to the respective speaker associated with each VFO. But the rig is not built to work that way it seems. There are number of ways to hard-fix that issue but in the interim, I just use the external monitor output tied to a 3rd speaker located directly in front of me.  In RTTY and PSK operation, the monitor note is subtle and sweet.  I can't say the same for the CW monitor, however (see wish list below).  This is a workable solution for now as my main contesting focus is on RTTY.
  
  
• My standard roofing selection for CW/RTTY modes are to use the Collins 300 hz filter on the 2nd RX - and the AC0C 2.4 KHz roofing filter by Network Sciences on the main RX. 
  
  
• Main RX DSP bandwidth  settings vary with conditions - but typically run 400-1200 hz in RTTY and 200-800 hz in CW. MMTTY bandwidths are really tightned down - 512 taps and 50-80 for width. Of course, each person's operating style will vary.
  
  

Understanding SO2V operation is simple.  N1MM presents you with two identical log windows, reflecting the two VFOs of the rig.  Clicking on each window with a send macro will cause a slight lag as if switching VFOs in SO2V operation as the logger sets up the rig to transmit on the selected VFO. Other than that slight pause, the two windows operate just as you would expect them too.

Now on the other hand, getting the timing of SO2V worked out from a human standpoint is a separate challenge.  In the unassisted operation case, as soon as the run VFO comes off of transmit, you must be tuning the sub VFO to the next station.  I find that it will take about 2-3 transmit iterations before I'm setup on the sub VFO to make a S&P QSO.  The actual time depends on how many of the guys you scan across have already been worked, as well as their sending pattern (some RUN stations don't identify very often which really can drag out operation).

For S&P in the assisted case, you can simply click on the bandmap as a new mult shows up on the screen.  In my personal operation, I run about 50/50 on assisted vs. unassisted.  

Since getting the system functioning, I've run about 1000 Q's with the MKII in the last few CW/RTTY contests.  About 1/3 of those have been on the FT2000's 2nd VFO in S&P mode while the main VFO was calling CQ in run mode. 

Based on the WPX RTTY and ARRL RU earlier this year, I estimate that the SO2V impact on Q-rate in RTTY operation is in the range of 25-50% over a straight run-only with occasional S&P-only operation style.  Of course, individual results will vary - and the improvement will probably be less if your run station is stronger. The higher range of improvement is a reflection of the modest antenna configuration here compared to what I call "full size stations" meaning a nice big tower with 3 elements or better.

 MKII Pros

Stepping back from the SO2V operation and taking a closer look at the MKII interface; there is a lot to like in the MKII beyond it's smooth SO2V operation.  Among the basic functionality of digital interface tasks like providing both AFSK and FSK support, USB sound card integration and the Winkeyer capability, the other MKII features and attributes I like most include:

1. Compatible operation - I've found no hardware or software problems with the box or the host driver called Router.  
   
   
2. LCD display - OK, this clearly falls into the eye candy category, but the MKII provides the CW speed display on-screen.  In RTTY SO2V operation, I prefer to have the TX and RX2 frequency display showing which is one of the many combinations that the configuration supports. Very cool.
   
   
3. No RFI problems - RFI feedback was an occasional problem for me with the old station interface.  This is largely due to the fact that the old interface had little in the way of RFI consideration as it was built in an era where high power 160-6m operation with an attic antenna was not then contemplated.  While I don't think the stock cable clamp will cover every instance, I've yet to find RFI related issues in the shack.
   
   
4. There's that tidy cable assembly - the cost of the cable assembly is significant but well worth the cost considering the challenges of getting all of these I/O lines routed to the huge DB37 on the back of the MKII.  The unit was completely plug and play requiring only an internal jumper to allow the rig's 12v feed to power the MKII. Even the splitter for the sub RX feed and jumper to the MKII box was included. Nice...
   
   
5. Hardware dedicated to the task - the semiconductor complement of the box is pretty serious.  The MKII is built around the Atmel AVR ATmega128 microprocessor.  This chip is in of itself capable of ADC/DAC as well as USB and serial functions.  However, Microham has chosen to use task-specific chips to avoid trade-offs in performance - and that leaves the Atmel AVR free to be optimized for sequencing and control functions.  I believe this is the reason the real-time nature of the box's function is so smooth.  After working on a real-time protection board for my Alpha 76PA, I really am sensitive to this and commend Microham for their choices.
   
   
6. The software host driver called "ROUTER" is versatile - almost all of the MKII characteristics can be set by the Router tray application.  The unit's refinement is really noticeable in the Router utility - for example, the monitor volume can be individually set for digital, CW and DVK functions.  And the various relays are disabled when the sequencing functions are not used - providing silent operation in that case. A built in level meter that samples the built in CODEC level as well as other inputs is a real help in troubleshooting. Very nice. 
   
   
7. Router functions with COM ports over 16. When a system is packed with stuff, juggling COM ports is a challenge. N1MM only supports COM 1-8; and a lot of modern apps stop at 16. Router's virtual COM drivers will work with anything. Let's call this "liberating."
   
   
8. Joe W4TV provides expert level support to his US customers in a style that I would characterize as "east-coast-get-to-the-point." What is exceptional about Joe's work is that he's 1) truly knoweldgable about the Microham products at a level of depth you don't see often - and (here's the really remarkable part) - he tends to provide that same top level of assistance on non-Microham products as well. East-coast or not, Joe is another reason i like the Microham.
    
   
   

  Guts

System topology is given by Microham in this logical block diagram...

The actual hardware implementation does not follow the block diagram exactly.  And it seems to be a bit more complicated.  Some of the chips in the box and what I believe to be their function include:

Atmel ATMega128 microprocessor - controls the unit's functionality and drives the LCD.

Micronas DAC - While it's not clear in the block diagram, I believe this chip provides the DAC side of the USB audio CODEC function.  The AVR is capable of the managing the ADC function for DVK voice recording and for providing the two relatively low sample rate ADC needs for the two waterfall inputs.

K1EL Winkey - The Winkey chip provides CW generation via dedicated hardware instead of relying on the rig's timing.  This is a big benefit in my case as I often have my 3.4 GHz Quad-core Q6600 CPU utilization pretty highly loaded with some configuration combinations and delays do occur.  Keying with the Winkey chip ensures proper CW response as well as full configuration to key characteristics like weighting and dot/dash ratio. 

FTDI FT232RL USB-Serial interface - the FTDI series chips seem to be the overall best choice for ensuring smooth operation with the rig's CAT lines.  N1MM never did like my Belkin adapter but I'm not sure if that was due to the adapter or the problems with the virtual COM port registry entries.  Whatever the actual cause, I do know is that N1MM will sit on top of the MKII interface without error almost perfectly now.  Nothing is more frustrating that having your log program crash in the middle of a SO2V session!

TDA1013B monitor amp driver - at 12v, this unit runs around 1W out max.  Enough volume to drive the monitor speaker in digital mode very nicely. 

All of the USB peripherals to the Atmel uP are tied together by the TI TUSB2036 hub.  And there's an Atmel flash memory chip on board as well.  The AVR has flash storage as well but I would guess the configuration storage is held there.

Rig isolation is handled via opto iso on the control lines and via Bourns transformers on the AF side. See Jack Smith K8ZOA's excellent technical analysis of the transformers used in the MKII HERE.

Interior view of the Microham Microkeyer MKII. 

Click picture to download a high resolution view.

 MKII Wish List

No box is going to be ideal for all applications, and all users.  But the MKII comes closer than most.  Of course, on a web site best known for sometimes esoteric hacks and mods to an otherwise fine FT-2000, I am compelled to find some areas of improvement if for no other reason than to ensure this page fits into the site's general theme!

I don't have any major complaints with the unit and as such consider the few quibbles to be of the "wish-list" variety rather than problems. Some could be properly characterized as nit-pickin'   Regardless of title, these wish list items would include:

1. By far the top of my wish list would be a 3rd (and ideally 4th) CAT virtual connection.  The router software provides 2 CAT connections in it's current evolution - one of these is dedicated to feeding my PowerSDR interface.  The second CAT is fed by N1MM logger in my configuration for contesting.  I also use HRD in non-contest work so it's easy to share the available port with these two applications but they must operate exclusively - if N1MM is in use, HRD must be shut down. 
   
   If an additional CAT were available, I could more easily run (for example) DM780 in parallel with N1MM/RTTY, for example. I think this would be accomplished by a Router version update... [I realize that one can daisy chain N1MM onto the back of HRD via the 3rd party virtual port but that solution is not without it's troublesand considerable compromises...]
   
   This is the one wish-list item that really does matter - and I think many other users would appreciate as well especially as the SDR bandscope options become more and more popular.
   
   
2. The 2m cable assembly is not available from the US distributor although it's available direct from the European factory.  Not available in the US means not by special order - and also not by other special arrangement.  Which means my only option was to order from Slovakia at a pretty good shipping adder overall -in the end, I just bought the 1m length and that's provided workable although I needed to be careful where I positioned the MKII on the shelf.  
    would have preferred to order the longer cable even at a slight added cost simply because shack configurations change and the 1m cable provided requires some attention to locating the rig and the MKII closer than a future layout may accommodate in a sort of future-proofing move... But I can understand Joe's decision not to stock the cable as most guys are probably satisfied with the 1m length normally.
   
   
3. The cabinet trim is very nice overall. Unfortunately, the knobs on the unit don't match the Yaesu family.  That could be addressed by swapping the stock knobs with some Yaesu rig spares pretty easily.  Not a Microham issue - more of a cosmetic preference on my side.
   
   
4. The LCD is a high contrast black on green type - and the rest of the home brew stuff I have is white on blue.  Fortunately, the LCD is configured as a plug-in type and it appears it could be swapped easily with a white/blue type if one preferred.  If this color were available from the factory, that would be even better! For now, the green/black type works fine and does look very nice.
   
   
5. About the closest I have come to finding an actual problem is with monitor leakage into the TX feeds.  In digital mode operation, there seems to be some level of leakage from the monitor line to the TX line feeds. As the monitor level increases, the phantom level in the TX line can be observed to move up.  This results in echo of the transmitted characters in MMTTY (for example).  
   
    The good news is that there is a simple work-around.  Just enable the squelch on MMTTY and set the level high enough to suppress the leakage - it's not a problem for normal operation with MMTTY used this way - because the received signal level is much much greater than the squelched level needed to prevent the echo print.  
   
   
6. While the monitor output in digital modes works great, the CW monitor has a poor keying characteristic due to the hard overshoot on the waveform's trailing edge.  In looking at the keyed waveform with a DSO, the monitor waveform is a sine to triangle shaped suggesting high 3rd harmonic content - but the waveform varies with load.  I think that's probably fine but the attack side of the key has a 100% overshoot and that tends to give the CW monitor tone a harsh thump sound.  
   
   I have not looked at the PCB close enough but this waveform does not look like it's driven directly by AVR as many common side-tone implementations are. But it's possible this could be improved with a firmware tweak in the future. 
   
   The easy external solution to this would be a passive bandpass filter to block the low frequency component (eliminating the overshoot punch sound) and by rolling off the higher frequency harmonics, leaving a more pure fundamental note closer to a sine than a triangle wave. In fact, I looked at a simple 4-pole design and the tone was much nicer although the amplitude a bit too far down for my poor hearing.  Since the issue is really on CW and that's not my primary contest mode, it's workable without any further attention - I will just continue to use the rig's main RX sidetone feed.  
   
   The monitor circuit has reasonable drive capability and with a higher efficiency speaker, the external passive solution would work.  An alternative would be implementing the BPF with a powered op-amp.  Of course, the best place to put this waveform-shaping is on the input side of the monitor amp but that would require surgery to the unit.  And I'm not ready to do that (hardware mods) to this otherwise FB unit - yet. :)
   
   
7. CW sidetone frequency selection - the CW sidetone frequency selection is limited with 675 hz being the only near-typical frequency (other choices are 335, 425 and 1375 hz - quite an odd selection suggesting there may be other constraints to the sidetone frequency selection). 
   
   675 hz is clearly functional for the sidetone purpose - but I prefer to have a sidetone matching the spot frequency so I am continually "training" my ears to be sensitive to the exact spot frequency.  So on the firmware update wish list, I  would add 600/650/700 hz options to cover the range most ops use.
   
   
8. Trim pots vs. digital pots - The unit uses 3 pots internally to set mic related levels.  For a top end unit like this, a more slick implementation would call for the use of digital pots controlled by the Router utility. 

 Summary

The Microham Microkeyer MKII has proven a great addition to the shack. By enabling SO2V, a clear boost in score is achievable which was the primary goal of swapping interfaces.  Future serious contest efforts will greatly benefit from the capability.

And the "creature comfort" design features like the LCD and Router utility make interaction with the box very smooth.  Including my much wanted WPM speed indication! 

While I'm sure there are many excellent alternatives, for the needs here at AC0C, the MKII was the winning pick and with SO2V working well now, I should be able to turn up the heat on some of my good friends who tend to run the race more or less at the same scores as I have had in the past!

 Projects for the Future

1. The only thing that I missing from this configuration is being able to use PowerSDR to click-tune on the sub RX as I can with the main RX.  Tuning time is at it's greatest premium in the SO2V role because all fine-tuning must be done between transmissions.  Click tuning is one way to achieve that.  There will be some limitations on the spread between the main and sub RX in this system but it's going to be worth figuring out because I can typically QSY with a click on a CW or RTTY band scope signal with the result being that it's close enough for the AFC to give me nearly instant copy.  
    looked a the source code for Scott's PowerSDR IF Stage and achieving this is not quite as simple as flipping the main RX cat commands to the sub RX. I'm hopeful that he may have another solution up his sleeve as time allows.
   
   And an interesting new app is from Larry N8LP. His band scope project is interfaced with the FT-2000 via TRX. That may make trying this idea out as easy as tweaking TRX's CAT commands.
   
   
2. The gain distribution of the FT-2000 sub RX is still not quite what I would like to see.  It needs about 6 db more front end gain to overcome the quiescent noise floor where the main RX does not.  Figuring these things out in the FT-2000 is never straight forward so it's a project for the dog days of summer when attic antenna work is hazardous for one's health. 
   
   
3. The world REALLY needs a RTTY Skimmer app that can be driven off my bank of SD Rs...  I've told Alex this is the sure fire path to independent wealth - I don't think he believe me .  :)
   
   
4. Take a look at the monitor switching path in the FT-2000...A possible compromise may be to feed both outputs instead of just the one.  Or perhaps bring the monitor tone feed outside the rig to drive a 3rd speaker.
   
   
5. I've often thought about the same-band limitation of the FT-2000 sub RX.  With the mods made to this sub RX, I'm very happy with it's strong signal handling capability and sound. And the appeal of cross-band operation for SO2V is interesting especially if a lock-out to the amp when the sub is on another band could be addressed.  
   
   With respect to the same band limit, it's not actually a same-ham-band limit; rather you suffer a pretty big attenuation looking at bands outside the main rig's preselector coverage range.  I don't think there is another limitation to true band-independent receive coverage.  And it may be possible to tie in an additional preselector bank that is dedicated to the sub RX and tracks the band it's on.  The trick would be reading the band assignment for the sub RX in order to command the preselector to the proper range.  Unfortunately, most of the I/O to the sub RX is done via serial commands so it's not quite as simple as tying into a pre-decoded band range.  Still, conceptually I think this would work.  As always, the details are where it would get interesting...

73/jeff/ac0c