CPU load related audio output frequency instability observed in Thetis.

[Mike Lewis]

I was using Thetis tonight with WSJT-X, flipped to WSPR mode and noticed the trace was very wavy.  I use an external 10M double oven reference with my HL2.  I disconnected it, power cycled the HL2 and configured clk1 to internal source.  Got a straight line.   I then connected the HL2 to use another OCXO I use on my VHF Xvtrs for years.  Below is the same result as the first newer OCXO.   This period, like others, I got no decodes.  I switched antennas to my K3 and it is perfectly straight decode, likely ruling out my computer sound card.  Seems like when on a 10Mhz ref this problem shows up.  OK on internal source (so far).   Very curious!

 

Some cycles are better than others.  The internal HL2 temp is reported as 33.3 to 33.8C range slowly wandering.   Only RX mode.

 

 

Letting it sit longer on the old OCXO It decodes one period and it happen to be a straight line.  Just before it was a bit of a hook similar to the lowest part of the trace from 04:24 period in the trace above.  The temp stayed at 33.8C during these straight periods each getting decodes.

 

Letting it sit longer and exposing the HL2 box to slightly cooler room air by moving the original OCXO module off the top of the HL2 case and blowing on it a bit the temp slowly slid down to 33.5C and the trace remained straight, this is still on the old OCXO.

 

I then tuned in WWV at 4.999MHZ and watched the carrier at 1KHZ in WSJTX.  Started off good.  Then this happened.  Temp now 33.0C, for all these periods, not sure there is any relation yet.

 

 

From this point on it stayed perfectly straight temp 32.9 down to 32.6C.  Station 12V unchanged, 13.6V at 7.5A.  Both OCXO are 12V but have internal reference voltage sources at 5 or 7.5VDC outputs used for trim voltage.

 

While watching and web browsing, the computer fan turned on and off several times, CPU raised to 80 or so several times. It is normally running around 50-65% running all this stuff at the same time.  I notices each time the SDR trace started waving around correlated to the CPU fan running.   I switched the antenna to the K3 which has an analog audio connection to the motherboard sound chip and it was always straight.

 

So now the question is how the computer fan/load can impact a purely non-analog RF ADC output-to-computer-data stream frequency analysis?  Or how could the computer fan/load affect the station 12V power and OCXO(s)?   Does the internal clock source ever waver?

 

Retesting the HL2 internal source, external OCXO disconnected, it does indeed waver also.  Here the red line is the switchover with SDR app toggled on/off after the Clk1 reconfig (This is all with Thetis HL2 B5 so far).  Again I start heavy web browsing activity.

 

 

So the apparent internal clock stability earlier was just lucky timing.  They both have the problem.  It is not likely a clock source stability issue, seems very computer/app related.  I also ran the Thetis waterfall, slowed down and zoomed in to try to spot it there.  I was not able to see it on that display, only in WJSTX (passing through Virtual Audio cables).  Here RX1 is panadapter and RX2 is waterfall, both on same frequency.  I am listening to RX1/VAC1 and WSJTX is on RX2/VAC2.  Thetis does not think or see a stability issues.  Only shows up on the output audio.

 

 

I briefly pushed the CPU to 100% opening several web sites.  That caused some interruption evidenced by the red line.  Back at 66% the normal waviness continues.  The pic below is WSJT-x at the same time (02:22 local/06:22 UTC) as the snapshot above.  Thetis is happy, WSJTX is not!

 

 

Flip back to the K3 while I raise the CPU to 100% and perfectly straight.

 

Likely an app issue I exit Thetis and start Quisk. It is configured by startup script to use the 10MHz external OCXO, so I reconnect it. The OCXOs are powered up 24/7 inside other boxes.  HL2 reports temp is 33C.  I raise CPU up the same way.  It is a bit harder as Thetis consumes more CPU than Quisk.  No wavy lines in WSJT-X.   I change to WSPR on 40M and push the CPU to stay above 90% for over 2 minutes and still no wavy lines and 20 decodes.  Ran 2 RX sessions and every decode cycle was successful unlike when running in Thetis.

 

Conclusion: The smoking gun is pointing at Thetis audio output being impacted by CPU load.  The FFT display does not seem impacted.  I have no clue why a completely digital process’s frequency analysis would be sensitive to CPU load but the evidence here shows there is an issue present.  I cannot see how a VAC cable could alter such data leaving the app itself or missing data in audio buffers maybe.

 

Mike

K7MDL  EL87sm & CN88sf

 

[Reid Campbell]

Hi Mike,

This rang a bell with me and I found the following message thread in the forum.

https://groups.google.com/g/hermes-lite/c/vD_hmoyAa9A/m/VBwL4RFKBAAJ

Near the end it talks about the VAC re-sampler. Could this be your issue?

Cheers

Reid
Gi8TME/Mi0BOT  

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CO6PR18MB385836A2935191E2E6CDACE0F6BB9%40CO6PR18MB3858.namprd18.prod.outlook.com.

[ron.ni...@gmail.com]

Dealing with multiple asynchronous clock domains can create interesting issues.  The HL2 is sending IQ samples over UDP at some multiple of 48 kHz, based on its TCXO.  The SDR software may be working with some timing relationship to the computer clock, which may or may not be NTP disciplined (and thus varying).  And the final audio DAC may or may not be using the same (44.1kHz or multiple of 48kHz) clock as the software APIs.  The "VAC cable" may be working off of yet another timer.  These clocks may or may not drift differently due to temperature differences or changes.  Potential slight difference between these clocks or frequency generators can result in the need for one of more of: adaptive fractional ratio resampling, anomalies caused by error concealment, or glitches from lack of error concealment of buffer underflow or overflow, due to any input/output sample rate differences.  In addition, underflow glitches can be caused by the CPU(s) not being able to keep up with something like audio DMA or interrupt requirements, due to task overloading.

73,

Ron

n6ywu

[Mike Lewis]

It appears to be VAC sample rate related and how Thetis deals with it differently than in Quisk.  Checking the Force boxes appeared to have no effect unlike one person’s experience in the linked thread.

 

I was using the free single cable version and the VA IO monitor said it was 48K input and 44K output, but that tool did not let me change that there.  The monitor tool has a menu setting for sample rate and latency options, but it does not appear to change the output sample rate.  The VA cable was configured to 44.1KHz in device properties.  I knew I wanted all to be 48KHz when possible, but I had forgotten you can change it in the sound device properties advanced tab like any other device. 

 

I also noted the Thetis VAC input and output and Var ratio numbers change with load but the WSJTX end wavering would happen even when those numbers were stable. 

 

I also saw the noise burst on the RX to TX changeover earlier and had read where that was from left over noise in the single VA cable.  This morning I installed VAC-A and VAC-B product (2 separate cables) and configured the connection between WSJT-X and Thetis to use the separate cables for input and output (all set to 48K 16-bit).  The transmit appears noise free on transition now.   

 

So my mystery is easily solved once you look it the right place. 

 

 

Mike

K7MDL  EL87sm & CN88sf

 

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/302fda9c-c40f-44af-abea-a1030733e7fbn%40googlegroups.com.