Replying to my own observation — the behavior is more complex than I realized.
I think that the program is actually trying to raise ptt on the Rx-only band,
630m, but a hamlib error message occurs and then seems to cause the program to
drop Tx Enable. (The radio is a TS-480.) This is consistent with Joe’s
suspicion that hamlib errors were canceling Tx Enable.
Steve k9an
> On Jun 5, 2015, at 11:27 PM, Steven Franke <s.j.fra...@icloud.com> wrote:
>
> 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
