construction – Page 6

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.

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.

Honey, I blew up the amplifier

Actually, let’s start on a bright note, and then we’ll get to the part involving smoke.

Inside view of the rockmite 40 installed in a mity box — The Rockmite 40

My main reason to build the amplifier was to get a bit more power out of the rockmite. Part of the problem in getting the amp working was also likely low driving power. The basic design of the rockmite uses the prototypical bipolar NPN for the “final” amplification — a 2N2222. There are variants that use other transistors and get the power above a watt, and there are also some tricks to increase the drive, but the stock rockmite should yield a nominal half watt or so with no mods. So, I took off the cover of the rockmite and poked around, checking all the part values. I had already made one substitution: C8 was decreased in value from 0.1 uF to 0.01 uF to knock the side tone volume level down to something tolerable.

Sure enough, I saw the problem — I had used 47 pF (marked 47J) instead of 470 pF (marked 471) for C15 and C17, which are on the output side. Yes, the “1” and the “J” looked similar. I stuck the right value capacitors in, and power output using a 13.2V supply was 550 m. Not too bad.

Next, I plugged the RM into the Texas Topper. I didn’t power it right away, though, because I was interested to see what sort of insertional loss the Texas Topper introduced when it was not active. Power output was about 400 mW. This probably wasn’t an entirely fair test because the Tx Topper was still on the bench top, with tack-soldered connections to the BNC connectors.

Texas Topper Partially Installed — Texas Topper before final install

I removed the extra N4148 from the amplifier, because I figured it probably had enough drive now to work without extra bias. Power output was measured as 2.2W, so about 6dB gain. While I could live with that (and, in retrospect should have), I was curious what would happen if I bumped the bias back up a bit. The N4148 went back in, raising the bias voltage from about 2.05 to 2.75V. Power output was now 7.7W — 11dB gain. I measured roughly 7Vpp in, 20Vpp out, so roughly in agreement. Part of the increase in gain might also have been due to switching from using alligator clips to apply power to using a thicker wire terminated on one end with a power pole connector and on the other end with a type N coaxial plug.

So, at this point, I was actually (hah) thinking of introducing a one or two dB attenuation pad, although the idea of burning off power in a QRP rig feels inelegant. More inelegant, however, was trying to bend the FET forward so the heat sink would fit in the enclosure. When I pushed it forward (yes, with power applied), there was a bit of sizzle and then a bright flash from the LED. I don’t know if something arced before the LED toasted, but I was left with the acrid and no doubt carcinogenic aftertaste of stupidity wafting through the shack.

I inspected the board around the FET and couldn’t see an obvious short. The parts in that area do share some close quarters, and the heat sink is right next to both transformer coils. I took out the LED (shorted now) and yanked the FET. Good thing I had a bag of them on hand….as will soon be even more evident.

With a new FET, a new LED (not quite the same type, but close), and another diode, I was back in business. Everything was fine until I tried to stuff the heat sink into the enclosure. This time, not under power. The problem is, though, at some point, you have to apply power, or the whole thing is just a paperweight. Zot. Sizzle. Flash. Puff.

Yeah. So, at this point, I’m out of FETs and thinking that maybe I need to do something more creative regarding the strained relations between the heat sink and the enclosure. The heat sink should be applied right to the metal tab on the FET, which is the drain. The case is aluminum, and at ground potential, so that particular twain shouldn’t meet.

I tend to only order from Mouser when I get enough items on my “want” list to make the shipping work out, so it might be a bit before I replace the burnt out components, but I’m sure I will in the next couple weeks. The board has held up very well to my repeated soldering/unsoldering, and I really don’t have any complaints about the Texas Topper per se. This is more a mechanical issue at this point — all the electronic bits seem to do a fine job of amplifying. I may, in fact, order another one just to play on another band.

Even without the Texas Topper, doubling the output of the Rockmite should make it more usable. I’m looking forward to rolling both it and the TenTec 1320 out next week for the QRP to the Field Event.

Texas Topper QRP Amplifier

I seem to be doing well enough running the Kenwood B2000 at 5W or the TenTec 1320 at around 4 watts, but I haven’t made many contacts with my Rockmite, which on a good day puts out around 250+ mW, but less when the battery runs down a bit. A while back, I had ordered the Texas Topper (a.k.a. Tuna Topper) amplifier (nominally 5W out) from www.QRPme.com. For $25 it’s a good deal. The design lends itself to flexibility and experimentation, allowing the user to choose whether to use onboard/offboard options, a tuna-shaped round or altoids-shaped rectangular form factor, a range of input powers (using fixed or variable attenuator, if necessary), fast/slow switching, and transceiver or xmtr/rcvr configuration.

I put the kit together last week, made an enclosure, stuck it in, connected everything up, and … nothing. Well, not quite nothing. My WM-2 wattmeter read about 50mW output. Not good — the amplifier was doing something, but not in the direction that I had hoped.

The amplifier is well-documented on Chuck Carpenter’s website, which provides a parts list, pictures of the board, schematics and helpful advice. From the circuit diagram, it’s apparent that there are two halves to the pc board — one that controls switching through a relay, and the business end of the amplifier that centers on a MOSFET followed by a filter network. As far as I could tell, nothing was shorted. In the “receive” state, signals fed straight through from input to output connectors. When I keyed down the rockmite, I could hear the relay click in, and I was able to verify that the input signal was being appropriately routed over to a 4:1 transformer to feed to the MOSFET.

I checked DC voltages with a DVM, and verified that the bias voltage (determined by the forward voltage drop across an LED that conveniently also serves to let you know power is applied) was 2.05V. The voltage on the MOSFET’s metal tab (the drain) was about the same as battery voltage, as it should be. Unfortunately, I didn’t have an RF probe on hand for tracing of RF voltages — the probe was lost in the last move. It would be easy enough to build one (see nice plans on W5ESE‘s site), but I didn’t have a suitable diode on hand and apparently Radio Shack no longer carries the 1N34 in stock. No problem — I have something better, although not quite as portable: an oscilloscope.

The incoming signal was about 8Vpp, and 4Vpp after the 4:1 input transformer. I expected to detect something on the drain of the MOSFET, but all I got was hum (maybe just background). Probing beyond the MOSFET, I didn’t get much. I was stumped at this point, and starting wondering if I had done something wrong during construction.

It seemed to me that there were two likely places that I could have screwed up — in winding the two bifilar transformers (which, I recall I did while watching an episode of “No Ordinary Family”, so maybe I was distracted), or maybe in installing the MOSFET. I had placed a mouser order at the same time as the kit order, so I had a couple extra MOSFETs to play with. Using static-free everything (mat, wrist band, soldering tip, etc) and low heat, I replaced the MOSFET. No change. The kit comes with 22 and 26 gauge red magnet wire for winding toroids. To be extra careful, when I rewound the two bifilar transformers, I used on strand of red, and a strand of another color. Radio Shack does carry a magnet wire set, which conveniently includes 22, 26 and 30 Ga lacquered wire, and the 22 is gold and the 26 is green. The transformers look much better when wound with two color wire, and it’s easy to verify at a glance that the correct wires are tied together and that they all end up where they should. Again, though, no change.

I tried replacing the MOSFET one more time, as I thought that perhaps I had not had the right load on the amplifier when I tested it the first time, but again, no change.

After I looked at the data sheet for the FET and noted that the gate threshold voltage is listed as a minimum of 2v and max of 4v. The transfer function graph showed the drain current picking up sharply above 4v. My rockmite has lower output than most, and it occurred to me that I might be at the lower end of this amplifier’s design — not enough umph to drive the FET’s gate. To up the bias voltage, I stuck a 1N4148 diode between the stock LED and ground. This bumped the bias from about 2V up to 2.75V. Result: 1.5W output. On the oscilloscope, the waveform was a bit distorted on the FET’s drain, but smoothed out in the filter and was well formed at output. Going from 250 mW to 1.5W is somewhere around 7dB gain — not quite the 10 dB gain typical for this amp, but a huge improvement over my rockmite’s usual output.

So, now I am playing around a little to see what happens when I run this system with a fully charged battery and play a bit with the bias voltage. Hopefully, I’ll have a chance to try out the rockmite-on-steroids this weekend.