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
