aethersdr / aethersdr/AetherSDR

Request to add support for elecraft kat 500 and kpa 500

Open
#4,953 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement external devices maintainer-review New Feature protocol safety
Dominant language
C++
Stars
221
Forks
117
Avg merge
2d 7h
Merged PRs (30d)
299

Description

Request preparation
  • I used an AI assistant to help structure this request
  • I checked for existing issues covering the same feature
What would you like?

Absolutely. AetherSDR can be extended to support the Elecraft KPA500 amplifier and KAT500 tuner, and Elecraft provides the serial command references needed to do it.

A sensible integration would be:

KPA500
Power ON/OFF
Amplifier standby/operate
Read RF output power
Read SWR
Read temperature
Read faults/status
Band/frequency synchronization
Display amplifier status in AetherSDR
KAT500
Read tuner status
Initiate tuning
Read SWR/input/output information
Antenna selection
Bypass/active status
Frequency/band synchronization
Display tuner status in AetherSDR

Elecraft actually publishes a KPA500 Programmer's Reference and a KAT500 Serial Command Reference, so we can implement this at the command/protocol level rather than trying to reverse-engineer the devices.

Elecraft also has separate remote-control applications for both units; the current published versions are KAT500 Remote v1.16 and KPA500 Remote v1.17.

I can help you implement it

If you can give me the AetherSDR GitHub repository URL (or upload the source), I can look through its existing architecture and determine the best place to add:

AetherSDR → Elecraft KPA500 / KAT500 → serial/USB

I'd suggest making the Elecraft equipment a separate hardware integration module, rather than mixing KPA500/KAT500 commands into the FlexRadio code. That would make it easier to add other amplifiers/tuners later.

If you send me the AetherSDR GitHub link, I can start by mapping out exactly which files/classes need to be changed.

I’ve looked through the current AetherSDR repository, and yes — KPA500/KAT500 support fits the project very well.

AetherSDR already has Qt6 QSerialPort support, serial PTT/CW infrastructure, and external-device integration. More importantly, it already has a model for integrating an amplifier and tuner: PGXL + TGXL are supported as external station hardware.

Elecraft publishes the official KPA500 Programmer's Reference and KAT500 Serial Command Reference, so we can implement the actual protocols directly rather than going through Hamlib.

What I would add

I'd make this a native Elecraft Station Hardware integration:

                     AetherSDR
                        │
         ┌──────────────┴──────────────┐
         │                             │
    Flex Radio                    Station Hardware
         │                             │
         │                    ┌────────┴────────┐
         │                    │                 │
         │                 KAT500            KPA500
         │                    │                 │
         └──── frequency ─────┴─────────────────┘

The important part is that AetherSDR becomes the coordinator.

When you change from, say, 14 MHz to 21 MHz:

AetherSDR gets the new VFO frequency.
KPA500 is told/updated with the operating frequency/band.
KAT500 follows the frequency.
AetherSDR displays amplifier/tuner state.
During TX, AetherSDR can monitor power/SWR/fault conditions.
KPA500 panel

I'd expose:

ON / OFF
STBY / OPERATE
Forward power
SWR
Temperature
Fault condition
Band/frequency
Amplifier status
Connection status
KAT500 panel

I'd expose:

TUNE
BYPASS
Active tuner state
SWR
Frequency
Antenna selection
Tune-memory state
Connection status

And I'd make the KAT500 → KPA500 relationship explicit, rather than treating them as two unrelated serial devices.

Elecraft specifically documents the KPA500/KAT500 as a Power Combo, and the KAT500 can automatically select stored tuning memories based on transmit frequency.

One thing I would not do

I would not implement this as a generic Hamlib feature.

AetherSDR already has Hamlib/rigctld for broad radio compatibility, but KPA500/KAT500 are much more interesting as native hardware integrations, similar to the existing PGXL/TGXL support. That gives us access to the amplifier/tuner-specific status and controls that a generic CAT abstraction may not expose.

Next step

I can go deeper into the actual AetherSDR source and lay out the specific files/classes to modify, including:

where PGXL/TGXL are implemented
where the serial-port abstraction lives
where the hardware settings UI is built
how to add KPA500 and KAT500 device classes
the exact Elecraft commands/responses to implement
how to synchronize frequency/band with the Flex
how to handle TX safety and fault states
unit tests for the command parsers

That would give us a concrete implementation plan rather than just a feature proposal.

provide a complete implimentaiton model

Yes. I would implement this as a native Elecraft station-hardware subsystem, with KPA500 and KAT500 as independent devices coordinated by a common ElecraftStationController.

I checked the current AetherSDR tree and the current Elecraft references. AetherSDR is C++20/Qt6, already uses Qt SerialPort, and already has external PGXL/TGXL support. Elecraft's current documentation provides the KPA500 Programmer's Reference and KAT500 Serial Command Reference; the KAT500 reference is currently version 02.012.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the existing PGXL/TGXL external station-hardware integration and the Qt6 QSerialPort and serial PTT/CW infrastructure named in the issue. Compare those entry points with the official KPA500 Programmer’s Reference and KAT500 Serial Command Reference; done requires support for device controls, status display, frequency and band synchronization, TX safety, and command-parser tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
desktop
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.