I've been trying to get a QSE (exciter) working but am having a problem where the generated RF is jumping around in discrete steps.? See the attached screenshots taken while generating a 1000Hz input using WSJTX in "Tune".

?

I thought it was perhaps a hardware issue, the first QSE tested was a modified QRP Labs QSD, tested with both a XTAL osc LO (x4) and an external, stable LO source with no difference in behavior.? I am now getting the same result with a Multus Geminus MKII TRX (pretty much using the standard Softrock RXTX QSE circuit).? I've exhausted everything I can think of as far as hardware (different soundcards, different computers, different QSD hardware, audio level adjustments, etc. etc.), so am leaning towards something going on with how Quisk is generating the output IQ.? This behavior may be acceptable for SSB voice, FT8, etc., but for WSPR, FST4, FST4W, and other narrow spaced modes it results in undecodable signals.

?

(... and yes, I've gone through and performed TX IQ ampl. and phase adjustment)

?

?

... seems to also follow a repeatable pattern of shifting low and then back up.

?

?

?

Some additional info on this issue... I loaded up Quisk on a Win11 machine and it works perfectly... no frequency hopping or drifting, waveform looks very clean, etc.? So the issue seems to be specific to Linux.? I tested and had the problem on both a desktop and laptop, running Arch and Ubuntu respectively.? In both cases with all hardware tested, Quisk was configured to access the soundcards directly through ALSA (96k sample rate).

?

Additional info... back to Linux for further testing, this time letting PulseAudio manage the soundcard.? TX IQ works as expected, no abnormal behavior, stable and RF waveform is clean with a 1kHz audio signal.? I mention the waveform because when using ALSA, there was a fair amount of amplitude noise / variation on the resultant RF output of the QSE.? Of course, PulseAudio is not ideal, about 22 times more latency according to the Quisk stats and thousands of "errors" on the TX IQ side, but that seems to be of no consequence as far as the final result "works".

?

So there seems to be something weird going on with Quisk using native ALSA w.r.t. TX IQ.

?

This looks like a problem with resampling in the sound card. For example, if a card only works at 44.1 ksps, and you request 48 ksps, the card will resample to the different rate. Depending on how it does this you can get frequency drifts. But you said you used different sound cards. And 48 ksps is a standard rate that should not need resampling. If you are using 96 ksps it might be interesting to try the same thing at 48 ksps.?

?

I wonder if WSJT-X might be doing resampling. As you can see, I am confused by this. Quisk will never resample except in integer steps.

?

Jim

N2ADR

Did you try at a sample rate of 48ksps?

?

Jim

N2ADR

Interestingly, the built-in PCM device in the Multus radio isn't allowing a sample rate of 48k.? I'll have to test with the homebrew QSE and Xonar card, but that'll take a few days as that project was already being stripped of parts!? I'll post results when available.

?

Actually, that looks like the effects I see from the Quisk cut and splice re-sampling logic. ?I'm not sure I understand what the "reference frequency" for the error detection is. It seems to depend on the mode. The phase changes it introduces eventually are seen as slight frequency modulation. There's no proper smoothing in the correction process, so it jumps around between the correction intervals.

?

To confuse testing still more, it doesn't start correction for about 20 seconds or so, which makes it hard to diagnose problems.

?

Under many circumstances it introduces data dependent "glitches" due to extreme splices between HF samples that really confuse measuring equipment. Some spectrum analyzers show very confusing behavior when they experience this sort of thing.

?

I think it causes a lot of trouble and should not be used on the output IQ channels - input channels get filtered later in the DSP processing and the Speaker output doesn't matter much - but the IQ outputs cannot be filtered without clobbering any compensation in effect. Perhaps Quisk should use the primary IQ output as the reference frequency based on smoothed buffer fill sensing?

?

I'm pretty sure that no analog sound card I've ever seen does resampling except those that try to "genlock" to external clock sources. In the "old days", PC sound cards used to switch clock rates, but these days they are almost all single rate. I suppose some drivers may do it, but I'm not aware of any that do.

?

My own QSE design uses a it's own si5351 channel for clock control, so it can be reset to almost any frequency - but this is very unusual and was just a convenience to eliminate other parts.

?

Some operating systems do resampling - Apple products do this under some circumstances, but the details of how and when they do it has varied over the years. I swear that pulse audio does some sort of resampling, but talking about what it does is confusing because it keeps being rewritten and emulated and all linux audio is inherently a moving target. I don't know what Windows does these days.

?

...and don't even get me started about AES/SPDIF cards that do byte stuffing on the digital streams!

?

Just a few observations from my own experiences - I'm not trying to start a debate or critique Jim's excellent work!

?

M

Mario, I looked back to your message from last year regarding clicks in the TX IQ stream... I do hear those clicks as well, rather regularly.? Interesting observations... in your other message you mentioned modifying the correction or re-sampling behavior in Quisk on the outgoing IQ; were you able to make any progress on that and to what effect?