Commander + JTDX CAT issues


Gregg W6IZT
 

Other have reported difficulties when trying to use Commander with JTDX. It appears that the CAT interface on JTDX is intolerant to any serial port collisions. I've tried a number methods for multiple apps to access the CAT port on the K3 without success. I haven't used my K3 on FT8 for several months. I did not have this issue previously.

Has anyone come up with a stable solution?

Any assistance is greatly appreciated.

Gregg W6IZT


Dave AA6YQ
 

+ AA6YQ comments below

Other have reported difficulties when trying to use Commander with JTDX. It appears that the CAT interface on JTDX is intolerant to any serial port collisions. I've tried a number methods for multiple apps to access the CAT port on the K3 without success. I haven't used my K3 on FT8 for several months. I did not have this issue previously.

Has anyone come up with a stable solution?

Any assistance is greatly appreciated.

+ The only reliable way to enable multiple apps to simultaneously control the same transceiver is by developing a transceiver emulator that provides each client application with a dedicated virtual port that interacts with that emulator, and that keeps the emulated transceiver and physical transceiver in sync. That's how Commander's Secondary CAT port works (but it doesn't provide all of the functionality that JTDX requires), and that's how Tom VA2FSQ's Win4K3Suite works.

https://va2fsq.com/ultimate-control/

+ WSJT-X solves this problem by providing the option of using Commander for transceiver control. Does JTDX not provide that option? I've largely ignored JTDX because it is a hostile fork of the WSJT-X code.

73,

Dave, AA6YQ


Ian Cook - VK6DW
 

Hi All
I use JTDX all of the time.  I dont use WSJT-X at all if I can help it.  I find JTDX a lot more user friendly (I didnt know JTDX was an unfriendly, should I revise my useage?). 

That out of the way, I use JTDX with DX Labs, using the DX Labsuite option under radio tab, and it works just fine.  I also use it without commander just using the serial port (one created using VSPE) and also using OmniRig.  

That being said, I dont use multiple programs to try and control my radio, just one at a time.

Ian -VK6DW


Dave AA6YQ
 

+ AA6YQ comments below

I use JTDX all of the time. I dont use WSJT-X at all if I can help it. I find JTDX a lot more user friendly (I didnt know JTDX was an unfriendly, should I revise my useage?).

That out of the way, I use JTDX with DX Labs, using the DX Labsuite option under radio tab, and it works just fine. I also use it without commander just using the serial port (one created using VSPE) and also using OmniRig.

That being said, I dont use multiple programs to try and control my radio, just one at a time.

+ Many thanks for that information, Ian! Thus anyone wishing to use JTDX with DXLab should configure JTDX to select the DXLab Suite option under radio tab, as you report above. Doing so eliminates all conflicts over radio access.

73,

Dave, AA6YQ


Barry Murrell ZS2EZ
 

I have been using JTDX along with JTAlert and the DXLab Suite for several years, with no CAT issues - like WSJT-X, it offers Commander (and FLRig for that matter) as an option under the Radio selection. This has worked flawlessly for me - and I have the 2nd CAT port in Commander feeding an SDR with no problems. Bottom Line - any DXLab user should select Commander as the radio!!!

JTDX is a derivative focused purely on HF DX - all the VHF stuff is taken out, and the UI is designed for easier operation (I personally FAR prefer the JTDX UI, and I was an early adopter of the original WSJT back in 2001!!!)... also handles decodes a bit differently and has a much more refined (in my opinion at least) AutoSequencing methodology. Like WSJT-X, it requires operator intervention for logging (unlike the robotic function of WSJT-Z).

Not sure what a Hostile Fork is Dave?? Source code is available with every release, and the developers always abide by any requests made by the WSJT-X team.

BTW, I also have WSJT-X installed, and when a new GA comes out (I avoid the RC versions) I run it for several days - always worth keeping an open mind!!

73 de BARRY MURRELL ZS2EZ
KF26ta - Port Elizabeth, South Africa
EPC#0558 DMC#1690 30MDG#4081
DXCC HONOR ROLL (332/340)
DXCC(mixed)#41,146 DXCC(RTTY)#1,916
DXCC(phone)#34,990 DXCC(CW)#11,714
DXCC 80m,40m,30m,20m,17m,15m,12m,10m 5BDXCC#8,916
WAS Triple Play #492 WAS(RTTY)#538 WAS(Digital)#163-Endorsements JT65,FT8
WAZ(RTTY)#185 WAE-I(mixed)#72 WAZS(mixed)#214 AAA#1569 SARL Top Band Award #120
AS ZR6DXB: VUCC(50MHZ)#1,334 UKSMG WAE(Silver)#75 UKSMG AFRICA#22 WAC (Satellite)
website : www.zs2ez.co.za

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dave AA6YQ
Sent: Monday, 15 February 2021 00:04
To: DXLab@groups.io
Subject: Re: [DXLab] Commander + JTDX CAT issues

+ AA6YQ comments below

Other have reported difficulties when trying to use Commander with JTDX. It appears that the CAT interface on JTDX is intolerant to any serial port collisions. I've tried a number methods for multiple apps to access the CAT port on the K3 without success. I haven't used my K3 on FT8 for several months. I did not have this issue previously.

Has anyone come up with a stable solution?

Any assistance is greatly appreciated.

+ The only reliable way to enable multiple apps to simultaneously control the same transceiver is by developing a transceiver emulator that provides each client application with a dedicated virtual port that interacts with that emulator, and that keeps the emulated transceiver and physical transceiver in sync. That's how Commander's Secondary CAT port works (but it doesn't provide all of the functionality that JTDX requires), and that's how Tom VA2FSQ's Win4K3Suite works.

https://va2fsq.com/ultimate-control/

+ WSJT-X solves this problem by providing the option of using Commander for transceiver control. Does JTDX not provide that option? I've largely ignored JTDX because it is a hostile fork of the WSJT-X code.

73,

Dave, AA6YQ


Dave AA6YQ
 

I have been using JTDX along with JTAlert and the DXLab Suite for several years, with no CAT issues - like WSJT-X, it offers Commander (and FLRig for that matter) as an option under the Radio selection. This has worked flawlessly for me - and I have the 2nd CAT port in Commander feeding an SDR with no problems. Bottom Line - any DXLab user should select Commander as the radio!!!

+ Thanks, Barry!

JTDX is a derivative focused purely on HF DX - all the VHF stuff is taken out, and the UI is designed for easier operation (I personally FAR prefer the JTDX UI, and I was an early adopter of the original WSJT back in 2001!!!)... also handles decodes a bit differently and has a much more refined (in my opinion at least) AutoSequencing methodology. Like WSJT-X, it requires operator intervention for logging (unlike the robotic function of WSJT-Z).

Not sure what a Hostile Fork is Dave?? Source code is available with every release, and the developers always abide by any requests made by the WSJT-X team.

+ A hostile fork is a fork unilaterally created without the approval of the original project. Barring a compelling rationale, hostile forks should be avoided, as they discourage developers from making their code available as open source.

+ The threat of a hostile fork is one of the reasons that DXLab is not an open source project.

+ Perhaps my characterization of JTDX as a hostile fork of WSJT-X is erroneous.

Dave, AA6YQ


Joe Subich, W4TV
 

On 2021-02-15 2:21 AM, Dave AA6YQ wrote:

+ Perhaps my characterization of JTDX as a hostile fork of WSJT-X is erroneous.
Your characterization is not erroneous. The developers of WSJT-X have,
on multiple occasions, objected to modifications in the decoding
algorithms made in JTDX.

73,

... Joe, W4TV


On 2021-02-15 2:21 AM, Dave AA6YQ wrote:
I have been using JTDX along with JTAlert and the DXLab Suite for several years, with no CAT issues - like WSJT-X, it offers Commander (and FLRig for that matter) as an option under the Radio selection. This has worked flawlessly for me - and I have the 2nd CAT port in Commander feeding an SDR with no problems. Bottom Line - any DXLab user should select Commander as the radio!!!
+ Thanks, Barry!
JTDX is a derivative focused purely on HF DX - all the VHF stuff is taken out, and the UI is designed for easier operation (I personally FAR prefer the JTDX UI, and I was an early adopter of the original WSJT back in 2001!!!)... also handles decodes a bit differently and has a much more refined (in my opinion at least) AutoSequencing methodology. Like WSJT-X, it requires operator intervention for logging (unlike the robotic function of WSJT-Z).
Not sure what a Hostile Fork is Dave?? Source code is available with every release, and the developers always abide by any requests made by the WSJT-X team.
+ A hostile fork is a fork unilaterally created without the approval of the original project. Barring a compelling rationale, hostile forks should be avoided, as they discourage developers from making their code available as open source.
+ The threat of a hostile fork is one of the reasons that DXLab is not an open source project.
+ Perhaps my characterization of JTDX as a hostile fork of WSJT-X is erroneous.
Dave, AA6YQ