Bug #10510
closedCHIRP Next Serial port flow control
100%
Description
I am using a DigiRig radio interface which has a built in sound card, CI-V port and uses RTS o the same COM port to key PTT.
When CHIRP Next 20230409 reads the radio it asserts RTS on the serial port which keys the transmitter.
RTS nor DTR are needed for CI-V so CHIRP should not assume that the port requires flow control. This should be the default for all CI-V based radios but a pair of checkboxes on the initial READ RADIO dialog to disable RTS and DTR would solve this issue.
I don't see a configuration dialog where port parameters can be changed.
Updated by Dan Smith over 1 year ago
- Status changed from New to Not a bug
CHIRP is specifically asking for no hardware flow control on the Icom CIV drivers. Also just to be clear (from the conversation on the mailing list), the setting in Device Manager has no impact on CHIRP. Even if it were set differently, CHIRP's request overrides at open time.
If RTS or DTR are getting set, it's not because CHIRP is asking for it. Most USB-to-serial devices do not do hardware flow control correctly anyway, so it may be something with your device or driver. But, since CHIRP is already requesting neither assertion, there's nothing more it can do.
Updated by Dan Smith over 1 year ago
- Assignee set to Dan Smith
- Target version set to chirp-py3
Further discussion on the ML and in private resulted in discovering this pyserial bug:
https://github.com/pyserial/pyserial/issues/124
..which apparently prevents pyserial from honoring the rtscts=False
and dsrdtr=False
flags to opening the port.
Updated by Dan Smith over 1 year ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Applied in changeset github|0b4dc9229a5f49e0dcf3df33645d43d31e335bfa.