Mike,
I believe it is quite reasonable to implement rig_get_vfo for the
FT-891, FT991, and similar. In this case it may be that a implementation
that always returns VFO A is correct as I don't believe these rigs use
VFO B for anything other than SPLIT Tx transmit frequency. That aside,
what is important here is that we have a regression that needs a
solution. The simple fact is that every rig (except for a couple of
ancient ones with one-way CAT control) have the ability to query the
current frequency without specifying a VFO. The current Hamlib seems not
to reflect that reality for the rigs in question and that needs to be fixed.
Getting to detail, a rig_get_vfo(RIG_VFO_CURR) on these rigs need do no
more than issue an IF; command and return the VFO frequency in the
reply. That doesn't seem difficult to me! This is no different than the
solution for the Icom rigs you bring up, in that an 0x03 query command
has a similar function, i.e. return the frequency of the current VFO.
73
Bill
G4WJS.
On 03/06/2020 05:20, Black Michael via wsjt-devel wrote:
The FT-991 is one that doesn't have the ability to query which VFO is
active and doesn't have the ability to query "current VFO" either.
Since we allow currVFO to pass through to the Icoms it's also now
passing through to all rigs.
So it seems the only choice here would be to set the current VFO when
it's not already set and set it to VFOA or Main as appropriate for
non-Icom rigs.
I think we can use the get_vfo function absence to determine when to
do this.
Out of 37 Yaesu rigs only 25 have get_vfo.
Of course no Icom rigs have this capability but they do understand
currVFO concept.
And 4 Kenwood rigs don't have get_vfo
On Tuesday, June 2, 2020, 11:01:04 PM CDT, Bill Somerville
<[email protected]> wrote:
Mike,
OK, WSJT-X checks for both of those return codes when it makes its
first attempt to get the current VFO. So Hamlib must not lie about
that capability and return a success status, otherwise WSJT-X continue
on the basis that rig_get_vfo() works for the current rig.
Is this error because WSJT-X calls rig_get_vfo(), because I still
don't understand why the error being reported by WSJT-X as coming from
Hamlib is "Invalid parameter", *while trying to get the current
frequency*. That sounds like an unrelated issue within Hamlib.
The first few Hamlib API calls WSJT-X makes when Hamlib reports that
the current rig cannot respond to rig_get_vfo(), but can be set to
SPLIT mode, are:
rig_init()
rig_open()
rig_get_vfo() // allows -RIG_ENIMPL and -RIG_EINVAL error statuses
rig_get_freq(RIG_VFO_CURR)
I believe it is the last of those that is failing with -RIG_EINVAL,
that shouldn't happen as it must be possible to read the current
frequency of any rig.
This must be collateral damage within Hamlib from the last minute
fixes to sort out similar issues with some Icom rigs. Nothing
relevant has changed in the Hamlib interface code in WSJT-X since
v2.2.0 RC3, yet these rigs (FT-891 & FT-991) were OK then and not now.
73
Bill
G4WJS.
On 03/06/2020 04:28, Black Michael via wsjt-devel wrote:
Don't know for sure...but it's been that way since version 3.3
As the error codes say in rig.h
RIG_ENIMPL, /*!< 4 function not implemented, but will be */
RIG_ENAVAIL, /*!< 11 Function not available */
On Tuesday, June 2, 2020, 05:35:42 PM CDT, Bill Somerville
<[email protected]> <mailto:[email protected]> wrote:
Mike,
don't do that, the whole point of that query is to find out if the
rig can be queried for the current VFO, the result determines how the
rig is handled via the Hamlib API. Hamlib should return "not
implemented", why is an "invalid parameter" error being returned?
73
Bill
G4WJS.
On 02/06/2020 23:21, Black Michael via wsjt-devel wrote:
So WSJT_X is asking "v" when the rig has no get_vfo function.
I could modify rig.c to return RIG_OK from rig_get_vfo if
RIG_VFO_CURR is asked for.
Bill?
Mike W9MDB
On Tuesday, June 2, 2020, 04:03:30 PM CDT, DG2YCB, Uwe
<[email protected]> <mailto:[email protected]> wrote:
Hi Bill,
Done. See file enclosed. FYI: During the test, I clicked two times
on the Test CAT button. Each times the error message popped up.
73 de Uwe, DG2YCB
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
