Hi Wolf, Uwe, Peter,
after a little experimentation, I think I have
found a way to set up SpecLab to eliminate transmit phase jumps caused
by dropouts in the soundcard output. As a proof of
concept, I generated
an 8269.998 Hz audio carrier last night. This happened
to leak from the audio wires to my VLF antenna, and produced a
weak but well defined dash in the 42 uHz grabber
window.
We can use SpecLabs GPS tracking to take care
of any irregularities in the sound input path to the ADC. When using the 1-pps
reference with phaselock it can identify and correct short dropouts.
Augmented by the built-in NMEA-based timestamping scheme, SpecLab can in
principle even provide a defined absolute phase, referenced to
the beginning of the UT day.
But the timing is always relative to the reference
seen by the ADC input, and there is no way to directly sense latency variations
in the buffering between the software and the DAC output. Unfortunately on
many machines, buffer underflows or dropouts on the playback side seem to
happen fairly often, especially when the PC is not left alone but is used for
other jobs on the side.
The idea is to feed back a sample of the analog
output to the input, using either an analog loopback (eg the audio mixer, but
not a digital loop like VAC). Or set up a pickup probe to sense antenna current
or voltage, which would also take care of phase shifts from variable
antenna tuning. Then SpecLab can do a phase comparison to
a GPS-referenced internal generator, and steer the frequency of
an independent output oscillator to bring the radiated signal back to
the correct phase.
If you want to experiment with this method, you can
download the configuration file
which generates a 8270 Hz stabilised signal. To see
how it works, take a look at the circuit diagram
in:
The output signal is generated by the digimode
terminal block, which can be set up either for a continuous carrier, or for QRSS
or Opera modulation if you want. It feeds the DAC and the power amplifier
through L5. The output is brought back to the left input (L1) and fed to
the "E" channel of a colour-DF spectrogram. The right channel (R1) gets the
1pps signal from the GPS which is used for samplerate lock.
Lacking an appropriate GPS unit, I'm not using NMEA timestamps here, but you
could chose so if your unit provides serial data with proper
timing.
The steady reference frequency is provided by
the test signal generator - this is where you enter your desired output
frequency. It is fed to the second "H" channel of the spectrogram through R5.
The colour (azimuth) of the trace gives an indication of the phase
difference between L1 and R5.
The phase lock is implemented as a macro in
conditional actions: Every 200 ms, it checks whether there is a valid probe
signal at L1, and is so, it shifts the digimode frequency within
+-0.18 Hz according to the phase difference. Check this by turmning the
DAC off and on: The trace comes back on with an arbitrary colour, but
it will always revert to green (180°) within about three
seconds.
So to get started,
- set up the analog loop path and the
1-pps,
- load VLF_TX_1pps_PLL.usr,
- change the test signal
generator frequency from Uwe's 8270.004 to yours,
- set the digimode teminal to send unmodulated
test tone at TX frequency.
- enjoy!
Hope this may be useful.
Best 73,
Markus (DF6NM)
Sent: Sunday, January 19, 2014 7:01 PM
Subject: Re: DJ8WX 8270.004 Hz - transmit phase
correction?
Hello Markus and all,
Am 19.01.2014 18:43,
schrieb Markus Vester:
30 dB ...not too bad, is it?
Still wondering about the
nature of those transmit glitches. Assuming perfect GPS
sync, all possible interruptions in the input data stream could be
detected by the timestamp identification. But there is still a
chance for undetected buffer underruns in the sound output. Would
that affect the phase permanently? Or would the average fill state of the
FIFO buffering eventually be pulled back to the original lag
(probably not)?.
I have been pondering a scheme
where one audio channel is getting 1pps while the other is used
to sample the transmitter output, eg with a small pickup loop. That
way all phase variations in the transmit chain would be caught, and
the software oscillator could be steered to revert to the original phase
within a few seconds. With timestamping, we could even
prescribe absolute phase, allowing comparative measurements across
different sessions many days apart.
Wolf what do you think? If it
makes sense, I might try to implement something based on the
Sndinput / Sndoutpt combo.
Yes, certainly.
If there was a drop-out of the audio output, we cannot be sure if the latency
between 'application' and the arrival of the sample at the D/A-converter remains
exactly the same. Observing the phase of the *radiated signal* and steering the
signal generated by software to get the phase 'back where it belongs' would be
better because it would also compensate phase deviations caused by the antenna
itself.
Have a nice evening,
Wolf .
Best 73,
Markus
