SSDR 1.16.17 CAT issues with FB commands

W0DHB

SSDR CAT 1.6.17 FB commands are not working when CAT port is selected to Slice A . This will break many satellite applications that do uplink and downlink doppler tuning, typically Slice B uplink and Slice A downlink. Changing CAT port to Slice B allows FB to work, but breaks FA Commands I'm not sure if this was the intended consequence or not. Dave W0DHB

Tim - W4TME

FB command reads or sets VFO B.  That can't work on Slice A.  it will only work on slice B.

W0DHB

Understand, Didn't quite say it clearly. FB commands are not setting Slice B when CAT port is set to Slice A. FA commands work fine setting Slice A If I Change CAT port to Slice B FB works and FA no longer sets Slice A Same CAT software worked fine pre 1.6

Tim - W4TME

I understood exactly what you said.

FB is a VFO B command that is used when the radio is in split mode to read or set the VFO B frequency.  In that mode, a VFO B centric CAT command is ignored if it is sent to VFO A (slice A).  The same applies to FA which is a VFO A (Slice A) centric command; it will be ignored if sent to a CAT port associated with slice B (VFO ,

This is all working as designed for the new CAT.  

W0DHB

Ok, I was afraid that was the case. Thanks.

John G3WGV

I'm just starting to look into interfacing SSDR CAT 1.8.4 with my homebrew logging program.

FB; and ZZZB; do not work (return ?;) on either slice in my tests using the log function, which is odd. FA; on slice A gives slice A's frequency and FA; on slice B gives slice B's frequency but that seems to be at odds with the documentation.

There is a more fundamental question though: On a standard Kenwood-type radio there is one serial interface and that provides control of both VFO-A and VFO-B. As far as I can see, to do that with SSDR CAT I have to have two com ports open, one for each slice. I can write code to do that, as it's my own logging software but I don't see how it can work with other logging programs that are running the Kenwood CAT protocol.

Perhaps I am missing something?

73, John, G3WGV

Tim - W4TME

The radio is not in split mode.  Since any slice can be associated with a CAT port, VFO B commands are only valid if the radio is in split mode.

Use the ZZSW; command to set split mode.  ZZSW1; = split on / ZZSW0; = split off.

John G3WGV

Thanks, Tim, I was indeed missing something.

In the Kenwood radio world split mode is set just by enabling VFO-B on the front panel (in the Flex world, starting the 2nd slice) but I can see that's not valid in this case. Is there a way to (re)set split mode from Win SSDR/Maestro SSDR? I looked briefly and cannot see it.

Tim - W4TME

In the Kenwood radio world, CAT was not designed to work with up to 8 receivers ;-)

Is there a way to (re)set split mode from Win SSDR/Maestro SSDR? I looked briefly and cannot see it.

The short answer is no.  

Here is the long answer. Remember CAT is a separate non-GUI client application that interacts with the radio emulating the CAT protocol.  This construct of "split" is only defined at the CAT level, meaning when in split mode, it is how CAT responds to the different VFOx commands to comply with emulating the protocol.  So the enable/disable logic for putting the radio into split mode really should only be controlled by CAT or you can get into all sorts of strange operating states.  

Example: a contest mode app (logger) puts the radio into split mode and things are working properly.  Then an operator sits down and inadvertently changes the split state using SmartSDR for Windows (or Maestro).  Now the contest software that initiated the split state is not working properly anymore.  Why?  Because CAT is a get/set stateless communication protocol and is not designed be informed that a secondary process just messed with its operating state.  In addition, since you can have  up to 8 slices (4 "split" radios), it becomes more complicated to make sure the right slice "split" pair gets taken into or out of split mode from the GUI application.

This example demonstrates why CAT is a very poor protocol to use to control or interact with a radio (especially one with up to 8 receivers) and why the FlexLib API, where you can subscribe to events to enable a stateful communication process between the radio hardware and a third-party app is a vastly superior way to interface with a radio than the legacy get/set architecture of CAT. 

John G3WGV

That's very useful and informative, thanks Tim. Your points are well made and I agree that the proper solution is to use the FlexLib API. I'm looking into the API as part of a controller project and it may be that's how I'll end up implementing the logging interface as well, although it's a lot of code overhead just to read and set a handful of radio parameters from the logger!