Bill,
>> While you are on a roll, I’ll just mention another wish-list item. We 
>> already have a Tx Next button — it would be nice to have a Next Band 
>> selector that would override the band-picking algorithm. This could just be 
>> a box with up-down arrow to cycle through the bands… This could be active in 
>> both hopping _and_ non-hopping modes.
> Couldn't this be achieved by simply selecting a different band from the 
> main window drop down? We would have to define what that meant when 
> hopping is active, for example it could disable hopping or it could use 
> the selected band for one period then return to the normal schedule.
What I had in mind was to relieve the user from trying to time the band-change 
to the 8 second (or so) interval in between receive or transmit periods so that 
we don’t “waste” a period when changing bands. The Next Band option would 
essentially queue up the next band, use it for one period, then return to the 
normal schedule. 

I don’t see why we couldn’t implement this behavior using the main window drop 
down. Would it make sense to change the behavior of the drop-down between 
hopping and non-hopping mode? In hopping mode, choosing a band from the 
drop-down would queue up the next band to hop to, whereas in non-hopping mode 
it would just do what it does now… 

Here’s the scenario that I have in mind: while hopping among the “Day” bands, 
you hear a comment on the local repeater that says that 6m is open to VE3 (that 
just happened here) - so I’d like to check 6m as the “Next Band” so that I 
visit 6m once, then return to normal hopping.

Or would this behavior just confuse the heck out of people who are using the 
program for the first time. Feel free to tell me that it’s just too complicated.

Also, I’ll note that currently, selecting a band from the drop-down bypasses 
the call to user_hardware. My earlier suggestion on this was to make the 
user_hardware call an atomic part of any band change. But I have to admit that 
I don’t understand what implications this might have for the other modes.
Steve k9an

> 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

Reply via email to