Bill, I really like what you’ve done with the Band Hopping scheduler! Before checking any boxes in the active-band scheduler I checked to see if it would automatically transmit on a single-band (Band Hopping unchecked) that was not active in the scheduler. No problem! I also noticed that there is no display of the day-night-gray status while conducting this experiment. Which is not a problem, just an observation.
Next, I filled in the scheduler and checked Band Hopping. This caused the “Sunset grayline” status to show up, and it started hopping among the selected bands. Having just now crossed the 1-hour-past sunset time of 2120LT here, I can also confirm that the status has correctly changed to “Night” and the radio has already visited 160m, which is on the night schedule. Also, I started with Tx Pct = 50%, and observed two double-transmission events within the first 30 minutes. This is expected (and required) behavior. The scheduler is set up to enforce ntxlimit=1 when the requested (integer) percentage is 49 or less, and it switches to ntxlimit=2 for percentages of 50 or above. It will go to txlimit=3 at some even higher percentage. I have now lowered the Tx Pct to 49. This should eliminate the double-transmission events. It will take awhile to gather enough data to prove that this is working... It’s looking good! Steve k9an > On Jun 6, 2015, at 12:13 AM, Bill Somerville <g4...@classdesign.com> wrote: > > Hi All, > > to all testers of the development WSPR code, I have enhanced the band > hopping scheduling to allow any band to be included in the schedule. > Bands not in the 10 coordinated bands will only be scheduled when the > band for the current coordinated slot is not available, in this case all > the checked bands will be considered and a random one from that set will > be used. > > Because of these changes I have invalidated any prior schedule tables so > you will have to set up the table again, sorry about that but as this is > unreleased code it is much easier to invalidate than provide an upgrade > process. > > 73 > Bill > G4WJS. > > On 03/06/2015 18:36, Bill Somerville wrote: >> Hi All, >> >> I am working on re-factoring this to simplify teh MainWindow code a >> little and to provide a more robust user interface for band hopping >> settings. >> >> There was some discussion about picking any random band from the users >> configured bands when the scheduled band is not configured. This is >> potentially tricky because the user specified "tune up" is only >> specified for the 10 standard hopping bands. It would perhaps be better >> to specify the "tune up required" flag at the station list level rather >> than in the band hopping setup. That way it could be used for any band >> change in any mode. >> >> The same applies for invoking a call out to a hardware setup executable, >> in this case there would be no user facing setup it could just invoke >> the call out on any band change. >> >> I cannot work out the purpose of the 1/2 second sleep in the band >> hopping invocation, there is a comment asking if it is allowed to which >> the answer is not really as it is stalling the GUI thread which can have >> many unwanted consequences. >> >> There is a potential issue with the timing of the user hardware >> executable and the tune up signal, the user hardware script is invoked >> asynchronously so even though there is a 1/4s delay before the audio >> starts there is no guarantee that the user hardware script has completed >> before the audio starts. I suspect this may lead to undesirable hot >> switching in some cases. >> >> At a higher level: why is a tune up signal needed at all given that all >> the "slow mode" signals are pretty much indistinguishable from a carrier? >> >> 73 >> Bill >> G4WJS. >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
