How to set up OS X to run multiple HPSDRs

How to set up OS X to run multiple HPSDRs

by w3sz 9/14/2009 [updated 7-1-2012]

Twin Apple LED Cinema displays showing 6 SDR GUIs. The 6 SDRs are simultaneously receiving the 6 W3CCX Beacons transmitting on 50-903 MHz

One of my interests in Amateur Radio is designing and implementing single-user multiband contest station setups. My specific area of interest is in systems for the VHF/UHF/microwave contests, covering the Amateur bands from 50 MHz through 24 GHz, inclusive. I want to be able to run multiple software defined radios [SDRs] from a single computer, using the same screen/keyboard/mouse and also the same microphone/footswitch/speaker for all of them. The goal is to have individual, always-on bandscopes that simultaneously view the 50, 144, 222, 432, and 1296 MHz bands, as well as a selected microwave band on a sixth SDR that covers 903 MHz and each of the bands 2.3 through 24 GHz inclusive, and to have the "radio be the bandscope". This minimizes the operational complexity of the system, by allowing the operator to instantly switch the "active radio" frequency to be that frequency on which an interesting signal has been spotted, on any one of the six "bands", by clicking on the appropriate radio/bandscope. Also, I want all six SDRs to appear as a single radio to the N1MM logging program, and for N1MM to automatically select the correct SDR when the operator switches bands within the N1MM program.

The paradigm is to have 6 radio GUI-bandscopes, one for each "band" as defined above. There are two ways for the operator to select which band is active. The first way of selecting a band for operation is by mouse-clicking on the GUI-bandscope for a given band. This action will, if the software is operating in the automatic mode, cause the selected footswitch, microphone, and CW key to be assigned to that band/radio, and cause N1MM to switch logging to that band. The second way of activating a given band is by typing a frequency into N1MM (e.g. 144200). That will cause the SDR covering that band to automatically get the "focus" and thus take possession of the selected footswitch, microphone, and CW key. For the operator using N1MM, the experience is that of having a single radio with always-on bandscopes for all of the bands [as defined above] that covers every band from 50 MHz through 24 GHz, inclusive.

The server, or computer that displays all of the GUIs and provides switching of the input devices [footswitches, microphone, and key] to the appropriate band [radio] is an Apple Mac Pro Dual Quad Core running OS X (currently version 10.7, Lion). It uses two Cinema LED displays. The image above shows it running 6 PowerSDR GUIs simultaneously as well as the RadioManager radio input device control software, the Audio Controller audio routing software, and a TCP server application that allows N1MM on another computer to control which radio has focus, and to send CAT commands to the radio that has focus. RadioManager, Audio Controller, and the TCP server are simple applications that I wrote. They are rudimentary, but adequately perform the tasks required.

The Mac TCP server application GUI up close looks like this:

Below is a close up of the two Mac apps, RadioManager and AudioController. The Radio Manager is on the left and the Audio Controller is on the right. They are both in automatic mode. The Radio Manager also has a radio button to activate or deactivate a network link telling N1MM which SDR has the "focus" on the Mac Pro.

The hardware/software hierarchy at present is as follows:

Radio Server: Mac Pro Dual Quad Core running OS X 10.7

RadioManager [X-Core/Applescript application] running on Radio Server to control assignment of footswitches, microphone, and CW key to proper radio

Audio Controller [X-Core/Applescript application] running on Radio Server to control assignment of receive audio from the six radios to any one of 3 stereo audio outputs

JavaVNC clients running on RadioServer to connect each SDR to the Radio Server. Works with VNC servers running on each SDR

A Visual Basic Program running on the N1MM logging computer that communicates using the Kenwood CAT protocol with each of the SDRs and with N1MM, so that N1MM thinks it is talking to one radio that covers 50 MHz through 24 GHz, and the CAT control of each radio receives commands from N1MM only when the band that radio covers is selected, either through N1MM or by clicking on that radio's GUI on the Mac Pro Radio Server.

A TCP Server running on the Mac Pro Radio Server that receives information from the N1MM computer Visual Basic program telling it which band is selected in N1MM, so that it can give the appropriate SDR the "focus" on the Mac Pro, thus giving that radio the selected footswitch, microphone, CW key, and receive audio, and directing CAT commands from N1MM to that SDR.

PowerSDR software running on each SDR to control that SDR. Different versions of PowerSDR are used for the Flex 5000 and the HPSDR SDRs. For the Flex 5000, PowerSDR can be downloaded from http://www.flex-radio.com/Default.aspx . For the HPSDR radios, PowerSDR can be obtained from http://svn.tapr.org/repos_sdr_windows/ , although I run my own "improved" version of PowerSDR. Or, you can look here for an overview of the available HPSDR software

50 MHz SDR: Flex 5000 with PowerSDR running on a 3.2 GHz Pentium 4

144 MHz SDR: Elecraft K3 with an HPSDR bandscope and PowerSDR running on a 3.1 GHz Core 2 Duo

222 MHz SDR: HPSDR Atlas/Ozy/Penelope/Mercury stack and PowerSDR running on a 3.1 GHz Core 2 Duo

432 MHz SDR: HPSDR Atlas/Ozy/Penelope/Mercury stack and PowerSDR running on a 3.1 GHz Core 2 Duo

1296 MHz SDR: HPSDR Atlas/Ozy/Penelope/Mercury stack and PowerSDR running on a 3.1 GHz Core 2 Duo

903 MHz and 2.3-24 GHz SDR: HPSDR Atlas/Ozy/Penelope/Mercury stack and PowerSDR running on a 3.1 GHz Core 2 Duo

The individual SDRs are linked to the Radio Server using a Gigabit Ethernet switch, and both the server and all of the SDRs are running Gigabit links with jumbo frames capability.

The Radio Server and the RadioManager application use a Parallax Propeller USB Proto Board running a custom Spin application to set the assignment of the footswitch, microphone, and if necessary CW key to the appropriate SDR. The Propeller Spin application was written on the Mac Pro using the excellent BST Multiplatform Propeller Tool Suite . A USB 2.0 connection is used between the Radio Server and the Parallax Propeller. Serial communications over the USB port is courtesy of SerialPort X by Art Coughlin. SerialPort X.osax must be copied into one of two directories: either Macintosh HD/Library/ScriptingAdditions/ or ~/Library/ScriptingAdditions/ where ~/ is your home folder [for me it is 73w3sz].

Each of 28 Propeller outputs drives, through a 22K resistor, a 2N2222a which controls a G6L-1P-DC12 relay that provides the necessary switching between the radios of the left and right footswitches, microphone, and CW key [4 banks of 7 outputs each, to connect Left Footswitch, Right Footswitch, Microphone, and CW Key each to one of the 7 radios]. A single small printed circuit board from Express PCB is used for each bank of 7 outputs. The ExpressPCB PCB file for the RadioManager boards is here. The ExpressPCB schematic file for the RadioManager boards is here.

I made the audio control interface a separate application. This separate X Core/Applescript application controls the [stereo] audio outputs of the 6 radios. The paradigm is similar to the above; the X Core AudioControl application controls, via USB, a Parallax USB Propeller Proto Board running a custom Spin application which drives, through 22K resistors, 2N2222a transistors that control 3 banks of 7 G5V-2-H1-DC12 DPDT 12VDC relays each, so that I can switch each of the 6 radios to any one of 3 audio output ports. There is one "extra" relay bank available for expansion to 7 radios. The Express PCB boards used for this task are similar to, but not identical to, those used for the input device switching described above. As with the RadioManager, switching can be manual or follow the focus of the mouse. Each of the three audio channels can be independently muted, as well. The ExpressPCB PCB file for the Audio Controller boards is here. The ExpressPCB schematic file for the Audio Controller boards is here.

To initiate a session, each SDR and its associated computer is powered up and PowerSDR is started on that machine. Next a Unix script is run on Radio Server to initiate the connection between the Radio Server and one of the SDRs. This script starts the JavaVNC instance for that SDR and calls an Applescript application that obtains and saves the Apple OS Process ID [ProcID] for that instance of Java VNC. This ProcID is used by the RadioManager X-Core AppleScript application to provide automatic switching of the footswitch, microphone, and CW key to the SDR that has the focus. A separate Unix script is used to start each SDR JavaVNC session. I found this [using a separate script to start each Java VNC session] necessary to get proper assignment of the ProcID to the desired SDR GUI. Next RadioManager is started. Finally, the AudioControl X-Core AppleScript application "Audio Controller" is started. Each of the applications running on the Mac Pro has been updated to work properly with OS X Lion and XCode 4.1. The CAT control of each SDR is connected by a TCP virtual com port (com0com) to the Visual Basic interface program running on the N1MM logging computer. A TCP server program running on the Mac Pro keeps track of which radio has focus based on the frequency selected in N1MM.

My writing of all of this makes it seem complicated. But it is actually a very simple system. As usual, a picture is worth a thousand words, and demonstrates its simplicity.

Below is the layout of the controller with the 2 Parallax Propellers at the top and the 4 RadioManager boards with small beige relays, and the 3 Audio Controller boards with the larger black relays. The ExpressPCB PCB file for the RadioManager boards is here. The ExpressPCB PCB file for the Audio Controller boards is here. The ExpressPCB schematic file for the RadioManager boards is here. The ExpressPCB schematic file for the Audio Controller boards is here.

Below is how the Controller looks when completely wired.

Below is a front view of the finished product.

Below is a view of the rear panel.

Below is a picture of the SDR controller and five of the six computers with their associated HPSDR units. The sixth computer is off-screen and controls the Flex 5000.

Below is the W3SZ operating position as of February, 2012.

In the cell phone picture of my operating position above, on the left is one of the two Apple Cinema Display screens displaying 3 of the SDR GUIs and the control software, all running on the Mac Pro. Between the two Cinema Displays are the N1MM logging computer screen and the Elecraft K3. To the right is the second Apple Cinema Display, showing the remaining 3 SDR GUIs running on the Mac Pro. The Radio Manager application running on the Mac Pro is networked via a TCP client to the N1MM computer, so that band information is sent to the logging computer/program [and N1MM] whenever an SDR GUI has its focus activated by clicking on it with the mouse. In this way, band information is automatically entered into N1MM when an SDR is activated by mouse-clicking on its GUI, so no manual band or frequency entry to N1MM is necessary. The code for this TCP client application is here. The code for the Visual Basic TCP server application that runs on the N1MM computer to link N1MM to the SDR Server is here. One can also operate primarily from the N1MM entry window and select frequencies by typing them into the N1MM entry window. Doing this will cause the appropriate SDR to be selected and given focus on the Mac Pro. In this case one does not need to click on the individual SDR GUI on the Mac Pro to give that SDR focus; typing its frequency into N1MM accomplishes that. In every case, whether "running the bands" by clicking sequentially on each SDR GUI on the Mac Pro Radio Server, or by typing the bands/frequencies sequentially into the N1MM entry window, the desired footswitch, microphone, and CW key will be switched automatically to the appropriate SDR as one runs through the bands from 50 MHz through 24 GHz, and N1MM will direct its CAT commands to the appropriate SDR. Whatever method of operation is chosen, the correct N1MM logger "band", the appropriate SDR, and the appropriate footswitch, microphone and CW key are automatically chosen.

Another view of the operating position is below.

This is another cell phone picture, taken from the left and behind the operating position. Visible are the two Apple Cinema Display screens showing the 6 SDRs and the control software, and the computer screen running the N1MM logging program and the K3 between the two Cinema Display screens. The K3 is used only on 144 MHz and its PowerSDR GUI is on the leftmost screen, at the top right. I originally used the K3 for 144 MHz because of concern about the performance of the SDRs on 144 MHz with its multiple very strong signals. That concern was unfounded, but I have kept the K3. The screen on the very right is the Linrad computer screen; Linrad provides an extremely high-sensitivity waterfall that will detect signals whose strength places them below audibility. Occasionally, a signal will only be visible on this waterfall and not on the HPSDR waterfalls, and my software will send the frequency of such a signal from Linrad to the SDR, placing it in the center of the HPSDR passband.

In Early 2012 I decided to change my logging program from WriteLog to N1MM, in part because WriteLog has limited facilities for using external databases to "pre-fill" the grid-square locations (and other station data) of stations placed in the entry field. So I had to rewrite the Visual Basic program that previously interfaced with WriteLog, to interface with N1MM. The code for the N1MM Visual Basic TCP server application that runs on the N1MM computer, is here. As noted above, this program links N1MM to the SDR Server and to the individual SDRs, and also links the microwave SDRs to Linrad so I can 'spot' very weak stations on Linrad in the unlikely event that they don't show up on the PowerSDR display and then just hit a key and put those signals into the passband of the appropriate SDR. This program is designed so that N1MM sees all of the SDRs as a single radio covering 50 MHz through 24 GHz. The Visual Basic interface program exchanges CAT information with all of the SDRs, and combines the 50 MHz, 144 MHz, 222 MHz, 432 MHz, 1296 MHz SDRs and the "Giga SDR" [which covers 903 MHz and 2,3,5,10, and 24 GHz] into one radio for N1MM. Thus for all bands logging of frequency, mode, and time information is automatic, and the operator only needs to enter the callsign and grid for each exchange. N1MM is operated in "SO1R" mode, although it is actually running as "SO6R", thanks to the capabilities of the Visual Basic interface program.

A screen grab of the N1MM computer set up for contest operation is below. The Visual Basic Interface program is at the upper left of the screen. The other windows are all N1MM windows:

A short paper that I gave at the combined PackRats/NEWS Group VHF and up conference in October, 2012 that explains why all of this is important is here.

Finally, below is a screen capture of the old setup on the logging computer, showing WriteLog on the right, and on the left from top to bottom a homebrew rotor interface program, the TCP server application to connect WriteLog to the SDR Controller computer, a Sked Clock by W3KM, and WinGrid, by W4SM. This is how the computer used to be set up for contest operation. The rig interface program shows the frequency received from the Mac SDR Controller [144200], the current WriteLog frequency for the "right" radio [144200; this should always be the same as the value for the frequency received from the Mac], and on the left the frequency for the "left" radio, the 2.4 GHz through 24 GHz SDR. This radio's frequency is connected by a networked virtual serial port to WriteLog, and its frequency can be set either by the SDR GUI on the Mac or by WriteLog. Any change made to the frequency by the SDR GUI will be immediately noted by WriteLog, and vice versa. The new N1MM arrangement is a vast improvement over this earlier design.

Brought to you by the folks at W3SZ