Re: Inconsistent CQCQCQ responses

开云体育

Hi Mike...

Did the three radios have different and unique callsigns in them?? You didn't say.

Is this an authentic ICOM D-STAR repeater?? You said no gateway...but nothing else about the repeater.

Randy - W4LKS

On 12/19/2022 18:31, VA3MCT wrote:

I removed the repeater from the setup and ran everything as simplex and all works fine.

This however makes use of this software for EmComm purposes very limited for the 1700 square km that my team covers.

Thanks to all for your input.

73
Mike VA3MCT

Re: Inconsistent CQCQCQ responses

#2511

I removed the repeater from the setup and ran everything as simplex and all works fine.

This however makes use of this software for EmComm purposes very limited for the 1700 square km that my team covers.

Thanks to all for your input.

73
Mike VA3MCT

Re: Inconsistent CQCQCQ responses

#2510

Glen,

Thank you for the explanation of the color coding of the callsigns in the Stations column. In my situation, because there is some kind of issue with the communications between these three radios, I am seeing a station come up as blue on one machine and black on another, or not at all.

My next test is to remove the repeater from this scenario and try on a simplex frequency.

As for the second comment about multiple copies of d-RATS running simultaneously, that is not the case with my testing.

73
Mike VA3MCT

Re: Inconsistent CQCQCQ responses

#2509

The radios I am working with are all older models.

D-STAR ready

The ID-880H provides D-STAR DV mode digital voice and low-speed data communications.

The IC-80AD supports the D-STAR?“DV” mode, which transmits digital voice?concurrent with a low-speed (1200 bps) data?stream.?

In this case all 3 of the radios I am using can only handle the 1200bps data stream

73
Mike VA3MCT

Re: Inconsistent CQCQCQ responses

#2508

On Sun, Dec 18, 2022 at 01:26 PM, WB3ILX wrote:

Also when doing RF with DRATS it is never a good idea to do a PING.

Ron,

There is no SignalinkUSB involved here, though I do use them for Winlink Packet and VARA FM occasionally, but not at this time for this use case.

I am also intrigued by the comment "Also when doing RF with DRATS it is never a good idea to do a PING." The D-RATS software enables it to work. If it's not a good idea, then maybe it should be removed when using an RF connection.

I am NOT a D-STAR expert by any means, but could you please explain why this is not a good idea??

73
Mike VA3MCT

Re: Inconsistent CQCQCQ responses

#2507

开云体育

Mike,

When a ping comes back with the station’s callsign in black, it indicates that the station just recently signed off.? Those in blue are online or on the air.? The reason to know that a station just went QRT lets you know that if you had traffic for that station, it cannot presently go out.? You could either keep your station on the air until they come back up on frequency or redirect the message to one of the ratflectors acting as a file server and mail drop that would deliver the traffic for you the next time the station is back.

?

As for the multiple IDs being seen, you might check to make sure that station did not accidentally bring up the D-Rats software twice.? Some of the Windows 10 machines are running quite slowly these days due to the large numbers of patches and updates that have been added to them over time.? When trying to start the software we might sometimes click on the icon to start the program, but nothing seems to be happening, so we click on it again thinking it didn’t start, only to find out later that we now have two instances of the software running on the same computer.? This would cause you to see that station’s call when you do a ping, because the second running software answered the ping and everyone else might see it twice.

?

I have never documented that problem happening any other way.

?

Cordially,

Glen – KG5CEN

StTammany.ratflector.com

Re: Inconsistent CQCQCQ responses

#2506

开云体育

Hi this Ron / WB3ILX,

If you are using a Signal link or any device in the 6 pin mini din on the 880H just plugging the device in puts the 899H into analog FM mode. ?At least it does on mine. ?Just FYI. ?The orange data cable should work with the 889H. ?Also when doing RF with DRATS it is never a good idea to do a PING.

Ron / WB3ILX

Show quoted text

On Dec 18, 2022, at 11:13 AM, Marius, YO2LOJ <marius@...> wrote:

?
Please also be aware that there are 2 data modes in D-Star: DV low speed and DV ligh speed. DV high speed is not supported by all radios, while low speed is supported by all of them.

On 18/12/2022 15:42, VA3MCT wrote:

Marius,

Thanks for the swift response.

I did think that was the issue I was seeing, Two radios both trying to respond simultaneously to a single CQCQCQ.

I have now removed one of the radios and the D-RATS (closed it down).

Now what I see is as follows:-

Station A runs Ping All Stations. Station B responds back to the ping and marks Station A as Black in the Stations list

Station B runs Ping All Stations. Station A never responds. and I never saw the Station A callsign on the radio screen. That might lead me to think this is an RF issue.

However, if I go back to using the radio with an antenna in the basement (Station C), then Station B and C can both see each other without issue.

So I do not believe it is an RF issue and I do not believe it is a lack of TDMA.?

I tried to make testing simpler by going to Chat on each of the three stations. When doing Chat, its just one station sending out with no expectation of an acknowledgement from the receiving stations, unlike the ping.

Station A sending Chat is seen by Station B and C
Station B sending is seen by Station C but not Station A
Station C sending is seen by Station A and B

So, there would appear to be an issue with Station B's transmission (ID-880H) as it is not seen by Station A (IC-80AD) and yet it is seen by Station C (IC-80AD).

73
Mike VA3MCT

Re: Inconsistent CQCQCQ responses

Marius, YO2LOJ

#2505

开云体育

Please also be aware that there are 2 data modes in D-Star: DV low speed and DV ligh speed. DV high speed is not supported by all radios, while low speed is supported by all of them.

On 18/12/2022 15:42, VA3MCT wrote:

Show quoted text

Marius,

Thanks for the swift response.

I did think that was the issue I was seeing, Two radios both trying to respond simultaneously to a single CQCQCQ.

I have now removed one of the radios and the D-RATS (closed it down).

Now what I see is as follows:-

Station A runs Ping All Stations. Station B responds back to the ping and marks Station A as Black in the Stations list

Station B runs Ping All Stations. Station A never responds. and I never saw the Station A callsign on the radio screen. That might lead me to think this is an RF issue.

However, if I go back to using the radio with an antenna in the basement (Station C), then Station B and C can both see each other without issue.

So I do not believe it is an RF issue and I do not believe it is a lack of TDMA.?

I tried to make testing simpler by going to Chat on each of the three stations. When doing Chat, its just one station sending out with no expectation of an acknowledgement from the receiving stations, unlike the ping.

Station A sending Chat is seen by Station B and C
Station B sending is seen by Station C but not Station A
Station C sending is seen by Station A and B

So, there would appear to be an issue with Station B's transmission (ID-880H) as it is not seen by Station A (IC-80AD) and yet it is seen by Station C (IC-80AD).

73
Mike VA3MCT

Re: Inconsistent CQCQCQ responses

#2504

Marius,

Thanks for the swift response.

I did think that was the issue I was seeing, Two radios both trying to respond simultaneously to a single CQCQCQ.

I have now removed one of the radios and the D-RATS (closed it down).

Now what I see is as follows:-

Station A runs Ping All Stations. Station B responds back to the ping and marks Station A as Black in the Stations list

Station B runs Ping All Stations. Station A never responds. and I never saw the Station A callsign on the radio screen. That might lead me to think this is an RF issue.

However, if I go back to using the radio with an antenna in the basement (Station C), then Station B and C can both see each other without issue.

So I do not believe it is an RF issue and I do not believe it is a lack of TDMA.?

I tried to make testing simpler by going to Chat on each of the three stations. When doing Chat, its just one station sending out with no expectation of an acknowledgement from the receiving stations, unlike the ping.

Station A sending Chat is seen by Station B and C
Station B sending is seen by Station C but not Station A
Station C sending is seen by Station A and B

So, there would appear to be an issue with Station B's transmission (ID-880H) as it is not seen by Station A (IC-80AD) and yet it is seen by Station C (IC-80AD).

73
Mike VA3MCT

Re: Inconsistent CQCQCQ responses

Marius, YO2LOJ

#2503

开云体育

This is a consequence of the CDMA concept in D-Star data transmissions and to the fact that the radio's "are all programmed the same except for callsign".
The radios will check both that the channel is available and start to transmit, using similar timings. Depending on the small delay difference between the radios, they will either transmit or not.
But there is a chance that both will see the radio channel available and start transmitting at the same time. This will get dramatically worse if the radios can not hear each other, and only hear the repeater.
Since the 'ping all stations' is not connection oriented, responses will overlap, with one or even both data packets being compromised, depending on the RSSI at the receiving side.

Unless there is no form of TDMA implemented (remember DAMA for ax.25?), there is not much that can be done in this situation: P2P will work decently, P2MP will have these issues.

Marius, YO2LOJ

On 18/12/2022 13:57, VA3MCT wrote:

Show quoted text

I am testing out D-RATS for my local club from an EmComm perspective, because we bought into D-STAR a while back and have a large number of ID-880H and IC-80AD radios and I want t put them to use.

I have three radios all at my home location, the ID-880H is using an externally mounted antenna, one of the handhelds is using a mobile antenna installed in an upstairs room and the second handheld is using a very basic outdoor antenna inside my basement.

We have one local D-STAR repeater which unfortunately has no gateway, but that's a separate issue for a different forum. All radios are tuned to this one single repeater.

I am using "d-rats 0.3.10 beta 5 connect"? all on Windows 10 with full updates applied.

All radios use a USB to RS-232 and then RS-232 to the 2.5mm TRS connector on the radio.

What I find is that when I run "Ping all Stations", sometimes I get two responses from the other two radios and sometimes I only get one response and yet I know the other radio sent a reply. Each radio should see a response from each of the other two radios.

I have checked the settings in the radios so that they are all programmed the same except for callsign. I have checked the D-RATS config to ensure they are all set the same except for callsign, Name and ping reply.

I had this problem before and it seemed to get fixed by moving the USB to a different physical port on the computer and picking up a new serial port number, but that only seemed to last a few days.

I saw the details in a previous message about performance through a repeater and the warmup times settings and played with those, but no change.

If I take one of the radios out of the equation, and do a ping all stations, I do seem to get a response back from the missing radio, but it is marked in black and not blue, which I assume means it was heard but not acknowledged in some way.

Can anyone suggest what else I should be looking into?

73
Mike VA3MCT EC York Region ARES

Inconsistent CQCQCQ responses

#2502

I am testing out D-RATS for my local club from an EmComm perspective, because we bought into D-STAR a while back and have a large number of ID-880H and IC-80AD radios and I want t put them to use.

I have three radios all at my home location, the ID-880H is using an externally mounted antenna, one of the handhelds is using a mobile antenna installed in an upstairs room and the second handheld is using a very basic outdoor antenna inside my basement.

We have one local D-STAR repeater which unfortunately has no gateway, but that's a separate issue for a different forum. All radios are tuned to this one single repeater.

I am using "d-rats 0.3.10 beta 5 connect"? all on Windows 10 with full updates applied.

All radios use a USB to RS-232 and then RS-232 to the 2.5mm TRS connector on the radio.

What I find is that when I run "Ping all Stations", sometimes I get two responses from the other two radios and sometimes I only get one response and yet I know the other radio sent a reply. Each radio should see a response from each of the other two radios.

I have checked the settings in the radios so that they are all programmed the same except for callsign. I have checked the D-RATS config to ensure they are all set the same except for callsign, Name and ping reply.

I had this problem before and it seemed to get fixed by moving the USB to a different physical port on the computer and picking up a new serial port number, but that only seemed to last a few days.

I saw the details in a previous message about performance through a repeater and the warmup times settings and played with those, but no change.

If I take one of the radios out of the equation, and do a ping all stations, I do seem to get a response back from the missing radio, but it is marked in black and not blue, which I assume means it was heard but not acknowledged in some way.

Can anyone suggest what else I should be looking into?

73
Mike VA3MCT EC York Region ARES

Re: D-Rats over Repeater

#2501

Try this:

File>Preferences>Transfers

Set Warmup Timeout to 1.

Set Warmup Length to 8 and increase as necessary until you have reliable communications.

Patrick (N3TSZ)

On Thursday, December 15, 2022 at 07:35:10 AM EST, Michael Mandell <mikemandell@...> wrote:

Our weekly group uses a nice Icom repeater stack for D-Rats practice weekly. We have found chat is fine, but file transfers are slower and less reliable over the repeater than simplex. We suspect a timing issue with the repeater with ACK/NAK D-Rats stuff. Anybody have suggested settings for D-Rats to account for the slight repeater timing delay??

D-Rats over Repeater

#2500

Our weekly group uses a nice Icom repeater stack for D-Rats practice weekly. We have found chat is fine, but file transfers are slower and less reliable over the repeater than simplex. We suspect a timing issue with the repeater with ACK/NAK D-Rats stuff. Anybody have suggested settings for D-Rats to account for the slight repeater timing delay??

Re: Icom 9700 via USB only

#2499

I had the same issue with my 7100 via USB. I called Icom and got a guy who knew the whole story. The USB cable sends out serial in packet format, so it sends it in bursts of data. A short "chat" line can take 3-4 keys of transmit. The data cable (I use orange RT Systems) sends a continuous serial data stream. Makes sense and those have been my results. I do not have this issue with bluetooth, FWIW. On either my 5100 or my 4100. Works exactly like the data cable.?

Icom 9700 via USB only

#2498

Has anyone been able to successfully use D-RATS with the 9700 using just a USB cable? I'm able to get the radio to TX when I start D-RATS, but it TXs multiple times non-stop until it eventually stops. After it stops, I try sending a message in chat, but nothing happens.

Any ideas on what I'm doing wrong?

?

Someone posted the following in another thread. I've tried these settings, but no luck other than the radio TXing multiple times when starting D-RATS

?

Show quoted text

- Go to menu -> Set -> Connenctors -> USB(B)/Datafunctions:

??? ??? > Set USB (B) function to DV data

??? ??? > Set DATA function to DV Data

??? ??? > Set GPS Out to OFF

??? ??? > check DV Data/GPS Out Baud Rate to be as you would like to use (9600 is a good choice)

- Go to menu -> GPS

??? ??? > Set GPS TX Mode to OFF

- Go to menu -> Set -> DV/DD Set

??? ??? > Set DV Data TX to Auto

??? ??? > Depending on your partners, you may need to switch DV Fast Data off...

Re: Instructions for installing new D-Rats on Microsoft Windows

#2497

On 11/26/2022 11:48 AM, Ralph Barbakoff wrote:
Need 64 bit machine for testing these John??The MSYS2 distribution for Microsoft Windows no longer supports 32 bit machines, and will be dropping Windows 7 support sometime this year, if they have hot yet done so.

I have not tested on a 32 bit machine.

I did not create pre-built 32 bit LZHUF packages for the few Debian packages that I created.

For 32 bit Linux, you just need to build a 32 bit lzhuf from the lzhuf repository for winlink support, otherwise everything except Winlink should work with out it.

73,
-John, wb8tyw

Re: Instructions for installing new D-Rats on Microsoft Windows

#2496

Need 64 bit machine for testing these John??

Ralph Barbakoff (WA9LKZ)

Show quoted text

On Nov 26, 2022, at 11:13 AM, John E. Malmberg <wb8tyw@...> wrote:

?Updated tarball and wheel files uploaded.

This fixes the pip install on Ubuntu 20.04 and with a small additional fix gets the pip install working on AntiX-21 Linux.

On AntiX-21 Linux, and this may work for other platforms where an initial attempt of a pip install fails, issue while the virtual environment the command 'pip install -U pip' to upgrade to the current version of pip.

We still need volunteers to test this pip install of the tarball, and help update the Wiki and provide feedback to help other hams with this.

73,
-John, wb8tyw

On 11/23/2022 2:39 PM, John E. Malmberg wrote:
Hello All,
I have added to the ham-radio-software WIKI information on how to install the Python3 based D-Rats on Microsoft Windows.

Currently the only available install is for a pre-release that I am in the process of getting reviewed and merged into the main D-Rats repository.
I will leave it up to someone else to add the instructions to the Wiki for various Linux and Mac OS-X releases.  Please read the notes below and try to use the pip installable tarball first before resorting to using a checkout of the repository.
The process for Linux and Mac OS-X is similar, however I only have pre-built LZHUF binaries for Microsoft Windows 7 and later, and some Ubuntu and Debian releases.
Everyone else will need to build their own binary and D-Rats will expect it to be placed in "/usr/local/bin".  And the new binary will work on big-endian systems if anyone here is still running one.
If you can contribute a pre-built lzhuf binary for a different platform, and you do not know how or have the time to create an installable package for your platform, just use gzip on the binary and create a new directory for your platform in the d-rats directory.  Please also upload a file with some type of checksum for the binary that can be checked on the target platform.
As the lzhuf program is now separate from D-Rats, the PIP installable tarball is now common to all platforms.
Pip installs of D-Rats are currently broken for AntiX-21 Linux and Ubuntu 20.04, so D-Rats must be run from a checkout of the source repository on those platforms.  The people on the python forums that I am asking for help on seem to have a working theory that something is broken on some Debian based platforms.  The workaround being discussed seems to be far more work than just running D-Rats from a checkout of the repository.
At this time, the current master is at least two merges behind what is in the pre-release tarball that I have put out for testing, but the only things missing are the new tarball build procedure and a fix to version.py, so it should be good enough for testing.
If we can get the end user installation procedures documented, then I and others can start tackling the other bugs and misfeatures in D-Rats.
73,
-John
wb8tyw

Re: Instructions for installing new D-Rats on Microsoft Windows

#2495

Updated tarball and wheel files uploaded.

This fixes the pip install on Ubuntu 20.04 and with a small additional fix gets the pip install working on AntiX-21 Linux.

On AntiX-21 Linux, and this may work for other platforms where an initial attempt of a pip install fails, issue while the virtual environment the command 'pip install -U pip' to upgrade to the current version of pip.

We still need volunteers to test this pip install of the tarball, and help update the Wiki and provide feedback to help other hams with this.

73,
-John, wb8tyw

Show quoted text

On 11/23/2022 2:39 PM, John E. Malmberg wrote:
Hello All,
I have added to the ham-radio-software WIKI information on how to install the Python3 based D-Rats on Microsoft Windows.

Currently the only available install is for a pre-release that I am in the process of getting reviewed and merged into the main D-Rats repository.
I will leave it up to someone else to add the instructions to the Wiki for various Linux and Mac OS-X releases.? Please read the notes below and try to use the pip installable tarball first before resorting to using a checkout of the repository.
The process for Linux and Mac OS-X is similar, however I only have pre-built LZHUF binaries for Microsoft Windows 7 and later, and some Ubuntu and Debian releases.
Everyone else will need to build their own binary and D-Rats will expect it to be placed in "/usr/local/bin".? And the new binary will work on big-endian systems if anyone here is still running one.
If you can contribute a pre-built lzhuf binary for a different platform, and you do not know how or have the time to create an installable package for your platform, just use gzip on the binary and create a new directory for your platform in the d-rats directory.? Please also upload a file with some type of checksum for the binary that can be checked on the target platform.
As the lzhuf program is now separate from D-Rats, the PIP installable tarball is now common to all platforms.
Pip installs of D-Rats are currently broken for AntiX-21 Linux and Ubuntu 20.04, so D-Rats must be run from a checkout of the source repository on those platforms.? The people on the python forums that I am asking for help on seem to have a working theory that something is broken on some Debian based platforms.? The workaround being discussed seems to be far more work than just running D-Rats from a checkout of the repository.
At this time, the current master is at least two merges behind what is in the pre-release tarball that I have put out for testing, but the only things missing are the new tarball build procedure and a fix to version.py, so it should be good enough for testing.
If we can get the end user installation procedures documented, then I and others can start tackling the other bugs and misfeatures in D-Rats.
73,
-John
wb8tyw

Instructions for installing new D-Rats on Microsoft Windows

#2494

Hello All,

I have added to the ham-radio-software WIKI information on how to install the Python3 based D-Rats on Microsoft Windows.

Currently the only available install is for a pre-release that I am in the process of getting reviewed and merged into the main D-Rats repository.

I will leave it up to someone else to add the instructions to the Wiki for various Linux and Mac OS-X releases.  Please read the notes below and try to use the pip installable tarball first before resorting to using a checkout of the repository.

The process for Linux and Mac OS-X is similar, however I only have pre-built LZHUF binaries for Microsoft Windows 7 and later, and some Ubuntu and Debian releases.

Everyone else will need to build their own binary and D-Rats will expect it to be placed in "/usr/local/bin".  And the new binary will work on big-endian systems if anyone here is still running one.

If you can contribute a pre-built lzhuf binary for a different platform, and you do not know how or have the time to create an installable package for your platform, just use gzip on the binary and create a new directory for your platform in the d-rats directory.  Please also upload a file with some type of checksum for the binary that can be checked on the target platform.

As the lzhuf program is now separate from D-Rats, the PIP installable tarball is now common to all platforms.

Pip installs of D-Rats are currently broken for AntiX-21 Linux and Ubuntu 20.04, so D-Rats must be run from a checkout of the source repository on those platforms.  The people on the python forums that I am asking for help on seem to have a working theory that something is broken on some Debian based platforms.  The workaround being discussed seems to be far more work than just running D-Rats from a checkout of the repository.

At this time, the current master is at least two merges behind what is in the pre-release tarball that I have put out for testing, but the only things missing are the new tarball build procedure and a fix to version.py, so it should be good enough for testing.

If we can get the end user installation procedures documented, then I and others can start tackling the other bugs and misfeatures in D-Rats.

73,
-John
wb8tyw

Re: WL2K Messages Sent But Never Received

Carl Keller

#2493

Hi Glen!

I seem to have it working...

First, an SMTP server must be configured in Preferences/Outgoing mail, a a POP mail address must be configured and enabled using SSL in Preferences/Email Accounts, The POP address must be given access to BOTH under Email Access, and POP3 and SMTP servers must be configured under Preferences/Messages. POP email has to be working.
The POP email address you are using must be Whitelisted in your Winlink.org account.
Source Callsign is my callsign only, but my callsign is automatically routed through my POP email address to Winlink.org.
Destination Callsign only worked when "@winlink.org was added to the callsign. It would not work without the full destination information.
Using these settings, it did work to send an email to myself from myself after adding "@winlink.org".
Subject Line prefix had to be "//WL2K" in order for it to work.

At least I got an email to go through to Winlink using these settings!

Thanks for your input!

Carl