Date   

locked Re: WSPR Spot validation #WSPR

Roland
 

Many are already registered members on qrz.com (free or paid sub). In order to use the XML API you need to have an XML subscription (USD29.95/year). I use the service for several other HAM-related programs, so WSJT-X would just be another use case for their service. The API provides a convenient way to search for calls locators etc.

You are not forcing anyone to subscribe to qrz.com if you make it an option in WSJT-X.

73
Roland


locked Re: Rig Control Error v2.5.1 on Mac OS #macOS #Cat_RigControl

Bill Somerville
 

Mike,

your point #2 is not quite correct, it doesn't care what the mode other than it must be one that is expected, i.e. within the set of valid modes.

This was a simple coding error in MacLoggerDX which has been fixed, I suggest we move on.

73
Bill
G4WJS.

On 03/11/2021 13:59, Michael Black via groups.io wrote:

Do I not understand Mode=None in WJST-X then?
I thought it meant two things.
#1 WSJT-X makes no attempt to set mode
#2 WSJT-X makes no read of mode (or shouldn't care).

Is one of those assumptions wrong?

Mike W9MDB




On Wednesday, November 3, 2021, 08:54:11 AM CDT, Bill Somerville <g4wjs@...> wrote:


Mike,

that's not correct. If an application emulates another application then it should do so accurately, if it doesn't then a client can't be expected to behave exactly as it does for the original application. This issue has been resolved by a minor change in MacLoggerDX to improve the DX Lab Suite Commander emulation it provides.

73
Bill
G4WJS.

On 03/11/2021 13:45, Michael Black via groups.io wrote:
If you set mode to None you can do whatever you want on the rig.

Mike W9MDB




On Wednesday, November 3, 2021, 01:10:15 AM CDT, Frank, DH4FR <frank.klop@...> wrote:


Hi Bill,

One final question regarding modes:
Is it an error for WSJT-X when the mode on the rig is not set to USB-D? And how is this impacted by the "Mode" setting on the Radio panel?
For example, will WSJT-X throw an error when I switch mode to FM or LSB on the rig while WSJT-X is actively controlling the rig and mode is set to "None"?


Best 73
Frank



locked Re: WSPR Spot validation #WSPR

Bill Somerville
 

Mike,

other than the hash code table, the WSPR decoder is stateless and very rarely provides decodes with correct calls but corrupt grids. This can indeed happen with Type 2 and Type 3 messages due to hash collisions, although that would overwhelmingly produce false decodes where both the grid and call were valid but did not belong with each other, i.e. the wrong call printed. At least one of the cases cited had an unlikely grid for any station, I suggest that may be a false decode (which would have a correctly formatted grid) which was interpreted as a Type 2 or Type 3 message and a hash code lookup attached a valid but unrelated call to it.

73
Bill
G4WJS.

On 03/11/2021 13:57, Michael Black via groups.io wrote:

There are two points...one is bad decodes...the other is inaccurate grid reports which perhaps come from some internal error like not clearing the grid when a new call is decoded so an old grid gets used by default?

Mike  W9MDB




On Wednesday, November 3, 2021, 08:55:29 AM CDT, Bill Somerville <g4wjs@...> wrote:


Mike,

please review the thread so far, you may have missed the point.

73
Bill
G4WJS.

On 03/11/2021 13:43, Michael Black via groups.io wrote:
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 all bad decodes with invalid callsigns.


Mike



On Wednesday, November 3, 2021, 08:40:24 AM CDT, Roland <roland@...> wrote:


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.



locked Re: WSJT-X 2.5.0 and MCHF: issue reading-back the VFO setting #Cat_RigControl #linux #Yaesu #IssueReport

Michael Black
 

The FT847 does not have a get_vfo function.
The FT817 does now have a get_vfo function which apparently is not supported by that rig.

So looks like you need to use the FT847.

Mike W9MDB




On Wednesday, November 3, 2021, 03:34:25 AM CDT, PFA <fpaolo63@...> wrote:


[Edited Message Follows]

Hi Mike,

just a clarification:
as per subject and tags, my tests are based on  linux  using my mcHF-QRP rig:  it has a native CAT/Audio USB interface and emulate the ft817 ...

hamlib 4.3.1 ( wsjtx 2.5.0) and mcHF with 817 setting I got this error testing CAT:

Hamlib error: Protocol error

read_block(): Timed out 3.3116 seconds after 1 chars

rig_get_vfo: returning -8(Protocol error

0000 00 .

read_block(): Timed out 3.3116 seconds after 1 chars

read_block(): Timed out 3.3116 seconds after 1 chars)rig.c(2809):rig_get_vfo return(-8) while testing getting current VFO



as you suggested, i will repeat the test also for HamLib 4.4

As well I will repeat tests using my ft817 ....

I start a thread on mcHF group: https://groups.io/g/mcHF/topic/86598682

PS. just understood  what really means 847UNI .... sorry for the confusion

--
73 paolo IU2OMT




locked Re: Rig Control Error v2.5.1 on Mac OS #macOS #Cat_RigControl

Michael Black
 

Do I not understand Mode=None in WJST-X then?
I thought it meant two things.
#1 WSJT-X makes no attempt to set mode
#2 WSJT-X makes no read of mode (or shouldn't care).

Is one of those assumptions wrong?

Mike W9MDB




On Wednesday, November 3, 2021, 08:54:11 AM CDT, Bill Somerville <g4wjs@...> wrote:


Mike,

that's not correct. If an application emulates another application then it should do so accurately, if it doesn't then a client can't be expected to behave exactly as it does for the original application. This issue has been resolved by a minor change in MacLoggerDX to improve the DX Lab Suite Commander emulation it provides.

73
Bill
G4WJS.

On 03/11/2021 13:45, Michael Black via groups.io wrote:

If you set mode to None you can do whatever you want on the rig.

Mike W9MDB




On Wednesday, November 3, 2021, 01:10:15 AM CDT, Frank, DH4FR <frank.klop@...> wrote:


Hi Bill,

One final question regarding modes:
Is it an error for WSJT-X when the mode on the rig is not set to USB-D? And how is this impacted by the "Mode" setting on the Radio panel?
For example, will WSJT-X throw an error when I switch mode to FM or LSB on the rig while WSJT-X is actively controlling the rig and mode is set to "None"?


Best 73
Frank






locked Re: WSPR Spot validation #WSPR

Bill Somerville
 

Mike,

QRZ.COM callsign data lookups are not a free service, we have no intention of requiring that WSJT-X WSPR spotters use such a service. Caching such lookup data seems unwise as no data update service is available to my knowledge, and probably storing the lookup data in bulk is against the terms of usage of the QRZ.COM service anyway.

73
Bill
G4WJS.

On 03/11/2021 13:03, Michael Black via groups.io wrote:

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 almost zero.
I also put the filter in my spot filtering program that sits between the cluster and Log4OM to avoid Log4OM triggering on false decodes too.

But with the spot reporting being done internally in WSJTX the QRZ validation would have to be added internally unless we migrated it externally.

Mike W9MDB




On Wednesday, November 3, 2021, 07:40:27 AM CDT, Tom V. Segalstad <la4ln@...> wrote:


 

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 wrong FT8 decoding on 50.313 MHz here during the last week (WSJT-X v. 2.5.0):

 

181130 -24  2.0 1118 ~  FT0XHT 5R9KHX JP91

 

104745 -24  2.3 2951 ~  7I7IBM/P QF6GOM/P R KP02

 

122845 -20  4.0  899 ~  PT2KFL/R IP0RT PC08

 

122115 -19  4.1  210 ~  M52FPI/P TX5SPH BQ51

 

73 from Tom, LA4LN

 

 

Fra: Bill Somerville
Sendt: onsdag 3. november 2021 kl. 13.33
Til: main@WSJTX.groups.io
Emne: Re: [WSJTX] WSPR Spot validation #WSPR

 

On 03/11/2021 12:22, Roland wrote:
> 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.

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 of downstream databases.

73
Bill
G4WJS.

 


--
Tom (LA4LN)



locked Re: WSPR Spot validation #WSPR

Michael Black
 

There are two points...one is bad decodes...the other is inaccurate grid reports which perhaps come from some internal error like not clearing the grid when a new call is decoded so an old grid gets used by default?

Mike  W9MDB




On Wednesday, November 3, 2021, 08:55:29 AM CDT, Bill Somerville <g4wjs@...> wrote:


Mike,

please review the thread so far, you may have missed the point.

73
Bill
G4WJS.

On 03/11/2021 13:43, Michael Black via groups.io wrote:

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 all bad decodes with invalid callsigns.


Mike



On Wednesday, November 3, 2021, 08:40:24 AM CDT, Roland <roland@...> wrote:


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.






locked Re: WSPR Spot validation #WSPR

Bill Somerville
 

Mike,

please review the thread so far, you may have missed the point.

73
Bill
G4WJS.

On 03/11/2021 13:43, Michael Black via groups.io wrote:

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 all bad decodes with invalid callsigns.


Mike



On Wednesday, November 3, 2021, 08:40:24 AM CDT, Roland <roland@...> wrote:


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.



locked Re: Rig Control Error v2.5.1 on Mac OS #macOS #Cat_RigControl

Bill Somerville
 

Mike,

that's not correct. If an application emulates another application then it should do so accurately, if it doesn't then a client can't be expected to behave exactly as it does for the original application. This issue has been resolved by a minor change in MacLoggerDX to improve the DX Lab Suite Commander emulation it provides.

73
Bill
G4WJS.

On 03/11/2021 13:45, Michael Black via groups.io wrote:

If you set mode to None you can do whatever you want on the rig.

Mike W9MDB




On Wednesday, November 3, 2021, 01:10:15 AM CDT, Frank, DH4FR <frank.klop@...> wrote:


Hi Bill,

One final question regarding modes:
Is it an error for WSJT-X when the mode on the rig is not set to USB-D? And how is this impacted by the "Mode" setting on the Radio panel?
For example, will WSJT-X throw an error when I switch mode to FM or LSB on the rig while WSJT-X is actively controlling the rig and mode is set to "None"?


Best 73
Frank



locked Re: WSPR Spot validation #WSPR

Roland
 
Edited

My post is about invalid locators/callsign pairs. GM1BAN is a correct callsign.


locked No power or tones on alternate tries #txaudio #Yaesu #stopped_working

Robert Ahrens
 

I have been going crazy.  I jerked around with my setup for the CQWW SSB contest over the weekend and since then things have been weird.  I cannot fathom how anything I did could cause the problem I am having now.

Every other time that WSJT keys my FTDX3000, it fails to send tones so there is no power out.  The rig reliably keys and I have confirmed via the MON function that tones are produced only every other time that the Tune button on WSJT is activated, or that WSJT "transmits" a CQ (or any other message).

I am using OmniRig, full CAT with a single cable to the computer, and Win4Yaesu with a Win10 computer ... but I cannot imagine how any of that should matter.  The radio is keying every time, and the audio path (selection of audio devices, etc) appears to be OK since it does work predictably every other time. 

Any ideas?  Thank you for your help.  It is driving me crazy watching one DX station after another  scroll up the screen and I cannot even try. 

73 de NT5A - Bob


locked Re: WSPR Spot validation #WSPR

Roland
 

On Wed, Nov 3, 2021 at 02:01 PM, Bill Somerville wrote:
Many of the large volume WSPR spotting sources are not using WSJT-X so I guess they are forming spots from their own decoders, or more likely from running the underlying wsprd decoder application. Do you know if these bad spots are more prevalent from particular types of spot sources?
That's another good question. I think that needs more research. To stick to the example with GM1BAN and the wrong locator it was decoded by WSJT-X 2.1.2




 


locked Re: Rig Control Error v2.5.1 on Mac OS #macOS #Cat_RigControl

Michael Black
 

If you set mode to None you can do whatever you want on the rig.

Mike W9MDB




On Wednesday, November 3, 2021, 01:10:15 AM CDT, Frank, DH4FR <frank.klop@...> wrote:


Hi Bill,

One final question regarding modes:
Is it an error for WSJT-X when the mode on the rig is not set to USB-D? And how is this impacted by the "Mode" setting on the Radio panel?
For example, will WSJT-X throw an error when I switch mode to FM or LSB on the rig while WSJT-X is actively controlling the rig and mode is set to "None"?


Best 73
Frank




locked Re: WSPR Spot validation #WSPR

Michael Black
 

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 all bad decodes with invalid callsigns.


Mike



On Wednesday, November 3, 2021, 08:40:24 AM CDT, Roland <roland@...> wrote:


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.




locked Re: WSPR Spot validation #WSPR

Roland
 

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.


locked Re: WSPR Spot validation #WSPR

Michael Black
 

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




On Wednesday, November 3, 2021, 08:20:38 AM CDT, Roland <roland@...> wrote:


On Wed, Nov 3, 2021 at 02:03 PM, Michael Black wrote:
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 almost zero.
I also put the filter in my spot filtering program that sits between the cluster and Log4OM to avoid Log4OM triggering on false decodes too.
 
But with the spot reporting being done internally in WSJTX the QRZ validation would have to be added internally unless we migrated it externally.

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


Roland




locked Re: WSPR Spot validation #WSPR

Roland
 

On Wed, Nov 3, 2021 at 02:03 PM, Michael Black wrote:
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 almost zero.
I also put the filter in my spot filtering program that sits between the cluster and Log4OM to avoid Log4OM triggering on false decodes too.
 
But with the spot reporting being done internally in WSJTX the QRZ validation would have to be added internally unless we migrated it externally.

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

Roland


locked Re: WSPR Spot validation #WSPR

Roland
 

Every Operator is responsible for his own Data


locked Re: Rig Control Error v2.5.1 on Mac OS #macOS #Cat_RigControl

Bill Somerville
 

On 03/11/2021 13:05, Frank, DH4FR wrote:
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 could hear my FT4 signal almost the whole pass.

Best 73
Frank
Hi Frank,

thanks for the update and glad you are up and running on low-orbit satellites.

73
Bill
G4WJS.


locked Re: WSPR Spot validation #WSPR

 

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

 

From: Roland
Sent: 03 November 2021 12:30
To: main@WSJTX.groups.io
Subject: [WSJTX] WSPR Spot validation #WSPR

 

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 is to validate decoded locators against 3rd party DBs like qrz.com etc. on the client-side.Something like this

Compare decoded locator with 3rd party databases (qrz.com etc.) match callsign and locator if no match then discard - no upload, if call/locator is not registered in 3rd party DB accept Spot and upload.

I think this would eliminate a lot of wrong Spots like this one for example.



GM1BAN is registered on qrz.com and his locator is nowhere near the South Atlantic.

What do you think?
73
Roland

 


--
73 Phil GM3ZZA

10501 - 10520 of 40086