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.
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.
Current code always tries to set data mode with 'DAx' command after
setting the mode. According to 'PC control command reference' manual
that results in error for the CW, FSK and AM mode.
The provided patch sends 'DAx' only if we have some of the other modes.
It is targetable for read so set as targetable and added extra code in
set funnction to toggle VFOs where necessary. This is better than
setting as not targetable since reads do not have to toffle VFOs.
PowerSDR accepts a ZZID; command which changes the result of
subsequent ID; commands to ID900;. Since there seems no way of telling
PowerSDR to revert to the true TS2000 ID of ID019; we have to accept
ID900; as a TS2000.
Allow for SmartSDR Kenwood compatible IDs of 904 - 907 as TS-2000
synonyms.
Got a confirmation from Kenwood that the "TY" command returns "TYE 00"
or "TYK 00" for European or USA firmware.
So here's a patch that implements it for the TS590S.
The kenwood_transaction() function expects a buffer large enough for
the null terminated command response less the Kenwood command
terminator (';') but the read_string() call must allow an extra byte
for that same terminator.
Buffer size is now an input parameter only as the return data length
is implicit since a null terminated C string is returned. Better
precondition checks are impelmented.
There was an inconsistency in whether the CAT terminator character is
included in returned messages. It now follows the comment in
kenwood_transaction() i.e. strips of the terminator and returns a
message length that reflects that.
Using the priv->info buffer causes security checks on Mac OS X >= 10.9
because the source and destination of an internal strncpy can end up
being the same. It is bad practice anyway as it's undefined behaviour.
Allows for a single ';' for verification with the Elecraft XG3 single
character commands.
Allow for rig specific instance data (needed by the Elecraft XG3 that
is a bit different from the rest of the Kenwood/Elecraft group).
Do not send a startup command to turn off AI mode to the Elecraft XG3
as it doesn't have that command or mode.
Restore the positive RTTY mode enabled check to the Elecraft K2 as it
appears that the MD6; and MD9; comamnds are valid even when RTTY mode
is disabled on the rig.
Bill Barker