K3 with MicroHam MD6 failure

[mdblack98]

K3 RTS ptt off is too fast and K3 can't change mode while PTT is on.

[2021-06-12 14:10:57.944741][00:02:58.786651][RIGCTRL:trace] 0000 4d 44 36 3b MD6;
[2021-06-12 14:10:57.944741][00:02:58.786662][RIGCTRL:debug] write_block called
[2021-06-12 14:10:57.955734][00:02:58.797609][RIGCTRL:trace] write_block(): TX 3 bytes
[2021-06-12 14:10:57.955734][00:02:58.797633][RIGCTRL:trace] 0000 49 44 3b ID;
[2021-06-12 14:10:57.955734][00:02:58.797643][RIGCTRL:trace] read_string called, rxmax=35
[2021-06-12 14:10:57.955734][00:02:58.797724][RIGCTRL:trace] read_string(): RX 2 characters
[2021-06-12 14:10:57.955734][00:02:58.797733][RIGCTRL:trace] 0000 3f 3b ?;
[2021-06-12 14:10:57.955734][00:02:58.797742][RIGCTRL:trace] kenwood_transaction: read_string(len=2)='?;'
[2021-06-12 14:10:57.955734][00:02:58.797751][RIGCTRL:error] kenwood_transaction: Unknown command or rig busy 'MD6'
[2021-06-12 14:10:57.955734][00:02:58.797762][RIGCTRL:trace] kenwood_transaction: returning retval=-9
[2021-06-12 14:10:57.955734][00:02:58.797771][RIGCTRL:debug] kenwood.c(577):kenwood_transaction return(-9)
[2021-06-12 14:10:57.955734][00:02:58.797780][RIGCTRL:debug] k3.c(1171):k3_set_mode return(-9)
[2021-06-12 14:10:57.955734][00:02:58.797789][RIGCTRL:trace] rig_set_mode: targetable retcode after set_mode=-9
[2021-06-12 14:10:57.955734][00:02:58.797798][RIGCTRL:debug] rig.c(2200):rig_set_mode return(-9)
[2021-06-12 14:10:57.955734][00:02:58.798142][RIGCTRL:error] error: Command rejected by the rig

[g4wjs]

Mike,

this is not related to PTT other than it will cause delays to subsequent CAT commands, of which PTT is probably the most visible to the user. This is a known issue with K3 series rigs, sending redundant mode set commands (or necessary ones) cause an exponentially increasing delay before the command completes, i.e. sending a third mode change will take even longer that 500 mS to complete, and so on.

This is a Hamlib regression, is it scheduled for any future 4.2.1 bugfix release?

73
Bill
G4WJS.

[mdblack98]

I'm debating doing 4.2.1 or 4.3. Just two critical bugs right now....and since everybody seems to be in doing release candidates the 4.3 path might make more sense.... This might be a good time to test releasing a DLL with this patch in it.  I can also see this idea being good for other rigs too so might implement it in a higher layer in rig.c Mike W9MDB On Saturday, June 12, 2021, 10:38:23 AM CDT, Bill Somerville ***@***.***> wrote: Mike, this is not related to PTT other than it will cause delays to subsequent CAT commands, of which PTT is probably the most visible to the user. This is a known issue with K3 series rigs, sending redundant mode set commands (or necessary ones) cause an exponentially increasing delay before the command completes, i.e. sending a third mode change will take even longer that 500 mS to complete, and so on. This is a Hamlib regression, is it scheduled for any future 4.2.1 bugfix release? 73 Bill G4WJS. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[g4wjs]

Hi Mike, I am not aware of any other rig with this issue. We are not doing release candidates from Hamlib master, we are trying to stick with 4.2.x for now, hence the question about a 4.2.1. Although a DLL update is possible for MS Windows now with WSJT-X, it is not the same with either Linux or macOS where the system shared libraries are usually too old, so we still statically link. Part of the reason for sticking with 4.2.x is in hope that Linux distributions and the likes of MacPorts and Homebrew get that lineage and patch releases thereon. 73 Bill G4WJS.

…

On 12/06/2021 17:26, Michael Black wrote: I'm debating doing 4.2.1 or 4.3. Just two critical bugs right now....and since everybody seems to be in doing release candidates the 4.3 path might make more sense.... This might be a good time to test releasing a DLL with this patch in it.  I can also see this idea being good for other rigs too so might implement it in a higher layer in rig.c Mike W9MDB On Saturday, June 12, 2021, 10:38:23 AM CDT, Bill Somerville ***@***.***> wrote: Mike, this is not related to PTT other than it will cause delays to subsequent CAT commands, of which PTT is probably the most visible to the user. This is a known issue with K3 series rigs, sending redundant mode set commands (or necessary ones) cause an exponentially increasing delay before the command completes, i.e. sending a third mode change will take even longer that 500 mS to complete, and so on. This is a Hamlib regression, is it scheduled for any future 4.2.1 bugfix release? 73 Bill G4WJS.