Joe, Bill,
I’m confused about this change from r5542 which reverses a change that I had
done in r5539:
- if (m_auto &&hop_data.tx_next_) {
+// if (m_auto &&hop_data.tx_next_) {
+ if ( m_auto && next_tx_state(m_pctx) ) {
Was this intended? According to Bill’s comments below this would override the
blocking of transmissions on Rx only bands. I wonder if it is connected to the
following behavior - with 630m selected as an active hopping band, and the Rx
Only box checked for that band, I still see Tx cycles — the waterfall stops,
the display indicates that a transmission is underway, and a “Transmitting”
line is entered into the log. The radio is not keyed, but otherwise it behaves
like a TX cycle…
Steve k9an
> On Jun 5, 2015, at 9:26 AM, Bill Somerville <g4...@classdesign.com> wrote:
>
> 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
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
