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<j...@princeton.edu> 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<j...@princeton.edu> 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
>>>> wsjt-devel@lists.sourceforge.net
>>>> 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
>>> wsjt-devel@lists.sourceforge.net
>>> 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
>> wsjt-devel@lists.sourceforge.net
>> 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
> wsjt-devel@lists.sourceforge.net
> 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
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
