since
1407utc I was playing around with the settings. that caused mni
"glitches".
so I switch the PA off now at 1500utc to make some "dry
practices".
Hi
Markus,
now since 1238utc ZOA in 1pps_PLL.usr mode on 8270.004Hz
we will
see
GL
Uwe
Von:
[email protected]Gesendet: 23.01.2014 00:24
An:
[email protected]Kopie:
[email protected]Betreff:
VLF: Transmit phase correction
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 choose 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 if 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
