Serial port not fully initialized on start up -- permanent key-down

[zcsahok]

When specifying no line assignment (i.e. no -o option) the key and PTT pins are left as-is after opening the serial port. As the OS might have a different idea on what the normal of state of these lines is this can show up for example as a permanent key-down state until actual keying (or an ESC-0) is executed. I 've experienced this with a USB-to-TTL converter.

The reason is that with the introduction of configurable key/PTT lines tty_reset() is executed too early and sees both lines as opted-out (calloc sets both values to 0).

A quick (but not the most correct) solution is to move calling reset after setting the defaults for the lines.

--- a/src/ttys.c
+++ b/src/ttys.c
@@ -127,14 +127,15 @@ ttys_init (cwdevice * dev, int fd)
                cwdaemon_debug(CWDAEMON_VERBOSITY_E, __func__, __LINE__, "calloc() failed");
                exit(EXIT_FAILURE);
        }
-       dev->fd = fd;
-       dev->reset (dev);

        // modem control signals default to DTR for CW key, RTS for SSB PTT
        struct driveroptions *dropt = dev->cookie;
        dropt->key = TIOCM_DTR;
        dropt->ptt = TIOCM_RTS;

+       dev->fd = fd;
+       dev->reset (dev);
+
        return 0;
 }

[acerion]

Thank you for the report.

As the OS might have a different idea on ... I 've experienced this with a USB-to-TTL converter...

Can you please let me know which OS (distribution/version) and converter type are you using?

[zcsahok]

It's CP2102 converter and I'm using Debian 12 (bookworm) on an i386. Simply opening the port using picocom puts DTR to the "wrong" (key down) state, so it's not related to cwdaemon as such. But cwdaemon shall initialize the port to an idle state (key up, PTT off).

[acerion]

Thank you for the details. I will try to get my hands on the converter and replicate the issue. I won't be able to find i386 PC, but maybe with Debian 12 on a more modern box I'll also replicate it.

[zcsahok]

Thanks for looking into this problem. It would be generally wiser to initialize the control lines to a defined state, no matter what hardware device is used. The patch I provided solves my particular issue.