Hi Markus (and thank-you to Chris, Urlich, Iban and Graham for
reports/relays)
Your critiques of my signals are very thorough and masterful. I am
most grateful. There is a concensus amongst you, Domenico and Stefan
that I've gone off frequency again, at times more than 1 mHz!
Hopefully this will be corrected soon. I'll post your nice plots
on the web if you don't mind.
In the mean time, I ran Paul's ebbaut.c on the MUN unix box and
an old Model B raspi. It compiled flawlessly. I had to put in
arguments for -S and -r which I chose at random, my callsign and
pussycat's name and was rewarded with a long list of 0's and 1's.
So if I send a long carrier with a phase inversion every time a 1
is encountered, it will be a valid ebnaut transmission? What is
the duration of the elements and what arguments should I pass to
ebnaut.c? Also, would a transformer + DPDT relay work? A ring
mixer might not take kindly to a 12V squarewave.
Please excuse my naivety! Also, XYL is wondering why you want the
other details of the cat. She was my ground crew today while I was
atop the tower so I must be diplomatic!
MNI TNX
Joe VO1NA
On Wed, 11 Nov 2015, Markus Vester wrote:
Joe,
more of the same from last night, this time with frequency and level plots.
Again we see some frequency variation of similar size as yesterday. It is not
clear how much of that is due to propagation, I only think that
the rise near the end is due to Doppler from the descent of the ionosphere
at sunrise. Russian Loran lines on 137475 and 137482.5 seemed to have less
overnight variation (~ 0.1 mHz), but then of course the intra-European path
from Slonim is very different from yours.
Regarding EbNaut carrier analysis: for some reason (lack of coffee?), I only
saw Domenico's earlier mail after I had sent mine, so please excuse me for
basically having described the same procedure again. Anyway it's good that
we both arrived at the same conclusion: If Joe started sending EbNaut PSK
with his oscillator as it is now, we would very likely be able to decode it
here.
Joe so all you need now is a diode ring-mixer for PSK modulation and Paul's
ebnaut-tx program. Symbol timing will be derived from the PC clock, so
with NTP available there's no need to involve GPS at all. If Paul brought his
LF receiver back to life, he could probably copy you even if you reduced TX
power to 0.1 Deccas.
How many cats do you have? We want to know names, colours, sex and age for all
of them ;-)
All the best,
Markus (DF6NM)
PS. SpecLab question: Wolf is there a way to extract peak frequencies from past
spectrogram lines (semi-)automatically, without having to manually move and
read the mouse cursor over each point, e.g. something like a peak_f(f1,f2,
time) interpreter function?
-----Ursprüngliche Mitteilung-----
Von: Markus Vester <[email protected]>
An: rsgb_lf_group <[email protected]>
Verschickt: Mi, 11 Nov 2015 1:24 am
Betreff: LF: VO1NA frequency
Hi Joe,
the attached plot shows the frequency stability of your opds trace received last
night http://df6nm.bplaced.net/LF/opds32_151110_0736.png . Each data point is the interpolated peak of a
single 438 uHz FFT (i.e. 38 minute window). The average frequency seems to be 0.7 mHz below nominal, and
there are small temporal variations up to 0.5 mHz in either direction. Though some of that is
probably attributable to noise and propagation, I believe that there is also a bit of inherent instability
in the frequency source. Actually a few parts per billion is quite good for a free running OCXO
(assuming the "D" stands for "double oven" and not "discipled"), and that the
calibration was done over a 10 MHz HF link.
Is this good enough for EbNaut? During the experiments with IZ7SLZ we found
that for full sensitivity the phase variation over the EbNaut sequence
duration should not be much more than 90°. Thus for a half-hour message the
frequency should be ideally constant and known to about 0.14 mHz. If there is
more variation we often can still get decodes, but we will have to find
the best frequency offset by trial and error, which can be cumbersome if the
signal is weak.
I also fed opds data files from your Sat/Sun transmissions to the EbNaut decoder. The
idea was to see if your Opera transmissions would actually produce the
all-asterisk decode which is expected for a non-PSK-keyed straight carrier, and to
observe the symbol phase evolution over the 38 minute duration. Starting midnight UT,
one decode was attempted every 30 minutes, using a setting for 464 raw symbols (4
characters) and 5 seconds per symbol. A frequency offset of -0.6 mHz was selected to
obtain flat phase during the first decodes, and that offset was kept for all later
attempts. Despite the Opera gaps which degrade or drop half of the available
symbols, 12 out of 13 decode attempts produced the correct "****"
message, e.g. http://df6nm.bplaced.net/LF/r0317.png . However at times the frequency
drift was quite visible on the phase plot, e.g. in
http://df6nm.bplaced.net/LF/s0317.png (flat phase around 3:17) versus
http://df6nm.bplaced.net/LF/s0347.png (upward phase slope around 3:47).
Scaling down to VLF, deviations from the same oscillator will be 16x smaller
(~30 uHz at 8.3 kHz). This will be probably good enough even for narrow FFT
bins, corresponding to several hours coherent carrier integration or slow
EbNaut decodes.
All the best,
Markus (DF6NM)
From: [email protected]
Sent: Saturday, November 07, 2015 3:45 PM
To: [email protected]
Subject: Re: LF: VO1NA opds-32
LF Group,
Again, thanks to SV8RV DF2JP PA7EY and DF6NM for the reports.
In my last post I reported the drift was constrained to within 1 Hz.
This should be 1 mHz. Thanks Markus for your assurances that this
should be adequate for EbNaut which I hope to use to send send our
cat's name on LF. The little curls appear often on the QRSS traces on
your high res spectra. Doppler variations were removed from the 10 MHz
WWV signals with harmonic regression when the DOCXO was calibrated
so this effect is seen on LF but not as strongly.
After reading about EbNaut on Paul Nicholson's pages it seems I have
much catching up ahead. Fasinating stuff!
Can the EbNaut phase inversions be done without an absolute time
reference? I'm cheap and lazy so hoping GPS will not be needed.
The Opera will be doing an encore tonight and if the wind stays low
a tower climbing expedition is planned for the afternoon.
73
Joe VO1NA
On Sat, 7 Nov 2015, Markus Vester wrote:
> Hi Joe, LF,
>
> during the last couple of nights, opds detected all of your transmissions
between about 22 and 7:30 UT.
>
> Attached is a zoomed 40 mHz section from my opds-32 spectrogram, showing
your central coherent carrier which contains half of the transmitted average
power. It seems to be about 0.5 mHz below 137477 Hz (possibly due to a calibration
error in my receiver). The 2.7 mHz spaced sidelines during the early part (bottom)
were caused by 6-minute-periodic interruptions from my own MF WSPR transmissions.
However the little curls near the carrier can presumably be attributed to
Doppler-shifted multipath components. The carrier was still weakly visible for
another hour after the last detection.
>
> Comparing the looks of the carrier to earlier IZ7SLZ transmissions, the
stability of the signal and the path seems quite sufficient for half-hour EbNaut
PSK transmissions. Unfortunately I missed the opportunity to save the raw data and
analyze phase evolution using the EbNaut decoder itself - will try that next time.
>
> All the best,
> Markus (DF6NM)
>
>
>
>
> From: [email protected]
> Sent: Saturday, November 07, 2015 12:03 AM
> To: [email protected]
> Subject: Re: LF: last night opera opds detection in km07ks
>
>
> LF Group,
>
>
> I am grateful to Joe DF2JP for his captures QRSS and Opera
> Dionysious SV8RV for his OP decodes to Domenico IZ7SLZ
> for his OPDS decodes, and thanks to DF6NM for opds!
>
> I do not know if my DOCXO is stable enough for EbNaut.
> It was set a couple of years ago and has not drifted more than
> 1 Hz since then. It seems the phase decoherence has stopped
> haunting me.
>
> I am hoping to replace the halyard for the other 100m wire soon.
>
> OP32 again tonight as send this email.
>
> 73
> Joe
>
>
|
