MDC QSO P 2011

the logo for the Maryland-DC QSO Party "The Fun Contest"Last weekend, National Institutes of Health amateur radio station W3NIH went on the air to participate in the Maryland/DC QSO Party. The event ran on both Saturday and Sunday, plus a break in the middle. It’s been quite a while (as in, years) since the club has participated in a contest, and I had suggested that we try out this local, low pressure contest to gauge interest in this and other on-air activities.

While the club has a couple contesters, most of the members are more casual operators, and not all have experience in operating on HF. Nonetheless, a couple members made their first HF contacts during the event, and perhaps we enticed our one unlicensed guest to get her ticket.

We ended up working from about noon to 6 pm both days, with more phone than cw contacts. I don’t have the log in front of me, but I think we ended up with an estimated score above 20,000 or so. We were somewhat limited in cw because of the WAE contest the same weekend. 20m cw was bristling with European station. When we did go to cw, we tried not to pick bands accessible to EU, but even so, contesters there sniffed us out (yes Germany, Bulgaria, Slovenia, Russia, and Northern Island, I am looking at you). They were no doubt confused to get an exchange of “CLB MON” instead of “599 001”, but at least a couple knew about the QSOP and sent “STD DX”.

The NIH has a reasonably well-equipped station with an excellent antenna farm, mounted on the roof of one of the buildings on the main campus in Bethesda — a spiderbeam, a couple dipoles with broad coverage, a semi-functional GAP challenger vertical, but the radio room is not used frequently. As a contest station, it would take some work to optimize the room for efficient and comfortable operation. We’ll have to see after this event if any appetites have been whetted, and whether W3NIH will ride again in some other contest.

Listing of DX Cluster spots from 3 stations, one in Spain
We were spotted!

Controlling DTR in virtual Windows

[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.

a Kenwood CAT connector cable DIN connectorMy 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.

Keyspan USB to serial (DB9) adapterThe 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.

Homemade optoisolator and one-quarter inch plugAmazingly, 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 the 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.

An extra wire has been soldered to ground and DTR 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.

A close-up image of the optoisolator, diode and resistor interfaceFinally, 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.

adapter from EZP: USB to serial (DB9)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.

And that makes 50

A qsl card to ai4sv from n7mzw confirming a sideband contactI’ve never been overly concerned about collecting QSL cards, but it has bothered me for some time that I had not completed the basic WAS on LOTW because I lacked WV, DE, and WY. Both DE and WV are pretty close in, and I usually skip over them with my vertical antenna. All of these states have relatively small ham populations as well, and it seems like the ones that are there are not really into electronic QSLs. I’ve made more than a few contacts with each of these states, but had no electronic acknowledgement.

Last week, I went through my collection of physical QSL cards and dug up one from WV, but didn’t see any from DE or WY. I decided that while it would be nice to have them all in one place on LOTW, maybe it was time to do things the old fashioned way — so, I searched my log for those two states and shot off real QSL cards. Delaware came almost immediately, and yesterday, one finally came from Wyoming. Thanks N7MZW!

I still have to get these cards officially recognized through some arcane process that I think happens at hamfests, but in my mind, I’ve checked the WAS box.

Arissat1 – First Attempt

a graphic of Arissat1I got up a bit early this morning and parked the car on top of the 6-story NIH garage in Bethesda to catch the 10:45 UTC (06:45 local) pass of Arissat-1. From there, the view North is unobstructed. The max elevation on this pass was 20 degrees, with AOS at azimuth 304 and LOS at 94, almost ten minutes in duration.

I tuned to 145.920 on USB and twirled the RIT back and forth above that frequency because I wasn’t sure how much doppler shift would matter. About a minute and half in, I picked up the CW beacon. I did not hear the bpsk signal as clearly as in this audio file. Here is what I heard this morning: Audio from Arissat-1 attempt #1 from FM19km.

In principal, to decode the BPSK1000 signal, the lower cw beacon should be kept near 500 hz. I tried my best, but after today’s experience, I realized I need something to look at — either some sort of spectrum display or the windows version of the TLM software. I had not played with the software earlier, but hoped that if I kept the signal within the receiver’s bandwidth, the decoding software would be pretty tolerant to centering, and might even track the signal pitch. Well, that is not the case. Maybe I can somehow pitch shift what I’ve captured, but I think the more practical solution is to try again, adjusting pitch live.

I did switch briefly to FM and heard just a couple syllables of speech before it went into SSTV mode and faded to static. In the above audio clip, the first part is USB, and you can easily pick out the CW signal. About halfway through, I switch to FM and you can definitely hear the SSTV, although the signal goes up and down rapidly (changing orientation of the satellite?).

I have to admit, this was something of a last minute effort, but I did remember to throw an audio splitter cable and the computer into the car before taking off to work today. I am not using a special antenna — just my trunk-mounted antenna (1/2 wave on 2m, 3 dBi). Considering that this was all before coffee, I guess I should consider myself lucky to have heard anything at all.

Later in the day, I fired up the Mac version of the TLM software, which seems less developed than the windows version. I tried to import a wave file, and it seemed to hang for quite a while, but them became responsive again. I assume it was trying to decode the bpsk, and having a hard time because the signal is very low in my recording and the frequency is all over the place. Unfortunately, for purposes of troubleshooting, no sample file is available on line, although the Arissat website says one will be posted shortly.

There’s another higher-elevation pass tomorrow at 11:23 Z / 07:23 local, and I’m planning to be set up for it. This time, I would use the PC-based version of the TLM software, which provides a real-time frequency analysis to keep the cw beacon in a narrow-enough window to center the bpsk1000 within the expected bandpass for decoding.

It would be helpful if I could figure out when the satellite is in eclipse, to know when it will be operating in lower power mode. I assume that it’s keps are not very stable, so I’ve just been going to the orbit prediction page.

Addendum: Not sure why the Amsat page just went down this evening (Aug 4th), but there’s another tracker that does a nice job — it shows whether the satellite is in eclipse or not, and if it is likely to be visible. It also provides real time tracking: