Re: [wsjt-devel] IC-705 little to no decodes
Try running this simple web app from your browser, you will know right away whether your computers clock is synced to UTC. https://time.is/ Dave - wb9own On Tuesday, December 5, 2023 at 08:17:28 AM CST, robert evans LAST_NAME via wsjt-devel wrote: All good suggestions. Thank You. Last night.. Double checked everything on the old dell i3 win10 and it started decoding just fine. The thing is, that it is so slow, i loose track of what i did and didn't do when i make changes. And it takes forever to reboot. I keep it around because it is about the bare minimum system to support the usb drivers now used by windows for modern radios. ft-991, ft-dx10, ic-9700, ic-705, etc. etc. etc. So, as a beta test of WSJT-X 2.7.0-rc2 on a old dell i3 win10 with the IC-705 it worked fine. Back to the asus win11 i9 laptop / IC-705 : When WSJT-X 2.7.0-rc2 did decode the dt was like 0.2 or less. I'll revisit that soon. Thanks Again. N2LO~> On 12/05/2023 3:52 AM EST Kari Sillanmäki via wsjt-devel wrote: OM, Also make sure that you are not in "Hound" mode with the "Rx All Freqs" unchecked. 73's de Kari, oh2gqc On 12/4/23 20:57, robert evans LAST_NAME via wsjt-devel wrote: Using a IC-705 over the weekend and after installing the usb drivers in a asus win11 i9 laptop i started WSJT-X 2.7.0-rc2. The rig control worked fine and the signals where being displayed in the spect graph, but no decodes. Double checked the time set. Still no decodes. Walked away for many minutes and there were decodes when i got back, but only a few. Installed WSJT-X 2.6.1 and tried again. Same behavior. Every once in a awhile it would decode a frame and then none for long periods of time even though the spectrum graph showed signals on the waterfall continuously. Switched to an old dell i3 win10 laptop and saw the same behavior with wsjt-x. Tried fldigi and it decoded Olivia and psk31 as well as cw no problem. Tried JS8 as well - no problem. Back to WSJT-X and double checked the settings. Every once in a long while it might decode what looks like a frame. N2LO~> ___wsjt-devel mailing listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 160m S/N needs advanced mode
Hi Glenn,
Searching the User Guide for a keyword is often a helpful way to find a
section of interest, but it's hardly a substitute for actually reading
the Guide. The second and third paragraphs of the whole Guide introduce
each of the supported protocols and provide a few words about what it's
designed for. Here's what is said about FST4:
"FST4 is designed especially for the LF and MF bands."
For what it's worth: I note that the "CTRL-F" search that you mentioned
does take you directly to Table 7 in Section 17.2 -- the summary I drew
to your particular attention.
-- 73, Joe, K1JT
On 12/7/2023 5:41 PM, Glenn Williams via wsjt-devel wrote:
Thanks for the guidance.
So I'll take the hit for overlooking FST4 and FST4W for the needed low
S/N. I jumped to conclusions too quickly. I do that too
often in life. This happened after operating FT8 since 2021. My
oversight is due to the following reliance on a method of quickly
scanning for the assumed discussion early in the User Guide.
I started from the top of the User Guide PDF file and did a CTRL-F
("find") for "S/N". The third "Find" hit on "S/N" occurs in
Section 7.1 of the User Guide. The fourth hit on "S/N" occurs in
17.2.10. Between those two points, and in "1. Introduction" no
tabulation of S/N advantages occurs, when S/N is such a key value for
all WSJT-X modes. Albeit, discussions do occur about
weak-signal conditions on LF, HF, and VHF between those two points in
the Guide, but "how weak" is not as often emphasized.
--73, Glenn, AF8C
On 12/7/2023 2:55 PM, Reino Talarmo via wsjt-devel wrote:
Hello Glenn,
I think that you wish is already heard and fulfilled.
The suitable mode is FST4. There are seven modes with
transmission periods from 15 to 1800 seconds. The
performance of the FST4-120 is about the same as for
WSPR. For longer transmission periods transmitter
frequency stability requirement is higher as the used
bandwidth goes down. See user guide 17.2.10. Summary. Of
course the (un)stability of the propagation path on 160m
band may prevent usage of the slowest modes.
73, Reino OH3mA
-Original Message-
From: Glenn Williams via wsjt-devel [mailto:wsjt-
de...@lists.sourceforge.net]
Sent: Thursday, December 7, 2023 5:46 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Glenn Williams
Subject: [wsjt-devel] 160m S/N needs advanced mode
Hello,
FT8 on 160m pales.
WSJT-X operators customarily running FT8 and FT4 on
80m through 10m HF bands are likely disappointed with
trials on 160m. As one of those operators I recently
ran
WSPR on 160m in comparison to working FT8 QSOs on
160m. In NA EST daytime operation at 2220Z WSPR
faultlessly listed a
-28 dBm decode.
Here I suggest we need an improved decode sensitivity
for 160m QSOs, likely needing to be done with a new
mode. Granted, the TX and RX times would have to be
increased (Shannon-Hartley Theorem). That would
require additional operator patience and associated
protocols for the extended timing.
--73, Glenn, AF8C
--
This email has been checked for viruses by Avast
antivirus software.
www.avast.com
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 160m S/N needs advanced mode
I've tried using FST4-xxx modes on 160. Trouble is not enough are using it. How can we get more people to try it? Joe Taylor via wsjt-devel wrote: > Spend some time reading the WSJT-X User Guide. Pay particular attention > to Section 17.2. Its Table 7 summarizes the threshold sensitivities of > many of the available modes and submodes. For weak signal work on 160m > you might want to look at the FST4-xxx submodes. These submodes offer > sensitivities from 3 dB to 22 dB better than FT8 on an AWGN channel, and > comparable improvements on most channel conditions likely to be found on > our MF bands, including 160m. -- Brian D G3VGZ G8AOE G3T IO94im ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X parsing of the country file, specifically 4U1A (and others)
On Thu, Dec 7, 2023 at 2:46 AM Reino Talarmo wrote: > From: Jim Reisert AD1C via wsjt-devel [mailto: > wsjt-devel@lists.sourceforge.net] > > Sent: Thursday, December 7, 2023 3:51 AM > > > 3. 4U is listed as a prefix for Italy. > Regarding #3, this was done so that "new" (previously unknown) 4U > callsigns that are spotted on the DX cluster will propagate through the > network. If that prefix mapping were not there, those calls would be > ignored because they could not be associated with any entity in the country > file. Tis was done at the request of Lee VE7CC. 4U has been used numerous > times from Italy. 4U24OCT is a recent example. The QTH is the Global > Service Centre ARC in Brindisi, Italy, normally 4U1GSC. 4U could have just > as easily been listed as a prefix for Austria, but I chose Italy based on > past experience. > > Thanks Jim for clarification, > Just for educating myself may I ask, is the United Nations 4U the only > "country code" that is allowed to pop up in any country without a country > prefix xxx/? > Hi Reino, First, I heard and worked 4U1A this morning on 20m FT8, using WSJT-X 2.7 RC2. It was identified as "Vienna Intl Ctr" in the program, so I don't quite understand the problem that people have been having. I was using the country file released on November 29, without any edits. Perhaps the parsing of the country file was changed from the GA release to the 2.7 RC release(s). 4U used to be used in the 1970s and 1980s from various locations in the Middle East by members of various peacekeeping forces. It was also used from a few locations in Africa in the 1990s (such as 4U9U in Burundi).I can send you my entire list if you want, but it's probably not useful. Currently, the only use of this prefix is by the Vienna Int'l Center (4U1VIC etc), the United Nations HQ in New York (4U1UN etc) and the Global Service Centre ARC in Brindisi (4U1VIC etc.) Second question is how long "visiting" individual callsigns are kept in the > cty.dat file? Related question is why e.g. 4U24OCT and 4U1GSC are not > listed under Italy? Perhaps those will be listed, if the 4U movement to > Austria is implemented. > My software "activates" a callsign 45 days before it is scheduled to be used, through 45 days past the end. This allows a callsign to remain active in the country file throughout the two major CQWW DX contests, Phone at the end of October and CW at the end of November. Callsigns are "retired" because some software is unable to deal with very large country files. WSJT-X uses the big CTY.DAT file, which is quite large, and does not have this limitation: https://www.country-files.com/contest/wsjt-x/ (follow the link to CTY.DAT at the bottom of the web page). Could it be sensible that 4U will be listed as a separate "country" in > addition to the United Nations HQ with a line ending e.g. "Location > currently unknown:"? Of course the new call sign will be listed in the > proper entity as soon as it is known. > I'd rather not do it this way. It's best if any prefix or callsign has a valid DXCC entity code associated with it: https://www.adif.org/314/ADIF_314.htm#DXCC_Entity_Code_Enumeration The main points I was trying to make about the country file were: 1. Full callsigns take priority over prefixes. 2. WSJT-X should probably just be skipping the "WAEDC" entities, those which have a '*' in front of the prefix at the end of the first line. 3. Callsigns are duplicated in the file if they are also part of a "WAEDC" entity. Software has to make a decision. If it is using the WAEDC entities, then a callsign found in that list should be ignored if found elsewhere in the file. If the software is not using the WAEDC entities, then those entities in the country file can be skipped, and the duplicate callsign problem is avoided. -- Jim Reisert AD1C, , https://ad1c.us ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Auto logging to QRZ.COM
There are several programs that will log to QRZ. JTAlertLog4omDXKeeperHam Radio Deluxe And others that can chime in with their fav'. Mike W9MDB On Thursday, December 7, 2023 at 03:40:01 PM CST, Marty Wayne via wsjt-devel wrote: Is there a way to use UDP or other method to automatically log to QRZ.com log book? Marty waynemcway...@comcast.net ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 160m S/N needs advanced mode
Thanks for the guidance.
So I'll take the hit for overlooking FST4 and FST4W for the needed low
S/N. I jumped to conclusions too quickly. I do that too
often in life. This happened after operating FT8 since 2021. My
oversight is due to the following reliance on a method of quickly
scanning for the assumed discussion early in the User Guide.
I started from the top of the User Guide PDF file and did a CTRL-F
("find") for "S/N". The third "Find" hit on "S/N" occurs in
Section 7.1 of the User Guide. The fourth hit on "S/N" occurs in
17.2.10. Between those two points, and in "1. Introduction" no
tabulation of S/N advantages occurs, when S/N is such a key value for
all WSJT-X modes. Albeit, discussions do occur about
weak-signal conditions on LF, HF, and VHF between those two points in
the Guide, but "how weak" is not as often emphasized.
--73, Glenn, AF8C
On 12/7/2023 2:55 PM, Reino Talarmo via wsjt-devel wrote:
Hello Glenn,
I think that you wish is already heard and fulfilled.
The suitable mode is FST4. There are seven modes with
transmission periods from 15 to 1800 seconds. The
performance of the FST4-120 is about the same as for
WSPR. For longer transmission periods transmitter
frequency stability requirement is higher as the used
bandwidth goes down. See user guide 17.2.10. Summary. Of
course the (un)stability of the propagation path on 160m
band may prevent usage of the slowest modes.
73, Reino OH3mA
-Original Message-
From: Glenn Williams via wsjt-devel [mailto:wsjt-
de...@lists.sourceforge.net]
Sent: Thursday, December 7, 2023 5:46 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Glenn Williams
Subject: [wsjt-devel] 160m S/N needs advanced mode
Hello,
FT8 on 160m pales.
WSJT-X operators customarily running FT8 and FT4 on
80m through 10m HF bands are likely disappointed with
trials on 160m. As one of those operators I recently
ran
WSPR on 160m in comparison to working FT8 QSOs on
160m. In NA EST daytime operation at 2220Z WSPR
faultlessly listed a
-28 dBm decode.
Here I suggest we need an improved decode sensitivity
for 160m QSOs, likely needing to be done with a new
mode. Granted, the TX and RX times would have to be
increased (Shannon-Hartley Theorem). That would
require additional operator patience and associated
protocols for the extended timing.
--73, Glenn, AF8C
--
This email has been checked for viruses by Avast
antivirus software.
www.avast.com
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Auto logging to QRZ.COM
Is there a way to use UDP or other method to automatically log to QRZ.com log book? Marty Wayne mcway...@comcast.net ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 160m S/N needs advanced mode
Hi Glenn, FT4 and FT8 are a tiny fraction of what's available in WSJT-X. Modes that meet the needs you describe are already available in the program. Spend some time reading the WSJT-X User Guide. Pay particular attention to Section 17.2. Its Table 7 summarizes the threshold sensitivities of many of the available modes and submodes. For weak signal work on 160m you might want to look at the FST4-xxx submodes. These submodes offer sensitivities from 3 dB to 22 dB better than FT8 on an AWGN channel, and comparable improvements on most channel conditions likely to be found on our MF bands, including 160m. -- 73, Joe, K1JT On 12/7/2023 10:46 AM, Glenn Williams via wsjt-devel wrote: Hello, FT8 on 160m pales. WSJT-X operators customarily running FT8 and FT4 on 80m through 10m HF bands are likely disappointed with trials on 160m. As one of those operators I recently ran WSPR on 160m in comparison to working FT8 QSOs on 160m. In NA EST daytime operation at 2220Z WSPR faultlessly listed a -28 dBm decode. Here I suggest we need an improved decode sensitivity for 160m QSOs, likely needing to be done with a new mode. Granted, the TX and RX times would have to be increased (Shannon-Hartley Theorem). That would require additional operator patience and associated protocols for the extended timing. --73, Glenn, AF8C ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 160m S/N needs advanced mode
Hello Glenn, I think that you wish is already heard and fulfilled. The suitable mode is FST4. There are seven modes with transmission periods from 15 to 1800 seconds. The performance of the FST4-120 is about the same as for WSPR. For longer transmission periods transmitter frequency stability requirement is higher as the used bandwidth goes down. See user guide 17.2.10. Summary. Of course the (un)stability of the propagation path on 160m band may prevent usage of the slowest modes. 73, Reino OH3mA > -Original Message- > From: Glenn Williams via wsjt-devel [mailto:wsjt- > de...@lists.sourceforge.net] > Sent: Thursday, December 7, 2023 5:46 PM > To: wsjt-devel@lists.sourceforge.net > Cc: Glenn Williams > Subject: [wsjt-devel] 160m S/N needs advanced mode > > Hello, > > FT8 on 160m pales. > > WSJT-X operators customarily running FT8 and FT4 on > 80m through 10m HF bands are likely disappointed with > trials on 160m. As one of those operators I recently ran > WSPR on 160m in comparison to working FT8 QSOs on > 160m. In NA EST daytime operation at 2220Z WSPR > faultlessly listed a > -28 dBm decode. > > Here I suggest we need an improved decode sensitivity > for 160m QSOs, likely needing to be done with a new > mode. Granted, the TX and RX times would have to be > increased (Shannon-Hartley Theorem). That would > require additional operator patience and associated > protocols for the extended timing. > > --73, Glenn, AF8C > > -- > This email has been checked for viruses by Avast > antivirus software. > www.avast.com > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 160m S/N needs advanced mode
A few days ago I worked a ZL stn with 80 watts to a 40ft vertical with just a few long radials. My report was -11 on FT8. >From time to time 160M propagation is amazing even during strong Sun Spot cycle times. Bill W2PKY Tampa Fl. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 160m S/N needs advanced mode
Glenn,A mode that differs from FST4?Ed N4II. Original message From: Glenn Williams via wsjt-devel Date: 12/7/23 1:26 PM (GMT-06:00) To: wsjt-devel@lists.sourceforge.net Cc: Glenn Williams Subject: [wsjt-devel] 160m S/N needs advanced mode Hello,FT8 on 160m pales.WSJT-X operators customarily running FT8 and FT4 on 80m through 10m HF bands are likely disappointed with trials on 160m. As one of those operators I recently ran WSPR on 160m in comparison to working FT8 QSOs on 160m. In NA EST daytime operation at 2220Z WSPR faultlessly listed a -28 dBm decode.Here I suggest we need an improved decode sensitivity for 160m QSOs, likely needing to be done with a new mode. Granted, the TX and RX times would have to be increased (Shannon-Hartley Theorem). That would require additional operator patience and associated protocols for the extended timing.--73, Glenn, AF8C-- This email has been checked for viruses by Avast antivirus software.www.avast.com___wsjt-devel mailing listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 160m S/N needs advanced mode
Glenn the new mode you want has been out for quite awhile. FST4 is that mode. However 160M ops have been slow to adopt it. I guess because it’s not a set and forget mode like FT8 is. Fred N2XK > On Dec 7, 2023, at 2:28 PM, Glenn Williams via wsjt-devel > wrote: > > Hello, > > FT8 on 160m pales. > > WSJT-X operators customarily running FT8 and FT4 on 80m through 10m HF bands > are likely disappointed with trials on 160m. As one of those operators I > recently ran WSPR on 160m in comparison to working FT8 QSOs on 160m. In NA > EST daytime operation at 2220Z WSPR faultlessly listed a -28 dBm decode. > > Here I suggest we need an improved decode sensitivity for 160m QSOs, likely > needing to be done with a new mode. Granted, the TX and RX times would have > to be increased (Shannon-Hartley Theorem). That would require additional > operator patience and associated protocols for the extended timing. > > --73, Glenn, AF8C > > -- > This email has been checked for viruses by Avast antivirus software. > www.avast.com > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 160m S/N needs advanced mode
Hi Glenn, You might like the FST4 QSO mode. Same operating procedure as FT8, but depending on cycle length it can decode below -30 dB. It is mostly used on 630m but I also had (transatlantic) contacts on 160m. https://wsjt.sourceforge.io/FST4_Quick_Start.pdf 73 Stefan On 07.12.23 16:46, Glenn Williams via wsjt-devel wrote: Hello, FT8 on 160m pales. WSJT-X operators customarily running FT8 and FT4 on 80m through 10m HF bands are likely disappointed with trials on 160m. As one of those operators I recently ran WSPR on 160m in comparison to working FT8 QSOs on 160m. In NA EST daytime operation at 2220Z WSPR faultlessly listed a -28 dBm decode. Here I suggest we need an improved decode sensitivity for 160m QSOs, likely needing to be done with a new mode. Granted, the TX and RX times would have to be increased (Shannon-Hartley Theorem). That would require additional operator patience and associated protocols for the extended timing. --73, Glenn, AF8C ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 160m S/N needs advanced mode
Keep in mind that 160 is dead right now due to the sun cycle. 160 is always dead during the day. Larry / W1DYJ On 12/7/2023 10:46, Glenn Williams via wsjt-devel wrote: Hello, FT8 on 160m pales. WSJT-X operators customarily running FT8 and FT4 on 80m through 10m HF bands are likely disappointed with trials on 160m. As one of those operators I recently ran WSPR on 160m in comparison to working FT8 QSOs on 160m. In NA EST daytime operation at 2220Z WSPR faultlessly listed a -28 dBm decode. Here I suggest we need an improved decode sensitivity for 160m QSOs, likely needing to be done with a new mode. Granted, the TX and RX times would have to be increased (Shannon-Hartley Theorem). That would require additional operator patience and associated protocols for the extended timing. --73, Glenn, AF8C ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] 160m S/N needs advanced mode
Hello, FT8 on 160m pales. WSJT-X operators customarily running FT8 and FT4 on 80m through 10m HF bands are likely disappointed with trials on 160m. As one of those operators I recently ran WSPR on 160m in comparison to working FT8 QSOs on 160m. In NA EST daytime operation at 2220Z WSPR faultlessly listed a -28 dBm decode. Here I suggest we need an improved decode sensitivity for 160m QSOs, likely needing to be done with a new mode. Granted, the TX and RX times would have to be increased (Shannon-Hartley Theorem). That would require additional operator patience and associated protocols for the extended timing. --73, Glenn, AF8C -- This email has been checked for viruses by Avast antivirus software. www.avast.com ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X parsing of the country file, specifically 4U1A (and others)
> From: Jim Reisert AD1C via wsjt-devel > [mailto:wsjt-devel@lists.sourceforge.net] > Sent: Thursday, December 7, 2023 3:51 AM > 3. 4U is listed as a prefix for Italy. Regarding #3, this was done so that "new" (previously unknown) 4U callsigns that are spotted on the DX cluster will propagate through the network. If that prefix mapping were not there, those calls would be ignored because they could not be associated with any entity in the country file. Tis was done at the request of Lee VE7CC. 4U has been used numerous times from Italy. 4U24OCT is a recent example. The QTH is the Global Service Centre ARC in Brindisi, Italy, normally 4U1GSC. 4U could have just as easily been listed as a prefix for Austria, but I chose Italy based on past experience. Thanks Jim for clarification, Just for educating myself may I ask, is the United Nations 4U the only "country code" that is allowed to pop up in any country without a country prefix xxx/? Second question is how long "visiting" individual callsigns are kept in the cty.dat file? Related question is why e.g. 4U24OCT and 4U1GSC are not listed under Italy? Perhaps those will be listed, if the 4U movement to Austria is implemented. Could it be sensible that 4U will be listed as a separate "country" in addition to the United Nations HQ with a line ending e.g. "Location currently unknown:"? Of course the new call sign will be listed in the proper entity as soon as it is known. 73, Reino OH3mA ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
