Thanks Ben, for the reply!
I've pretty well eliminated my device as the cause and focussed on the resampling method, but I will spend a little more time figuring out how Quisk processes buffers. By measurements, experimentation with modifications to the source code and a little reasoning, it appears that periodic random jumps of up to 1/2 sample value (which the present method creates) are not a good thing. ?Doing this correction to wideband IQ samples just before they are sent to the hardware the way it does, precludes doing any low pass filtering - which would mitigate the spurious transients.
Unfortunately, the nasty side effects are not easy to detect with instruments because they are transient and randomized.
I'm pretty sure the best thing to do would be to minimize the resampling during actual transmitting. Right now the algorithm runs continually. It probably could be disabled during normal transmissions if the underlying clock error is not too great. This would usually hide the correction because hams usually do low duty cycle transmissions. A bigger "dead band" in the feedback loop might also help by having it run less often.
I've been too busy to try it, but I'm going to disable the correction code completely (not the measurement part - just the few lines that interpolate or drop the samples) and try running my high resolution variable codec clock to do the correction instead. I'm fairly certain this will do the resynchronizing without side effects, but it takes a little thought to design the PLL-like software loop that will do the adjustment smoothly. Unfortunately, this would only help hardware like mine and not other use cases.
If this works, I'll report back and request an easier way to allow user supplied correction methods to be used by disabling the interpolation/drop via a configuration switch so that it doesn't require recompilation. It would also be nice to have a clean way to access the buffer fill statistics for such methods to use. I'm envisioning something easy to add to the heartbeat method in the hardware object.?
My apologies to forcing everyone to follow my missteps and thinking out loud in public about this. I was kind of hoping it would bring more suggestions like yours out of the woodwork. The two clock problem is pervasive in communications and is never easy to fix!
M
