Bill,
> On Jun 6, 2015, at 10:18 AM, Bill Somerville <g4...@classdesign.com> wrote:
>
> 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.
I’ve just now confirmed that r5543 is back to not transmitting in non-hopping
mode unless the band that we are sitting on happens to be active in the
scheduler. I think that this may be the behavior that Josh commented on
earlier.
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.
Steve k9an
>> 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
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
