开云体育

On 5/25/2025 6:24 AM, Michael Mandell via groups.io wrote:

Thanks for the explanation, Icom's 'expert" just explained this very
basically. I don't get this over the dedicated serial cable or
bluetooth...just the wired USB connection where it breaks up
transmissions. It does work, though

It has to do with the technology, USB is a block mode transmission with hardware flow control that is simulating a serial device. The serial adapters I have have connections for one direction hardware flow control.

The Bluetooth serial adapter modules in my workbench do not have any hardware flow control connections to them. This indicates that there probably is not anything in the serial over Bluetooth that carries that data. So it is limited to software flow control.

Software flow control is totally broken on the older D-Rats, and still poorly implemented on the modern D-Rats.

Since you are watching this, have you ever looked into one of those
so-called AI programs to convert D-Rats? I don't know much about
them, but many people say they are great at this kind of thing.
Co-pilot for sure...my son has done some work like this. I wonder if
this might help your efforts on bringing D-Rats more up to date.

AI is currently of very limited use for Professional Programming and Public open source project.

My employers have strict rules about the use of AI to avoid legal problems.

One of the big legal problems in programming is copyright. There is a risk that an AI may have learned from copyrighted code that while it is public, requires a paid license to use, or it may have found copyrighted code that was posted by mistake, etc. The more code generated by AI the higher the chance of a copyright violation.

The second big problem is that AI has what is called hallucinations.
It can just simply makes up incorrect answers at times. The google search AI has on at least two occasions made up obviously incorrect answers to some of my queries. And several lawyers who should have known better are in trouble because they submitted AI generated documents to courts that that cited non-existent court cases.

A person has to know what they are doing and not rely on AI. They can use AI to help them learn, but if they don't verify or understand why the AI came up with the answer that it did, and can tell if the answer is valid or not, then the using AI is really no help.

One article I read on AI is that the users could not get the AI to explain how it came up with some of the answers that it did, even when the answers were correct. And this was a case where human experts looked over the same input data, and could not come up with those answers. That shows that while AI has the potential to really make things better for us, at least some of implementations have significant problems.

Planned for drats2 (and the list keeps growing)
* YAML config files, faster to load and parse.
* Central downloadable databases of Ratflectors, Radios, and other communication link types and devices.
* Full duplex I/O streams. This is required for software flow control to work correctly.
* Upgrade from AX.25 to FX.25 (Adds 7 character call signs and Forward error correction.
* See if FX.25 forward error correction can be applied to D-Rats chat and other packages.
* Station ID transmissions signed by public keys.
* Investigate additional support for other text protocols like LARA Mesh.

This will be a long time coming because it is a complete rewrite of the configuration file handler, and in the communication loop at the heart of D-Rats. And a lot of real life is getting in the way of my spending time coding.

73,
-John
wb8tyw

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

On 5/19/2025 9:29 AM, Michael Mandell via groups.io wrote:
<snip>

With a normal USB cable, serial transmissions are broken into
packets, so your radio will transmit D-Rats serial data in chunks. It
goes on and off in xmit to get the whole thing out.

It should not be doing that unless somethings is wrong. Yes the USB breaks up the serial data into chunks, but it can fit an entire d-rats packet into one chunk.

What USB is doing is delaying sending any characters until its buffer reaches fixed mount, or there is a very small time that no additional characters are added to the buffer.

The radio has an XON/XOFF handshaking to slow D-Rats down to the speed that the radio can accept.

With the RT Systems cable and the radio data port, serial is a
continuous stream and it goes out in one shot.

I called Icom on this and got a support guy in Texas who explained
the whole thing to me. Both work, but the orange data cable (Icom
has one, too, but it costs way more) is a better solution.

I don't think you fully understand how that works.

D-rats transfers data to and from a USB serial port at a rate of about 30 Megabytes per second. In addition that transfer from the USB serial is done with what is known as a DMA transfer. Which means that it does hardly stresses your CPU utilization at all.

That means only one interrupt per transfer. Interrupts are costly for a PC to process, because it has to save context, process the interrupt and then restore it. The computer does this every time you do I/O except for screen writes. Most devices on your computer use DMA transfer.

On a "standard" older PC that still has a serial port, it has a very small buffer and must interrupt the PC once it has either filled the buffer or emptied the buffer. So at best, it is processing one of those interrupts on every two characters transferred. D-Rats sends/receives around 200 bytes per transfer, so that is at least 100 interrupts per transfer.

Now most people don't load up their PCs to the point where that makes a difference.

But your PC can handle at least 20 times the number of USB ports running flat out with data than the maximum number of "standard" serial ports it can support. And it was hard to even add enough "standard" serial ports to cause a strain on the last models of PCs that had them available.

Yes, USB delivers the first character in a bunch of characters slightly slower than the serial port. If you get a good enough analyzer you can see that easily. However your computer is working much harder to deliver that data on using the older serial port.

So use what ever cable you want to use.

73,
-John

On 5/11/2025 10:35 AM, John E. Malmberg via groups.io wrote:

On 5/9/2025 6:08 AM, Facundo Fernandez-KK4ODA via groups.io wrote:

Hello, I have seen posts of hams using D-RATS with FLDIGI modes
instead of DSTAR. I have tried this with various degrees of success.
It occurred to me that it may be possible to run DRATS with VARA as a
modem.

Finally found this document:

Actually the relevant document is:


73,
John
wb8tyw

On 5/9/2025 6:08 AM, Facundo Fernandez-KK4ODA via groups.io wrote:

Hello, I have seen posts of hams using D-RATS with FLDIGI modes
instead of DSTAR. I have tried this with various degrees of success.
It occurred to me that it may be possible to run DRATS with VARA as a
modem.

Finally found this document:

However, I tried this using the default command port of 8300 with
no success. I know this is a long shot, but has anybody tested this
configuration succesfully?

Obviously I have no experience except from looking at the source code, but D-Rats generally does not send commands to TNCs and other Packet type modems. It assumes that they are already in either the AX25 or the KISS mode and only connects to them over what is presented to D-Rats as a serial device.

For VARA the above documentation says to use port 8100 for KISS mode.
As far as a modem is concerned KISS mode can also handle AX25 packets because in KISS mode just a raw 8 bit stream is sent over the radio.

This should work for AWGPE, as D-Rats seems to assume that the connection can handle AX25 frames, and parses the connection commands from the AX25 frames.

So far I have not found the username and password fields for the AGWPE connector used anywhere.

73,
-John

On 5/9/2025 10:01 AM, David Ranch via groups.io wrote:

I would think that D-RATS could be enhanced to work with D-RATS but it shouldn't be done via the old school KISS interface.? It would need to be done via the VARA native interface.

I have done a bunch of searching this morning and can not find anything that tells me anything about the VARA native interface or the KISS interface.

D-Rats implementation of Winlink seems to be limited to some message passing, not for chat.

D-Rats has basically these major modes of communication.

Repeater, after login, it just sends/receives its DDR2 Yencoded packets over a network connection.

Serial port: It just sends and receives its DDR2 Yencoded packets over the serial link and any radio modem that can pass through serial data will work.

AX25 mode: It sends/receives AX25 packets via the serial port or the AGWPE socket. Inside the packets is a DDR2 Yencoded packet.

KISS Mode: Looks like it just sends and receives DDR2 Yencoded packets through the serial port. Not sure if it can do that with the AGWPE interface.

Yencoding is needed for D-Star radios because the serial port is also used as a remote control for the radio and Yencoding filters out binary that could be interpreted by the radio.

If only sending data over a serial or network link is needed, the hardest part of modifying D-Rats is the way the current configure GUI is implemented and the glade tool that should allow customizing it easily is refusing to cooperate.

73,
-John

开云体育

I would think that D-RATS could be enhanced to work with D-RATS but it shouldn't be done via the old school KISS interface.? It would need to be done via the VARA native interface.?? If someone is looking for D-RATS like functionality but for VARA, check out VARAC:

??


It implements a lot of similar concepts in D-RATS, FSQ, etc. The interface is a bit complex but you get used to it.? It and both the VARA-FM or VARA-HF modem programs run fine under Wine for Linux and Mac users.? The tool automates all that installation which makes it a snap.


There is also vARIM tool as well which is very powerful but more complex:

??



--David
KI6ZHD

开云体育

DRATS uses several types of net linkage, including internet and RF. It does not have to speak DSTAR data. Best approach is to start with the most recent version 3.x and play with it while reading through some of the old documentation (in the files section) to get the basic set up. Ask questions here.

开云体育

John,?