Date   

locked Re: WSPR Spot validation #WSPR

Roland
 
Edited

On Wed, Nov 3, 2021 at 03:53 PM, Reino Talarmo wrote:
If GM1BAN sends 4 character locator, how the receiving entity can provide 6 character locator to the spot collector?
http://www.wsprnet.org/drupal/node/7109


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

Andy Talbot
 

Reading this thread piqued my intrigue, so went and had a look at the manual for my FT817ND.  The CAT command for getting frequency is there, but has the feeling of having been added as an afterthought.  It looks bodged

Issue CAT command 03 with 4 dummy bytes
It should return 5 bytes of data with frequency and mode.  
BUT BUT BUT ...

In footnotes, firstly it states "Do not use this command when using alkaline batteries or the supplied FNB-85 Ni-MH battery pack"
Then it goes on to state "Send a 5-byte dummy data (such as 00 00 00 00 00) first when sending this command

Why the battery pack should affect this particular CAT command  I shudder to think


locked Re: Exact frequency span occupied #TechnicalHelpQuestion #FT8

Ellis Birt (G7SAI)
 

It might be worth asking the WSJT-X developers to add the option of setting frequency limits for each band.  That way there would be no risk of transmitting out of band


On Wed, 3 Nov 2021 at 14:49, David Gould <dave@...> wrote:
Thanks Bill

73
Dave G3UEG



locked Re: WSPR Spot validation #WSPR

Reino Talarmo
 

On 03/11/2021 12:56, Roland wrote:
Biil, GM1BAN is only sending 4 character locator as all of our Beacons
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?
Hi Roland,
If GM1BAN sends 4 character locator, how the receiving entity can provide 6 character locator to the spot collector?

By the way could the spot collector check the validity of the call - locator pair or are there too many spots arriving for current computers? Also any data analyzing program should filter out clear outliers as in your example. Of course single spots of a station are that simple and an external database could be a proper solution (if it is up-to-date).

73, Reino OH3mA


locked Re: Exact frequency span occupied #TechnicalHelpQuestion #FT8

David Gould
 

Thanks Bill

73
Dave G3UEG


locked Re: Hamlib update for Xiegu G1M #Cat_RigControl

Antony Watts <antonywatts@...>
 

Absolutely no luck I'm afraid. Installed flrig for Mac (v "bs"). Chose G90 as rig, 19200, /dev/tty.usbserial110 seems to be the port.

Every time Ihit "init" the program crashes..

Will keep fiddling about, but this program seems somewhat sensitive and flaky?


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.



7241 - 7260 of 36836