We're trying to avoid bad decodes with bogus callsigns...not grids which could be a rover or somebody temporarily operating who frequently does not update their QRZ location. The examples given were

People are moving, changing locations for many reasons. Therefore I think a year is a long period of time for a client-side call/locator cache.

The QRZ cache can be for a VERY long time...maybe a year or more. The probability that what was a good callsign (silent key or changed) shows up in a bad decode is almost nil. Mike W9DMB

That would be great to have this functionality integrated into WSJT-X. I like the idea of caching for a certain time Roland

Every Operator is responsible for his own Data

Hi Frank, thanks for the update and glad you are up and running on low-orbit satellites. 73 Bill G4WJS.

I don’t know what is the most reliable source of locator. eQSL.cc, LotW, WSJT-X and QRZ.com are all provided by the operator. 73 Phil GM3ZZA IO85FU69. Sent from Mail for Windows

Hi Bill, Okay, thats good. Don, the author of MacLoggerDX, fixed the issue with LSB-D on the DX Lab Commander interface. I just ran WSJT-X with FT4 during a full pass of RS-44 and it worked perfect. I

It could be filtered with a QRZ lookup. I have a filter for the JTAlert email interface that does a QRZ lookup to avoid bad decodes like this and uses it's own local cache to reduce the QRZ queries to

Hi Roland, that was not clear from the link you sent when I first asked, hi. Many of the large volume WSPR spotting sources are not using WSJT-X so I guess they are forming spots from their own

Biil, GM1BAN is only sending 4 character locator as all of our Beacons

Hi Roland, is GM1BAM sending a 6-character grid locator? If it is you could reduce the likelihood of false decodes by using a 4-character grid square or checking the "Prefer Type 1

The question I have is can we validate some of the Spot data like the locator before it gets uploaded? As explained in my opening post?

We see from time to time that wrong decoding of weak signals are plotted on DXMAPS.COM (and other maps). But I assume that such wild decoding and reporting cannot be avoided? Some examples of

Hi Bill, I am the founder of the Intl. WSPR Beacon Project, GM1BAN is one of our Beacons. Here are his transmissions Link That is just one example. I don't know how many there are in total,

Hi Roland, do you have evidence that the stations you mention are sending the wrong locator in their WSPR beacon transmissions? It may be that the invalid location information is being added in one

It seems many decoded Spots contain wrong information like TX locator for example. There is no Data validation in the whole chain which leads to problems if you are into Data Analytics. My proposal

Hi Frank, WSJT-X still reads the mode even if it is not setting it, "FM" and "WBFM" are considered valid as DX Lab Suite Commander is known to report those mode designations among

Hi Dave, in all WSJT-X QSO modes except MSK144 the Tx audio offset (from USB VFO dial frequency) is the offset of the lowest frequency modulation tone (in MSK144 it is the centre frequency of the two

In UK on 60m our upper band limit is 5.358, so with dial set to 5.357 we should not TX above 1000Hz. On another forum, there is conflicting advice about the highest freq that the TX offset can be