I hate to be the bearer of bad news, but here in NWNM D-rats does not work reliably any longer via RF.
We have multiple stations that get intermittent reception/decode.
We have multiple stations that only decode one or two stations out of the group reliably.
We have tried going back to 0.3.3, then 2014, then 0.3.9 and coming forward as a group. No Joy.
Stations have tried a mix of different computers, different radios, different antennas. No Joy
There is a mix of Win 7 and Win10 computers, that does not seem to have any effect at all.
Transmission/reception range is about a 20 mile radius max from the KF5VBE repeater.
Linked operation between the KF5VBE repeater and the KF5VBF repeater to reduce that radius does not help.
Stations show up on the station list, but are not heard.?
Simplex operation has no better success. distance between some stations on simplex may be as little as a mile.
All stations are using an RTS05 orange RT Systems USB cable.
Radios used are ID51, ID5100, ID880, IC2820 with DSTAR add on.
To paraphrase Shakespeare, "Alas poor D-rats, we knew it well!"??

--
AL M
KF5SMH
HH5580

开云体育

The problem is that there is no error correction for D-Star slow speed data.?? On top of this D-Rats is checking to make sure that any received D-Star slow speed data is received perfectly (via CRC check).? Data that is not received perfectly is ignored (unless you turn on raw mode).?

What would have been better than adding all the email/file transfer ect. features on top of the basic chat service that D-Rats originally started as, would have been to focus on 'best effort' data reception that displays messages even if some bits are incorrect, and maybe application level error correction.?? D-Rats relies on a transport layer (the RF tx/rx) that it expects to be perfect, and when it isn't, results in a lot of retransmissions.? Those retransmissions are also likely to fail for the same reason the original transmission failed.? The result is the frustration your users are experiencing.

Mark (K9YK)

On 2/13/2023 11:17 AM, Mark McGregor via groups.io wrote:

The problem is that there is no error correction for D-Star slow speed data.

Reference:
D-STAR only has Forward Error Correction (FEC) on the encoded voice.

The D-STAR digital data format has a Frame Check Sequence (FCS) that is the same as used for an Ethernet frame.

On top of this D-Rats is checking to make sure that any received D-Star slow speed data is received perfectly (via CRC check).? Data that is not received perfectly is ignored (unless you turn on raw mode).

The only place I can find that D-Rats is sending and checking an FCS code is when it is embedding the D-RATS data over AX-25 protocol.
I may have missed something, but I gave it a quick look this morning.

The default settings of my Icom 91AD only receive/send the "data" section in the lower part of Figure 2 from the above link after the "MAC Header" section. Neither the "MAC Header" or the "FCS/crc" is presented to D-Rats through the serial port.

I do not know of any settings for the Icom 91AD to give the serial port access to the rest of the digital frame.

I do not know what the radio does with the received data frame if the FCS check fails.

So we need a lot more diagnostics to determine what is going wrong in this case. Turning SNIFF and RAW mode on in D-rats to see if anything is logged would be a start.

If the data is not getting to D-Rats, there is nothing that can done in software to fix it.

One of the early bytes in a D-Rats frame is one that tells D-Rats if the frame is chat data or other data. If that gets corrupted, all sorts of bad things can happen, up to and including D-Rats internally just hanging on that particular transfer. Do not try to ping your own station or send files to your local station.

What would have been better than adding all the email/file transfer ect. features on top of the basic chat service that D-Rats originally started as, would have been to focus on 'best effort' data reception that displays messages even if some bits are incorrect, and maybe application level error correction.?? D-Rats relies on a transport layer (the RF tx/rx) that it expects to be perfect, and when it isn't, results in a lot of retransmissions. Those retransmissions are also likely to fail for the same reason the original transmission failed.? The result is the frustration your users are experiencing.

I really could use some help in getting the actual state diagram for D-Rats documented. What we have is what we have.

My first focus was just getting D-Rats working on Python 3 so it can be used on current computers.

While doing so I noticed a lot of issues. I fixed a number of them, and filed tickets on the rest of the issues for future work.

I just do not have time to do everything my self.

One thing that I find odd with D-Rats, that may or may not be related to this issue is that D-Rats is handling XON/XOFF handshaking in its own software instead of letting the serial port software driver handle it.

There are no comments in code as to why that decision was made. In the future, I would like to have an option to allow the driver to handle the XON/XOFF so that we can test and find out if there was a reason for D-Rats to do it instead. It very well could be one of the reasons that D-Rats is receiving / sending garbled frames.

I previously have posted that data polling loops in D-Rats need to be changed to being event driven to take up less CPU when running and to be better able to prevent transmission collisions.

73,
-John
wb8tyw

--

On 2/19/2023 8:24 AM, Donald Hinsman wrote:

Dear All,
I too am having difficulties using D-Rats 0.3.9, Windows 11, ICOM-880h and
the RF. I uploaded the latest memory settings using the RTS05 orange cable
with no difficulties. The RTS05 cable showed in the Device Manager Ports
as COM 3. I then added a Serial port in the D-Rats Preferences. COM 3
hasn't listed but I manually addded it and labelled it D-Star.

If D-Rats does not list the serial port in the drop down, it will not be able to use it, so that is going to be a problem.

The log format looks like the out of date Python2 version of D-Rats.

No bug fixes are going into the python2 version, and there have been some fixes to the serial port handling in the python3 version.

Have you made sure that no other application is using the COM3 serial port? That will block D-Rats from being able to use it.

Have you verified the serial port setting for the radio?

Page 90 of



73,
-John
wb8tyw

--

On 2/19/2023 9:57 AM, Donald Hinsman wrote:

Dear John,
The 880h has a different back than the 800h but I'm sure mine is set
correctly. How do I get the python 3 version and is it still 0.3.9? I'm
hesitant to update 9 computers if I have to move from 0.3.9.

The old D-Rats 0.3.9 version will no longer run on most newer operating systems. Python2 is EOL, GTK2 is EOL, and are no longer available as a pre-built trusted packages. None of my development / Test systems can run the 0.3.9 version any more.

Most current D-Rats Today is 0.3.10b6.dev287 at:
/g/d-rats/files/D-Rats/D-RATS%20pre-release .

Microsoft Windows detailed instructions are at

As support From Microsoft has been dropped for all Microsoft versions prior to Windows-10, I do not know if Msys2 still has a package download for anything earlier.

For installation on other platforms:


Current prebuilt lzhuf needed for winlink is at
/g/d-rats/files/D-Rats

Otherwise it needs to be built from:


73,
-John
wb8tyw

--

On 2/19/2023 5:36 PM, Donald Hinsman wrote:

John, my installation as stalled at
Setup of a Python Virtual Environment for running D-Rats
101.010 Running D Rats in a Python virtual environment and PIP

- Microsoft Windows Msys2 Mingw you install
'mingw-w64-x86_64-python-virtualenv'
when I enter mingw-w64-x86_64-python-virtualenv in MINGW32, IT SAYS
bash: mingw-w64-x86_64-python-virtualenv: command not found

I have updated that wiki. If you ran the msys2_packages.sh script though the python-virtualenv is already installed.

and when I enter
python -m venv ~/my_hostname_venv --system-site-packages
I don't know what ~/my_hostname_venv IS

It really does not mater what you put in for "my_hostname_venv". It the directory to hold the virtual environment. I use the system name of my PC. I forgot that many people never set a system host name for their PCs. I usually name them ending with "_venv" just as a reminder of what it contains.

A virtualenv generally only works on the system it was created on, or one that is similar, and I tend to use a share that is common to a number of systems.

Msys2 did not let me create the virtualenv on the shared system.

I'm stuck but up to here your instructions are clear.

Hope this help you get going.

73,
-John
wb8tyw

Good Morning All!
I do not believe that the radio used has any effect on successful Tx/Rx decode, we have tried a number of radios as I stated.
Also would add that some of the Win7 and Win10 machines were stable operating systems then all at once should issues.
Win10 updates have always been suspect to me as the cause, but not being a coder I am at a loss to say that as matter-of-fact.

--
AL M
KF5SMH

On 2/20/2023 9:25 AM, Al Massaro KF5SMH wrote:

[Edited Message Follows]
Good Morning All!
I do not believe that the radio used has any effect on successful
Tx/Rx decode, we have tried a number of radios as I stated.

So far the most important question has not been answered.

Is the digital data getting from the radio into D-Rats at all?
For that the "sniff" and "raw" must be enabled on the radio port in D-Rats.

If you are not seeing sniffed data logged in d-rats for the missing transmissions from the chat window, etc, then issue is not a d-rats issue, but an general issue that for some unknown reason the transmission is not making it to the radio intact.

What to investigate next depends on the answer to the question above.

And if it is a D-Rats issue, the only version will be getting any fixes is version 0.3.10b6.dev287 as is also being discussed on this list.

I suspect that what ever the issue is, upgrading to the current D-Rats may not fix it, but it could be interesting to see if the current version works better.

Also would add that some of the Win7 and Win10 machines were stable
operating systems then all at once should issues.

No idea if there is anything wrong with the Windows systems in use from what has been posted so far. Chances are if there is something wrong with them, it would be more noticeable than just causing D-rats problems.

73,
wb8tyw

Two of us installed the?version 0.3.10b6.dev287 yesterday, I noted no significant change in operation from any of the previous installs. I am one of the successful Tx/RX stations here (knock on wood). The other station encountered an issue with his 880 not decoding when his 5100 would, same peripheral hardware just a radio change. We ran the connectivity test and found the 880 produced a flat "0" returns, while the 5100 resulted in a 66%,. That may indicate that the 880 does not receive as well in that location, so I may be incorrect somewhat in my previous statement. My statement about Win 7/10 was merely to say that D-RATS was operating fine on them, then just suddenly stopped decoding, As originally stated there is reception/decode from some stations but not all, indicating, but once again we are using a repeater so signals should be the same at all locations. We are going to run a S-RATS net this weekend we will have results fro that to share.

--
AL M
KF5SMH

Well, I run it on a Win 10 laptop and a Win 11 desktop. I'm running the 3.9 Python 2 version. I used the Windows installer, which puts on Python 2 (I think). It runs on both machines reasonably well (occasional crash, quickly restarted to fix). Can't tell you about a 2820 but I use the other radios, plus a 7100 and 4100. It works via bluetooth perfectly on both the 5100 and 4100.?
We have issues here using a repeater sometimes, peer to peer. Not sure why. We suspect maybe a timing issue. Simplex is perfect. Simplex relay is perfect.?
Bottom line....it can work. It does here. We'll use it again tonight for our weekly practice. The repeater is a real icom stack but is not using icom software. It's? part of a multi-mode thing (coverts basically every digital mode so they can talk). PennLinkGroup owns and runs it. We do have straight icom repeaters to try also but generally play with the PennLinkGroup repeater due to RF access and the owner is part of our group so we're good to play with it.?

No idea why some can't get Python2? to run....runs fine on this machine, which is a year-old Windows 11 Home machine. I suspect maybe there are vestiges of other library files from attempts at Python 3 on your machines. Just a guess from many years of using Windows. Some stuff just hangs around. Maybe try some kind of? cleaner software to purge .dll and other files that may affect this.?

I also have (and use with D-Rats) an 880H. I'm sure you know the settings and menu stuff is nowhere near as easy as the 5100.?
ID-800H 9600 DVT = DVTAT, SPD = SPD96? ? ?....this from D-Star info. On mine, I don't have external GPS so that is always off and a non-issue. I have had one Orange cable just fail on me---became flaky. Can you try another? I've bought a few of those. Seemed strange because the cablle that got weird is in the shack and reallly never moved at all.?

I don't notice a difference in RF performance in any of my radios (using the same coax and antenna), really. I'm not Rob Sherwood, though.?

Hopefully others can help here with ideas. We know it can work.?

John,?
Thanks for that reference. Very interesting and useful. However, it says that the slow speed data frame has no error correction at all, as a previous comment stated. I was also told this by Icom (called them) when I had problems with a USB connection to my 7100 breaking up D-Rats "chat" into several transmissions instead of just one longer one on the RT Systems cable. I was told that computer USB breaks up serial data into packets, while true DV Data is one continuous stream....exactly what that document says in paragraph 6.?

John:

?Take another look at the D-Star spec document you reference. I think you are confusing slow-speed (or fast mode) conncurrent voice/data D-Star with DD mode. DD mode is an entirely different aniimal and does not work with D-Rats. Thats the ID 1 1;2Ghz and now also the 9700 1.2Ghz mode. It's compatible with Ethernet. Again, totally different. DV data is a continuous data stream. No correction, no packets.?

On 2/22/2023 6:09 AM, Michael Mandell wrote:

John:
Take another look at the D-Star spec document you reference. I think
you are confusing slow-speed (or fast mode) conncurrent voice/data
D-Star with DD mode.

Yes, I discovered that yesterday that the slow speed digital data mode
is interleaved with the digital voice and has no correction.

One of my projects that I am working on is connecting a MMDVM GMSK modem to a IC-807H so that I can look at the entire D-Star packet and hopefully use that GMSK modem with D-Rats. This would allow d-rats to use radios with the 9600 baud TNC port.

What I find odd is what it states about XON / XOFF. It says not to use the device driver XON/XOFF setting, but to do it in software like D-Rats does.

The main problem with the XON/XOFF protocol is documented the document is that a corrupted data packet could send an XOFF code to the D-Rats program causing it to stop sending data to the radio.

The use of software XOFF instead of driver XOFF, is not going to change that problem. Using software XON/XOFF instead of driver XOFF, will result in the XOFF processing being slower, with a higher chance of the radio dropping characters.

I do not recall seeing any code in D-Rats for recovering from a spurious XOFF showing up from the radio serial port. I have not seen this happen, but as near as I can tell it will stop communications on that radio port. This is something that we should probably be looking at tin the code.

I plan to have a future version of D-rats offer the option to use the driver XOFF, and also test if the connected device supports the DSR and CTS signals. I have not checked if packet modem firmware support the RTS/CTS signals.

73,
-John

On 2/22/2023 5:20 AM, Michael Mandell wrote:
<snip>

No idea why some can't get Python2? to run

While you can still run python2 D-Rats on Windows, We can not run python2 based D-rats on current versions of Anti-X Linux, or the last two versions of Ubuntu LTS, or the current version of Raspbian for the Raspberry PIs. I suspect the same for Fedora, Rocky/Alma 8 or later, or OpenSUSE Leap 15. This also may be the case of current Mac OS.

Python2 is EOL and no longer being maintained.
GTK2 is EOL and no longer being maintained.

No bug fixes, including security fixes are being made to Python2, Python2 libraries, GTK2.

While it is possible to build a python 3 program that is backwards compatible with Python2, it really is just not practical for a GTK 3 based program. They just changed too much in the library calls.

73,
-John
wb8ytw

开云体育