Menu
▾
▴
Re: [wsjt-devel] wsjt-x
|
From: Joe T. <jo...@pr...> - 2015-05-18 14:43:40
|
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<jo...@pr...> 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<jo...@pr...> 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<jo...@pr...> 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 >>>>>> wsj...@li... >>>>>> 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 >>>>> wsj...@li... >>>>> 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 >>>> wsj...@li... >>>> 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 >>> wsj...@li... >>> 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 >> wsj...@li... >> 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 > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel |
