[This was written a couple years ago, but is archived on a site that I am not maintaining, so I’m duplicating it here as well, to make sure that I have a “living” copy and to put it in the backup stream of this blog.]
When my HP laptop went belly up after four and a half years of heavy use, I replaced it with a MacBook Pro … and thus began my reorientation towards the Mac-side. I made the switch for professional reasons including a desire to have access to a unix command line without needing to run a virtual machine or cygwin on the PC. From that perspective, I am very happy with the Mac, but migrating from Windows to Mac was more difficult in terms of amateur radio-related applications.
My needs are not overwhelming, and I was hoping to find some Mac equivalent for each application that I use. Categorically, I needed programs for logging, contesting and working digital modes. For these purposes, my solutions on the PC were N3FJP’s Amateur Contact Log 3.0, N1MM logger, and MixW, respectively.
It didn’t take me long to realize that the selection of software was much more limited on the Mac side. This is not surprising considering that Macs are relatively expensive and have less market share than PCs. Since many ham software developers are hobbyists, naturally they will develop for the computer that they are using themselves and which would benefit the most users. Don’t get me wrong: the Mac is a well-engineered machine with plenty of horsepower, but even for real time signals processing applications, a cheap PC does the job just as well. I suppose that I could just pick up a used laptop for ham-radio uses, but it just seems more elegant to me to make everything work on the Mac.
For logging on the Mac, there is MacLoggerDx, a very stylish program that has some nice bells and whistles and sells for more than 90 dollars. As such, it’s the most expensive logging program I can recall — likely due to the small market. A major selling point is that it can be extended through Applescript, and there is a community of users contributing scripts. For contesting, I haven’t seen anything on the Mac side that rivals N1MM logger, which has been used for so long by so many people, that it has been honed to a fine edge. For digital modes, some users have developed and shared programs (see several by W7A7 including cocoaModem), but even the most advanced of these suites lack the breadth and stability of their PC counterparts.
After thinking long and hard, my decision was to not abandon the programs that work so well on the PC side, but to run them in a virtual machine. I wasn’t sure this would work, given the need for real-time processing power and external hardware interfacing, but I can attest that this solution is practical. My Mac runs OS X 10.5.5, and for virtualization, I run Windows XP Pro SP3 under Parallels v3.0, with 512 MB memory allocated to the VM. More memory might be nicer, but I can assure you that this minimal configuration works fine. I do not have experience with VMware Fusion, but would guess that it would work in an analogous manner (perhaps someone would like to try this and let me know). As an aside, I have tried running N1MM logger and MixW under CrossOver on both the Mac and Linux platforms, and I could never get that to work entirely. Unlike Parallels and Fusion, CrossOver is not an emulator, but a commercial version of the linux-based wine project.
My goal was to integrate operation of a Kenwood TS-450S and a 2.2 Ghz Intel Core2Duo MacBook Pro. The first issue was one of hardware — how to control the rig from the computer. Previously, I bought a CAT cable on Ebay for around five dollars, and it worked flawlessly for years. The circular DIN connector plugs into the radio, while the other end of the cable, a nine-pin male serial connector (i.e., a DB9 connector) plugs into the computer. That was fine for my old HP laptop which sports an appropriate serial port, but it’s bad news for the MacBook Pro which, like many more recent laptops, entirely lacks serial ports. And this is where the witchcraft begins.
The obvious answer is to buy a USB-to-serial port converter. I picked up the Keyspan USA-19HS adapter (at left) for about thirty dollars on the web. It is a very popular device, and I’m sure it works well for most people’s applications either under MacOS X or Windows, but it turned out to be the wrong choice for trying to combine them. There is a long thread of postings thread of postings on the parallels support page regarding user frustration trying to get this adapter to work from within Parallels. In theory, there should be two mutually exclusive approaches: 1) Mac-centric — install the MacOSX drivers and then start up the virtual machine. Configure the virtual machine to use the “serial port” that it sees in the Mac environment; 2) Windows-center: within the virtual machine, install the Windows drivers for the device. Then, configure parallels to use this USB device. The latter seems cleaner to me, but fails utterly. The adapter comes with a driver disk that includes a nice diagnostic program which indicates that the port is not working under windows. Trying the Mac-based approach worked better. I found an excellent article by Brian Williams on Mac OS X Hints which detailed his experiences trying to do essentially the same thing. He describes a non-commericial program, serialclient, which makes the Mac-side serial port resource available to the VM.
Following the instructions in the Mac OS X Hints webpage, the MacOS X drivers are first installed, then the adapter is plugged in, and Parallels is launched. Briefly, using the configuration screen in parallels, a serial device is created as a socket in server mode and mapped to a file (e.g., /tmp/serial). A windows session is then launched. To actually enable the serial port, the helper application serialclient is then launched on the Mac side, with appropriate parameters for the connected device, as well as the name of the file serving as the “socket” above. Now, when you hit the “connect” button on serialclient, it links the file on the Windows side to the resource on the Mac side. The port is no longer available to OS X, as it has been redirected to Parallels. At this point, Windows should have a virtual serial port (e.g., COM1:) and you can launch your application.
Amazingly, all of the above actually works — but there are some caveats. First, this set up occasionally goes down in flames. I’ve had the laptop freeze up a few times, requiring a hard reset. It should be possible to control the port from within Windows, but it is not. Within a DOS shell, the “mode” command should be able to set COM port parameters, but this is not the case. This set up relies on a non-commercial bit of glue, serialclient, that is not supported, was never intended to be used in a general manner, and which might evaporate without warning or break with subsequent releases of Parallels. The deal-breaker for me, though, was that the DTR line does not function correctly.
Since the Kenwood uses RTS/CTS flowcontrol for its CAT functions and does not make any use of the DTR signal, I figured that I could use DTR for keying the rig, getting two-for-the-price-of-one from this serial port. A number of programs, for example N1MM and MixW can be configured to use DTR to key CW.
To use the DTR line, I built an opto-isolated interface according to this schematic provided by WM2U:
Essentially, a resister, an optoisolator IC and a diode to keep the electrons flowing in the right direction (click on the image at right for detail). I put this board inline, just before the 1/4″ plug that goes into the radio. In my case, since I want to be able to drive the radio from either an external keyer or the computer, it actually feeds into a Y-adapter. The other side of the Y-adapter goes to a K-12 keyer by K1EL and paddles.
The shielded line upstream of the optoisolator taps into the ground (pin 5) and DTR (pin 4) contacts of the CAT interface. I had to scrape away from plastic goop to get to these pins. Some diagrams show this connector from one direction, some from the other, so to be sure about orientation, check for continuity between pin 5 and the connector’s shield (assuming it is playing by the rules). The CAT is now a CAT of two tails — one going to the rig as before, the other going to the KEY port.
I tested this set up from the Mac side using the cocoaPTT program to toggle the DTR line, and it worked fine. However, when I set up parallels as above using serialclient as a conduit between OSX and Windows, the DTR line activated as soon as “connect” was hit. Initially, I thought that this was a Windows-related problem, but this does not appear to be the case. No matter what I did, as soon as I enabled the serial port under Windows, my key went down and stayed down. Not ideal operating procedure.
Finally, I tried replacing the Keyspan USB to serial adapter with one that I ordered from ZLP electronics in the UK. The ZLP device is much simpler, a short piece of wire with USB on one end, and serial on the other, with no indicator lights or other features. The device was shipped without driver software, but this turned out not to be a problem. Having removed all of the keyspan drivers, I loaded up my Parallels VM and booted the virtual Windows XP session. I then plugged in the adapter resulting in a “new device detected” message from Windows. Windows asked if I’d like to let it search Windows Update for an appropriate driver, and I let it do so. Within a few seconds, I had a functional serial port.
The only thing left to do at this point was to configure programs according the radio’s specifications. For the Kenwood 450, the settings are 4800 baud, 8 data bits, no parity, 2 stop bits. Here’s N1MM logger as an example.
The ZLP adapter works without any need for the serialclient program or other kludges, and it does not have any difficultly driving the DTR line correctly. I’ve used this set-up for a couple weeks now in conjunction with a number of Windows-based programs that use the serial port. So far, no problems.
Even with the overhead of running the windows emulation, the MacBook Pro does not come up short on processing power (e.g., I can be following many simultaneous digital mode conversations at once and otherwise multitask without putting a dent in performance). I have experienced no problems in terms of serial port latency or variations in timing of CW due to processor load. I should also mention that as the Mac is entirely encased in aluminum, I’ve had no problems with stray RF emission from the computer itself.
I’m sure I’m going to catch flak from Mac diehards who understandably want to see native applications developed for the Mac platform, but my conclusion is that when it comes to amateur radio applications, the most expedient way to access a wide library of popular and well-tested programs is to teach the Mac to be a PC. Over time, I am hopeful that the best of the ham-related windows applications will be ported to the Mac and that new Mac-native programs will be developed.