I just pushed a commit that has a new dummy device without set_vfo or get_vfo.
I was able to patch it to work with this situation so this should apply to any
older Icom rigs and Yaesu rigs that don't have set_vfo capability and/or
get_vfo capability.
I'm still waiting for my tester to get a current compile but he's having
problems and will have to respond tomorrow.
Bill...if you compile this into WSJT-X and choose the new dummy device it
should work and trigger the ENAVAIL for set_vfo and get_vfo.
Mike W9MDB
On Wednesday, June 3, 2020, 07:34:36 AM CDT, Bill Somerville
<[email protected]> wrote:
Hi Mike,
thanks for chasing this down. I have some confusion whether there are two
issues, one with direct rig control and another when using rigctld. I would be
good to test both, let me know if a test version of WSJT-X is needed with your
patch for any platform required? Although in this case I think just using an
'f' command with rigctl will suffice.
73
Bill
G4WJS.
On 03/06/2020 13:22, Black Michael via wsjt-devel wrote:
I've got a patched version that I sent to one of the testers....
On Wednesday, June 3, 2020, 06:26:20 AM CDT, Bill Somerville
<[email protected]> wrote:
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]> 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]>
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
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
