Re: Win11 ??

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