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 <j...@princeton.edu> 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<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 ------------------------------------------------------------------------------ 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
