On 05/06/2015 15:03, Steven Franke wrote: > Hi Bill, Hi Steve, > > On Jun 5, 2015, at 8:33 AM, Bill Somerville <g4...@classdesign.com> wrote: >> The point of call of Steve's new Tx scheduler needs to be moved into the >> WSPRBandHopping::next_hop() function so that the logic to decide when to >> tune and to block transmission on Rx only bands can be applied. >> Currently the decision to transmit in band hopping is not doing the >> above. It is a simple change but if we are going to use his transmission >> schedule for all WSPR transmission (probably a good idea since many >> users do not like the consequences truly random transmissions) it needs >> a little more adjustment. > Yes. Please feel free to make it right, or to give me marching orders for how > to proceed. Apologies for the temporary step backwards regarding the Rx only > functionality. It is only a small change. If you move the call of next_tx_state() from MainWindow::bandHopping() into WSPRBandHopping::next_hop() just after the call to FC_hopping(). The member variable m_->tx_percent_ tracks the current value of the UI Tx Pct spin box.
Something like: tx_next = next_tx_state (m_->tx_percent_); then revert MainWindow::bandHopping() to the commented out line above the previous call to next_tx_state(). I haven't looked at your code in detail yet but so long as it is Ok to call next_tx_state() after every period when band hopping (i.e. not just when auto tx is enabled) it should be all that is required. WSPRBandHopping::next_hop() will do all the required processing to determine if Tx is really allowed on the proposed band and whether a tune up signal is needed. I am currently working on extending WSPRBandHopping to allow any band with a WSPR frequency that is configured in Settings->Frequencies and checked for the current period of the day to be randomly chosen if a coordinated scheduled slot cannot be used. > > I’ll note that FC_hopping used to provide three things: > 1. tx scheduling > 2. index of next coordinated band > 3. grayline status > > We now have pulled out item 1, and it’s only a few lines of code to pull out > item 2. My inclination for next step would be to strip down FC_hopping so > that it just returns grayline status (and perhaps rename it to FC_grayline or > somesuch) and be done with it. If you and/or Joe feel that it would be > worthwhile, I’d be happy to reproduce the grayline functionality in C++. If > not, I’m content to leave it alone. Item 2 sounds like it really belongs in WSPRBandHopping. Item 3 probably uses some other existing Fortran subroutines that are used elsewhere and may well be best left as a Fortran subroutine. ... 73 Bill G4WJS. ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
