Various SDR consoles are supported by the TS-2000 back end, ensure
that commands unsupported are not sent to them. Added a flag that
shows back end is talking to an emulation like SmartSDR or PowerSDR.
The TS-790 is very prone to slow command responses, this change no
longer retries the sending of the original command when a busy
response "?;" is seen, instead it simply waits one retry delay and
tries response read again. It may be that this has always been the
correct action but most rigs do not return busy responses or behave
better when a command is retried.
Hi,
Gpredict issues set_vfo commands on sat track engage to switch a/b vfo
and set downlink/uplink frequency.
Although this generally works, Kenwood TS2000 has its own style during
satellite operation:
1) vfo B is *always* for uplink
2) vfo A is *always* for downlink
so vfo selection (FR command) doesn't work: kenwood firmware doesn't
recognize it in Satellite mode.
When Gpredict is trying to set_vfo on TS2000 in Satellite mode it loops
on unrecognized FR command and freezes.
Attached patch checks for TS2000 Satellite mode status and if ON
"disables" set_vfo command.
This allows Gpredict to track downlink/uplink frequency on TS2000 (you
need to configure manually downlink/uplink band on the rig before
engaging)
Please be aware this isn't a "Gpredict patch": it fixes set_vfo behavior
in satellite mode according to ts2000 firmware.
73, Ciao
Dario Ventura, IZ7CRX
This change allows the set_mode functions to leave the rig passband
unchanged if required. For the few rigs that do not have explcit
passband width control either current state is read and rewritten or a
"normal" width is chosen e.g. select a normal width when there is a
choice like CW and CW-NARROW.
It seems like || was used where && was intended here. Currently, the
conditions are always true, and there's no reason for them to be written
this way.
Found with Coccinelle.
The rig->state.rigport retry option can be overridden by a
configuration option and therefore should be used rather than the
initial capabilities default value.
Thanks to Ervin HA2OS for finding this defect.
This patch fixes a frequency overflow problem on kenwood and yaesu that
can occur with frequencies that over a 32-bit signed int. This has been
shown to fix the problem on kenwood.
73
Mike W9MDB
As Hamlib now restores the rig auto information state (AI) on exit
there is now a need to disable that functionality so that rigctl can
be used to set/reset AI mode on the rig explicitly.
A new public API function 'rig_no_restore_ai()' is also added that
allows any client to disable this auto AI restore functionality if
required. Most clients should do nothing as restoring AI state is a
good thing.
This issue came to light with the HDSDR program which has no ID
command response. For these awkward cases try an FA command to check
if the rig responds then use that same FA command for set command
verification. Otherwise use the ID command as before.
Kenwood, modern Yaesu rigs and many SDRs use an auto information
mechanism that broadcasts unsolicited rig state changes, Hamlib does
not support this and turns off the function. Because several passive
devices rely on this information to detect band changes for example
this change adds code to save the AI state on start up and restores it
on exit. These devices do no need the broadcasts since when an
application using Hamlib is running as necessary state polling by the
application provides continuous rig state updates.
Mikael Nousiainen