ham-radio-software
Serial port enhancements needed
In my long career, I have spent way too much time debugging serial connections, and most of it is caused by either programs or wired devices not following the existing standards.
There are multiple wiring patterns that people have for serial ports, and D-Rats is not fully compliant with them.
There is a minimal writing pattern that is common where only the send/receive and signal return lines.
In this configuration, software handshaking (XON/XOFF) is used and making sure that you have fast enough / big enough buffering.
The serial connection to an radio can be an example of the minimal wiring.
Some protocols like AX-25 KISS mode do not support software handshaking.
TNCs and D-rats should support a more full wiring of all the handshake lines, particularly RTS/CTS, CD, DSR and DTR.
The DTR signal must be asserted by a program when it has control of the serial port. The DTR signal is connected to the remote DSR signal. A program should not assume that anything is paying attention any data from the serial port if is not asserting the DTR signal.
For DSR D-rats needs an option to enable monitoring this signals for an active serial connection. If that option is enabled, D-rats should only consider the connection active if DSR is asserted and should set it to disconnected when it is not asserted. CD should also be monitored. A drop of CD or DSR means that the connection is down.
Unfortunately the python serial driver does not provide this monitoring.
The RTS signal should always be asserted before D-Rats sends any data. This is connected to the remote CTS signal.
A properly written serial port driver should handle RTS/CTS and/or XON/XOFF handshaking automatically so an application program only needs to know if it should tell the driver if either should be used.
So the user needs to know if the CTS signal is wired to know to request it being monitored.
Using DTR handshaking has only been seen in printers, so does not need to be considered or D-Rats.
Not sure if we have to pay attention to the CD or RI signals. This pretty much duplicates the DSR signal. DSR means that the modem is on, CD means that a remote modem is connected. And RI means that a remote system is requesting a connection.
And just to make things more complicated, one of my TNCs has a mis-wired serial port. I do not know why they did not follow the standard, but reading their manual shows that they swapped two of the signaling pins, so if you are want to use those signals, you need a non-standard wiring.
Hum, while hardware flow control would be ideal, it doesn't sound viable as a one-size-fits-all solution, because some D-Star radio models (eg. Icom ID-51 family) only feature a 3 wire serial port.
Have some tests been performed with enabling back pyserial's builtin software flow control mechanism?
While radio models may only implement a 3-wire arrangement, a program should still be setup to follow the standard, and so should the wiring of the standard D type serial connectors. And this also applies to Packet Modems.
The serial port driver software flow control was enabled in a test PR of D-Rats and the result was that reports of data corruption.
It was before I discovered the bug that that D-Rats expected that the first character received when the receive buffer was empty was an XOFF character, and if it was not, it discarded the character, which of course corrupted the incoming packet.
With driver XON/XOFF enabled, D-Rats would not ever get the XON character it was expecting.
I've experienced similar issues when experimenting with dvtnc, but relying on the OS' software flow control mechanism solved that mess for me (video of a successful P2P Wl2k connection over D-Star using DVTNC).
I'll try to twiddle a few things on my side, and will submit a PR once I have some extra time for that ;)
Slightly related to serial port protocols is https://github.com/ham-radio-software/D-Rats/issues/25 where we do not have a definition for protocols for RS-MSA1 integration.