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
<g4...@classdesign.com> 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
<g4...@classdesign.com> 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 <dg2...@gmx.de>
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
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
