Thetis code additions to support automated TUNE feature of Acom 1200S/700S/600S amps and companion 04AT/06AT tuners

[frboswell]

These Acom amps & tuners support a one mouse click or one button push automated tune feature by sending a string of CAT commands to Thetis. Present versions of Thetis do not process these commands in a way compatible with the Acom gear. Code is added to CATCommands.cs, CATParser.cs, and CATStructs.cs to process the Acom CAT commands in a way that enables the automated TUNE feature. More details appear as comments in the added code. The CAT command sequence from the Acom gear is considered proprietary by Acom and cannot practically be changed, so this approach is the only option currently available. I have compiled this fork, created an msi file and installed on my station computer in the usual fashion. Working well with my Acom 1200S and 04AT.

Maintainers: Please be patient. I am new at this!

Rick, K8EZB frboswell@gmail.com

[ramdor]

not sure i like the idea of flipping into FM which has the potential to change TX profile and all the issues related to that such as different DSP filters, and everything related to that tx profile just to produce a carrier? Why not use the tune functionality in Thetis that is already there, TUNE. Trap the DT if that is what comes in from the amp, and switch TUN on/off as required?. Example the ZZTU cat command. Does the amp need it to be some certain mode? I really dislike the idea of adding amp specific stuff to code to be honest with you.

[frboswell]

OK. For now I will maintain a private version of Thetis with these changes.

[laurencebarker]

From a quick glance at the ACOM manual: it needs to be able to put the transceiver into a TUNE state and would benefit from the frequency. An alternative approach could be to write some code for an Arduino to sit between the atu and Thetis; wired serial connection to the ATU and USB serial to Thetis. Then put your logic in the Arduino. Or do something similar with a raspberry pi that might one day turn into some kind of script engine.Some of my github repositories have CAT decoding and encoding code that might help. Https://github.com/laurencebarkerLook at Andromeda front panel or Odin in the first instance.Laurence BarkerSent from my Galaxy -------- Original message --------From: frboswell @.> Date: 03/01/2024 22:30 (GMT+00:00) To: ramdor/Thetis @.> Cc: Subscribed @.***> Subject: Re: [ramdor/Thetis] Thetis code additions to support automated TUNE feature of Acom 1200S/700S/600S amps and companion 04AT/06AT tuners (PR #378) Reopened #378.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[frboswell]

Richie, In principle, I concur with the key points in your comments:

 The approach I used could result in in undesirable side effects, and  Thetis may not be the place for amp specific code.

Thanks for your suggestions re an alternative approach (using the Thetis TUNE feature). I considered this approach initially but since the Acom amp TUNE feature works with many (if not most) modern CAT-capable transceivers from Elecraft, Icom, Kenwood, Yaesu, and perhaps others, but with the notable exception of Apache Labs and Flex, I decided to use the Acom model (change mode to one that produces a carrier, in this case FM rather than FSK) as a starting point. While this approach does have some minor side effects, in about 8 months of using this approach I am not seeing any significant side effects.

I will try your suggested approach of using the Thetis TUNE feature, however, I am forced to use the CAT command stream produce by the amp during a TUNE cycle. This is part of the amp tuning algorithm and there is no way I can alter the amp commands. I have asked Acom to provide support for this feature for AL radios and they have declined. So, I’ll need to devise a workaround that deals with this reality.

Thinking about it a bit, I concur with your view re adding “amp specific stuff” to Thetis. This could lead to issues downstream. My motivation for proposing my approach was to avoid having to create private version of Thetis with each new release to support this feature. After a slow start, I now have this process well organized and easy enough to do.

Laurence, Thanks for your suggested approach. This is interesting and I may consider it at a future date, but for now, it seems like considerable effort for a small benefit.

Rick K8EZB

[ramdor]

Hi Rick, I don't really have too much of an issue issue with hardware specific stuff in Thetis, as long as it is gated via options. My main concern is the approach of using a mode change (FM) to do a tune, which will cause Thetis to switch to different TX profiles amongst other things, which is far from ideal tbh.

[laurencebarker]

I’ve been reading up on this. There are “middleware” products that communicate with other devices using CAT for exactly the kind of purpose you describe. DDUTIL is one; but another I wasn’t aware had a strong amateur radio following is NodeRED.

I’m still looking into it, but that’s exactly the kind of purpose they are there to serve. Thetis supports CAT commands over TCP/IP so having that program running on the same PC may well work.

And by the way: I’m already convinced that a NodeRED type approach would be more appropriate than the Arduino approach.

Laurence Barker G8NJJ

@.***

From: frboswell @.> Sent: Saturday, January 6, 2024 3:10 PM To: ramdor/Thetis @.> Cc: Laurence Barker @.>; Comment @.> Subject: Re: [ramdor/Thetis] Thetis code additions to support automated TUNE feature of Acom 1200S/700S/600S amps and companion 04AT/06AT tuners (PR #378)

Richie, In principle, I concur with the key points in your comments:

• The approach I used could result in in undesirable side effects, and
• Thetis may not be the place for amp specific code.

Thanks for your suggestions re an alternative approach (using the Thetis TUNE feature). I considered this approach initially but since the Acom amp TUNE feature works with many (if not most) modern CAT-capable transceivers from Elecraft, Icom, Kenwood, Yaesu, and perhaps others, but with the notable exception of Apache Labs and Flex, I decided to use the Acom model (change mode to one that produces a carrier, in this case FM rather than FSK) as a starting point. While this approach does have some minor side effects, in about 8 months of using this approach I am not seeing any significant side effects.

I will try your suggested approach of using the Thetis TUNE feature, however, I am forced to use the CAT command stream produce by the amp during a TUNE cycle. This is part of the amp tuning algorithm and there is no way I can alter the amp commands. I have asked Acom to provide support for this feature for AL radios and they have declined. So, I’ll need to devise a workaround that deals with this reality.

Thinking about it a bit, I concur with your view re adding “amp specific stuff” to Thetis. This could lead to issues downstream. My motivation for proposing my approach was to avoid having to create private version of Thetis with each new release to support this feature. After a slow start, I now have this process well organized and easy enough to do.

Laurence, Thanks for your suggested approach. This is interesting and I may consider it at a future date, but for now, it seems like considerable effort for a small benefit.

Rick K8EZB

— Reply to this email directly, view it on GitHub https://github.com/ramdor/Thetis/pull/378#issuecomment-1879724085 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AEXTXZ76CXKMJAEPHTWRHW3YNFSL5AVCNFSM6AAAAABBMCEXYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZG4ZDIMBYGU . You are receiving this because you commented. https://github.com/notifications/beacon/AEXTXZYV2XUEHDQZJ3OHJVTYNFSL5A5CNFSM6AAAAABBMCEXYGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTQBJIDK.gif Message ID: @. @.> >

[frboswell]

Laurence,

I have some NodeRED flows running in parallel with Thetis on my station computer to provide various other functions. I hadn't considered NodeRED for this purpose but on your suggestion, I'll invest some time in exploring this possibility.

Thaks, Rick K8EZB

[w-u-2-o]

Chiming in a little late on this, my apologies...

I provided some advice to Rick on this when he started development of this feature. You can blame me for the FM mode suggestion. Please consider the following thoughts and ideas.

1. Objections to FM mode: if this is the only philosophical impediment to implementation then it appears there is an easy fix. As Richie has already proposed, upon receipt of a DT2 command then assert TUN. On receipt of a DT1 command de-assert TUN. The part of the code that answers a DT query can even be made "legit", i.e. as long as DT tracks the state of TUN, and as long as an ACOM user does not try to start a tune cycle with TUN already asserted all will work correctly. Note: this does require the ACOM user to set the TUN function to use the drive slider and NOT the tune slider because the ACOM amp only controls the drive slider. Make an option called "Support ACOM DT command" in order to make this super-clean (because DT is an Elecraft-specific CAT command used for setting data modes). Put that option in Setup > Serial/Network/Midi CAT > Options > Other.

Rick--you might try making those changes and see if they work OK.

2. Objections to the philosophy of adding amp-specific code: it's not really amp specific, it's more like tuner-specific. This has always been a gaping hole in the Thetis repertoire. It surely would be nice to provide integration/automation with the many tuners who otherwise provide CAT-based solutions for Kenwood/Yaesu/Icom/Elecraft/etc. Rick has already provided a solution for ACOM. I could provide some pseudo-code (not real code, unfortunately) to do the same for the Elecraft KPA1500.

3. External solutions: DDUtil is not a good solution. It has not been supported for anything other than Flex SmartSDR for many years. Node Red can and does work, but requires the user to implement a Node Red server and is beyond the capabilities of the average (or below average!) user even if they are provided with a ready-made Node Red flow to install.

That said, some time ago and for myself I implemented full integration/automation for Thetis and the ATU in the Elecraft KPA1500 amplifier using Node Red. Node Red has proven quite useful to me as it's low-code programming environment is well suited to a non-developer like me :-)

73!

Scott

[laurencebarker]

There is a setup form that could be repurposed for this. Setup->Andromeda actually has no Andromeda setup options but was made the home for Apollo amplifier controls, settings for the Aries ATU and the Ganymede PA protection. Apollo has a small following; Aries may eventually get into G2 and Ganymede will be the protection controller for G2-1K if and when it materialises. That whole tab could be renamed “PA and ATU” or somesuch.

I’m close to having integration into G2 for the LDG family of ATUs: they provide a hardwired strobe requesting TUNE power. We provided a connector on the Saturn PCB for ATU integration and when that signal is asserted IO6 is now activated. I was going to add code in Thetis that listens for IO6 and activated tune while it is asserted; but I’m looking at using CAT over ethernet now (sending ZZTU1; to activate) to avoid changes to Thetis itself.

Laurence Barker G8NJJ

@.***

From: w-u-2-o @.> Sent: Sunday, January 7, 2024 2:31 PM To: ramdor/Thetis @.> Cc: Laurence Barker @.>; Comment @.> Subject: Re: [ramdor/Thetis] Thetis code additions to support automated TUNE feature of Acom 1200S/700S/600S amps and companion 04AT/06AT tuners (PR #378)

Chiming in a little late on this, my apologies...

I provided some advice to Rick on this when he started development of this feature. You can blame me for the FM mode suggestion. Please consider the following thoughts and ideas.

1. Objections to FM mode: if this is the only philosophical impediment to implementation then it appears there is an easy fix. As Richie has already proposed, upon receipt of a DT2 command then assert TUN. On receipt of a DT1 command de-assert TUN. The part of the code that answers a DT query can even be made "legit", i.e. as long as DT tracks the state of TUN, and as long as an ACOM user does not try to start a tune cycle with TUN already asserted all will work correctly. Note: this does require the ACOM user to set the TUN function to use the drive slider and NOT the tune slider because the ACOM amp only controls the drive slider. Make an option called "Support ACOM DT command" in order to make this super-clean (because DT is an Elecraft-specific CAT command used for setting data modes). Put that option in Setup > Serial/Network/Midi CAT > Options > Other.

Rick--you might try making those changes and see if they work OK.

2. Objections to the philosophy of adding amp-specific code: it's not really amp specific, it's more like tuner-specific. This has always been a gaping hole in the Thetis repertoire. It surely would be nice to provide integration/automation with the many tuners who otherwise provide CAT-based solutions for Kenwood/Yaesu/Icom/Elecraft/etc. Rick has already provided a solution for ACOM. I could provide some pseudo-code (not real code, unfortunately) to do the same for the Elecraft KPA1500.
3. External solutions: DDUtil is not a good solution. It has not been supported for anything other than Flex SmartSDR for many years. Node Red can and does work, but requires the user to implement a Node Red server and is beyond the capabilities of the average (or below average!) user even if they are provided with a ready-made Node Red flow to install.

That said, some time ago and for myself I implemented full integration/automation for Thetis and the ATU in the Elecraft KPA1500 amplifier using Node Red. Node Red has proven quite useful to me as it's low-code programming environment is well suited to a non-developer like me :-)

73!

Scott

— Reply to this email directly, view it on GitHub https://github.com/ramdor/Thetis/pull/378#issuecomment-1880075497 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AEXTXZYZMRWW3HGVC4AIWETYNKWRJAVCNFSM6AAAAABBMCEXYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBQGA3TKNBZG4 . You are receiving this because you commented. https://github.com/notifications/beacon/AEXTXZ6BNBHSA4JRJMYYCBLYNKWRJA5CNFSM6AAAAABBMCEXYGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTQB6WOS.gif Message ID: @. @.> >