Hi Steve and other WSPRers,
Another question about implementing band hopping in WSJT-X. Do you see
any need for selection of TxPct (percent of time allocated for
transmitting) on a band-by-band basis, as we did in the original WSPR
program? Or is a one-size-fits-all policy OK here?
-- Joe, K1JT
On 5/17/2015 2:56 PM, Steven Franke wrote:
Joe,
I’d vote to keep sunrise and sunset separate Joe. Thinking of 10m propagation
in particular, there is significant asymmetry between sunset and sunrise at my
location.
Re idea #1 - this is what I meant when I talked about switching metric tables.
The idea would be to switch the table (and possibly the symbol amplitude
scaling) based on estimated SNR. I will give this a try and let you know what I
find out.
Idea #2 - sounds like the CLEAN algorithm… Yes, this would be fun to try.
Yes, I agree that sqrt(power) vs power is a moot point as long as the metric
table is constructed accordingly.
73 Steve k9an
On May 17, 2015, at 12:31 PM, Joe Taylor<[email protected]> wrote:
Hi Steve,
Thanks for sharing further thoughts on band hopping -- and the results
of your optimization efforts on the WSPR decoder. It's good to have a
professional's attention paid to some of the relevant formalities of
communication theory. I do read the textbooks -- the classic by Proakis
long ago became my favorite -- but I'm never quite sure that I have
everything exactly right.
A spinner control to set the duration of the grayline choice of bands
should be no problem. One question about this: do you forsee any reason
to select a different group of bands (or duration of the grayline
window) for sunrise and sunset? If not, would three columns of
band-select buttons (Day, Night, and Gray Line) be better than four?
On the optimization question: As you have now discovered independently,
I decided to maximize the number of decodes for a typical mix of
on-the-air signals, on a variety of bands, rather than for a specific
type of idealized signal -- say, the weakest ones detectable. So I'm
not surprised that one can do somewhat better for simulated signals with
S/N = -30 dB. I think the choice of using power or sqrt(power) is moot
if a corresponding metric table is used.
I've had two possible ideas for improving decoding performance even
further, beyond the present wsprd.
1. When the time-consuming Fano process is started, we already have a
good estimate of signal strength. We could, therefore, have two (or
even more than two) metric tables ready for use -- one for the weakest
decodable signals, and one for signals stronger by at least 5 dB (or
some such number).
2. These days, crowded WSPR sub-bands fairly often have signals that
overlap in frequency. The stronger one is usually decoded, but the
other one generally not -- even though it's easily strong enough to be
decoded in the clear. Here's what we could do. For every decoded
signal we know, in principle, the exact waveform that was transmitted.
So we regenerate that signal in the decoder, as a unit-amplitude complex
waveform. Multiply the received complex waveform (the one already
downsampled to 375 Hz) by the complex conjugate of the idealized decoded
signal. Lowpass filter the result at something like 1 Hz, to get rid of
all the other signals and most of the noise. The should leave something
close to DC: slowly varying amplitude and phase, corresponding to
propagation changes and perhaps oscillator instabilities. These can be
fit these with a complex polynomial -- and then we could create a nearly
exact replica of the decoded signal. This can be subtracted from the
received complex waveform, leaving everything BUT the one signal so
treated. This procedure could be followed for each of the decoded
signals, and then the WSPR decoder could be turned loose again, on
what's left.
I can imagine that such a procedure might increase the number of decodes
in a particular 2-minute interval by a few, when the band is crowded.
-- Joe
On 5/17/2015 12:26 PM, Steven Franke wrote:
For my purposes, I like the idea of using automatically calculated
sunrise/sunset as the pre-defined center of the sunrise/sunset windows. It'd be
sufficient to accept just one parameter, transition_duration, which would be
the width of the sunrise/sunset transition periods. That is essentially what
I’ve been doing here with transition_duration=2 hours (i.e. one hour before and
after), except that I have to manually adjust the center of the transition
window as the season changes. This scheme may not make sense for those who live
at high latitudes though...
One more thing on hopping - when hopping, I always honor the coordinated
hopping schedule. That is, if a band is active, I will always visit that band
at the appointed coordinated hopping time. Coordinated hopping times that
correspond to an inactive band are filled with a random selection from the set
of active bands. I think that this is consistent with what your WSPR program
does.
I spent yesterday trying to tune the wspr decoder to see if I could produce
more spots than the latest version that includes your tweaks. My effort focused
on trying to optimize the metric table and the symbol amplitude scaling. I
discovered your genmet.f90 simulation program and modified it so that it writes
out the biased and scaled metric table directly. Long story short, by going
back to “power”-based symbols and creating a metric table that is appropriate
for non-coherent 2-FSK “power” symbols and low (4.0 dB Eb/No) SNR, I was able
to beat the current version by about 10% on decodes of test files produced by
wspr0 with SNR=-30 dB. On a large batch of files containing all types of
conditions (160-10m, day and night) my tweaked version still loses to the
current version by a couple of percent, however. The last thing on my list of
things to try is to switch between low- and high-SNR metric tables to see if
that improves average execution time. I doubt that it�
��
s going to make much difference. It looks like you’ve got it pretty much
optimized.
I found a couple of interesting papers that suggest that the “Z-J” stack
algorithm may have a significant speed advantage over the Fano algorithm for
the more difficult-to-decode frames. It doesn’t seem like the extra memory
requirements of the stack algorithm would be an issue on the type of computing
platform that we are using. As a summer project, it might be fun to code-up
that algorithm to see how well it works. Before I go down that road - have you
or someone else already tried this for the JT-X and WSPR application?
72 Steve k9an
On May 17, 2015, at 9:45 AM, Joe Taylor<[email protected]> wrote:
Hi Steve and all,
I'm starting to plan a Band Hopping implementation for WSJT-X, and I
appreciate having your suggestions.
Suppose we have four columns of band-activation buttons: Day, Night, and
morning and evening gray lines. We already have the necessary
astronomical routines in place, so in principle WSJT-X knows when
sunrise and sunset occur. We could therefore choose the transition
times between one set of bands and the next automatically. What would
be the best indicator of the time to switch? Something like half an
hour before/after sunrise or sunset? Or some other criterion?
Including a facility to call a user_hardware script before each 2-minute
window should be no problem: earlier versions of WSPR do that, and it
works well.
-- Joe, K1JT
On 5/13/2015 10:45 PM, Steven Franke wrote:
Hi Joe,
I tried the latest wsjt-x_exp this evening on Ubuntu 14.04 and it worked great! My
regular hopping setup uses gnuradio to read the TS-480's audio from a sound card and
write it to a .wav file. I send xmlrpc commands to stop and start recording. I was
surprised to find that I could start wsjt-x "on top" of my program, and have it
listen to the same sound card that my gnuradio program was recording.
I see that you intend to add band hopping. That's great! It'd be nice if you'd
include the facility to call a user_hardware script before each 2-minute
window. I need this to control antenna and filter switches. The next interval's
frequency could be provided as an argument to the user_hardware script.
While you're at it, how about 4 hopping schedules that can be run during a 24
hour cycle? Day, night, and sun rise-set transition windows... That's what I
use here, but it's orchestrated by a cron job. It'd be nice to be able to
control it from within your slick GUI. It would be sufficient to have 4 rows of
band buttons to select the active bands, and set the transition times.
Thanks for the very cool program!
73 Steve k9an
On May 13, 2015, at 12:05 PM, Joe Taylor<[email protected]> wrote:
Hi Edson,
PY2SDR wrote:
Would it add too much complexity to have the frequency error correction in
the audio base band of the decoders? This would prevent having to re-tune
the rig and would also allow crystal controlled transceivers to also have
frequency error correction.
This could be done, of course. For a single-band crystal controlled
WSPR rig the number from a "Frequency correction" entry widget (a
spinner control, say) could be used to alter the (audio) frequency range
covered by the decoder, fix up the reported frequencies of decoded
signals, and adjust the frequency of Tx audio tones.
For some years already, production WSPR versions have included the
ability to set a "BFO frequency" to something other than 1500 Hz. I
think that could accomplish the necessary recalibration for the crystal
controlled case.
But under normal circumstances with rig control, I see little
disadvantage to retuning the radio. We have all the tools in place, and
they work well. Several people have been testing JT4 on the 10 GHz EME
path in recent weeks, using the automatic Doppler control (both Tx and
Rx) now in v1.6.1. They are delighted with it!
-- Joe, K1JT
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
