Re: [Hamlib-developer] [Hamlib/Hamlib] 0ba199: Make TS890S behave like TS990S for mode on VFOB

[Black M. <mdb...@ya...>]

Try this DLL.  Looks like some more changes are need for the TS890/990 to get the correct VFO under all conditions (namely Split VFOB/VFOA instead of just Split VFOA/VFOB).But that can wait as it's a rare situation when somebody wants to do reverse split (as in nobody has ever asked for it).
https://www.dropbox.com/scl/fi/ccchzrdd9u35jguwbhhxo/libhamlib-4.dll?rlkey=dnpxz9fb6eci696uextmwja8o&dl=0

Just to give you an idea of what's going on.
#1 We need to determine the current VFO -- but that depends on transmit status and split status  So we need FR/FT and then transmit status to figure out what "OM" is answering with.  #2 Then we have set mode -- the 890 cannot set mode on B directly...have to make VFOB the active vfo with FR1;, set mode with OM, then set FR0; back.  But this also depends on which way split is being done which I haven't implemented yet for reverse split.  The TS990 looks like we can use the SF command to set freq/mode on either VFO which I'll have to implement.
Mike W9MDB

 

    On Friday, April 12, 2024 at 07:14:08 AM CDT, Brian Morrison via Hamlib-developer <ham...@li...> wrote:  
 
 On Fri, 12 Apr 2024 05:23:09 -0400
George Baltz <geo...@gm...> wrote:

> This commit breaks TS-890S operation.  The TS-990 code path calls 
> kenwood_get_vfo_main_sub(), which is TS-990 specific - it uses the
> "CB" command which does not exist on the TS-890S.  So
> kenwood_get_mode() fails, and thing go downhill fast.
> 
> It also does not handle correctly the somewhat bizarre function of
> the 890 OM command - vfo B does not always mean P1 = 1.

Thanks for confirming what I am seeing George, just goes to show that
Kenwood firmware is a variable feast.

-- 

Brian  G8SEZ


_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer