The TS-711 and TS-811 use an IF10 board just like the TS-140/TS-680/TS-590
and thus share a lot of the same commands with it.
Tested:
* TS-711A
* TS-811E
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
If the ts570 backend was called without the radio being turned on or the
wrong IO port specified, the library would generate a number of timeouts
and then fall through to behaving as though the communications channel
were opened. Discovered that the backend did not specify a function for
rig_open in the rig_caps structure.
Thanks to Volker Schroer, DL1KSV, for reporting this issue.
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.
This back end used a 480 second timeout which effectively blocks
retries. The long timeout claimed to be for something to do with
tuning which I assume is related to an auto ATU blocking rig CAT
responses. The standard retry mechanism should cope with this without
resorting to an artificially extended timeout.
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.
