Revised kenwood rig busy response handling

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.
This commit is contained in:
Bill Somerville 2016-09-11 13:54:09 +01:00
parent 5b8e56c8ef
commit ce8189f029

View File

@ -263,6 +263,7 @@ int kenwood_transaction(RIG *rig, const char *cmdstr, char *data, size_t datasiz
}
}
transaction_read:
/* allow one extra byte for terminator we don't return */
len = min (datasize ? datasize + 1 : strlen (priv->verify_cmd) + 13, KENWOOD_MAX_BUF_LEN);
retval = read_string(&rs->rigport, buffer, len, cmdtrm, strlen(cmdtrm));
@ -321,7 +322,7 @@ int kenwood_transaction(RIG *rig, const char *cmdstr, char *data, size_t datasiz
{
rig_debug(RIG_DEBUG_ERR, "%s: Retrying shortly\n", __func__);
usleep (rig->caps->timeout * 1000);
goto transaction_write;
goto transaction_read;
}
retval = -RIG_ERJCTED;
goto transaction_quit;
@ -2604,6 +2605,7 @@ int kenwood_get_trn(RIG *rig, int *trn)
/* these rigs only have AI[0|1] set commands and no AI query */
if (rig->caps->rig_model == RIG_MODEL_TS450S
|| rig->caps->rig_model == RIG_MODEL_TS690S
|| rig->caps->rig_model == RIG_MODEL_TS790
|| rig->caps->rig_model == RIG_MODEL_TS850
|| rig->caps->rig_model == RIG_MODEL_TS950SDX) {
return -RIG_ENAVAIL;