Joe - Sure! The more knobs the better as far as I am concerned. But it should be easy for a less hard-core user to be able to just enter one number and have it apply globally. A couple of other thoughts -
- it would be nice to have an ability to select NEXTBAND and have that selection override the hopping band selection process. I assume that you will also provide a TXNEXT capability so that if I want to be sure that I TX on, say, 10m during the next interval I can do that. - I’d like to suggest that you allow us to set a limit on maximum number of successive transmissions. In my case, I prefer to limit the number of successive TX intervals to a maximum of 2. Of course, this limits max TX percentage to 67% and makes it more complicated to ensure that actual TX % matches up with what is requested... Steve k9an > On May 18, 2015, at 9:43 AM, Joe Taylor <j...@princeton.edu> wrote: > > 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<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 > > ------------------------------------------------------------------------------ > 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
