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
