Ham radio remote operations latency measurements

Introduction

There are ham operations that a remote operator needs to carry out that do not require real-time speed. Examples are switching antennas, adjusting radio parameters, fiddling with amplifier settings, and others. The one action that is most time-critical is when the operator responds to an on-the-air signal. If that does not happen quickly, time is lost by repeats, others getting to make that QSO first, or the QSO is not happening at all. That is theoretically true for both local and remote operations, but most critical for success while operating contests remotely.

I have participated in contests for a long time. I am just getting started with remote contesting and noticed a subjective increase in doubling. It happens more often that I am trying to respond to a caller and we both transmit at the same time. It seems I waited too long. The reason is obvious: there is some delay in my setup that puts my signal on the air later and the other station has already started transmitting again.

When breaking down this delay further, it seems the 2 most crucial components that affect this overall are:

  • The time of the RX audio to reach the control operator’s ears, and
  • The time of the control operator’s action (keyboard stroke) to key the transmitter.

I will call the components “RX audio latency” and “keyboard latency”.

My goal is to the measure the delay of each properly and compare alternative solutions.

Receive audio latency test setup

In these tests, I am comparing two receivers. To establish a baseline, I first use 2 local receivers and later I use one local and one remote receiver.

Both receivers are tuned into the same strong station. The ear will already confirm that there is a time difference of the received signals. It is easier to detect with strong stations that transmit at a certain interval. For this purpose, I used WWV.

Figure 1 RX audio latency test setup

Both receivers’ audio (one direct and one coming from the remote) will be fed into its own sound card microphone jack. Both sound cards are the same. As we are only interested in the difference of the latency, using similar sound cards and measuring the delay between both audio channels will be sufficient. The right picture shows how to connect if you have the 2 audio signals coming from local hardware. I used this setup when both receivers are sitting on the same work bench. There are other scenarios to measure, where the audio arrives from the remote location. In that case I used a 3.5mm jumper cable to feed the remote audio into the microphone input (I did not find a better solution. Since the audio in this case comes from the remote, I must convert it from a playback to a recording device)

Figure 2 Sound card connections

It’s easy to record a stereo signal and measure the delay between left and right channels with the open-source tool Audacity. In order to get the signals mixed this way I choose Voicemeeter Banana.

In Audacity, chose the output of the B1 channel of VoiceMeeter as the input, and chose stereo. Then record the input and when you see a good signal that can be measured, stop the recording (1, 2). Use the mouse to drag a selection from the signal’s start in the left channel to the start in the right channel (3). The program then shows the time of the interval, which is the latency we want to measure (4). In the example screen shot it shows 96ms, which is the delay of the audio the Flex 6600M adds with medium-sharp filter settings.

Figure 3 Audacity

RX audio latency measurements

Audio 1 sourceAudio 2 sourceMeasured delay
Local K2, speaker output jackLocal Flex 6600M, speaker output jack, lowest filter sharpness setting48ms
SameLocal Flex 6600M, speaker output jack, highest filter sharpness setting160ms
SameLocal Flex 6600M, speaker output jack, medium filter sharpness setting96ms
SameLocal Flex 6600M (medium filter), SmartSDR with PCAudio, network latency < 1ms572ms
SameRemote Flex 6600 (medium filter), local SmartSDR via SmartLink with PCAudio, network latency 45ms721ms
SameRemote Flex 6600 (medium filter), remote SmartSDR with PCAudio and audio via AnyDesk, network latency 45ms1035ms
SameRemote Flex 6600 (medium filter), local SmartSDR via SmartLink no PCAudio, audio via mumble/murmur audio server, network latency 45ms, mumble/murmur both running on Windows396ms
SameSame as previous but mumble on non-Windows OS (RPI, etc.)not tested
SameSame as previous but using RemoteRigNot tested, estimated to be around 221ms (see below)
   

Notes:

  • Any software tools used here add latency on their own. I have not tested the audio latency of VoiceMeeter Banana, the sound cards or Audacity. However, since I route both channels through the same components, the added latency will be in both channel’s latency. Measuring the difference of both channels spectrum should cancel them all out.
  • A good solution I found is using a PC gaming audio server/client tool called murmur/mumble. The tool is designed for low latency.  It is a software only solution.
  • The 396ms measurement for the lowest latency does include the 96ms for the SDR filtering. A traditional, non-SDR radio using mumble would therefore measure close to 300ms latency.
  • Window’s audio chain is known to have latency. I am not sure if running murmur or mumble on small dedicated non-Windows-based computers would decrease the latency more, but it would be a good test.
  • A RemoteRig is not physically available to test. RemoteRig is advertised to be designed for low latency and may not have the overhead of the Windows operating system. The information gathered from RemoteRig support is this:
    • If you use the default setting packet size = 20ms and jitterbuffer delay = 3, the latency will be 20ms to sample the first packet +45ms your internet latency +3 x 20= 60 ms buffering = 125ms
  • I have to add the 96ms Flex filter latency to really compare the same things. Total would be around 221ms.

To summarize, using a radio without any filter latency the RX latency is 125ms with RemoteRig and 300ms with murmur/mumble server.
Using A Flex with medium filter latency (adds 96ms), the RX latency is 221ms with RemoteRig, 396ms with murmur/mumble server and 721ms with SmartSDR/PC audio.
All numbers include a 45ms network latency.

Keyboard latency

The question I tried to answer was: How much is added to the delay because of the operator is not close to the radio and therefore any keyboard action will take some time to reach the radio.

Figure 4 keyboard latency test setup

I put Meinberg NTP time sync software onto both computers. I also used https://time.is/ to verify that the time was close to exact. Then I added a small AutoHotKey script on the users PC that logs the timestamp of when the Enter key is hit.

Enter::

{          

    OutputDebug, key was hit at %A_Min%.%A_Sec%.%A_MSec%

    Send {Enter}

    return

}

Next, I wrote a small FlexAPI-based Windows Forms app that shows the exact time when the FlexRadio is being put into transmit (Radio.MOX property).

Keyboard latency measurement (Anydesk, remote N1MM+)

When I compared these timings, the difference was around 50 – 60ms. Considering a 45ms network latency (and a 0ms setting for PTT lead time in N1MM+), that is a very good result. It turns out that AnyDesk has implemented this very well.

This result is so good, that I did not measure how long it would take with N1MM+ close to the control operator position, but I assume it would be similar.

Appendix

VoiceMeter Banana setup

Figure 5 VoiceMeeter Banana

In the screen shot you can see that my inputs 1 and 2 are coming from the 2 sound cards. In order to route the inputs to the proper output chose B1 and B2 for both inputs (1, 2). To get radio 1’s left channel and radio 2’s right channels mixed into the output, I adjusted the balance of the inputs appropriately (3, 4).

Optimal murmur/mumble setup

For setup instructions, follow: https://www.youtube.com/watch?v=DBfyQRvOmag

Also, I opted for not using a VPN, but to use port forwarding for the one port that murmur exposes. VPNs will add latency and can also complicate LAN IP ranges.

Special thanks for Michael, VA3MW and Steve, N2IC for valuable input.

Leave a Reply

Your email address will not be published. Required fields are marked *