Menu
▾
▴
wsjt-devel
|
From: Joe T. <jo...@pr...> - 2015-05-13 14:48:08
|
Hi all, One of the fun things about WSPR is the frequency accuracies that are involved. Having WSPR mode in WSJT-X motivates some serious thought about how best to handle frequency calibration errors in transceivers. Typical dial readout errors in modern radios are a few parts per million -- for example, a 20 Hz error at 14 MHz. For JT65 or JT9 such discrepancies are not very important. But the WSPR sub-bands in conventional use since 2008 are only 200 Hz wide, and we'd like to use all of that range effectively. If my transceiver's dial reads 20 Hz low, and yours reads 20 Hz high, and we both set our dials to the conventional 14.0956 MHz for 20 meters, after setting our WSPR Tx frequencies at random within the 200 Hz sub-band there's something like a 20% chance that we won't decode one another. Earlier production versions of WSPR have handled these issues in a rather sophisticated way. The User's Guide includes detailed instructions for determining calibration constants for your transceiver using over-the-air signals (see Appendix C of http://physics.princeton.edu/pulsar/K1JT/WSPR_3.0_User.pdf ). The resulting accuracies can be better than 1 Hz. If CAT control is in use and "Enable frequency correction" is ticked on WSPR's "Advanced Setup" window, frequencies sent to the radio are adjusted so as to compensate for the dial errors. For example, if 14.0956 MHz has been requested, the command for 14095620 Hz may be sent to the radio. I picture this being implemented in WSJT-X in a similar way. In this example, the radio dial would read 14.096520. I'm suggesting that the frequency readout on the WSJT-X screen would read 14.095600, the supposedly "true" frequency. Comments and suggestions would be welcome. -- 73, Joe, K1JT |
|
From: Edson W. R. P. <ewp...@gm...> - 2015-05-13 15:49:54
|
Hi Joe, 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. 73, Edson PY2SDR --- - We humans have the capability to do amazing things if we work together. - Nós seres humanos temos a capacidade de fazer coisas incríveis se trabalharmos juntos. On Wed, May 13, 2015 at 11:48 AM, Joe Taylor <jo...@pr...> wrote: > Hi all, > > One of the fun things about WSPR is the frequency accuracies that > are involved. Having WSPR mode in WSJT-X motivates some serious thought > about how best to handle frequency calibration errors in transceivers. > > Typical dial readout errors in modern radios are a few parts per million > -- for example, a 20 Hz error at 14 MHz. For JT65 or JT9 such > discrepancies are not very important. But the WSPR sub-bands in > conventional use since 2008 are only 200 Hz wide, and we'd like to use > all of that range effectively. If my transceiver's dial reads 20 Hz > low, and yours reads 20 Hz high, and we both set our dials to the > conventional 14.0956 MHz for 20 meters, after setting our WSPR Tx > frequencies at random within the 200 Hz sub-band there's something like > a 20% chance that we won't decode one another. > > Earlier production versions of WSPR have handled these issues in a > rather sophisticated way. The User's Guide includes detailed > instructions for determining calibration constants for your transceiver > using over-the-air signals (see Appendix C of > http://physics.princeton.edu/pulsar/K1JT/WSPR_3.0_User.pdf ). The > resulting accuracies can be better than 1 Hz. > > If CAT control is in use and "Enable frequency correction" is ticked on > WSPR's "Advanced Setup" window, frequencies sent to the radio are > adjusted so as to compensate for the dial errors. For example, if > 14.0956 MHz has been requested, the command for 14095620 Hz may be sent > to the radio. > > I picture this being implemented in WSJT-X in a similar way. In this > example, the radio dial would read 14.096520. I'm suggesting that the > frequency readout on the WSJT-X screen would read 14.095600, the > supposedly "true" frequency. > > Comments and suggestions would be welcome. > > -- 73, 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 > |
|
From: Joe T. <jo...@pr...> - 2015-05-13 17:05:27
|
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 |
|
From: Steven F. <s.j...@ic...> - 2015-05-14 02:45:35
|
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 |
|
From: Joe T. <jo...@pr...> - 2015-05-17 14:45:18
|
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 |
|
From: Steven F. <s.j...@ic...> - 2015-05-17 16:26:49
|
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 |
|
From: Joe T. <jo...@pr...> - 2015-05-17 17:31:30
|
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 |
|
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 |
|
From: Joe T. <jo...@pr...> - 2015-05-17 19:35:24
|
Hi Steve, I forgot to comment on one further point that you raised. Trying the "stack algorithm" for decoding our long-constraint convolutional code has long been on my To Do list -- it just hasn't yet got close enough to the top. By all means, I'd sat it's worth a try! These days, memory is not likely to be an issue. -- 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 |
|
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 |
|
From: Joe T. <jo...@pr...> - 2015-05-18 14:09:12
|
A few more thoughts about dial calibration errors. A couple of days ago I put my TS-2000 radio through the calibration procedure described in Appendix C of the WSPR 4.0 User's Guide http://physics.princeton.edu/pulsar/K1JT/WSPR_4.0_User.pdf The procedure takes about half an hour, end to end, yielding the values of two constants A and B. These constants appear in the equation d = A + B*f where d is the radio's dial error in Hz and f is the received frequency in MHz. In my case the constants are A = 2.14 Hz and B = 1.6254. I note that the value of A has remained constant, but several years ago B was somewhat smaller (B = 1.2885 in 2011), so the master oscillator in my TS-2000 has aged a bit. From the values of A and B I computed the dial error for each amateur band and entered those values (expressed in MHz) in the "Offset" column of the WSJT-X Settings | Frequencies tab. Frequencies reported for my WSPR decodes now agree with those reported by Steve, K9AN, to within 1 Hz. (Steve's receiver uses GPS-disciplined oscillators, so his WSPR reports are a good standard for comparison.) It might be handy to permit a user of WSJT-X to enter values for A and B and have the program calculate the resulting "Offset" values for the Frequencies tab. The resulting system behavior is very sensible, in my opinion. When WSPRing on 20 meters, for example, my TS-2000 dial now reads 14.09562 MHz. WSJT-X intentionally sets the radio about 24 Hz high on this band, to compensate for its dial error. The dial frequency displayed on the WSJT-X main window is the corrected value, 14.095 600 MHz. -- 73, Joe, K1JT On 5/13/2015 10:48 AM, Joe Taylor wrote: > Hi all, > > One of the fun things about WSPR is the frequency accuracies that > are involved. Having WSPR mode in WSJT-X motivates some serious thought > about how best to handle frequency calibration errors in transceivers. > > Typical dial readout errors in modern radios are a few parts per million > -- for example, a 20 Hz error at 14 MHz. For JT65 or JT9 such > discrepancies are not very important. But the WSPR sub-bands in > conventional use since 2008 are only 200 Hz wide, and we'd like to use > all of that range effectively. If my transceiver's dial reads 20 Hz > low, and yours reads 20 Hz high, and we both set our dials to the > conventional 14.0956 MHz for 20 meters, after setting our WSPR Tx > frequencies at random within the 200 Hz sub-band there's something like > a 20% chance that we won't decode one another. > > Earlier production versions of WSPR have handled these issues in a > rather sophisticated way. The User's Guide includes detailed > instructions for determining calibration constants for your transceiver > using over-the-air signals (see Appendix C of > http://physics.princeton.edu/pulsar/K1JT/WSPR_3.0_User.pdf ). The > resulting accuracies can be better than 1 Hz. > > If CAT control is in use and "Enable frequency correction" is ticked on > WSPR's "Advanced Setup" window, frequencies sent to the radio are > adjusted so as to compensate for the dial errors. For example, if > 14.0956 MHz has been requested, the command for 14095620 Hz may be sent > to the radio. > > I picture this being implemented in WSJT-X in a similar way. In this > example, the radio dial would read 14.096520. I'm suggesting that the > frequency readout on the WSJT-X screen would read 14.095600, the > supposedly "true" frequency. > > Comments and suggestions would be welcome. > > -- 73, 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 |
|
From: Edson W. R. P. <ewp...@gm...> - 2015-05-18 17:14:26
|
Hello Joe, I just checked some of the common received spots between my station and Steve's on 15m and I am 9 Hz off (down). This makes me think that having a standard station in WSPR like Steve's could allow an automatic calibration by performing a query on the wsprnet database for our station and a standard one and compare the results The difference could be converted into the A and B values. Could this work? 73, Edson PY2SDR --- - We humans have the capability to do amazing things if we work together. - Nós seres humanos temos a capacidade de fazer coisas incríveis se trabalharmos juntos. On Mon, May 18, 2015 at 11:09 AM, Joe Taylor <jo...@pr...> wrote: > A few more thoughts about dial calibration errors. > > A couple of days ago I put my TS-2000 radio through the calibration > procedure described in Appendix C of the WSPR 4.0 User's Guide > http://physics.princeton.edu/pulsar/K1JT/WSPR_4.0_User.pdf > > The procedure takes about half an hour, end to end, yielding the values > of two constants A and B. These constants appear in the equation > > d = A + B*f > > where d is the radio's dial error in Hz and f is the received frequency > in MHz. In my case the constants are A = 2.14 Hz and B = 1.6254. I > note that the value of A has remained constant, but several years ago B > was somewhat smaller (B = 1.2885 in 2011), so the master oscillator in > my TS-2000 has aged a bit. > > From the values of A and B I computed the dial error for each amateur > band and entered those values (expressed in MHz) in the "Offset" column > of the WSJT-X Settings | Frequencies tab. Frequencies reported for my > WSPR decodes now agree with those reported by Steve, K9AN, to within 1 > Hz. (Steve's receiver uses GPS-disciplined oscillators, so his WSPR > reports are a good standard for comparison.) > > It might be handy to permit a user of WSJT-X to enter values for A and B > and have the program calculate the resulting "Offset" values for the > Frequencies tab. The resulting system behavior is very sensible, in my > opinion. When WSPRing on 20 meters, for example, my TS-2000 dial now > reads 14.09562 MHz. WSJT-X intentionally sets the radio about 24 Hz > high on this band, to compensate for its dial error. > > The dial frequency displayed on the WSJT-X main window is the corrected > value, 14.095 600 MHz. > > -- 73, Joe, K1JT > > On 5/13/2015 10:48 AM, Joe Taylor wrote: > > Hi all, > > > > One of the fun things about WSPR is the frequency accuracies that > > are involved. Having WSPR mode in WSJT-X motivates some serious thought > > about how best to handle frequency calibration errors in transceivers. > > > > Typical dial readout errors in modern radios are a few parts per million > > -- for example, a 20 Hz error at 14 MHz. For JT65 or JT9 such > > discrepancies are not very important. But the WSPR sub-bands in > > conventional use since 2008 are only 200 Hz wide, and we'd like to use > > all of that range effectively. If my transceiver's dial reads 20 Hz > > low, and yours reads 20 Hz high, and we both set our dials to the > > conventional 14.0956 MHz for 20 meters, after setting our WSPR Tx > > frequencies at random within the 200 Hz sub-band there's something like > > a 20% chance that we won't decode one another. > > > > Earlier production versions of WSPR have handled these issues in a > > rather sophisticated way. The User's Guide includes detailed > > instructions for determining calibration constants for your transceiver > > using over-the-air signals (see Appendix C of > > http://physics.princeton.edu/pulsar/K1JT/WSPR_3.0_User.pdf ). The > > resulting accuracies can be better than 1 Hz. > > > > If CAT control is in use and "Enable frequency correction" is ticked on > > WSPR's "Advanced Setup" window, frequencies sent to the radio are > > adjusted so as to compensate for the dial errors. For example, if > > 14.0956 MHz has been requested, the command for 14095620 Hz may be sent > > to the radio. > > > > I picture this being implemented in WSJT-X in a similar way. In this > > example, the radio dial would read 14.096520. I'm suggesting that the > > frequency readout on the WSJT-X screen would read 14.095600, the > > supposedly "true" frequency. > > > > Comments and suggestions would be welcome. > > > > -- 73, 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 > |
|
From: Michael B. <mdb...@ya...> - 2015-05-18 17:21:47
|
You have to have samples along the entire frequency band to get a fit for slope an intercept. One freq doesn't do it. You really only need 2 for a linear fit but more samples gets a bit more accurate. I've just about got this thing coded up…and you COULD just put a fixed value in A if all you do is one band. So in your case you could stick a -9 in A and perhaps that's all you need. Mike W9MDB From: Edson W. R. Pereira [mailto:ewp...@gm...] Sent: Monday, May 18, 2015 12:14 PM To: WSJT software development Subject: Re: [wsjt-devel] Dial calibration errors Hello Joe, I just checked some of the common received spots between my station and Steve's on 15m and I am 9 Hz off (down). This makes me think that having a standard station in WSPR like Steve's could allow an automatic calibration by performing a query on the wsprnet database for our station and a standard one and compare the results The difference could be converted into the A and B values. Could this work? 73, Edson PY2SDR --- - We humans have the capability to do amazing things if we work together. - Nós seres humanos temos a capacidade de fazer coisas incríveis se trabalharmos juntos. On Mon, May 18, 2015 at 11:09 AM, Joe Taylor <jo...@pr...> wrote: A few more thoughts about dial calibration errors. A couple of days ago I put my TS-2000 radio through the calibration procedure described in Appendix C of the WSPR 4.0 User's Guide http://physics.princeton.edu/pulsar/K1JT/WSPR_4.0_User.pdf The procedure takes about half an hour, end to end, yielding the values of two constants A and B. These constants appear in the equation d = A + B*f where d is the radio's dial error in Hz and f is the received frequency in MHz. In my case the constants are A = 2.14 Hz and B = 1.6254. I note that the value of A has remained constant, but several years ago B was somewhat smaller (B = 1.2885 in 2011), so the master oscillator in my TS-2000 has aged a bit. From the values of A and B I computed the dial error for each amateur band and entered those values (expressed in MHz) in the "Offset" column of the WSJT-X Settings | Frequencies tab. Frequencies reported for my WSPR decodes now agree with those reported by Steve, K9AN, to within 1 Hz. (Steve's receiver uses GPS-disciplined oscillators, so his WSPR reports are a good standard for comparison.) It might be handy to permit a user of WSJT-X to enter values for A and B and have the program calculate the resulting "Offset" values for the Frequencies tab. The resulting system behavior is very sensible, in my opinion. When WSPRing on 20 meters, for example, my TS-2000 dial now reads 14.09562 MHz. WSJT-X intentionally sets the radio about 24 Hz high on this band, to compensate for its dial error. The dial frequency displayed on the WSJT-X main window is the corrected value, 14.095 600 MHz. -- 73, Joe, K1JT On 5/13/2015 10:48 AM, Joe Taylor wrote: > Hi all, > > One of the fun things about WSPR is the frequency accuracies that > are involved. Having WSPR mode in WSJT-X motivates some serious thought > about how best to handle frequency calibration errors in transceivers. > > Typical dial readout errors in modern radios are a few parts per million > -- for example, a 20 Hz error at 14 MHz. For JT65 or JT9 such > discrepancies are not very important. But the WSPR sub-bands in > conventional use since 2008 are only 200 Hz wide, and we'd like to use > all of that range effectively. If my transceiver's dial reads 20 Hz > low, and yours reads 20 Hz high, and we both set our dials to the > conventional 14.0956 MHz for 20 meters, after setting our WSPR Tx > frequencies at random within the 200 Hz sub-band there's something like > a 20% chance that we won't decode one another. > > Earlier production versions of WSPR have handled these issues in a > rather sophisticated way. The User's Guide includes detailed > instructions for determining calibration constants for your transceiver > using over-the-air signals (see Appendix C of > http://physics.princeton.edu/pulsar/K1JT/WSPR_3.0_User.pdf ). The > resulting accuracies can be better than 1 Hz. > > If CAT control is in use and "Enable frequency correction" is ticked on > WSPR's "Advanced Setup" window, frequencies sent to the radio are > adjusted so as to compensate for the dial errors. For example, if > 14.0956 MHz has been requested, the command for 14095620 Hz may be sent > to the radio. > > I picture this being implemented in WSJT-X in a similar way. In this > example, the radio dial would read 14.096520. I'm suggesting that the > frequency readout on the WSJT-X screen would read 14.095600, the > supposedly "true" frequency. > > Comments and suggestions would be welcome. > > -- 73, 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 |
|
From: Edson W. R. P. <ewp...@gm...> - 2015-05-18 19:03:03
|
Hi Mike, You are correct. I should have mentioned that the same measurement should be done on a different band in order to have the second set of measurements. With band hopping and one calibrated station it may be possible? 73, Edson PY2SDR --- - We humans have the capability to do amazing things if we work together. - Nós seres humanos temos a capacidade de fazer coisas incríveis se trabalharmos juntos. On Mon, May 18, 2015 at 2:21 PM, Michael Black <mdb...@ya...> wrote: > You have to have samples along the entire frequency band to get a fit for > slope an intercept. > > One freq doesn't do it. You really only need 2 for a linear fit but more > samples gets a bit more accurate. > > > > I've just about got this thing coded up…and you COULD just put a fixed > value in A if all you do is one band. So in your case you could stick a > -9 in A and perhaps that's all you need. > > Mike W9MDB > > > > *From:* Edson W. R. Pereira [mailto:ewp...@gm...] > *Sent:* Monday, May 18, 2015 12:14 PM > *To:* WSJT software development > *Subject:* Re: [wsjt-devel] Dial calibration errors > > > > > > Hello Joe, > > > > I just checked some of the common received spots between my station and > Steve's on 15m and I am 9 Hz off (down). This makes me think that having a > standard station in WSPR like Steve's could allow an automatic calibration > by performing a query on the wsprnet database for our station and a > standard one and compare the results The difference could be converted into > the A and B values. Could this work? > > > > 73, Edson PY2SDR > > > > > --- > > - We humans have the capability to do amazing things if we work together. > > - Nós seres humanos temos a capacidade de fazer coisas incríveis se > trabalharmos juntos. > > > > On Mon, May 18, 2015 at 11:09 AM, Joe Taylor <jo...@pr...> wrote: > > A few more thoughts about dial calibration errors. > > A couple of days ago I put my TS-2000 radio through the calibration > procedure described in Appendix C of the WSPR 4.0 User's Guide > http://physics.princeton.edu/pulsar/K1JT/WSPR_4.0_User.pdf > > The procedure takes about half an hour, end to end, yielding the values > of two constants A and B. These constants appear in the equation > > d = A + B*f > > where d is the radio's dial error in Hz and f is the received frequency > in MHz. In my case the constants are A = 2.14 Hz and B = 1.6254. I > note that the value of A has remained constant, but several years ago B > was somewhat smaller (B = 1.2885 in 2011), so the master oscillator in > my TS-2000 has aged a bit. > > From the values of A and B I computed the dial error for each amateur > band and entered those values (expressed in MHz) in the "Offset" column > of the WSJT-X Settings | Frequencies tab. Frequencies reported for my > WSPR decodes now agree with those reported by Steve, K9AN, to within 1 > Hz. (Steve's receiver uses GPS-disciplined oscillators, so his WSPR > reports are a good standard for comparison.) > > It might be handy to permit a user of WSJT-X to enter values for A and B > and have the program calculate the resulting "Offset" values for the > Frequencies tab. The resulting system behavior is very sensible, in my > opinion. When WSPRing on 20 meters, for example, my TS-2000 dial now > reads 14.09562 MHz. WSJT-X intentionally sets the radio about 24 Hz > high on this band, to compensate for its dial error. > > The dial frequency displayed on the WSJT-X main window is the corrected > value, 14.095 600 MHz. > > -- 73, Joe, K1JT > > > On 5/13/2015 10:48 AM, Joe Taylor wrote: > > Hi all, > > > > One of the fun things about WSPR is the frequency accuracies that > > are involved. Having WSPR mode in WSJT-X motivates some serious thought > > about how best to handle frequency calibration errors in transceivers. > > > > Typical dial readout errors in modern radios are a few parts per million > > -- for example, a 20 Hz error at 14 MHz. For JT65 or JT9 such > > discrepancies are not very important. But the WSPR sub-bands in > > conventional use since 2008 are only 200 Hz wide, and we'd like to use > > all of that range effectively. If my transceiver's dial reads 20 Hz > > low, and yours reads 20 Hz high, and we both set our dials to the > > conventional 14.0956 MHz for 20 meters, after setting our WSPR Tx > > frequencies at random within the 200 Hz sub-band there's something like > > a 20% chance that we won't decode one another. > > > > Earlier production versions of WSPR have handled these issues in a > > rather sophisticated way. The User's Guide includes detailed > > instructions for determining calibration constants for your transceiver > > using over-the-air signals (see Appendix C of > > http://physics.princeton.edu/pulsar/K1JT/WSPR_3.0_User.pdf ). The > > resulting accuracies can be better than 1 Hz. > > > > If CAT control is in use and "Enable frequency correction" is ticked on > > WSPR's "Advanced Setup" window, frequencies sent to the radio are > > adjusted so as to compensate for the dial errors. For example, if > > 14.0956 MHz has been requested, the command for 14095620 Hz may be sent > > to the radio. > > > > I picture this being implemented in WSJT-X in a similar way. In this > > example, the radio dial would read 14.096520. I'm suggesting that the > > frequency readout on the WSJT-X screen would read 14.095600, the > > supposedly "true" frequency. > > > > Comments and suggestions would be welcome. > > > > -- 73, 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 > > |
|
From: Michael B. <mdb...@ya...> - 2015-05-18 19:10:48
Attachments:
calibrated.patch
|
If you mean can you compute it yourself…sure… http://www.miniwebtool.com/slope-intercept-form-calculator/ Just put the frequencies expected in X and what you measure in Y. Attached is a patch against 1.6.1 that adds intercept and slope to the Frequencies tab. You do have to change band after setting as I couldn't quite figure out how to force an update and exactly when that should be done (on exiting dialog? After entering either number?). Might also need some mention that you do either this or the offsets in the table…both are possible but not sure that makes any sense to do. 73 Mike W9MDB From: Edson W. R. Pereira [mailto:ewp...@gm...] Sent: Monday, May 18, 2015 2:03 PM To: WSJT software development Subject: Re: [wsjt-devel] Dial calibration errors Hi Mike, You are correct. I should have mentioned that the same measurement should be done on a different band in order to have the second set of measurements. With band hopping and one calibrated station it may be possible? 73, Edson PY2SDR --- - We humans have the capability to do amazing things if we work together. - Nós seres humanos temos a capacidade de fazer coisas incríveis se trabalharmos juntos. On Mon, May 18, 2015 at 2:21 PM, Michael Black <mdb...@ya...> wrote: You have to have samples along the entire frequency band to get a fit for slope an intercept. One freq doesn't do it. You really only need 2 for a linear fit but more samples gets a bit more accurate. I've just about got this thing coded up…and you COULD just put a fixed value in A if all you do is one band. So in your case you could stick a -9 in A and perhaps that's all you need. Mike W9MDB From: Edson W. R. Pereira [mailto:ewp...@gm...] Sent: Monday, May 18, 2015 12:14 PM To: WSJT software development Subject: Re: [wsjt-devel] Dial calibration errors Hello Joe, I just checked some of the common received spots between my station and Steve's on 15m and I am 9 Hz off (down). This makes me think that having a standard station in WSPR like Steve's could allow an automatic calibration by performing a query on the wsprnet database for our station and a standard one and compare the results The difference could be converted into the A and B values. Could this work? 73, Edson PY2SDR --- - We humans have the capability to do amazing things if we work together. - Nós seres humanos temos a capacidade de fazer coisas incríveis se trabalharmos juntos. On Mon, May 18, 2015 at 11:09 AM, Joe Taylor <jo...@pr...> wrote: A few more thoughts about dial calibration errors. A couple of days ago I put my TS-2000 radio through the calibration procedure described in Appendix C of the WSPR 4.0 User's Guide http://physics.princeton.edu/pulsar/K1JT/WSPR_4.0_User.pdf The procedure takes about half an hour, end to end, yielding the values of two constants A and B. These constants appear in the equation d = A + B*f where d is the radio's dial error in Hz and f is the received frequency in MHz. In my case the constants are A = 2.14 Hz and B = 1.6254. I note that the value of A has remained constant, but several years ago B was somewhat smaller (B = 1.2885 in 2011), so the master oscillator in my TS-2000 has aged a bit. From the values of A and B I computed the dial error for each amateur band and entered those values (expressed in MHz) in the "Offset" column of the WSJT-X Settings | Frequencies tab. Frequencies reported for my WSPR decodes now agree with those reported by Steve, K9AN, to within 1 Hz. (Steve's receiver uses GPS-disciplined oscillators, so his WSPR reports are a good standard for comparison.) It might be handy to permit a user of WSJT-X to enter values for A and B and have the program calculate the resulting "Offset" values for the Frequencies tab. The resulting system behavior is very sensible, in my opinion. When WSPRing on 20 meters, for example, my TS-2000 dial now reads 14.09562 MHz. WSJT-X intentionally sets the radio about 24 Hz high on this band, to compensate for its dial error. The dial frequency displayed on the WSJT-X main window is the corrected value, 14.095 600 MHz. -- 73, Joe, K1JT On 5/13/2015 10:48 AM, Joe Taylor wrote: > Hi all, > > One of the fun things about WSPR is the frequency accuracies that > are involved. Having WSPR mode in WSJT-X motivates some serious thought > about how best to handle frequency calibration errors in transceivers. > > Typical dial readout errors in modern radios are a few parts per million > -- for example, a 20 Hz error at 14 MHz. For JT65 or JT9 such > discrepancies are not very important. But the WSPR sub-bands in > conventional use since 2008 are only 200 Hz wide, and we'd like to use > all of that range effectively. If my transceiver's dial reads 20 Hz > low, and yours reads 20 Hz high, and we both set our dials to the > conventional 14.0956 MHz for 20 meters, after setting our WSPR Tx > frequencies at random within the 200 Hz sub-band there's something like > a 20% chance that we won't decode one another. > > Earlier production versions of WSPR have handled these issues in a > rather sophisticated way. The User's Guide includes detailed > instructions for determining calibration constants for your transceiver > using over-the-air signals (see Appendix C of > http://physics.princeton.edu/pulsar/K1JT/WSPR_3.0_User.pdf ). The > resulting accuracies can be better than 1 Hz. > > If CAT control is in use and "Enable frequency correction" is ticked on > WSPR's "Advanced Setup" window, frequencies sent to the radio are > adjusted so as to compensate for the dial errors. For example, if > 14.0956 MHz has been requested, the command for 14095620 Hz may be sent > to the radio. > > I picture this being implemented in WSJT-X in a similar way. In this > example, the radio dial would read 14.096520. I'm suggesting that the > frequency readout on the WSJT-X screen would read 14.095600, the > supposedly "true" frequency. > > Comments and suggestions would be welcome. > > -- 73, 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 |
|
From: Bill S. <g4...@cl...> - 2015-05-18 21:33:46
|
On 18/05/2015 20:10, Michael Black wrote: Hi Mike, > > If you mean can you compute it yourself…sure… > http://www.miniwebtool.com/slope-intercept-form-calculator/ Just put > the frequencies expected in X and what you measure in Y. > > Attached is a patch against 1.6.1 that adds intercept and slope to the > Frequencies tab. You do have to change band after setting as I > couldn't quite figure out how to force an update and exactly when that > should be done (on exiting dialog? After entering either number?). > > Might also need some mention that you do either this or the offsets in > the table…both are possible but not sure that makes any sense to do. > You can simplify that patch considerably by not adding the linear correction constants to the Configuration public interface. They are only needed within the Configuration class implementation. Also you probably want to take out the "RR73" change as it is unrelated and probably not intended. > > 73 > > Mike W9MDB > 73 Bill G4WJS. > > *From:*Edson W. R. Pereira [mailto:ewp...@gm...] > *Sent:* Monday, May 18, 2015 2:03 PM > *To:* WSJT software development > *Subject:* Re: [wsjt-devel] Dial calibration errors > > Hi Mike, > > You are correct. I should have mentioned that the same measurement > should be done on a different band in order to have the second set of > measurements. With band hopping and one calibrated station it may be > possible? > > 73, Edson PY2SDR > > > --- > > - We humans have the capability to do amazing things if we work together. > > - Nós seres humanos temos a capacidade de fazer coisas incríveis se > trabalharmos juntos. > > On Mon, May 18, 2015 at 2:21 PM, Michael Black <mdb...@ya... > <mailto:mdb...@ya...>> wrote: > > You have to have samples along the entire frequency band to get a fit > for slope an intercept. > > One freq doesn't do it. You really only need 2 for a linear fit but > more samples gets a bit more accurate. > > I've just about got this thing coded up…and you COULD just put a fixed > value in A if all you do is one band. So in your case you could > stick a -9 in A and perhaps that's all you need. > > Mike W9MDB > > *From:*Edson W. R. Pereira [mailto:ewp...@gm... > <mailto:ewp...@gm...>] > *Sent:* Monday, May 18, 2015 12:14 PM > *To:* WSJT software development > *Subject:* Re: [wsjt-devel] Dial calibration errors > > Hello Joe, > > I just checked some of the common received spots between my station > and Steve's on 15m and I am 9 Hz off (down). This makes me think that > having a standard station in WSPR like Steve's could allow an > automatic calibration by performing a query on the wsprnet database > for our station and a standard one and compare the results The > difference could be converted into the A and B values. Could this work? > > 73, Edson PY2SDR > > > --- > > - We humans have the capability to do amazing things if we work together. > > - Nós seres humanos temos a capacidade de fazer coisas incríveis se > trabalharmos juntos. > > On Mon, May 18, 2015 at 11:09 AM, Joe Taylor <jo...@pr... > <mailto:jo...@pr...>> wrote: > > A few more thoughts about dial calibration errors. > > A couple of days ago I put my TS-2000 radio through the calibration > procedure described in Appendix C of the WSPR 4.0 User's Guide > http://physics.princeton.edu/pulsar/K1JT/WSPR_4.0_User.pdf > > The procedure takes about half an hour, end to end, yielding the values > of two constants A and B. These constants appear in the equation > > d = A + B*f > > where d is the radio's dial error in Hz and f is the received frequency > in MHz. In my case the constants are A = 2.14 Hz and B = 1.6254. I > note that the value of A has remained constant, but several years ago B > was somewhat smaller (B = 1.2885 in 2011), so the master oscillator in > my TS-2000 has aged a bit. > > From the values of A and B I computed the dial error for each amateur > band and entered those values (expressed in MHz) in the "Offset" column > of the WSJT-X Settings | Frequencies tab. Frequencies reported for my > WSPR decodes now agree with those reported by Steve, K9AN, to within 1 > Hz. (Steve's receiver uses GPS-disciplined oscillators, so his WSPR > reports are a good standard for comparison.) > > It might be handy to permit a user of WSJT-X to enter values for A and B > and have the program calculate the resulting "Offset" values for the > Frequencies tab. The resulting system behavior is very sensible, in my > opinion. When WSPRing on 20 meters, for example, my TS-2000 dial now > reads 14.09562 MHz. WSJT-X intentionally sets the radio about 24 Hz > high on this band, to compensate for its dial error. > > The dial frequency displayed on the WSJT-X main window is the corrected > value, 14.095 600 MHz. > > -- 73, Joe, K1JT > > > On 5/13/2015 10:48 AM, Joe Taylor wrote: > > Hi all, > > > > One of the fun things about WSPR is the frequency accuracies that > > are involved. Having WSPR mode in WSJT-X motivates some serious thought > > about how best to handle frequency calibration errors in transceivers. > > > > Typical dial readout errors in modern radios are a few parts per million > > -- for example, a 20 Hz error at 14 MHz. For JT65 or JT9 such > > discrepancies are not very important. But the WSPR sub-bands in > > conventional use since 2008 are only 200 Hz wide, and we'd like to use > > all of that range effectively. If my transceiver's dial reads 20 Hz > > low, and yours reads 20 Hz high, and we both set our dials to the > > conventional 14.0956 MHz for 20 meters, after setting our WSPR Tx > > frequencies at random within the 200 Hz sub-band there's something like > > a 20% chance that we won't decode one another. > > > > Earlier production versions of WSPR have handled these issues in a > > rather sophisticated way. The User's Guide includes detailed > > instructions for determining calibration constants for your transceiver > > using over-the-air signals (see Appendix C of > > http://physics.princeton.edu/pulsar/K1JT/WSPR_3.0_User.pdf ). The > > resulting accuracies can be better than 1 Hz. > > > > If CAT control is in use and "Enable frequency correction" is ticked on > > WSPR's "Advanced Setup" window, frequencies sent to the radio are > > adjusted so as to compensate for the dial errors. For example, if > > 14.0956 MHz has been requested, the command for 14095620 Hz may be sent > > to the radio. > > > > I picture this being implemented in WSJT-X in a similar way. In this > > example, the radio dial would read 14.096520. I'm suggesting that the > > frequency readout on the WSJT-X screen would read 14.095600, the > > supposedly "true" frequency. > > > > Comments and suggestions would be welcome. > > > > -- 73, Joe, K1JT > |
|
From: Michael B. <mdb...@ya...> - 2015-05-19 04:18:16
Attachments:
calibrate.patch
|
Thanks Bill .yup forgot to remove the RR73 from my other experimentation. Removed the public API too. So patch is definitely smaller now. 73 Mike W9MDB From: Bill Somerville [mailto:g4...@cl...] Sent: Monday, May 18, 2015 4:34 PM To: wsj...@li... Subject: Re: [wsjt-devel] Dial calibration errors On 18/05/2015 20:10, Michael Black wrote: Hi Mike, If you mean can you compute it yourself sure http://www.miniwebtool.com/slope-intercept-form-calculator/ Just put the frequencies expected in X and what you measure in Y. Attached is a patch against 1.6.1 that adds intercept and slope to the Frequencies tab. You do have to change band after setting as I couldn't quite figure out how to force an update and exactly when that should be done (on exiting dialog? After entering either number?). Might also need some mention that you do either this or the offsets in the table both are possible but not sure that makes any sense to do. You can simplify that patch considerably by not adding the linear correction constants to the Configuration public interface. They are only needed within the Configuration class implementation. Also you probably want to take out the "RR73" change as it is unrelated and probably not intended. 73 Mike W9MDB 73 Bill G4WJS. From: Edson W. R. Pereira [mailto:ewp...@gm...] Sent: Monday, May 18, 2015 2:03 PM To: WSJT software development Subject: Re: [wsjt-devel] Dial calibration errors Hi Mike, You are correct. I should have mentioned that the same measurement should be done on a different band in order to have the second set of measurements. With band hopping and one calibrated station it may be possible? 73, Edson PY2SDR --- - We humans have the capability to do amazing things if we work together. - Nós seres humanos temos a capacidade de fazer coisas incríveis se trabalharmos juntos. On Mon, May 18, 2015 at 2:21 PM, Michael Black <mdb...@ya...> wrote: You have to have samples along the entire frequency band to get a fit for slope an intercept. One freq doesn't do it. You really only need 2 for a linear fit but more samples gets a bit more accurate. I've just about got this thing coded up and you COULD just put a fixed value in A if all you do is one band. So in your case you could stick a -9 in A and perhaps that's all you need. Mike W9MDB From: Edson W. R. Pereira [mailto:ewp...@gm...] Sent: Monday, May 18, 2015 12:14 PM To: WSJT software development Subject: Re: [wsjt-devel] Dial calibration errors Hello Joe, I just checked some of the common received spots between my station and Steve's on 15m and I am 9 Hz off (down). This makes me think that having a standard station in WSPR like Steve's could allow an automatic calibration by performing a query on the wsprnet database for our station and a standard one and compare the results The difference could be converted into the A and B values. Could this work? 73, Edson PY2SDR --- - We humans have the capability to do amazing things if we work together. - Nós seres humanos temos a capacidade de fazer coisas incríveis se trabalharmos juntos. On Mon, May 18, 2015 at 11:09 AM, Joe Taylor <jo...@pr...> wrote: A few more thoughts about dial calibration errors. A couple of days ago I put my TS-2000 radio through the calibration procedure described in Appendix C of the WSPR 4.0 User's Guide http://physics.princeton.edu/pulsar/K1JT/WSPR_4.0_User.pdf The procedure takes about half an hour, end to end, yielding the values of two constants A and B. These constants appear in the equation d = A + B*f where d is the radio's dial error in Hz and f is the received frequency in MHz. In my case the constants are A = 2.14 Hz and B = 1.6254. I note that the value of A has remained constant, but several years ago B was somewhat smaller (B = 1.2885 in 2011), so the master oscillator in my TS-2000 has aged a bit. From the values of A and B I computed the dial error for each amateur band and entered those values (expressed in MHz) in the "Offset" column of the WSJT-X Settings | Frequencies tab. Frequencies reported for my WSPR decodes now agree with those reported by Steve, K9AN, to within 1 Hz. (Steve's receiver uses GPS-disciplined oscillators, so his WSPR reports are a good standard for comparison.) It might be handy to permit a user of WSJT-X to enter values for A and B and have the program calculate the resulting "Offset" values for the Frequencies tab. The resulting system behavior is very sensible, in my opinion. When WSPRing on 20 meters, for example, my TS-2000 dial now reads 14.09562 MHz. WSJT-X intentionally sets the radio about 24 Hz high on this band, to compensate for its dial error. The dial frequency displayed on the WSJT-X main window is the corrected value, 14.095 600 MHz. -- 73, Joe, K1JT On 5/13/2015 10:48 AM, Joe Taylor wrote: > Hi all, > > One of the fun things about WSPR is the frequency accuracies that > are involved. Having WSPR mode in WSJT-X motivates some serious thought > about how best to handle frequency calibration errors in transceivers. > > Typical dial readout errors in modern radios are a few parts per million > -- for example, a 20 Hz error at 14 MHz. For JT65 or JT9 such > discrepancies are not very important. But the WSPR sub-bands in > conventional use since 2008 are only 200 Hz wide, and we'd like to use > all of that range effectively. If my transceiver's dial reads 20 Hz > low, and yours reads 20 Hz high, and we both set our dials to the > conventional 14.0956 MHz for 20 meters, after setting our WSPR Tx > frequencies at random within the 200 Hz sub-band there's something like > a 20% chance that we won't decode one another. > > Earlier production versions of WSPR have handled these issues in a > rather sophisticated way. The User's Guide includes detailed > instructions for determining calibration constants for your transceiver > using over-the-air signals (see Appendix C of > http://physics.princeton.edu/pulsar/K1JT/WSPR_3.0_User.pdf ). The > resulting accuracies can be better than 1 Hz. > > If CAT control is in use and "Enable frequency correction" is ticked on > WSPR's "Advanced Setup" window, frequencies sent to the radio are > adjusted so as to compensate for the dial errors. For example, if > 14.0956 MHz has been requested, the command for 14095620 Hz may be sent > to the radio. > > I picture this being implemented in WSJT-X in a similar way. In this > example, the radio dial would read 14.096520. I'm suggesting that the > frequency readout on the WSJT-X screen would read 14.095600, the > supposedly "true" frequency. > > Comments and suggestions would be welcome. > > -- 73, Joe, K1JT |
|
From: Bill S. <g4...@cl...> - 2015-05-19 18:08:01
|
On 19/05/2015 05:18, Michael Black wrote: Hi Mike & All > > Thanks Bill….yup…forgot to remove the RR73 from my other > experimentation. Removed the public API too. So patch is definitely > smaller now. > I have implemented a change based on your patch. I had to change it a bit to make it more robust and also corrected the math errors ;) It does behave a bit strangely on rigs with less than 1 Hz resolution but there's not a great deal we can do that is better for them, at least it is benign if the calibration constants are zero. Currently the intercept error is +/- 10 kHz and the slope factor is +/- 1000 ppm which is probably enough range. > > 73 > > Mike W9MDB > 73 Bill G4WJS. > > *From:*Bill Somerville [mailto:g4...@cl...] > *Sent:* Monday, May 18, 2015 4:34 PM > *To:* wsj...@li... > *Subject:* Re: [wsjt-devel] Dial calibration errors > > On 18/05/2015 20:10, Michael Black wrote: > Hi Mike, > > If you mean can you compute it yourself…sure… > http://www.miniwebtool.com/slope-intercept-form-calculator/ Just > put the frequencies expected in X and what you measure in Y. > > Attached is a patch against 1.6.1 that adds intercept and slope to > the Frequencies tab. You do have to change band after setting as > I couldn't quite figure out how to force an update and exactly > when that should be done (on exiting dialog? After entering > either number?). > > Might also need some mention that you do either this or the > offsets in the table…both are possible but not sure that makes any > sense to do. > > You can simplify that patch considerably by not adding the linear > correction constants to the Configuration public interface. They are > only needed within the Configuration class implementation. > > Also you probably want to take out the "RR73" change as it is > unrelated and probably not intended. > > 73 > > Mike W9MDB > > 73 > Bill > G4WJS. > > *From:*Edson W. R. Pereira [mailto:ewp...@gm...] > *Sent:* Monday, May 18, 2015 2:03 PM > *To:* WSJT software development > *Subject:* Re: [wsjt-devel] Dial calibration errors > > Hi Mike, > > You are correct. I should have mentioned that the same measurement > should be done on a different band in order to have the second set of > measurements. With band hopping and one calibrated station it may be > possible? > > 73, Edson PY2SDR > > > --- > > - We humans have the capability to do amazing things if we work together. > > - Nós seres humanos temos a capacidade de fazer coisas incríveis se > trabalharmos juntos. > > On Mon, May 18, 2015 at 2:21 PM, Michael Black <mdb...@ya... > <mailto:mdb...@ya...>> wrote: > > You have to have samples along the entire frequency band to get a fit > for slope an intercept. > > One freq doesn't do it. You really only need 2 for a linear fit but > more samples gets a bit more accurate. > > I've just about got this thing coded up…and you COULD just put a fixed > value in A if all you do is one band. So in your case you could > stick a -9 in A and perhaps that's all you need. > > Mike W9MDB > > *From:*Edson W. R. Pereira [mailto:ewp...@gm... > <mailto:ewp...@gm...>] > *Sent:* Monday, May 18, 2015 12:14 PM > *To:* WSJT software development > *Subject:* Re: [wsjt-devel] Dial calibration errors > > Hello Joe, > > I just checked some of the common received spots between my station > and Steve's on 15m and I am 9 Hz off (down). This makes me think that > having a standard station in WSPR like Steve's could allow an > automatic calibration by performing a query on the wsprnet database > for our station and a standard one and compare the results The > difference could be converted into the A and B values. Could this work? > > 73, Edson PY2SDR > > > --- > > - We humans have the capability to do amazing things if we work together. > > - Nós seres humanos temos a capacidade de fazer coisas incríveis se > trabalharmos juntos. > > On Mon, May 18, 2015 at 11:09 AM, Joe Taylor <jo...@pr... > <mailto:jo...@pr...>> wrote: > > A few more thoughts about dial calibration errors. > > A couple of days ago I put my TS-2000 radio through the calibration > procedure described in Appendix C of the WSPR 4.0 User's Guide > http://physics.princeton.edu/pulsar/K1JT/WSPR_4.0_User.pdf > > The procedure takes about half an hour, end to end, yielding the values > of two constants A and B. These constants appear in the equation > > d = A + B*f > > where d is the radio's dial error in Hz and f is the received frequency > in MHz. In my case the constants are A = 2.14 Hz and B = 1.6254. I > note that the value of A has remained constant, but several years ago B > was somewhat smaller (B = 1.2885 in 2011), so the master oscillator in > my TS-2000 has aged a bit. > > From the values of A and B I computed the dial error for each amateur > band and entered those values (expressed in MHz) in the "Offset" column > of the WSJT-X Settings | Frequencies tab. Frequencies reported for my > WSPR decodes now agree with those reported by Steve, K9AN, to within 1 > Hz. (Steve's receiver uses GPS-disciplined oscillators, so his WSPR > reports are a good standard for comparison.) > > It might be handy to permit a user of WSJT-X to enter values for A and B > and have the program calculate the resulting "Offset" values for the > Frequencies tab. The resulting system behavior is very sensible, in my > opinion. When WSPRing on 20 meters, for example, my TS-2000 dial now > reads 14.09562 MHz. WSJT-X intentionally sets the radio about 24 Hz > high on this band, to compensate for its dial error. > > The dial frequency displayed on the WSJT-X main window is the corrected > value, 14.095 600 MHz. > > -- 73, Joe, K1JT > > > On 5/13/2015 10:48 AM, Joe Taylor wrote: > > Hi all, > > > > One of the fun things about WSPR is the frequency accuracies that > > are involved. Having WSPR mode in WSJT-X motivates some serious thought > > about how best to handle frequency calibration errors in transceivers. > > > > Typical dial readout errors in modern radios are a few parts per million > > -- for example, a 20 Hz error at 14 MHz. For JT65 or JT9 such > > discrepancies are not very important. But the WSPR sub-bands in > > conventional use since 2008 are only 200 Hz wide, and we'd like to use > > all of that range effectively. If my transceiver's dial reads 20 Hz > > low, and yours reads 20 Hz high, and we both set our dials to the > > conventional 14.0956 MHz for 20 meters, after setting our WSPR Tx > > frequencies at random within the 200 Hz sub-band there's something like > > a 20% chance that we won't decode one another. > > > > Earlier production versions of WSPR have handled these issues in a > > rather sophisticated way. The User's Guide includes detailed > > instructions for determining calibration constants for your transceiver > > using over-the-air signals (see Appendix C of > > http://physics.princeton.edu/pulsar/K1JT/WSPR_3.0_User.pdf ). The > > resulting accuracies can be better than 1 Hz. > > > > If CAT control is in use and "Enable frequency correction" is ticked on > > WSPR's "Advanced Setup" window, frequencies sent to the radio are > > adjusted so as to compensate for the dial errors. For example, if > > 14.0956 MHz has been requested, the command for 14095620 Hz may be sent > > to the radio. > > > > I picture this being implemented in WSJT-X in a similar way. In this > > example, the radio dial would read 14.096520. I'm suggesting that the > > frequency readout on the WSJT-X screen would read 14.095600, the > > supposedly "true" frequency. > > > > Comments and suggestions would be welcome. > > > > -- 73, Joe, K1JT > |
|
From: Black M. <mdb...@ya...> - 2015-05-19 19:39:30
|
I installed JTSDK on a new computer and building wsjtx fails as it can't find python.
Turns out JTSDK now installs Python33 and not python27. Compiling on my old computer works as it has both 27 and 33. I assume the 33 came from a JTSDK update.
wsjtxexp compiles OK but doesn't appear to use python.
73
Mike W9MDB
From: Bill Somerville <g4...@cl...>
To: wsj...@li...
Sent: Tuesday, May 19, 2015 1:07 PM
Subject: Re: [wsjt-devel] Dial calibration errors
On 19/05/2015 05:18, Michael Black wrote:
Hi Mike & All
<!--#yiv3900820176 _filtered #yiv3900820176 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv3900820176 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv3900820176 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv3900820176 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv3900820176 #yiv3900820176 p.yiv3900820176MsoNormal, #yiv3900820176 li.yiv3900820176MsoNormal, #yiv3900820176 div.yiv3900820176MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:"Times New Roman", "serif";color:black;}#yiv3900820176 a:link, #yiv3900820176 span.yiv3900820176MsoHyperlink {color:blue;text-decoration:underline;}#yiv3900820176 a:visited, #yiv3900820176 span.yiv3900820176MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv3900820176 p.yiv3900820176MsoAcetate, #yiv3900820176 li.yiv3900820176MsoAcetate, #yiv3900820176 div.yiv3900820176MsoAcetate {margin:0in;margin-bottom:.0001pt;font-size:8.0pt;font-family:"Tahoma", "sans-serif";color:black;}#yiv3900820176 span.yiv3900820176BalloonTextChar {font-family:"Tahoma", "sans-serif";}#yiv3900820176 span.yiv3900820176EmailStyle19 {font-family:"Calibri", "sans-serif";color:#1F497D;}#yiv3900820176 span.yiv3900820176EmailStyle20 {font-family:"Calibri", "sans-serif";color:#1F497D;}#yiv3900820176 .yiv3900820176MsoChpDefault {font-size:10.0pt;} _filtered #yiv3900820176 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv3900820176 div.yiv3900820176WordSection1 {}--> Thanks Bill….yup…forgot to remove the RR73 from my other experimentation. Removed the public API too. So patch is definitely smaller now.
I have implemented a change based on your patch. I had to change it a bit to make it more robust and also corrected the math errors ;)
It does behave a bit strangely on rigs with less than 1 Hz resolution but there's not a great deal we can do that is better for them, at least it is benign if the calibration constants are zero.
Currently the intercept error is +/- 10 kHz and the slope factor is +/- 1000 ppm which is probably enough range.
73 Mike W9MDB
73
Bill
G4WJS.
From: Bill Somerville [mailto:g4...@cl...]
Sent: Monday, May 18, 2015 4:34 PM
To: wsj...@li...
Subject: Re: [wsjt-devel] Dial calibration errors On 18/05/2015 20:10, Michael Black wrote:
Hi Mike,
If you mean can you compute it yourself…sure… http://www.miniwebtool.com/slope-intercept-form-calculator/ Just put the frequencies expected in X and what you measure in Y. Attached is a patch against 1.6.1 that adds intercept and slope to the Frequencies tab. You do have to change band after setting as I couldn't quite figure out how to force an update and exactly when that should be done (on exiting dialog? After entering either number?). Might also need some mention that you do either this or the offsets in the table…both are possible but not sure that makes any sense to do.
You can simplify that patch considerably by not adding the linear correction constants to the Configuration public interface. They are only needed within the Configuration class implementation.
Also you probably want to take out the "RR73" change as it is unrelated and probably not intended.
73 Mike W9MDB 73
Bill
G4WJS.
From: Edson W. R. Pereira [mailto:ewp...@gm...]
Sent: Monday, May 18, 2015 2:03 PM
To: WSJT software development
Subject: Re: [wsjt-devel] Dial calibration errors Hi Mike, You are correct. I should have mentioned that the same measurement should be done on a different band in order to have the second set of measurements. With band hopping and one calibrated station it may be possible? 73, Edson PY2SDR
--- - We humans have the capability to do amazing things if we work together. - Nós seres humanos temos a capacidade de fazer coisas incríveis se trabalharmos juntos. On Mon, May 18, 2015 at 2:21 PM, Michael Black <mdb...@ya...> wrote: You have to have samples along the entire frequency band to get a fit for slope an intercept. One freq doesn't do it. You really only need 2 for a linear fit but more samples gets a bit more accurate. I've just about got this thing coded up…and you COULD just put a fixed value in A if all you do is one band. So in your case you could stick a -9 in A and perhaps that's all you need. Mike W9MDB From: Edson W. R. Pereira [mailto:ewp...@gm...]
Sent: Monday, May 18, 2015 12:14 PM
To: WSJT software development
Subject: Re: [wsjt-devel] Dial calibration errors Hello Joe, I just checked some of the common received spots between my station and Steve's on 15m and I am 9 Hz off (down). This makes me think that having a standard station in WSPR like Steve's could allow an automatic calibration by performing a query on the wsprnet database for our station and a standard one and compare the results The difference could be converted into the A and B values. Could this work? 73, Edson PY2SDR
--- - We humans have the capability to do amazing things if we work together. - Nós seres humanos temos a capacidade de fazer coisas incríveis se trabalharmos juntos. On Mon, May 18, 2015 at 11:09 AM, Joe Taylor <jo...@pr...> wrote: A few more thoughts about dial calibration errors.
A couple of days ago I put my TS-2000 radio through the calibration
procedure described in Appendix C of the WSPR 4.0 User's Guide
http://physics.princeton.edu/pulsar/K1JT/WSPR_4.0_User.pdf
The procedure takes about half an hour, end to end, yielding the values
of two constants A and B. These constants appear in the equation
d = A + B*f
where d is the radio's dial error in Hz and f is the received frequency
in MHz. In my case the constants are A = 2.14 Hz and B = 1.6254. I
note that the value of A has remained constant, but several years ago B
was somewhat smaller (B = 1.2885 in 2011), so the master oscillator in
my TS-2000 has aged a bit.
From the values of A and B I computed the dial error for each amateur
band and entered those values (expressed in MHz) in the "Offset" column
of the WSJT-X Settings | Frequencies tab. Frequencies reported for my
WSPR decodes now agree with those reported by Steve, K9AN, to within 1
Hz. (Steve's receiver uses GPS-disciplined oscillators, so his WSPR
reports are a good standard for comparison.)
It might be handy to permit a user of WSJT-X to enter values for A and B
and have the program calculate the resulting "Offset" values for the
Frequencies tab. The resulting system behavior is very sensible, in my
opinion. When WSPRing on 20 meters, for example, my TS-2000 dial now
reads 14.09562 MHz. WSJT-X intentionally sets the radio about 24 Hz
high on this band, to compensate for its dial error.
The dial frequency displayed on the WSJT-X main window is the corrected
value, 14.095 600 MHz.
-- 73, Joe, K1JT
On 5/13/2015 10:48 AM, Joe Taylor wrote:
> Hi all,
>
> One of the fun things about WSPR is the frequency accuracies that
> are involved. Having WSPR mode in WSJT-X motivates some serious thought
> about how best to handle frequency calibration errors in transceivers.
>
> Typical dial readout errors in modern radios are a few parts per million
> -- for example, a 20 Hz error at 14 MHz. For JT65 or JT9 such
> discrepancies are not very important. But the WSPR sub-bands in
> conventional use since 2008 are only 200 Hz wide, and we'd like to use
> all of that range effectively. If my transceiver's dial reads 20 Hz
> low, and yours reads 20 Hz high, and we both set our dials to the
> conventional 14.0956 MHz for 20 meters, after setting our WSPR Tx
> frequencies at random within the 200 Hz sub-band there's something like
> a 20% chance that we won't decode one another.
>
> Earlier production versions of WSPR have handled these issues in a
> rather sophisticated way. The User's Guide includes detailed
> instructions for determining calibration constants for your transceiver
> using over-the-air signals (see Appendix C of
> http://physics.princeton.edu/pulsar/K1JT/WSPR_3.0_User.pdf ). The
> resulting accuracies can be better than 1 Hz.
>
> If CAT control is in use and "Enable frequency correction" is ticked on
> WSPR's "Advanced Setup" window, frequencies sent to the radio are
> adjusted so as to compensate for the dial errors. For example, if
> 14.0956 MHz has been requested, the command for 14095620 Hz may be sent
> to the radio.
>
> I picture this being implemented in WSJT-X in a similar way. In this
> example, the radio dial would read 14.096520. I'm suggesting that the
> frequency readout on the WSJT-X screen would read 14.095600, the
> supposedly "true" frequency.
>
> Comments and suggestions would be welcome.
>
> -- 73, 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
|
|
From: Bill S. <g4...@cl...> - 2015-05-19 19:49:24
|
On 19/05/2015 20:39, Black Michael wrote: Hi Mike, > I installed JTSDK on a new computer and building wsjtx fails as it > can't find python. > > Turns out JTSDK now installs Python33 and not python27. Compiling on > my old computer works as it has both 27 and 33. I assume the 33 came > from a JTSDK update. Currently ^/branches/wsjtx requires Python >2.4 but <3.0. This is a requirement of Asciidoc which is used to build the user guide. One way or another the CMAKE_PREFIX_PATH need the path to a Python 2.x installation on it. I thought Greg had changed the JTSDK to provide both Asciidoc and a suitable Python version. Currently the CMake option WSJT_GENERATE_DOCS defaults to OFF which should stop this error. Have you turned this option ON? > > wsjtxexp compiles OK but doesn't appear to use python. > 73 > > Mike W9MDB > 73 Bill G4WJS. |
|
From: KI7MT <ki...@gm...> - 2015-05-19 19:58:25
|
Hi Bill, Sorry, but I do not get Mike's emails when posted to the wsjt-devel list. I do get them when posted to the wsjtgroup email address. Yes, I added an update installer that installs both Python2 and AsciiDoc within the C:\JTSDK folder structure. The second update was the the build script and is performed by updating JTSDK from the Start Menu: Start > JTSDK > Update Update Installer Link: http://sourceforge.net/projects/jtsdk/files/win32/2.0.0/JTSDK-2.0.0-u1-win32.exe/download This only applies to the the one WSJT-X branch that you've enabled the doc builds on. 73's Greg, KI7MT On 05/19/2015 01:49 PM, Bill Somerville wrote: > On 19/05/2015 20:39, Black Michael wrote: > > Hi Mike, >> I installed JTSDK on a new computer and building wsjtx fails as it >> can't find python. >> >> Turns out JTSDK now installs Python33 and not python27. Compiling on >> my old computer works as it has both 27 and 33. I assume the 33 came >> from a JTSDK update. > Currently ^/branches/wsjtx requires Python >2.4 but <3.0. This is a > requirement of Asciidoc which is used to build the user guide. > > One way or another the CMAKE_PREFIX_PATH need the path to a Python 2.x > installation on it. I thought Greg had changed the JTSDK to provide both > Asciidoc and a suitable Python version. > > Currently the CMake option WSJT_GENERATE_DOCS defaults to OFF which > should stop this error. Have you turned this option ON? >> >> wsjtxexp compiles OK but doesn't appear to use python. >> 73 >> >> Mike W9MDB >> > 73 > Bill > G4WJS. |
|
From: Bill S. <g4...@cl...> - 2015-05-19 20:04:24
|
On 19/05/2015 20:58, KI7MT wrote: > Hi Bill, Hi Greg, > > > Sorry, but I do not get Mike's emails when posted to the wsjt-devel > list. I do get them when posted to the wsjtgroup email address. Odd, I definitely got his message via the list. It is on the list archive here: https://sourceforge.net/p/wsjt/mailman/message/34126476/ It has got an odd parentage but I think that's because Mike used a message from another thread to generate it. > > Yes, I added an update installer that installs both Python2 and AsciiDoc > within the C:\JTSDK folder structure. Good. > > The second update was the the build script and is performed by updating > JTSDK from the Start Menu: Start > JTSDK > Update > > Update Installer Link: > http://sourceforge.net/projects/jtsdk/files/win32/2.0.0/JTSDK-2.0.0-u1-win32.exe/download Perhaps Mike needs to update his JTSDK. > > This only applies to the the one WSJT-X branch that you've enabled the > doc builds on. It should be moot given the user guide build option is OFF by default. > > > 73's > Greg, KI7MT 73 Bill G4WJS. > > On 05/19/2015 01:49 PM, Bill Somerville wrote: >> On 19/05/2015 20:39, Black Michael wrote: >> >> Hi Mike, >>> I installed JTSDK on a new computer and building wsjtx fails as it >>> can't find python. >>> >>> Turns out JTSDK now installs Python33 and not python27. Compiling on >>> my old computer works as it has both 27 and 33. I assume the 33 came >>> from a JTSDK update. >> Currently ^/branches/wsjtx requires Python >2.4 but <3.0. This is a >> requirement of Asciidoc which is used to build the user guide. >> >> One way or another the CMAKE_PREFIX_PATH need the path to a Python 2.x >> installation on it. I thought Greg had changed the JTSDK to provide both >> Asciidoc and a suitable Python version. >> >> Currently the CMake option WSJT_GENERATE_DOCS defaults to OFF which >> should stop this error. Have you turned this option ON? >>> wsjtxexp compiles OK but doesn't appear to use python. >>> 73 >>> >>> Mike W9MDB >>> >> 73 >> Bill >> G4WJS. |
|
From: KI7MT <ki...@ya...> - 2015-05-19 20:19:23
|
Hi Bill, 73's Greg, KI7MT On 05/19/2015 02:04 PM, Bill Somerville wrote: > On 19/05/2015 20:58, KI7MT wrote: >> Hi Bill, > Hi Greg, >> >> >> Sorry, but I do not get Mike's emails when posted to the wsjt-devel >> list. I do get them when posted to the wsjtgroup email address. > Odd, I definitely got his message via the list. It is on the list > archive here: > > https://sourceforge.net/p/wsjt/mailman/message/34126476/ Yes, I can Mike's postings when browsing the archives on Sourceforge, but I only check that randomly. <snip> 73's Greg, KI7MT |
|
From: Black M. <mdb...@ya...> - 2015-05-19 20:02:48
|
I dont' remember turning it on. Checking the CmakeCache.txt in the wsjtx\build\Release directory does show it turned on.I removed the build directory and "build-wsjtx rinstall" put it right back with the docs being turned on.
I see the option with the OFF in src\wsjtx\CMakeLists.txt so how is it getting turned on again?
73Mike W9MDB
From: Bill Somerville <g4...@cl...>
To: wsj...@li...
Sent: Tuesday, May 19, 2015 2:49 PM
Subject: Re: [wsjt-devel] JTSDK python error
On 19/05/2015 20:39, Black Michael wrote:
Hi Mike,
I installed JTSDK on a new computer and building wsjtx fails as it can't find python.
Turns out JTSDK now installs Python33 and not python27. Compiling on my old computer works as it has both 27 and 33. I assume the 33 came from a JTSDK update.
Currently ^/branches/wsjtx requires Python >2.4 but <3.0. This is a requirement of Asciidoc which is used to build the user guide.
One way or another the CMAKE_PREFIX_PATH need the path to a Python 2.x installation on it. I thought Greg had changed the JTSDK to provide both Asciidoc and a suitable Python version.
Currently the CMake option WSJT_GENERATE_DOCS defaults to OFF which should stop this error. Have you turned this option ON?
wsjtxexp compiles OK but doesn't appear to use python.
73
Mike W9MDB
73
Bill
G4WJS.
------------------------------------------------------------------------------
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
|
|
From: Bill S. <g4...@cl...> - 2015-05-19 20:05:25
|
On 19/05/2015 21:02, Black Michael wrote: Hi Mike, > I dont' remember turning it on. Checking the CmakeCache.txt in the > wsjtx\build\Release directory does show it turned on. > I removed the build directory and "build-wsjtx rinstall" put it right > back with the docs being turned on. > > I see the option with the OFF in src\wsjtx\CMakeLists.txt so how is it > getting turned on again? I don't understand that, it should be OFF for now at least. > > 73 > Mike W9MDB 73 Bill G4WJS. > > ------------------------------------------------------------------------ > *From:* Bill Somerville <g4...@cl...> > *To:* wsj...@li... > *Sent:* Tuesday, May 19, 2015 2:49 PM > *Subject:* Re: [wsjt-devel] JTSDK python error > > On 19/05/2015 20:39, Black Michael wrote: > > Hi Mike, >> I installed JTSDK on a new computer and building wsjtx fails as it >> can't find python. >> >> Turns out JTSDK now installs Python33 and not python27. Compiling on >> my old computer works as it has both 27 and 33. I assume the 33 came >> from a JTSDK update. > Currently ^/branches/wsjtx requires Python >2.4 but <3.0. This is a > requirement of Asciidoc which is used to build the user guide. > > One way or another the CMAKE_PREFIX_PATH need the path to a Python 2.x > installation on it. I thought Greg had changed the JTSDK to provide > both Asciidoc and a suitable Python version. > > Currently the CMake option WSJT_GENERATE_DOCS defaults to OFF which > should stop this error. Have you turned this option ON? > > > >> >> wsjtxexp compiles OK but doesn't appear to use python. >> 73 >> >> Mike W9MDB >> > 73 > Bill > G4WJS. |
Thanks for helping keep SourceForge clean.
X