Menu
▾
▴
Re: [wsjt-devel] wsjt-x
|
From: Steven F. <s.j...@ic...> - 2015-05-17 18:56:26
|
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 |
