On 04/06/2015 13:29, Joe Taylor wrote: > Hi Bill, Hi Joe, > > Nice job with the new band-hopping setup window. Much better than my > quick-and-dirty setup using Tab 4. :-) Also no code in MainWindow and many less lines to get the same result.
There is more to come. I have an idea for Steve's request to use any configured band when a coordinated schedule band cannot be used. I liked his example of adding 6m & 2m to the mix when Es propagation is likely. It will maintain the scheduling flags for every band possible, but only show check boxes for the bands that have WSPR working frequencies defined. I also think that highlighting the coordinated band and period (i.e. Day/10m) currently scheduled. The dialog could easily be dynamic and move the highlight around as the schedule progresses through the day. > >> 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. > I think an automatic ATU tuneup makes sense only after an automated band > change -- which occurs only in WSPR mode. In other modes, band changes > are always initiated by an operator, and we can leave any necessary > tuneup to the operator's discretion, using the existing "Tune" button. Understood, I was just thinking ahead if we add other bands for the uncoordinated additions to the standard schedule. I have a way to do this which I will try out. How about making the user hardware script more general? I'm not sure what users use to do this. I have an SO2R box that does all the switching for me by tracking the CAT commands and DX Lab Suite Commander doing the rig switches depending on frequency requested. I have left the user_hardware.* invocation in MainWindow for now as it didn't seem to be closely coupled to band hopping, it could be moved into the existing band change code quite easily. > >> 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. > That's me. I considered it a temporary fix to some timing problem. I > knew it was bad practice. Take it out, and see if any timing problems > arise. Ok, I guessed something like that but couldn't work out what the hazard was, maybe the band hop and related actions being triggered before the previous Tx period had completed? > >> 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. > A better scheme may be possible. Something much like this one has > worked well in traditional WSPR for some years. I suppose most user hardware executables will finish very quickly and there will be no problem. > >> 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? > Because you may want your antenna tuned for Rx sequences, as well as Tx > sequences. I figured that out after I posted, I have gated the tune up flag to Rx periods only in a later check in, it makes more sense now. > > -- Joe, K1JT 73 Bill G4WJS. ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
