Report preparation

• I used the AI-assisted bug report tool (Help → Support → File an Issue)
• I have attached a support bundle or log file

What happened?

Summary

I am testing remote CW operation with AetherSDR using a physical iambic paddle connected directly to a real serial port on the Windows PC running AetherSDR.

The paddle input works correctly. AetherSDR receives both paddle contacts and generates cw key 1 / cw key 0 events. Local sidetone also sounds correct.

However, when CW Break-in is enabled, not all CW elements are transmitted over RF. The local sidetone sounds complete, but the transmitted signal is missing some dots/dashes, especially at the beginning of a transmission.

When Break-in is disabled and I manually put the radio into TX before sending CW, transmission is much more reliable.

This suggests a possible timing/race condition between serial paddle input, local sidetone/keyer, SWCW Break-in, netCW, and the radio TX state.

Operating conditions / station setup

The radio is being operated remotely using AetherSDR.

CW is generated from a physical iambic paddle connected to the client PC running AetherSDR.

The radio is not being keyed directly by an external hardware keyer. The keying path is:

Physical paddle
→ real serial COM port on the PC
→ AetherSDR serial input
→ AetherSDR CW keyer / SWCW / netCW
→ remote radio TX

Operating system and serial hardware

Operating system: Windows
Serial port used: COM1
Serial port type: real hardware COM port from motherboard COM header
Serial bracket: StarTech PLATE9M16 DB9 serial bracket

The COM port appears correctly in Windows Device Manager as:

Communications Port (COM1)

The PC did not originally have an external DB9 serial connector. I installed a StarTech serial bracket connected to the motherboard COM header.

StarTech PLATE9M16
Motherboard COM header → DB9 male serial port bracket

The serial port is recognized by Windows and by AetherSDR.

Paddle wiring

Physical iambic paddle connected directly to the DB9 serial port.

Paddle common  → DB9 pin 4 / DTR
DIT contact    → DB9 pin 8 / CTS
DAH contact    → DB9 pin 6 / DSR

Important note: in my setup, DB9 pin 4 / DTR is used as the paddle common reference, not DB9 pin 5 / GND. Using pin 5 did not work correctly with this serial port.

Manual pin tests:

DB9 pin 8 shorted to pin 4 → DIT works
DB9 pin 6 shorted to pin 4 → DAH works

AetherSDR serial configuration

In AetherSDR serial settings:

Port: COM1
Baud: 9600
Data: 8
Parity: None
Stop: 1

Pin assignment:

DTR: None
RTS: None
CTS: CW Dit Input
DSR: CW Dah Input

The paddle works correctly with this configuration. DIT and DAH are both detected.

AetherSDR CW configuration

Tested CW settings:

Mode: CW
Iambic: ON
Sidetone: ON
Breakin: ON
Breakin delay tested: approximately 1000–1200 ms

Also tested:

Breakin: OFF
Manual TX/MOX before keying

With Breakin OFF and manual TX/MOX, CW transmission is much more reliable.

Observed behavior

With Breakin enabled:

Local sidetone sounds complete.
AetherSDR receives paddle input.
Logs show cw key 1 / cw key 0 events.
Radio enters SWCW transmit.
But some CW elements are missing on RF transmission.

The issue is most noticeable at the start of a transmission. It sounds locally as if the full CW message was sent, but over RF some dots/dashes are missing.

The log shows that cw key events can occur before the radio has fully reached TRANSMITTING.

Example pattern observed:

cw key 1
cw key 0
PTT_REQUESTED
TRANSMITTING

This suggests that the first CW element may be sent before the radio is actually transmitting.

Actual behavior

The first cw key events can be generated before the radio reaches the TRANSMITTING state.

Possible result:

Local sidetone: complete
RF transmission: missing initial dot/dash or part of first character

Increasing Break-in delay helps keep the radio in TX after keying, but it does not appear to solve the initial TX timing issue.

The missing elements seem to happen at the start of transmission, before the radio has fully entered TX.

What did you expect?

Expected behavior

When Breakin is enabled and CW is generated from serial paddle input, AetherSDR should ensure that the radio is actually in TX before the first CW element is sent over netCW/SWCW.

Expected sequence:

Serial paddle input detected
→ request SWCW Break-in / PTT
→ wait until radio state is TRANSMITTING and tx_allowed=1
→ then send cw key 1 / cw key 0 events

Alternatively, AetherSDR could buffer the first CW element until TX is confirmed active.

Steps to reproduce

Reproduction steps

1. Operate the radio remotely using AetherSDR.

2. Use a real serial COM port on Windows.

3. Connect an iambic paddle to the serial port:

Paddle common → DB9 pin 4 / DTR
DIT           → DB9 pin 8 / CTS
DAH           → DB9 pin 6 / DSR

4. Configure AetherSDR serial input:

DTR → None
RTS → None
CTS → CW Dit Input
DSR → CW Dah Input

5. Set the radio/slice to CW mode.

6. Enable:

Iambic ON
Sidetone ON
Breakin ON

7. Set Break-in delay to a high value, for example:

1000–1200 ms

8. Send CW using the paddle.

9. Compare:

Local sidetone
RF transmitted CW
Log timing of cw key events
Log timing of PTT_REQUESTED / TRANSMITTING

10. Repeat the same test with:

Breakin OFF
Manual TX/MOX ON before sending CW

In my tests, Breakin OFF + manual TX/MOX is much more reliable.

bbbd1898-d44c-4154-b207-2f7fe9c4acae.log

AetherSDR version

0.9.8

Radio model & firmware

FLEX 6300 4.2.18

Operating system

Windows

OS version and hardware

Windows 10