Re: Win11 ??

Yes… you have to remember how those audio signals get generated. The key here is that they all start out as RF signals near 15 MHz.

To get to audio frequencies, the SSB demodulator performs a heterodyne operation between these RF signals and an internal oscillator. That internal oscillator is locked to a reference frequency of 10 MHz coming from the GPSD-OCXO.

Now imagine that the internal oscillator glitches by needing to step up or down by a minimum increment, and then the PLL has to deal with a step change in frequency, which takes time (~6ms), and then settles to a new steady oscillation. But the new oscillation phase has some arbitrary relationship to the phase it had before the step change.

That shifted phase (at RF !!) produces the new audio signals that you see after the glitch. The RF signals didn’t change, just the internal demodulation oscillator. So the after signals look very much like the before signals, but with some shifted phase with respect to each other.

- DM

> On Sep 4, 2025, at 07:19, Yuri Davidovsky <[email protected]> wrote:
> 
> 
>> On 4 Sep 2025, at 12:28, David McClain <[email protected]> wrote:
>> 
>> Here is a link to an 80 MB file on my shared public cloud drive. It is a 48/24 stereo file. The glitch is in the left channel at 3:51.831.
>> …
>> And this follows your earlier notion of a 32-bit counter. I’m pretty sure the DDS inside the radio is using a 32-bit counter.
> 
> I am not too sure now that it may have to do with the counter since you found out that the time periods between the events vary, which should not be the case unless it does not count all the cycles it needs to count. However you would have a better idea how this piece of hardware should operate, so it might as well be, if you think so.
> 
> I did some messing around with the sound file posted, it was a fun exercise but the result did not produce anything ground breaking, everything is pretty much in line with what has been discussed so far. Nevertheless, here are a few screenshots on what I ended up with along with some of my thoughts on it.
> 
> So what I did was pretty simple, I loaded the file twice into a multitrack (Reaper for those interested) after cropping it and extracting just the left channel since that is the one of interest. Then I inverted the phase of one of the track files and shifted it so that it would be cancelling the payload sines while keeping the burst (hopefully) intact in the other track.
> 
> <Image 4-9-25 at 15.20.jpeg>
> 
> 
> The image above shows the alignment of the waveforms before bouncing down. Once the alignment was done, I rendered the project in the multitrack, which is basically merging the track together into a single waveform. Here is the result:
> 
> <Image 4-9-25 at 15.21.jpeg>
> 
> Evidently, we are not seeing the actual burst in its isolated form. The part of the payload sines before the event got cancelled out cleanly enough, but we can clearly see that it did not work all that well after the event, where the wave simply continued. Here is the zoomed out view:
> 
> <Image 4-9-25 at 15.23.jpeg>
> 
> There is certainly an irregular waveform represented by the event, but after that the waveform continues seemingly without getting cancelled. Why it happens this way is fairly evident when we zoom out at all the files involved aligned:
> 
> <Image 4-9-25 at 15.24.jpeg>
> 
> Never mind the change in the amplitude, I was getting some clipping so dropped the gain on the master track a bit to make sure it fits into the dynamic range. But here we clearly see that after the event waveforms got almost perfectly back into phase from the initial 180° shift, which also caused the clipping that I needed to account for by adjusting the master gain.
> 
> So this is indeed the source of that phase shift that you have flagged as an issue. By looking closely at the screenshot, it becomes clear that the event is not a burst blended into the signal (hence we can rule out RF interference from neighbours’ microwave) but rather a delay that lasts for about half a cycle of the lower frequency sine before it continues, producing the phase delay in question.
> 
> A logical conclusion would be that there is an issue with the generator that produces the lower frequency wave, rather than the receiver, but since you have ruled that out, from what I understand, it might as well be the receiver as the last remaining link in the processing chain. By the look of it, from the findings we have come to so far, it almost definitely does not look like an issue with the audio subsystem of the machine the software is run on.


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html