Re: Win11 ??

Okay, here is how you get arbitrary phase shifts…

Let’s assume our electrical oscillator, a VCO tied to the DDS output, must be phase continuous. It cannot suffer abrupt phase jumps. Its phase proceeds according to its instantaneous frequency and elapsed time.

If the oscillator is asked to shift according to a step input, it will move with some trajectory toward the target frequency. Overshoot, or critically damped motion. Meanwhile, its phase is advancing according to the instantaneous frequency.

Since we are using USB demodulation, our signals are above our heterodyne carrier, and so if the DDS commands an increase in frequency then our relative phases will slip backwards. Or vice versa for a decrease in frequency.

The total phase shift between the heterodyne carrier and the signals will be the path integral of phase differences along the trajectory. If the trajectory has any ringing, it will be a merry ride of speed up and slow down on the way to the target frequency.

I see no restrictions on relative phase relationships across a commanded step jump in frequency.

eh?

- DM

> On Sep 4, 2025, at 10:40, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
> 
> So the waveform you see surrounding the glitch,
> 
> <PastedGraphic-1.png>
> 
> Is essentially just the two injected DSB reference carriers. The SOI is very weak here. The major wave is the 99.5 Hz reference, and within it is the higher frequency 2900.5 Hz reference.
> 
> Major peak to major peak is nominally 10.1 ms, while the peak to major peak surrounding the glitch measures about 16 ms.
> 
> The glitch itself looks very much like a PLL losing lock, in response to a step change, then settling to a new stable setting. 6 ms is pretty fast settling (167 Hz !!), much faster than any human needs while spinning the dial.
> 
> It almost appears that the low-frequency 99.5 Hz reference is phase continuous after an inserted delay of 6 ms, like the NCO just picked up where it left off.
> 
> But, mind you, we are seeing the reference signals relative to the underlying heterodyne oscillator. In actual fact, these signals are hitting the DSP at somewhere above 18 kHz (mid-band of the 36 kHz IF). And so this is the view that would be seen by someone riding along on the underlying NCO carrier.
> 
> It seems to me that you could produce any arbitrarily large phase shift post vs pre, by simply choosing the phase of your own post NCO carrier to suit. But you would have to know to make that choice - that a glitch had just happened. And so how would have known this, as the DSP?
> 
> You probably can’t and don’t know this.
> 
> So, instead, what of a DDS slip prior to A/D conversion into the DSP? Now we are working at RF frequencies, or possibly around 36 kHz at the low end. The incoming signals are phase continuous. But your heterodyne carrier is not. Once the heterodyne carrier from the DDS settles down, it seems it could have arbitrary phase relative to the continuous phase input signals.
> 
> - DM
> 
>> On Sep 4, 2025, at 09:57, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
>> 
>> Yes, the Icom IC-7700, first released in 2008, uses a DSP to perform its demodulation. So it is software based, and hence buffered. Filters are all FIR with measurable throughput delays.
>> 
>> The front-end of the IC-7700 uses up-conversion, a la Ulrich Rhode, to a first IF of 64.455 MHz, and then heterodynes to a 2nd IF of 36 kHz where it then goes into an A/D converter and then into a DSP for demodulation and audio conversion. Heterodyning is by way of a numerically controlled oscillator (NCO - just like in my Lisp code for analysis).
>> 
>> The DSP Is driven by a 12.288 MHz clock that is phase locked to the external 10 MHz reference frequency. And the up-conversion to 64.455 MHz is controlled by a phase-locked DDS fed by a 40 MHz oscillator derived (quadrupled after hard clipping) from the injected 10 MHz frequency standard.
>> 
>> So if there is a glitch coming from the DDS, you would think that should not affect the DSP running its own NCO. How would the DSP know that the tuning had changed? All it knows is that it is running an NCO at ??kHz to produce an audio tone at 1500 Hz. And these frequencies are measured on the assumption that the injected clock is running at 12.288 MHz.
>> 
>> So… I don’t really understand how or why the phase shift in the audio demod signal happens. It clearly does happen, and seems to follow a transient 6 ms glitch that is inserted into the audio output, not a glitch that overwrites an underlying audio signal.
>> 
>> But what I have mentioned above about various IF frequencies and clock frequencies is just about the full extent of the documented info about the innards of the IC-7700. IOW - not very well documented at all. I don’t even know the details of the DDS counter sizes and such. Nobody does. It just sort of works.
>> 
>> ——————————
>> 
>> I’m injecting a DSB pair centered at the nominal frequency of interest, 15 MHz, and with sidebands at ±1400.5 Hz. The receiver is tuned to 14.9985 MHz so that the SOI appears nominally at 1500 Hz. The sidebands are then at 99.5 Hz at 2900.5 Hz. 
>> 
>> Using the two injected sidebands and known frequencies allows me to analyze the output audio from the receiver and measure both the sample rate of the ADC, and the frequency offset in the tuning. I derive the tuning offset as -19.493±0.003 mHz at 14.9985 MHz nominal dial tuning. The ADC clock is locked tightly to Word Clock at 48 kHz derived from the master 10 MHz clock. 
>> 
>> These frequencies are good to about 2e-12 over the 15 sec data collection period per grand decimated input buffer. I’m decimating 48 kHz sample rate by a factor of 6x256 and using FFTs of length 1024 with 50% overlap. 
>> 
>> A full 1024 of decimated samples takes about 30 seconds to obtain. But with 50% overlap I analyze the input every 15 sec. So my bin-width is 30 mHz, and with a DSB reference SNR of 70+ dB, that should allow me to measure to about ±30 microHz over a long enough data collection duration (≈9.3 hours).
>> 
>> That extreme precision is for the unvarying reference lines. But any one look at the signal of interest, propagating via the ionosphere, gives me an accuracy of around 0.15 mHz from look to look.
>> 
>> - DM
>> 
>> 
>>> On Sep 4, 2025, at 08:49, Yuri Davidovsky (as work at disclosure dot ie) <[email protected]> wrote:
>>> 
>>> 
>>> 
>>>> On 4 Sep 2025, at 16:55, David McClain <[email protected]> wrote:
>>>> 
>>>> 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.
>>> 
>>> I am a bit unsure how heterodyning a radio frequency back to the audible range in an AM receiver can produce such a massive phase shift in the payload signal. Surely the change of the phase in the demodulation oscillator might cause DC offset issues in the recovered audio signal, but why such a massive phase alteration?
>>> 
>>> If there were some issues with the carrier wave demodulation, I would expect the signal to choke for a bit until the oscillator recovers (the 6ms gap), which would be annoying enough but afterwards the audio should continue as if nothing happened.
>>> 
>>> The only thing I can think of is that there is some digital processing happening inside the receiver with some sort of buffering of the recovered signal going on. The audio output stops for a bit to reset the oscillator but then continues from the point in the buffer where it halted before the reset.
>>> 
>>> _______________________________________________
>>> Lisp Hug - the mailing list for LispWorks users
>>> [email protected]
>>> http://www.lispworks.com/support/lisp-hug.html
>> 
>> 
>> _______________________________________________
>> Lisp Hug - the mailing list for LispWorks users
>> [email protected]
>> http://www.lispworks.com/support/lisp-hug.html
> 


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