On 5/23/2025 1:16 PM, Michael Mandell via groups.io wrote:
Have you ever tried a DStar Radio that has both a USB data cable and
a dedicated data port? Such as the Icom 7100? I'm betting no. If you had,you would have seen the behaviour I described.
No, I was making assumptions based on the hardware differences on the computer side. I forgot that the USB hardware on the client side may be more primitive.
Almost all testing that I can do with D-Rats Serial ports is via "Null Modem" interconnects between two D-Rats clients. I have to rely on several volunteer testers on this list for actual on-air tests.
All I have is an IC-91AD to test radio behavior with.
This is most noticable in DRats chat, which has no error correction.
Send a long (couple hundred words) text messages on chat both ways
and watch the radio.
The radio sees no data until the send button is sent.
Then D-Rats sends the entire chat text.
With out some serial port traces and some USB transfer traces, or some documentation from Icom, I did not know why the behavior is different.
So I did some research. It turns out that USB serial devices do flow control handling differently from hardware serial devices, and this is significant to D-rats.
Traditional serial ports have two methods of doing flow control.
Most commonly use is XON/XOFF where the receiving device sends an XOFF character when the buffer is almost full, and then when the buffer is empty it sends an XON character. This has a limitation that pure binary 8 bit data can not be sent over the link with out some modifications.
The other flow control, which is not available on Icom serial ports that I have seen is RTS/CTS which are hardware signals. RTS/CTS is needed for hardware packet modems running in KISS mode for reliable operation.
With those two flow control methods, they are usually handled by the device driver, after the application program like D-Rats connects to the port. For reasons unknown, D-Rats completely disables the driver handling of the flow control, and handles it itself incorrectly.
With a built-in USB serial device, the USB device is using its own hardware handshaking. This can not be disabled by applications as far as I know.
This hardware handshaking is only available with built in USB adapters, not in in USB to serial connector devices. Those devices have no idea what size a buffer that of what they are connected is.
Now for the observed differences:
I would need to connect a serial port trace to confirm this, or have a modified version of D-Rats to confirm it.
D-Rats implemented the serial port incorrectly as a half-duplex driver which means that it is not seeing the XOFF character sent by the device when it should be getting it. In other words, D-Rats is acting like all handshaking is turned off.
So it is likely that the ICOM 7100 is sending an XOFF character to D-Rats requesting that on the serial port that D-Rats should pause sending, but D-Rats ignores the XOFF because it will not look for an XOFF until after it completes sending the data to the radio.
So for Chat messages on a USB to USB connection like the Icom 7100 has, you can send any length of message, and it will get through.
But for the serial port, including USB serial adapters, it is possible that some data will be lost on transmit on a very long message, which D-Rats should flag as a checksum error.
So it is mainly a matter of luck or Icom having much larger buffers than they set their handshaking for that D-Rats is not overfilling the buffers on the radio and causing data loss.
It is possible that if the XON/XOFF handling in D-Rats is fixed to work as correctly, that the radio will start sending smaller packets, or it may not. I don't know.
The current version of Python-3 version has an important bug fix in XON/XOFF handshaking.
Any version of D-rats older than November 7, 2023 has a bug where it can lose data.
The problem is that D-Rats was expecting that if it ever caught up with reading data from the serial port, was because the radio had sent an XOFF character, and if the next character seen from the radio was not an XON character, D-Rats would discard the entire packet and prints a diagnostic messages.
Fixing the XON/XOFF Handling would require a complete rewrite of that section of D-Rats, which is something I will be looking at in Drats2.
Currently there is the older python2 version that still runs on Windows and older out of support Linux Distros. No bug fixes are going into it.
The current version of D-Rats is based on Python3, and available for Windows under MobaXterm and Msys2, and is also available and in use on MacOS and Linux including Raspberry PI systems.
Currently we are mainly testing D-Rats on Windows using MobaXterm as it the easiest way to
The current python3 D-rats supports these features that are no longer working on the python2 version:
* Serial port data loss fix.
* Lookup of address from GPS coordinates.
* QSTs based on USGS becons and NBDC buoys.
* Conversion of D-STAR GPS icons to/from APRS icons.
73,
-John WB8TYW
