And I can also confirm.

>From None or Fake It to Rig turns split on when exiting Configuration.

Rig Split to Fake It turns off split mode when exiting Configuration.

So why doesn't Rig Split to None turn it off too?  I think this needs to be
consistent.

 

73

Mike W9MDB

 

From: Michael Black [mailto:mdblac...@gmail.com] 
Sent: Sunday, July 05, 2015 4:40 PM
To: 'WSJT software development'
Subject: RE: [wsjt-devel] rig_get_split_mode

 

Got the get_split_mode implemented and it appears the FT-991 is fully
functional now in both Fake It and Rig split.  I've got one WSPR-tester in
France and a JT65/JT9 guy in Arizona both testing successfully now (the WSPR
guy doesn't really care about split mode though).

 

I'm still seeing the problem though when changing from Rig to None on split.
One way works.None-to-Rig.turns on split when exiting Configuration.  The
other way Rig-to-None does not turn off split when exiting Configuration.but
does fix itself on program restart.

 

This is true for the FT-991 and for my Omni VII too so I have two rigs
exhibiting this behavior.

 

I'm trying to trace it down but having a hard time following the logic where
Configuration exit triggers split=1 but not split=0

 

73

Mike W9MDB

 

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Sunday, July 05, 2015 9:12 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] rig_get_split_mode

 

On 05/07/2015 14:56, Michael Black wrote:

Hi Mike,

This code section is causing some problems with Yaesu hamlib entries

 

         if (rationalise_mode)

            {

              rmode_t current_mode;

              pbwidth_t current_width;

 

              error_check (rig_get_split_mode (rig_.data (), RIG_VFO_CURR,
&current_mode, &current_width), tr ("getting mode of split TX VFO"));

              TRACE_CAT ("rig_get_split_mode mode = " << rig_strrmode
(current_mode) << "bw =" << current_width);

 

              auto new_mode = map_mode (state ().mode ());

              if (new_mode != current_mode)

                {

                  TRACE_CAT ("rig_set_split_mode mode = " << rig_strrmode
(new_mode));

                  error_check (rig_set_split_mode (rig_.data (),
RIG_VFO_CURR, new_mode, RIG_PASSBAND_NORMAL), tr ("setting split TX VFO
mode"));

 

                  // do this again as setting the mode may change the
frequency

                  error_check (rig_set_split_freq (rig_.data (),
RIG_VFO_CURR, tx), tr ("setting split TX frequency"));

                }

            }

 

 

The "rig_get_split_mode" is only defined for the FT920.  So all others (I'm
working on the FT-991 right now) are getting an error

Sat Jul 4 22:54:24 2015 GMT(C:\JTSDK\src\wsjtx\Configuration.cpp:2338)Debug:
Configuration::handle_transceiver_failure: reason: "Hamlib error: Feature
not available while getting mode of split TX VFO

"

That error shouldn't happen. For rigs where the "other" VFO mode can be
directly queried get_split_mode() should be implemented, for rigs that
can't, the front end function rig_get_split_mode() assists by swapping VFOs
and using a normal mode query. The caps->targetable_vfo flags should control
this behaviour.

What value do you currently have for caps->targetable_vfo for the FT-991?
The FT-991 has the "OI" query but no command to set the "other" VFO mode so
I think it must be RIG_VFO_TARGETABLE_FREQ only.

 

73

Mike W9MDB

73
Bill
G4WJS.

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to