The latest WriteLog rig driver for the FlexRadio-6000 series supports their SmartSDR 2.0. Earlier versions of the rig driver can read and control the FlexRadio frequency on SmartSDR 2, but cannot do DAX or DAX IQ. This release restores full functionality to the rig driver. I have obtained the lowest latency of any version of WriteLog and SmartSDR with these lateste versions, and on both transmit and receive streams.
|K2 and K3||Both receiving WWV||zero|
|K2 and Flex||Both receiving WWV||60 msec|
These timings should not be taken to be any more accurate than about +/- 20 msec. Nor should they taken to be a definitive statement of what radios have what latency. Instead, the measurements are the numbers I observed with the setup I have in my own shack. I arrived at my setup taking into account multiple constraints, like, how much hardware I have, how much room I have on my desk, and how much I was willing to pay for software add-ons. Compared with earlier versions of SmartSDR, I am very happy with the above results.
What do the numbers mean? When receiving WWV on both the K2 and K3, the time difference in their recordings was less than 20msec. When talking into the mic with WriteLog routing audio to the K2, the recording of that mic audio in parallel with the recording of the K3’s received audio (tuned to the same frequency) showed a delay of roughly 60msec. Switch the direction, and the delay grew to about 100msec.
Using the K2 as a reference, replace the K3 with the FlexRadio 6500. Record the two of them receiving WWV. The Flex’s recording channel is roughly 60msec behind. Transmit using the K2 while recording the Flex receiver shows about 120msec delay. Reverse the direction, and the delay is about 140msec.
Are these numbers good or bad? Its up to your taste. For my own operating ability, its unlikely I will ever notice the slightly longer delay using the Flex than the K3. A Morse code dot at 25WPM is about 50 msec, which is roughly the extra time delay length.
The rest of the post describes the configuration used to obtain those numbers. There are a lot of configurable items. Some of them can likely be configured better than what I have found and describe here, but this is a record of how I go the numbers above.
The hardware configuration that I used to obtain those latencies looks like this:
The hard-wired connection between the desktop PC and the Flex eliminates any possibility of a router introducing latency. (The licensing technology in SmartSDR 2 requires the Flex “see” the internet. In my configuration described below, neither the Flex nor the SmartSDR sees the internet. I used a different cabling configuration to get SmartSDR 2 installed and the Flex upgraded to its required firmware. And, as far as I can tell, it not necessary that access be continuous. )
The desktop machine has VirtualBox installed and a second Windows 10 instance running in a virtual machine hosts SmartSDR. Both SmartSDR 1.10.16 and 2.0 work in this configuration. The latency numbers I measured of one SmartSDR version versus the other were not significantly different. WriteLog is installed on the desktop, but not the virutal machine. SmartSDR is deployed the other way around. The primary impact of SmartSDR’s absence from the desktop is there are no DAX RX or DAX TX audio devices available for WriteLog’s DAX replacement.
To get WriteLog to route the Flex audio, for both TX and RX, the DAX audio device functionality must be replaced. There are various Virtual Audio Cable software products available, and I am using http://software.muzychenko.net/eng/vac.htm. Why did I run SmartSDR in a virtual machine? I got tired of its DAX audio device cluttering the selection dialogs making everything else I do with audio on the machine more difficult than necessary. I do not claim any performance benefit. However, it is possible that the muzychenko Virtual Audio Cables are at least partially responsible for the lower latency in my most recent measurements. But I have not taken the trouble to do controlled tests to determine that.
All the physical sound devices are on USB. The station microphone is on a dedicated Blue Icicle. The stations headphones are also on USB, an ASUS playback device. The K3S has a built-in audio codec, and a West Mountain Radio RIGblaster Advantage is used to get digital audio to/from the K2.
SmartSDR 2.0.17 is configured with its lowest latency filters.
The WriteLog Sound Board mixer control is configured to route both microphone and receiver audio. I have renamed the K2 RIGblaster sound devices, but the Virtual Audio Cable devices I have left named as Line 1 and Line 5.
WriteLog’s Flex Front Panel right mouse menu, when run in the absence of a SmartSDR installation, offers this additional dialog to route the Flex audio.
I run WriteLog using the above setup, and with its Continuous Recording turned on, with it set for Quad channel recording. I talk into the mic with the Right radio on transmit, then switch WriteLog transmit focus to the Left radio and talk some more. The result of the recording is a .WAV file that can be opened and examined with Audacity. WriteLog arranged for channel Left to be its left receiver, channel Right to be the right receiver, channel 3 to be left audio transmit, and 4 to be right audio transmit.
The orange lines show the delay between WriteLog’s recording of the microphone audio and the corresponding reception of that audio on the other radio. Note that WriteLog’s internal buffering can affect this delay. It is reading 4 separate recording audio streams and laying them down into a single quad-channel recording. It maintains on the order of 10 to 20 msec of buffering to accomplish that mixing, and the time axis alignment is unlikely to repeat from one WriteLog run to the next.
The display is zoomed out to show the channel layout. In order to measure the time difference, I zoomed into an audio artifact of my choice that I could identify on two waveforms. Then I used Audacity to select that interval. The “Length” display at the bottom then reads out the latency directly. Like this:
Audacity indicates the above selection is 128msec in length, which corresponds to the “K2->Flex” table entry, recorded as 120msec above.
The particular Virtual Audio Cable product I used is itself highly configurable. Here is a screenshot of how I had it configured. I note that the “Ms per int” setting was particularly sensitive. Set it higher than 7msec and the audio sounded very, very bad.
To emphasize: your mileage may vary. The latencies I observe with this setup as described are the lowest I have observed on my FlexRadio 6500 and I am very happy with the result.
The latest WriteLog rig driver documentation is unchanged from the previous blog posting.