Date   

locked Re: WSPR Spot validation #WSPR

Michael Black
 

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

Bill Somerville
 

On 03/11/2021 12:56, Roland wrote:
Biil, GM1BAN is only sending 4 character locator as all of our Beacons
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 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?

73
Bill
G4WJS.


locked Re: WSPR Spot validation #WSPR

Roland
 

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


locked Re: WSPR Spot validation #WSPR

Bill Somerville
 

On 03/11/2021 12:38, Roland wrote:
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, difficult to quantify exactly.

Cheers
Roland

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 Messages" option which ensures only 4-character grids are sent.

73
Bill
G4WJS.


locked Re: WSPR Spot validation #WSPR

Roland
 

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?


locked Re: WSPR Spot validation #WSPR

Tom V. Segalstad
 

 

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

Roland
 

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, difficult to quantify exactly.

Cheers
Roland


locked Re: WSPR Spot validation #WSPR

Bill Somerville
 

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.


locked WSPR Spot validation #WSPR

Roland
 

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


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

Bill Somerville
 

On 03/11/2021 06:10, Frank, DH4FR 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
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 others.

73
Bill
G4WJS.


locked Re: Exact frequency span occupied #TechnicalHelpQuestion #FT8

Bill Somerville
 

On 03/11/2021 10:50, David Gould wrote:
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 set.
Option 1   950Hz with 50Hz upper sideband above.
Option 2   975Hz  with signal  +/-  25Hz

I think it is option 1 with the red "goalposts" showing the correct span of the TX signal keeping below 1000Hz

Could the development team please confirm.

73,
Dave G3UEG
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 tones, i.e. 1500 Hz). So your option 1 would be correct for FT8 mode.

73
Bill
G4WJS.


locked Exact frequency span occupied #TechnicalHelpQuestion #FT8

David Gould
 

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 set.
Option 1   950Hz with 50Hz upper sideband above.
Option 2   975Hz  with signal  +/-  25Hz

I think it is option 1 with the red "goalposts" showing the correct span of the TX signal keeping below 1000Hz

Could the development team please confirm.

73,
Dave G3UEG


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

PFA
 
Edited

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

Frank, DH4FR
 

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: WSJT-X 2.5.0 and MCHF: issue reading-back the VFO setting #Cat_RigControl #linux #Yaesu #IssueReport

Michael Black
 

And what if you replace the dll with the appropriate 32/64-bit one from here which is the current 4.4 development ?


What error do you get from the FT817?

Mike W9MDB




On Tuesday, November 2, 2021, 08:30:31 PM CDT, PFA <fpaolo63@...> wrote:


for who is interested on this topic:


just done some troubleshooting ...

RECAP working settings:
wsjtx 2.4.0 (it use Hamlib 4.2) -> set CAT for FT817 or FT847
wsjtx 2.5.0rc5
(it use Hamlib 4.3) ->  set CAT for FT817 or FT847
wsjtx 2.5.0 + Hamlib 4.3.1 ->  set CAT for FT847 (no UNI)

wsjtx 2.5.0 + Hamlib 4.3 -> set CAT for FT817 or FT847

... so which is the expected settings ? 817 or 847 or both ?
Any way it seems new Hamlib introduced the different behaviour .

--
73 paolo IU2OMT




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

PFA
 

for who is interested on this topic:


just done some troubleshooting ...

RECAP working settings:
wsjtx 2.4.0 (it use Hamlib 4.2) -> set CAT for FT817 or FT847
wsjtx 2.5.0rc5
(it use Hamlib 4.3) ->  set CAT for FT817 or FT847
wsjtx 2.5.0 + Hamlib 4.3.1 ->  set CAT for FT847 (no UNI)

wsjtx 2.5.0 + Hamlib 4.3 -> set CAT for FT817 or FT847

... so which is the expected settings ? 817 or 847 or both ?
Any way it seems new Hamlib introduced the different behaviour .

--
73 paolo IU2OMT


locked Re: Kenwood TS-2000 - no TX-NF in Versions 2.4 up #linux #Cat_RigControl #txaudio #IssueReport #Kenwood

Bill Somerville
 

On 02/11/2021 20:20, Karl Beckman WA8NVW - AFA5VB wrote:
Stefan:

The Kenwood TS-2000 is indeed a bit peculiar regarding use of the rear panel 13-pin DIN J7 accessory connector for data interfaces.  
If you are sending USB sound card audio to the rear connector J7 you can only apply data PTT ground to the proper pin of that same connector.  Sending a CAT PTT command to the TS2k radio will ALWAYS mute the Accy Conn audio input and enable the front panel microphone connector instead.  There is no known easy or seriously difficult way to alter this behavior of the TS2k.  That is why almost every TS2k owner uses a Signalink USB interface with built-in VOX to operate the WSJT-x modes. 
You don't need to modify or patch anything involving HamLib or RigCtl libraries because you can't use CAT.  Erase all those thoughts permanently from your mind.  Just buy the Signalink USB and the CAT13 interface cable which plugs into the rear panel 13-pin Accy Conn. 
--
Karl  WA8NVW  OH

Karl,

that is not a correct assessment, many users of many different rigs use a simple serial port driven PTT switch utilizing the RTS or DTR signal and a basic singe transistor circuit. There's no need whatsoever to ditch CAT control just because a hardwired PTT signal needs to be provided to cause a rig to select a particular Tx audio source (I know you are not saying that but your message can easily be misinterpreted as such). This not unique to the TS-2000 either, several Kenwood rigs require PTT via the correct ACC socket pin if audio is provided via the same socket. WSJT-X via all of its CAT interfacing options provide for PTT using either the RTS or DTR signal, either on the CAT serial port itself or via a second serial port specifically for that purpose.

I agree that the TS-200 CAT TX; command cannot be used to key the rig when audio is provided via the ACC socket, but almost everything else you mention is incorrect or confusing the issue unnecessarily. Buying a redundant audio interface is folly if one already has an audio interface to the PC and only need a simple PTT switch circuit to get up and running.

73
Bill
G4WJS.


locked Re: Kenwood TS-2000 - no TX-NF in Versions 2.4 up #linux #Cat_RigControl #txaudio #IssueReport #Kenwood

Karl Beckman WA8NVW - NNV5BH
 

Stefan:

The Kenwood TS-2000 is indeed a bit peculiar regarding use of the rear panel 13-pin DIN J7 accessory connector for data interfaces.  
If you are sending USB sound card audio to the rear connector J7 you can only apply data PTT ground to the proper pin of that same connector.  Sending a CAT PTT command to the TS2k radio will ALWAYS mute the Accy Conn audio input and enable the front panel microphone connector instead.  There is no known easy or seriously difficult way to alter this behavior of the TS2k.  That is why almost every TS2k owner uses a Signalink USB interface with built-in VOX to operate the WSJT-x modes. 
You don't need to modify or patch anything involving HamLib or RigCtl libraries because you can't use CAT.  Erase all those thoughts permanently from your mind.  Just buy the Signalink USB and the CAT13 interface cable which plugs into the rear panel 13-pin Accy Conn. 
--
Karl  WA8NVW  OH
WA8NVW@...
in WSJTX@groups.io


locked Re: 60 METER FT8 #TechnicalHelpQuestion

 

I finally figured it out. Thanks for the reply

On 11/2/2021 2:01 PM, Bill Somerville wrote:
On 02/11/2021 18:50, Dave Tucker Nu4N wrote:
How do i add 60 meters to WSJT-X ? I know it's under frequencies but I forgot how to add a new frequency.
-- 
Thanks 73's de NU4N/Dave

Dave,

the WSJT-X User Guide is always a good place to start when you need to find out how to do something:

https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.5.1.html#BAND_SETTINGS

73
Bill
G4WJS.





--
Thanks 73's de NU4N/Dave


locked Re: 60 METER FT8 #TechnicalHelpQuestion

Bill Somerville
 

On 02/11/2021 18:50, Dave Tucker Nu4N wrote:
How do i add 60 meters to WSJT-X ? I know it's under frequencies but I forgot how to add a new frequency.
--
Thanks 73's de NU4N/Dave
Dave,

the WSJT-X User Guide is always a good place to start when you need to find out how to do something:

https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.5.1.html#BAND_SETTINGS

73
Bill
G4WJS.

7281 - 7300 of 36849