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.

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

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.

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?

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

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.

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 3^rd 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

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.

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.

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 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

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

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

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.

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

I finally figured it out. Thanks for the reply

--
Thanks 73's de NU4N/Dave

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.