On 06/06/2015 05:36, Steven Franke wrote:
Hi Steve,
> 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.
The unintended change in r5542 would have disabled any gating of send
commands for Rx only bands. If a rig returns a CAT error when sent to a
non-HAM band or if asked to SEND on a non-HAM band then a rig control
error is likely. We do not distinguish between CAT errors we can ignore
and those we can't, apart from some obvious cases where a retry might
work. It is up tp the operator to ensure that WSJT-X doesn't try and
make the rig do something it can't. Now that Rx only during band hopping
is being honoured both for messages and tune up this should not be an issue.
> Steve k9an
73
Bill
G4WJS.
>
>> 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
