Input/Output Frequency shift with UPhoria 204HD

USB headsets to digital audio workstation software...
AB2EZ
Posts: 44
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Input/Output Frequency shift with UPhoria 204HD

Postby AB2EZ » Mon Aug 28, 2017 6:40 pm

I'm experimenting with the use of a UPhoria UMC204HD as an audio interface for FT8 (and also JT65/JT9).

ANAN-10E analog audio line output (left channel) => UMC204HD left channel line input (with 20dB attenuator activated) => WSJT digital audio input (selected from the WSJT input pull-down menu).

WJST digital audio output => UMC204HD right channel digital audio input (selected from the WSJT pull-down menu) => ANAN-10E front panel analog microphone input (taken from the UMC204HD right channel Main analog audio output) .

I am not using VMB in the digital audio path.

Note that the receive latency (as determined from the "DT" readings on decodes) and the transmit latency (as determined from the ANAN-10E waterfall display), and the glitch-free transmit behavior appear to be better than when I use VMB in conjunction with VAC-1

Everything works fine... except that I am curious about one minor issue.

The frequency of the transmitted signal (whether I send a constant frequency tone using the WSJT "tune" button or a regular FSK sequence) is typically low by around .02Hz, more or less... depending upon the WSJT-FT8 audio frequency at the end of the FSK sequence. I.e. at the end of an FT8 transmit sequence, the tone frequency should be the selected FT8 transmit frequency + 3 x 6.25 Hz. With FT8. the transmitted tone frequency at the end of a transmitted sequence happens to be 3 x 6.25 Hz higher in frequency than the lowest frequency tone in the sequence. 6.25Hz is the nominal spacing between the tones.

I have verified this several ways.

For example, using the VMB/VAC-1 arrangement, and (for example) setting the ANAN-10E to 14.074MHz, and the WSJT/FT8 application to 1700Hz... the Agilent frequency counter (set to a gate width of 0.03 seconds) reads a final output frequency of 14.075,718,75MHz.

Using the UMC204HD (as described above), the frequency counter reads 14.075,718,47MHz

Likewise, using the WSJT/FT8 "tune" function, the frequency counter reads 14.075,699,74MHz. If I activate "tune" on the ANAN-10E, the frequency counter reads 14.074,000,00MHz.

I'm thinking that there is a digital audio format conversion taking place in the UMC204HD between the 48kHz digital audio output of the WSJT application, and the analog output of the UMC204HD.

I have the UMC204HD set to 48KHz/16 bits CD Quality using the Windows 10 "recording device" and "playback device" settings. The control panel application that came with the UMC204HD shows the current "sample rate" as 48000Hz. However, on the "Format" tab of the UMC204HD control panel, the "Input" is shown as "2 channels, 24bits". That setting has an associated pull down menu... but it is "grayed out"... and I can't change the setting.

The small frequency shift is not creating any problems... but it is puzzling.

Stu
AB2EZ
Posts: 44
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: Input/Output Frequency shift with UPhoria 204HD

Postby AB2EZ » Mon Aug 28, 2017 10:11 pm

Replying to my own post:

It occurred to me that the UMC204HD is employing its own internal clock to withdraw samples from its buffer, and to drive its D/A converter.

-0.28Hz/1700Hz => -165ppm.

That sounds somewhat inaccurate for a modern crystal clock... but maybe that's what this digital audio interface provides.

VMB and the WSJT application are using the computer's clock... which is synchronized (I believe in frequency as well as time) to a network time server using the Meinberg NTP application.

The ANAN-10E is driven by an external, 10MHz, GPS-disciplined TCXO.

Stu
Last edited by AB2EZ on Thu Aug 31, 2017 7:33 pm, edited 1 time in total.
User avatar
w-u-2-o
Posts: 454
Joined: Fri Mar 10, 2017 1:47 pm

Re: Input/Output Frequency shift with UPhoria 204HD

Postby w-u-2-o » Tue Aug 29, 2017 12:19 am

Stu,

While you are going to expect me to say that going through all those analog gyrations is silly, and you'd be right ;) , nevertheless variety is the spice of life. If it makes you happy...

Be that as it may, certainly it is not unreasonable to find a 16PPM differential in even a professional sound interface. Such tiny errors are not audible with respect to "normal" sound recording/reproduction and therefore that kind of accuracy is completely acceptable for "normal" DAW applications. Interestingly, as it happens, there is some work being done on an improved resampler for the VAC interfaces that will work to help prevent under/overruns in the VAC ringbuffers that cause audible clicks and pops in the audio. This early work has shown that, on a variety of interfaces, the differential between the radio 48KHz and the PC sound interface 48KHz is in that range exactly. So your estimate of 16PPM definitely passes the "goofy test".

Note also that your frequency counter is another source of error. While your radio is locked to the external 10MHz reference, is your frequency counter also locked to the same reference?

73,

Scott
AB2EZ
Posts: 44
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: Input/Output Frequency shift with UPhoria 204HD

Postby AB2EZ » Tue Aug 29, 2017 12:39 am

Scott

Thanks for the comments.

The frequency counter is locked to the same 10MHz gps-disciplined reference as the ANAN-10E.

When I use the VAC-1 + VMB approach... I can see a substantial time delay between the switch of the ANAN-10E to transmit... which starts the waterfall display of the transmitted signal... and the start of the actual appearance of the FT8 transmitted waterfall trace. The are also frequent "glitches" on the transmit audio waterfall trace. These do not occur with the analog configuration.

I believe that the transmit latency causes FT8 decoding problems for some prospective recipients whose computer clocks are synchronized to NTP.

Note that I have the "high level" set to +10dBm on the waterfall... so that I can get a good transmitted waterfall trace.

Stu
Last edited by AB2EZ on Tue Aug 29, 2017 2:50 am, edited 1 time in total.
User avatar
w-u-2-o
Posts: 454
Joined: Fri Mar 10, 2017 1:47 pm

Re: Input/Output Frequency shift with UPhoria 204HD

Postby w-u-2-o » Tue Aug 29, 2017 2:48 am

I have measured my transmit latency on the following path: Mic --> UMC202 --> VMB --> Pro Tools (with minimal processing) --> VMB --> PowerSDR (with CFC et al) --> ANT.

This was using the low latency filters in PowerSDR.

The result was 44mS.

Even if, for some ungodly reason, the latency of the WSJT-X --> VMB --> PowerSDR was twice that (which I sincerely doubt), there's no way it would affect FT8 or JT mode time synchronization in any substantive way. Indeed, I have ZERO problems running any of those modes using the software-only audio path.

Are you using the low latency filters? If not, then you should be. The group delay in those filters is nowhere near what the ionosphere does to the signal, so it's a "don't care" from that perspective. The only other reason to use the linear phase filters is if you are using CESSB, which requires linear phase. However, since CESSB should be OFF for digi modes, that is not a compelling reason.

As for the glitches, that could be an issue with your PC's ability to handle real-time audio data. However I seem to remember you saying that LatencyMon and DPC Checker both gave your PC a clean bill of health.

73,

Scott
AB2EZ
Posts: 44
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: Input/Output Frequency shift with UPhoria 204HD

Postby AB2EZ » Tue Aug 29, 2017 2:57 am

Scott

As an experiment:

Set your waterfall "high level" to +10dBm

See if you observe a noticeable delay between the switch to transmit mode on the waterfall, and the appearance of the FT8 (or JT65) signal.

Also, see if you notice any "glitches" on the transmitted waterfall trace.

Stu
User avatar
w-u-2-o
Posts: 454
Joined: Fri Mar 10, 2017 1:47 pm

Re: Input/Output Frequency shift with UPhoria 204HD

Postby w-u-2-o » Tue Aug 29, 2017 3:53 am

I don't need to mess with the waterfall.

When using the default settings in WSJT-X there is a 0.2 second delay between the assertion of PTT (via CAT) and the assertion of audio out of WSJT-X. Go to File > Settings > Advanced to change that.

I have no problem with the default delay setting. It does not affect my ability to execute successful QSOs. On 40M just now I got an instant response (the band is hopping!) and the auto-sequencer took over and completed a QSO on the first try. My entire transmission is always completely contained within the 15 second window.

Nevertheless, to address your point, that delay, measured by eye/ear, is effectively identical whether I send the sound via VMB to my speakers, or whether I send it directly to my speakers (i.e. setting the output device in WSJT-X to VMB or to my speakers directly). I suspect that if I put a scope on the problem and measured the delay from PTT to audio it would be nearly identical whether direct to speakers or routed via VMB to speakers. Certainly the difference is under 100mS, which is immaterial in the JT and FT scheme of things.

I did notice that there are a lot of FT8 signals that start before the 15 second tick--those folks are not sync'd. Note that I use Meinberg to sync my computer. My current offset right now is +.5mS according to the Meinberg monitoring software. Knowing how meticulous you are, no doubt your system is synchronized as precisely, and I would be willing to bet that any difficulties with decode are on the part of other station's synchronization and not your fault.

If the delay bothers you, simply go into the WSJT-X advanced settings and change it to zero. I just tried that for kicks and I still made contacts with zero difficulty, if you'll pardon the pun!

73,

Scott
AB2EZ
Posts: 44
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: Input/Output Frequency shift with UPhoria 204HD

Postby AB2EZ » Tue Aug 29, 2017 5:20 am

Scott

Okay...

Thanks for the additional comments/thoughts

As you suspected, I am also using Meinberg to synchronize my computer's clock to UTC.

I also have the WSJT transmit delay set to 0.

Nothing additional to add for now.

Stu
AB2EZ
Posts: 44
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: Input/Output Frequency shift with UPhoria 204HD

Postby AB2EZ » Tue Aug 29, 2017 11:02 pm

Scott

I made the following additional measurement:

Two channel scope.

Input 1 is the voltage on the PTT line between the ANAN-10E and my Elecraft KXPA100 amplifier. The scope triggers on the negative transition of this voltage waveform... i.e. when the ANAN-10E switches to transmit, and draws current from the amplifier's PPT input.

Input 2 is the output of an RF sampler connected to the output of the amplifier.

I used this setup to measure the delay between the transition from receive-to-transmit (i.e. when PTT is activated by the WSJT program connected to the ANAN-10E via CAT using a virtual serial connection) and the onset of RF output from the amplifier.

With the WSJT=> VMB => VAC-1 connection... this delay was consistently 640 milliseconds. Note, this delay is not necessarily the digital audio path latency + the ANAN-10 VAC-1 input-to-RF output latency... (although one might think it would be). This delay is the delay between when the WSJT program activates PTT... and when the RF output first appears.

With the WSJT => Behringer UMC204HD => ANAN-10 microphone input connection, this delay was consistently 425 milliseconds.

Note that:

WSJT (advanced settings) is set to a delay of 0 seconds
The VAC-1 settings are: MME, Buffer size 128, Sample rate 48kHz, Buffer latency: 120 milliseconds. If I change the VAC-1 buffer latency setting to 20ms, the above delay does change. I.e. it is not consistently 640 milliseconds. It varies from 560ms to 640ms... depending upon how long the ANAN-10 has been in the receive state before the switch to transmit occurs. Most of the time, it is around 600ms.

Stu
Last edited by AB2EZ on Wed Aug 30, 2017 2:02 am, edited 1 time in total.
AB2EZ
Posts: 44
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: Input/Output Frequency shift with UPhoria 204HD

Postby AB2EZ » Tue Aug 29, 2017 11:47 pm

The above "begs the question":

Are these delays entirely a translation in time of the FT8 waveform... or are the first few hundred milliseconds of the transmitted waveform being chopped off?

I believe that the first few hundred milliseconds are important for decoding by the receiver at the other end of the link. Modes like Jt65 have a much longer "opening flag" (compared with FT8) that the receiver requires for synchronization.

Stu
AB2EZ
Posts: 44
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: Input/Output Frequency shift with UPhoria 204HD

Postby AB2EZ » Wed Aug 30, 2017 5:17 pm

Additional data:

Same test as in my previous post... with the connection between WSJT and the ANAN-10E being: WSJT=> Behringer UMC204HD = ANAN-10E front panel microphone input... and with PTT being controlled by the WSJT application via a virtual VAC/serial port connection.

Delay between the activation (i.e. the high impedance-to-low impedance transition) of the ANAN-10E PTT output (same as the amplifier PTT input) and the beginning of RF output from the amplifier:

Case 1: Using the ANAN-10E "tune" button on the main GUI: 40 milliseconds
Case 2: Using the "tune" button of the WSJT FT8 application GUI: 150 milliseconds
Case 3: Using the "Enable TX" button on the WSJT FT8 application GUI... to enable "CQ" sequences... with the WSJT "advanced" tab used to set the WSJT delay to [b 0.0[/b] seconds: 480 milliseconds (more than yesterday's 425 milliseconds).
Case 4: Using the "Enable TX" button on the WSJT FT8 application GUI... to enable "CQ" sequences... with the WSJT "advanced" tab used to set the WSJT delay to 0.1 seconds: 480-520 milliseconds (some variation).
Case 5: Using the "Enable TX" button on the WSJT FT8 application GUI... to enable "CQ" sequences... with the WSJT "advanced" tab used to set the WSJT delay to 0.2 seconds: 480-520 milliseconds (some variation).
Case 6: Using the "Enable TX" button on the WSJT FT8 application GUI... to enable "CQ" sequences... with the WSJT "advanced" tab used to set the WSJT delay to 0.3 seconds: 820-900 milliseconds (some variation).
Case 7: Using the "Enable TX" button on the WSJT FT8 application GUI... to enable "CQ" sequences... with the WSJT "advanced" tab used to set the WSJT delay to 0.4 seconds: 880-920 milliseconds (some variation).

The above is not all that clear... in terms of an explainable pattern of delay ...

But it does appear (comparing Case 1, Case 2, and Case 3, and when one includes the longer delays, reported previously, when using the VAC-1 + VMB connection)... that there may be some delay in completing the transmit audio connection... that is not associated with the ANAN-10E's T/R relays or the amplifier's PTT + T/R process... that is within the ANAN-10E...and that occurs when the transceiver switches from receive to transmit.

It also appears from... from comparing Cases 2-3... that much of this delay is within the WSJT application itself.

Stu
Last edited by AB2EZ on Wed Aug 30, 2017 7:16 pm, edited 1 time in total.
AB2EZ
Posts: 44
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: Input/Output Frequency shift with UPhoria 204HD

Postby AB2EZ » Wed Aug 30, 2017 6:08 pm

Additional (perhaps more useful) data

Repeating the experiments in the previous post... but using the ANAN-10 PTT output / Amplifier PTT input line as an "external trigger" for the oscilloscope... I can now view both the commencement of the audio input to the ANAN-10E front panel microphone jack (scope channel 1) and the sample of the RF output (scope channel 2)... and their commencement delays compared to the PTT line high-to-low transition.

Case 3:

Delay between the commencement of audio input to the ANAN-10 microphone input jack and the commencement of RF output: 40 milliseconds. I.e., the same as the latency previously measured (in other experiments involving AM and SSB) for this path between microphone audio input and modulated RF output.

Delay between the commencement of audio input to the ANAN-10 microphone jack and the PTT line high-to-low transition: 400-440 milliseconds (varies). Note that the WJST delay is set to 0.0 seconds on the advanced settings tab.

Therefore, most (i.e. more than 90 percent) of the 400+ milliseconds of delay reported earlier for Case 3 (and also the delays reported in the other cases) is associated with the combination of: the delay between the T/R output activation and the commencement of digital audio out of the WSJT application, the latency in the digital audio path from the WSJT application digital audio output to the Behringer UMC204HD input, and the digital audio input-to- analog audio output latency of the Behringer UMC204HD.

There does not appear to be any mysterious "turn-on" delay associated with the establishment of the ANAN-10E transmit audio path during a transition from receive to transmit... and therefore no "chopping off" of the leading part of the WSJT digital audio output signal.

Stu
User avatar
w-u-2-o
Posts: 454
Joined: Fri Mar 10, 2017 1:47 pm

Re: Input/Output Frequency shift with UPhoria 204HD

Postby w-u-2-o » Thu Aug 31, 2017 12:06 am

Stu,

Those delays are crazy long. Would you confirm whether or not you are using the low latency filters in PowerSDR mRX, please?

Thanks,

Scott
AB2EZ
Posts: 44
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: Input/Output Frequency shift with UPhoria 204HD

Postby AB2EZ » Thu Aug 31, 2017 12:50 am

Scott

I am using the low latency filters:

Digital Buffer size: Rx 64 Tx 128. Digital Transmit and Receive Filter size: 1024

From my last posted measurements, the microphone input => RF output latency is only 40 milliseconds.

The large delay between the T/R line transition, from high to low, and the commencement of RF output is due to: the delay between the assertion of the T/R CAT command by then WSJT application and the commencement of digital audio output from the WSJT application + the latency between the digital audio output from the WSJT application and the digital audio input to the UMC204HD + the latency between the digital audio input to the UMC204HD and the analog audio output of the UMC204HD. Since this total varies from about 100 milliseconds (on activation of the WSJT tune function) to about 400 milliseconds (on activation of any of the WSJT FT8 output sequences), it is now clear that most of the delay is associated with the WSJT application.

Stu
AB2EZ
Posts: 44
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: Input/Output Frequency shift with UPhoria 204HD

Postby AB2EZ » Mon Sep 04, 2017 3:58 pm

Update:

Out of curiosity, I tried two additional experiments

1. I measured the delay between the assertion by WSJT of the T/R CAT command (i.e. using the high-to-low transition of the impedance across the ANAN-10E T/R output port to trigger the oscilloscope) and the commencement of WSJT digital audio output for JT65. It was consistently 950 milliseconds (vs 450 milliseconds for FT8... using the same digital audio interface/sound card configuration).

In this measurement, the connection for transmit audio was: WSJT digital audio output => computer's Realtek sound card digital audio input => Realtek sound card analog headphone output => ANAN 10E front panel microphone input.

2. I compared the above delays using: a Behringer UMC204HD external digital audio interface, vs. using the internal Realtek sound card. There was no significant difference.

It appears that most of this delay is built into the WSJT-X application... and is taken into account by WSJT when the T/R command is asserted (relative to the computer's clock) and/or when "DT" is computed from each successfully decoded received signal.

Note: In all of these measurements, the WSJT "Tx delay" (Advanced tab in WSJT setup) is set to 0.

Going back to the original issue that I raised in my first post to this thread... it appears that the clock in the computer's internal Realtek sound card is accurate to within 20PPM (less than 0.02 Hz out of 1000 Hz).... whereas the clock in the external Berlinger digital audio interface is slow by about 165 PPM (about - 0.28 Hz out of 1700 Hz)

In all cases, the additional delay (latency) between the commencement of audio input to the ANAN 10E front panel microphone input jack, and the commencement of RF output is 40 milliseconds

Stu
Last edited by AB2EZ on Tue Sep 05, 2017 6:20 pm, edited 2 times in total.
User avatar
w-u-2-o
Posts: 454
Joined: Fri Mar 10, 2017 1:47 pm

Re: Input/Output Frequency shift with UPhoria 204HD

Postby w-u-2-o » Mon Sep 04, 2017 8:30 pm

Everything about your last post makes total sense, Stu, and is exactly what I would expect. Including the 40mS from front panel mic to RF out.

I don't see the value of not using VAC to move audio from program to program, though. When you take the analog route, now you've got this legendarily torturous path (on transmit, receive is similar):

Dig program > PC sound interface > Radio > Radio Audio CODEC > FPGA > Ethernet > PowerSDR > Ethernet > FPGA > RF DAC

Using VAC it's a lot simpler and shorter:

Dig program > VAC > PowerSDR > Ethernet > FPGA > RF DAC.

73,

Scott
AB2EZ
Posts: 44
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: Input/Output Frequency shift with UPhoria 204HD

Postby AB2EZ » Tue Sep 05, 2017 6:18 pm

Here is an explanation of what I have observed... from a member of the WSJT-X design group.

Stu

"Hi Stu,

the logical start of a transmitted codeword is a t=1s for all the slow modes except for FT8 where it is at t=0.5s. We reduced the start delay in FT8 to try and win back some thinking time at the end of the period. The actual timing of PTT and start of audio is somewhat variable depending on CAT latency and in some cases waiting for confirmation that the rig has actually switched to send mode. These variabilities have no bearing on the timing of the codeword symbols which are synchronized to the generating PC clock with a small delay due to audio buffer latency. The decoders allow for the t=1s or t=0.5s logical start and also add a small "fudge factor" (100ms I believe) to account for expected latencies at both ends. This means estimated dT values are a reasonable measure of relative wall clock time difference between sending and receiving stations.

73
Bill
G4WJS
"

Return to “Digital ("Virtual") Audio”