Re: [wsjt-devel] calling CQ every 2nd round

[Paul Kube]

On Mon, May 25, 2020 at 3:33 PM Rik Strobbe  wrote:

>
> For now I do the manually (via the enable TX button), but if others find
> this useful as well it might be considered to add it as an option in WSJT-X?
>

In my opinion, this should be the default, for FT8 and FT4.

73, Paul K6PO

___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

[Stephen VK3SIR]

Bill and Joe,

As a summary for readers I have identified that MANY false decodes being 
observed were observed ESPECIALLY using the “flipping” of the bits that results 
in a /R. Subsequently there has also been a bit of chatter re field days etc. 
and the use of non-standard suffixes even in the few hours that I have been 
sleeping.

The intent of prefixes and suffixes is to satisfy overseas “reciprocal” and 
“local” short-term operating rights primarily i.e VK1/K1JT (operating 
short-term in Australian Capital Territory) … though it is more difficult with 
some region specifiers now dropped internationally. Likewise there are 
“standard aceepted” suffixes recommended internationally to indicate operation 
away from nominated base that many regulators accept and require: with the main 
suffixes being /mobile, /portable, /aeronautical mobile and /maritime mobile 
(accepted as /m, /p, /am and /mm in the CW/Digital world).

There are explosions of bastardisations of agreed callsign structures, callsign 
templates and “special calls” that create problems and issues generally (i.e. 
The VK F-call template).

Additional suffixes such as /R that are RARELY used are NON STANDARD; in fact 
such suffixes may not be acceptable to regulators here in VK and in EU.

AP Mode is a necessary fact of life for those of us in far-away places; 
many-many discussions on these forums refer to RR/73 loops. AP modes are a 
necessity to complete many transactions.

It is more than highly annoying when you are following all recommended 
operational parameters - watch the automation pick out a false decode – and 
then to have to spring into action which does not necessarily look good to 
other operators observing your QSOs….. Unnecessary noise, chatter resultant QRM 
etc.

In response to this issue and the recognition that the /R switch is being 
observed with MANY MANY false decodes, would it not be in order to apply 
mitigation strategies? I am seeing quite a number of posts re false decodes or 
potential bug reports before they head here as some have fear of how they will 
be received. I say to all POST as they need to know ! “The good, the bad and 
the ugly” must be reported !

I foresee that the “mitigation strategy” that would best suit the vast numbers 
of us that rely on AP modes to complete transactions – that would also fit 
logic and processing and performance requirements - would be to employ a hash 
table of acceptable “standard” suffixes . This hash table should loaded from 
the wsjtx.ini at load time and decodes checked against this. If it is not in 
the table its rejected by QSO-processing logic as being valid and therefore  is 
not subject to the automated handling.

For those that do use non-standard suffixes an option, not checked as default, 
may be in order to allow “non-standard suffixes” through the automated 
procedure.

I’ll keep sending these false decodes through when observed as we know (and 
both of you have said to others in private messages) that false decodes of any 
form that can be reproduced are extremely valuable.

73, and keep up the amazing work !

Steve I
VK3VM / VK3SIR
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] bug report for WSJT-X 2.2.0-rc2

[Joe Taylor]

Hi Bruce,

On 5/25/2020 5:44 PM, Bruce H. Bern K3NQ wrote:


Program version: (beta) WSJT-X 2.2.0-rc3;  My system: Win 10 Pro X64; Intel
Core i7-3930K; CPU@3.2 GHz; RAM=24Gb; Radio Kenwood TS-990, Baud rate:
115,200; data bits, stop bits, handshake all default
Precis of problem: If a transmit frequency of <200 Hz is selected by holding
shift and clicking below 200 Hz, the transmit frequency will move no lower
than 200Hz. If a target station has already been selected, and his/her call
sign already double-clicked (transmit enabled), any attempt to move the
transmit frequency by holding shift and double clicking below 200Hz results
in loss of the recorded waterfall display (as well as moving the transmit
frequency no lower than 200 Hz). The waterfall remains functional, but
starts again as if the program was just opened. I've attached a
less-than-perfect video. I am very much enjoying the rapid decoding.


Thanks for the additional information.  I still have not been able to 
reproduce the behavior you describe.


It is intentional that the Tx audio frequency cannot be set lower than 
200 Hz.  This is because you might not be using Split=Rig or
Split=Fake It, and in that case the very low requested audio frequency 
would be sent to your SSB transmitter.  Most likely the audio frequency 
would be outside your Tx filter's passband.


If I shift+click on the waterfall at a frequenct below 200 Hz, the Tx 
freq is set to 200 Hz.  If I decode a signal below 200 Hz and 
double-click on the decoded text, the Tx freq is set to 200 Hz.  I 
haven't found anything that on my system "results in loss of the 
recorded waterfall display".


If I have overlooked something important, or if your system behaves 
different from mine, please give me an exact list of steps that will 
result in loss of the waterfall display.



On a side note, I worked you a few months back. Excited by my brush with ham
royalty, I called over and over with an appropriate power of 30-40 watts.
Finally, I switched on the linear assuming the problem was my since-replaced
and long overdue for maintenance antenna. You gave me a -03dB report- I gave
you a -14 dB report. I was embarrassed at the realization I was using ten
times more power than necessary. I had meant to apologize for my violation
of the spirit of WSJT.


No problem at all!  It's not always easy to choose appropriate Tx power; 
QSB and QRM often determine how strong and how copyable a signal may be.


-- 73, Joe, K1JT


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] calling CQ every 2nd round

[Rik Strobbe]

Hello,

on a quiet band I find it useful to call CQ every second round (once a minute 
in FT8).
That allows me to monitor both even and odd periods inbetween the CQ's and as 
the duty cycle is only 25% I can CQ for a long period without overheating the 
TX.
For now I do the manually (via the enable TX button), but if others find this 
useful as well it might be considered to add it as an option in WSJT-X?

73, Rik  ON7YD - OR7T


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc2: Split Operation issues with macOS and IC-7300

[Artie Langston]

I also observed split issues with the identical setup on my IC-7300, only
with Windows 10.
After installing rc2, in FT-8 mode the rig was receiving on 7.074 when set
for 40M, but was transmitting on 14.074 on 20M on split! Apparently,
whatever was previously in VFO B was retained.

73

Artie KD0GY

On Mon, May 25, 2020 at 3:11 PM Matt Henry  wrote:

> Hello,
>
> I am observing some split operation issues with WSJT-X 2.2.0-rc2 on macOS
> and IC-7300.
>
> My Setup:
> Computer: macOS Catalina 12.15.4
> Rig: Icom IC-7300
> WSJT-X 2.2.0-rc2
>
> WSJT-X Radio Tab:
> Rig: Icom IC-7300
> Serial Port: /dev/cu.SLAB_USBtoUART
> Baud Rate: 115200
> Data Bits: Eight
> Stop Bits: One
> Handshake: None
> PTT Method: CAT
> Mode: Data/Pkt
> Split Operation: Rig
> Test CAT is green
>
> Steps:
> 1. Split is off on Rig
> 2. WSJT-X is set to 20m band (140.074.000 MHz)
> 3. Rig dial frequency is 14.074.00 MHz
> 4. WSJT-X Tx offset is 1500 Hz
> 5. Press Tune
> 6. Rig changes to split mode and transmits on 14.074.00 MHz
> 7. Change WSJT-X Tx offset to 500 Hz
> 8. Press Tune
> 9. Rig transmits on 14.074.00 MHz (expected 14.073.00 MHz)
> 10. Change WSJT-X Tx offset to 2500 Hz
> 11. Press Tune
> 12. Rig transmits on 14.074.00 MHz (expected 14.075.00 MHz)
> 13. Turn off split on rig and leave WSJT-X Tx offset at 2500 Hz
> 14. Press Tune
> 15. Rig transmits on 14.075.00 MHz
> 16. Change WSJT-X Tx offset to 1500 Hz
> 17. Press Tune
> 18. Rig transmits on 14.075.00 MHz (expected 14.074.00 MHz)
> 19. Change WSJT-X Tx offset to 500 Hz
> 20. Press Tune
> 21. Rig transmits on 14.075.00 MHz (expected 14.073.00 MHz)
> 22. At this point I notice that when transmission stops, the rig dial
> frequency quickly changes from 14.075.00 to 14.073.00 and then to 14.074.00.
>
> It appears that the the split offset is correctly applied when split is
> off on the rig, but the offset doesn't change thereafter.
>
> No problems are observed when running these same steps with WSJT-X 2.1.2.
>
> 73,
> Matt, NR3M
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJT-X 2.2.0-rc2: Split Operation issues with macOS and IC-7300

[Matt Henry]

Hello,

I am observing some split operation issues with WSJT-X 2.2.0-rc2 on macOS and 
IC-7300.

My Setup:
Computer: macOS Catalina 12.15.4
Rig: Icom IC-7300
WSJT-X 2.2.0-rc2

WSJT-X Radio Tab:
Rig: Icom IC-7300
Serial Port: /dev/cu.SLAB_USBtoUART
Baud Rate: 115200
Data Bits: Eight
Stop Bits: One
Handshake: None
PTT Method: CAT
Mode: Data/Pkt
Split Operation: Rig
Test CAT is green

Steps:
1. Split is off on Rig
2. WSJT-X is set to 20m band (140.074.000 MHz)
3. Rig dial frequency is 14.074.00 MHz
4. WSJT-X Tx offset is 1500 Hz
5. Press Tune
6. Rig changes to split mode and transmits on 14.074.00 MHz
7. Change WSJT-X Tx offset to 500 Hz
8. Press Tune
9. Rig transmits on 14.074.00 MHz (expected 14.073.00 MHz)
10. Change WSJT-X Tx offset to 2500 Hz
11. Press Tune
12. Rig transmits on 14.074.00 MHz (expected 14.075.00 MHz)
13. Turn off split on rig and leave WSJT-X Tx offset at 2500 Hz
14. Press Tune
15. Rig transmits on 14.075.00 MHz
16. Change WSJT-X Tx offset to 1500 Hz
17. Press Tune
18. Rig transmits on 14.075.00 MHz (expected 14.074.00 MHz)
19. Change WSJT-X Tx offset to 500 Hz
20. Press Tune
21. Rig transmits on 14.075.00 MHz (expected 14.073.00 MHz)
22. At this point I notice that when transmission stops, the rig dial frequency 
quickly changes from 14.075.00 to 14.073.00 and then to 14.074.00.

It appears that the the split offset is correctly applied when split is off on 
the rig, but the offset doesn't change thereafter. 

No problems are observed when running these same steps with WSJT-X 2.1.2.

73,
Matt, NR3M




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Addition of G and H to the Field Day class characters.

[Jim Shepherd]

We declared that a completed QSO had a 599 signal report... Since the 59 or
599 is given automatically by most contest logging programs, this is not a
real deciding element of the exchange. With the successful exchange of the
location data either there or absent, this is actually a better signal
report than the usual "you are 59, repeat the exchange agn agn, slowly with
phonetics..." exchange.  The location exchange would be set before the
contest or when a rover changed locations so there is no need to look it up
during the contest.  14A NV is my location in Pershing county, 14B is
Elko/Humboldt/Lander counties junction... It is really no different than
having to look up the county abbreviations as they may be different in
different states--Lincoln, Oregon is ORLNN and Lincoln, Nevada is NVLIN and
in Maine it is LINME.

We run a program that translates the FT8 Cabrillo log into the same format
as the Cabrillo log for SSB, CW and the conversational digital modes and
appends that log if necessary to the end of that other log.  (1500 lines of
COBOL that adds the 599. the 5 digit state/county abbreviation, and turns
them into multiple contacts if either the sent or received is on a
countyline)

This is a workaround that tries to stay in the limitations of the current
capabilities of WSJT-X. It will take a huge effort to expand that program
to 110 bits.

Thanks for your great work on this program. I like the more visible green
marker on the waterfall

73

Jim W6US

On Mon, May 25, 2020 at 11:10 AM Joe Taylor  wrote:

> Hi Jim,
>
> Of course it would be trivial to enable display of characters G and H as
> "pseudo-classes" in the ARRL Field Day message formats used for MSK144,
> FT4, and FT8.  But I don't see this as a very desirable message format
> for state QSO parties.  A few problems, for example:
>
>   - Operators would need a look-up table to determine their appropriate
> "number of transmitters" and operating class.
>
>   - Displayed message information would mean something very different
> from what it appears to mean.
>
>   - Messages would contain no signal report -- presently a required part
> of the NV QSO Party exchange.
>
> SSeems to me that a good solution for the wide variety of exchanges in
> state QSO parties really needs a message payload more like 110 bits,
> rather than 77.
>
> -- 73, Joe, K1JT
>
> On 5/25/2020 1:20 PM, Jim Shepherd wrote:
> > Hi,
> > There are 8 characters available for the Field Day contest overlay
> > to designate class of operation. Currently A-F are used, and if G and H
> > are activated it will allow for 256 combinations of the transmitter
> > number (1-32) and the letters.  Right now only 192 combinations are
> > available.  Why this matters is that this overlay can be used for state
> > QSO parties to add county and county line designations for the FT8/FT4
> > contacts. Here in Nevada we have 17 counties and 54 county line
> > locations, and the system works fine for us. Maryland is using 25
> > counties this year. Texas has 254 counties, so while county line
> > operations would require a couple of thousand designations, they would
> > just have to settle with the single counties only. It would also allow
> > the ARRL to add two new classes to Field Day to handle VPN linked
> > locations in the new normal of social distancing in the future.
> >
> > Thanks for considering this.
> >
> > 73
> >
> > Jim Shepherd W6US
> > NVQSO Party Chairman
> >
> >
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] bug report for WSJT-X 2.2.0-rc2

[Joe Taylor]

Hi Bruce,

On 5/25/2020 2:53 PM, Bruce H. Bern K3NQ wrote:
Using latest Win-10, if attempting to place the transmit frequency below 
200 Hz, the display crashes


I can't reproduce the effect you describe.

If it's reproducible for you, please follow instructions for bug reports 
here in the User Guide:


http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.2.0-rc2.html#SUPPORT

To be useful, bug reports should include at least the following information:

 - Program version

 - Operating system

 - Concise description of the problem

 - Exact sequence of steps required to reproduce the problem

-- 73, Joe, K1JT


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] bug report for WSJT-X 2.2.0-rc2

[Bruce H. Bern]

Using latest Win-10, if attempting to place the transmit frequency below 200
Hz, the display crashes

Thanks,

Bruce K3NQ

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] trouble keying PTT with com port RTS or DTS

[Charles Suckling]

Dave

A few of us have seen the same problem with this type of PTT control with
rc2.  Devel team are aware.

73

Charlie G3WDG

On Mon, 25 May 2020 at 17:43, David Tiller  wrote:

> FYI team, I also reported an issue with PTT with RC1 that does not seem to
> be solved in RC2. I believe the issue was the initialization of the cat
> state for rigs that cannot be queried.
>
> The command I was previously asked to run returns '0' each time, so it
> seems to be something else.
>
> dtiller$ ./Applications/wsjtx.app/Contents/MacOS/rigctl-wsjtx -p
> /dev/cu.usbserial-141201 -P RTS -v -Z t pause 1 t pause 1 t
> 2020-05-25:16:35:56.919181: rigctl, Hamlib 4.0~git May 23 2020 23:00:09
> 2020-05-25:16:35:56.919533: Report bugs to <
> hamlib-develo...@lists.sourceforge.net>
>
> 2020-05-25:16:35:56.919552: rig_init called
> 2020-05-25:16:35:56.919580: initrigs4_dummy: _init called
> 2020-05-25:16:35:56.919596: rig_register called
> 2020-05-25:16:35:56.919602: rig_register: rig_register (1)
> 2020-05-25:16:35:56.919614: rig_register called
> 2020-05-25:16:35:56.919620: rig_register: rig_register (2)
> 2020-05-25:16:35:56.919626: rig_register called
> 2020-05-25:16:35:56.919632: rig_register: rig_register (4)
> 2020-05-25:16:35:56.919638: rig_register called
> 2020-05-25:16:35:56.919676: rig_register: rig_register (5)
> 2020-05-25:16:35:56.919717: dummy_init called
> 2020-05-25:16:35:56.919749: rig_passband_normal called
> 2020-05-25:16:35:56.919757: rig_passband_normal called
> 2020-05-25:16:35:56.919774: rig_open called
> 2020-05-25:16:35:56.919794: port_open called
> 2020-05-25:16:35:56.919802: ser_open called
> 2020-05-25:16:35:56.922284: ser_set_dtr called
> 2020-05-25:16:35:56.922296: ser_set_dtr: DTR=0
> 2020-05-25:16:35:56.922332: ser_set_rts called
> 2020-05-25:16:35:56.922339: ser_set_rts: RTS=0
> 2020-05-25:16:35:56.922354: ser_close called
> 2020-05-25:16:35:56.922360: ser_close: no options for fd to restore
> 2020-05-25:16:35:56.923688: dummy_open called
> 2020-05-25:16:35:56.948756: rig_get_vfo called
> 2020-05-25:16:35:56.948788: elapsed_ms: start = 0,0
> 2020-05-25:16:35:56.948812: rig_get_vfo: cache check age=100ms
> 2020-05-25:16:35:56.948821: rig_get_vfo: cache miss age=100ms
> 2020-05-25:16:35:56.968886: dummy_get_vfo called: VFOA
> 2020-05-25:16:35:56.968917: elapsed_ms: start = 0,0
> 2020-05-25:16:35:56.968930: elapsed_ms: after gettime, start =
> 1590424556,968927000
> 2020-05-25:16:35:56.968953: rig_set_parm called
> 2020-05-25:16:35:56.968964: rig_has_set_parm called
> 2020-05-25:16:35:56.968980: rig_setting2idx called
> 2020-05-25:16:35:56.968992: rig_strparm called
> 2020-05-25:16:35:56.969009: rig_strparm called
> 2020-05-25:16:35:56.969018: dummy_set_parm called: SCREENSAVER 0
> Opened rig model 1, 'Dummy'
> 2020-05-25:16:35:56.969152: Backend version: 20200503.0, Status: Stable
> 2020-05-25:16:35:56.969176: rigctl_parse: called, interactive=0
> 2020-05-25:16:35:56.969204: rigctl_parse: debug1
> 2020-05-25:16:35:56.969217: rigctl_parse: debug5
> 2020-05-25:16:35:56.969228: rigctl_parse: debug10
> 2020-05-25:16:35:56.969244: rigctl_parse: vfo_mode=0
> 2020-05-25:16:35:56.969266: rig_get_ptt called
> 2020-05-25:16:35:56.969320: elapsed_ms: start = 0,0
> 2020-05-25:16:35:56.969339: rig_get_ptt: cache check age=100ms
> 2020-05-25:16:35:56.969357: rig_get_ptt: cache miss age=100ms
> 2020-05-25:16:35:56.991473: dummy_get_ptt called
> 2020-05-25:16:35:56.991570: elapsed_ms: start = 0,0
> 2020-05-25:16:35:56.991630: elapsed_ms: after gettime, start =
> 1590424556,991627000
> 0
> 2020-05-25:16:35:56.991650: rigctl_parse: retcode=0
> 2020-05-25:16:35:56.991668: rigctl_parse: called, interactive=0
> 2020-05-25:16:35:56.991723: rigctl_parse: debug1
> 2020-05-25:16:35:56.991738: rigctl_parse: debug3
> 2020-05-25:16:35:56.991754: rigctl_parse: debug5
> 2020-05-25:16:35:56.991775: rigctl_parse: debug10
> 2020-05-25:16:35:56.991785: rigctl_parse: vfo_mode=0
> 2020-05-25:16:35:57.996817: rigctl_parse: retcode=0
> 2020-05-25:16:35:57.996849: rigctl_parse: called, interactive=0
> 2020-05-25:16:35:57.996856: rigctl_parse: debug1
> 2020-05-25:16:35:57.996861: rigctl_parse: debug5
> 2020-05-25:16:35:57.996866: rigctl_parse: debug10
> 2020-05-25:16:35:57.996871: rigctl_parse: vfo_mode=0
> 2020-05-25:16:35:57.996878: rig_get_ptt called
> 2020-05-25:16:35:57.996884: elapsed_ms: start = 1590424556,991627000
> 2020-05-25:16:35:57.996893: elapsed_ms: elapsed_secs=1005.26
> 2020-05-25:16:35:57.996900: rig_get_ptt: cache check age=1005ms
> 2020-05-25:16:35:57.996905: rig_get_ptt: cache miss age=1005ms
> 2020-05-25:16:35:58.016952: dummy_get_ptt called
> 2020-05-25:16:35:58.016982: elapsed_ms: start = 0,0
> 2020-05-25:16:35:58.016992: elapsed_ms: after gettime, start =
> 1590424558,1699
> 0
> 2020-05-25:16:35:58.017007: rigctl_parse: retcode=0
> 2020-05-25:16:35:58.017016: rigctl_parse: called, interactive=0
> 2020-05-25:16:35:58.017027: rigctl_parse: debug1
> 2020-05-25:16:35:58.017036: 

Re: [wsjt-devel] Addition of G and H to the Field Day class characters.

[Joe Taylor]

Hi Jim,

Of course it would be trivial to enable display of characters G and H as 
"pseudo-classes" in the ARRL Field Day message formats used for MSK144, 
FT4, and FT8.  But I don't see this as a very desirable message format 
for state QSO parties.  A few problems, for example:


 - Operators would need a look-up table to determine their appropriate
   "number of transmitters" and operating class.

 - Displayed message information would mean something very different
   from what it appears to mean.

 - Messages would contain no signal report -- presently a required part
   of the NV QSO Party exchange.

SSeems to me that a good solution for the wide variety of exchanges in 
state QSO parties really needs a message payload more like 110 bits, 
rather than 77.


-- 73, Joe, K1JT

On 5/25/2020 1:20 PM, Jim Shepherd wrote:

Hi,
    There are 8 characters available for the Field Day contest overlay 
to designate class of operation. Currently A-F are used, and if G and H 
are activated it will allow for 256 combinations of the transmitter 
number (1-32) and the letters.  Right now only 192 combinations are 
available.  Why this matters is that this overlay can be used for state 
QSO parties to add county and county line designations for the FT8/FT4 
contacts. Here in Nevada we have 17 counties and 54 county line 
locations, and the system works fine for us. Maryland is using 25 
counties this year. Texas has 254 counties, so while county line 
operations would require a couple of thousand designations, they would 
just have to settle with the single counties only. It would also allow 
the ARRL to add two new classes to Field Day to handle VPN linked 
locations in the new normal of social distancing in the future.


    Thanks for considering this.

73

Jim Shepherd W6US
NVQSO Party Chairman


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Addition of G and H to the Field Day class characters.

[Jim Shepherd]

Hi,
   There are 8 characters available for the Field Day contest overlay to
designate class of operation. Currently A-F are used, and if G and H are
activated it will allow for 256 combinations of the transmitter number
(1-32) and the letters.  Right now only 192 combinations are available.
Why this matters is that this overlay can be used for state QSO parties to
add county and county line designations for the FT8/FT4 contacts. Here in
Nevada we have 17 counties and 54 county line locations, and the system
works fine for us. Maryland is using 25 counties this year. Texas has 254
counties, so while county line operations would require a couple of
thousand designations, they would just have to settle with the single
counties only. It would also allow the ARRL to add two new classes to Field
Day to handle VPN linked locations in the new normal of social distancing
in the future.

   Thanks for considering this.

73

Jim Shepherd W6US
NVQSO Party Chairman
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] rc2 UI

[Bill Somerville]

Hi Georg,

as you say "Preferences" I assume you are using macOS. What o/s version 
are you using please?


73
Bill
G4WJS.

On 25/05/2020 17:38, Georg Isenbürger wrote:

Joe et al,

while using „Configurations“ I was not able to get back into „Preferences“ 
anymore. Showed a menue similar to „Configurations“.

73’s Georg


Am 25.05.2020 um 18:17 schrieb Joe Taylor:

Hi Jim,

On 5/25/2020 3:04 AM, Jim Brown K9YC wrote:

Thanks VERY much for this one:
"Hold Tx frequency no longer cleared when switching between modes."
We're halfway there -- TX frequency defaults to 1500 Hz when I've returned from 
MSK144 to FT8. Is it possible to remember prior setting of TX frequency?

As a matter of policy the WSJT-X user interface does not "remember" optional 
user settings after switches between modes.  If you want total recall of your mode 
settings, use a Configuration.


I think the goalpost markers are improved, but I'm not colorblind.:)

-- 73, Joe, K1JT



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] rc2 UI

[Georg Isenbürger]

Joe et al,

while using „Configurations“ I was not able to get back into „Preferences“ 
anymore. Showed a menue similar to „Configurations“.

73’s Georg

> Am 25.05.2020 um 18:17 schrieb Joe Taylor :
> 
> Hi Jim,
> 
> On 5/25/2020 3:04 AM, Jim Brown K9YC wrote:
>> Thanks VERY much for this one:
>> "Hold Tx frequency no longer cleared when switching between modes."
>> We're halfway there -- TX frequency defaults to 1500 Hz when I've returned 
>> from MSK144 to FT8. Is it possible to remember prior setting of TX frequency?
> 
> As a matter of policy the WSJT-X user interface does not "remember" optional 
> user settings after switches between modes.  If you want total recall of your 
> mode settings, use a Configuration.
> 
>> I think the goalpost markers are improved, but I'm not colorblind. :)
> 
>   -- 73, Joe, K1JT
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] trouble keying PTT with com port RTS or DTS

[David Tiller]

FYI team, I also reported an issue with PTT with RC1 that does not seem to be 
solved in RC2. I believe the issue was the initialization of the cat state for 
rigs that cannot be queried.

The command I was previously asked to run returns '0' each time, so it seems to 
be something else. 

dtiller$ ./Applications/wsjtx.app/Contents/MacOS/rigctl-wsjtx -p 
/dev/cu.usbserial-141201 -P RTS -v -Z t pause 1 t pause 1 t
2020-05-25:16:35:56.919181: rigctl, Hamlib 4.0~git May 23 2020 23:00:09
2020-05-25:16:35:56.919533: Report bugs to 


2020-05-25:16:35:56.919552: rig_init called
2020-05-25:16:35:56.919580: initrigs4_dummy: _init called
2020-05-25:16:35:56.919596: rig_register called
2020-05-25:16:35:56.919602: rig_register: rig_register (1)
2020-05-25:16:35:56.919614: rig_register called
2020-05-25:16:35:56.919620: rig_register: rig_register (2)
2020-05-25:16:35:56.919626: rig_register called
2020-05-25:16:35:56.919632: rig_register: rig_register (4)
2020-05-25:16:35:56.919638: rig_register called
2020-05-25:16:35:56.919676: rig_register: rig_register (5)
2020-05-25:16:35:56.919717: dummy_init called
2020-05-25:16:35:56.919749: rig_passband_normal called
2020-05-25:16:35:56.919757: rig_passband_normal called
2020-05-25:16:35:56.919774: rig_open called
2020-05-25:16:35:56.919794: port_open called
2020-05-25:16:35:56.919802: ser_open called
2020-05-25:16:35:56.922284: ser_set_dtr called
2020-05-25:16:35:56.922296: ser_set_dtr: DTR=0
2020-05-25:16:35:56.922332: ser_set_rts called
2020-05-25:16:35:56.922339: ser_set_rts: RTS=0
2020-05-25:16:35:56.922354: ser_close called
2020-05-25:16:35:56.922360: ser_close: no options for fd to restore
2020-05-25:16:35:56.923688: dummy_open called
2020-05-25:16:35:56.948756: rig_get_vfo called
2020-05-25:16:35:56.948788: elapsed_ms: start = 0,0
2020-05-25:16:35:56.948812: rig_get_vfo: cache check age=100ms
2020-05-25:16:35:56.948821: rig_get_vfo: cache miss age=100ms
2020-05-25:16:35:56.968886: dummy_get_vfo called: VFOA
2020-05-25:16:35:56.968917: elapsed_ms: start = 0,0
2020-05-25:16:35:56.968930: elapsed_ms: after gettime, start = 
1590424556,968927000
2020-05-25:16:35:56.968953: rig_set_parm called
2020-05-25:16:35:56.968964: rig_has_set_parm called
2020-05-25:16:35:56.968980: rig_setting2idx called
2020-05-25:16:35:56.968992: rig_strparm called
2020-05-25:16:35:56.969009: rig_strparm called
2020-05-25:16:35:56.969018: dummy_set_parm called: SCREENSAVER 0
Opened rig model 1, 'Dummy'
2020-05-25:16:35:56.969152: Backend version: 20200503.0, Status: Stable
2020-05-25:16:35:56.969176: rigctl_parse: called, interactive=0
2020-05-25:16:35:56.969204: rigctl_parse: debug1
2020-05-25:16:35:56.969217: rigctl_parse: debug5
2020-05-25:16:35:56.969228: rigctl_parse: debug10
2020-05-25:16:35:56.969244: rigctl_parse: vfo_mode=0
2020-05-25:16:35:56.969266: rig_get_ptt called
2020-05-25:16:35:56.969320: elapsed_ms: start = 0,0
2020-05-25:16:35:56.969339: rig_get_ptt: cache check age=100ms
2020-05-25:16:35:56.969357: rig_get_ptt: cache miss age=100ms
2020-05-25:16:35:56.991473: dummy_get_ptt called
2020-05-25:16:35:56.991570: elapsed_ms: start = 0,0
2020-05-25:16:35:56.991630: elapsed_ms: after gettime, start = 
1590424556,991627000
0
2020-05-25:16:35:56.991650: rigctl_parse: retcode=0
2020-05-25:16:35:56.991668: rigctl_parse: called, interactive=0
2020-05-25:16:35:56.991723: rigctl_parse: debug1
2020-05-25:16:35:56.991738: rigctl_parse: debug3
2020-05-25:16:35:56.991754: rigctl_parse: debug5
2020-05-25:16:35:56.991775: rigctl_parse: debug10
2020-05-25:16:35:56.991785: rigctl_parse: vfo_mode=0
2020-05-25:16:35:57.996817: rigctl_parse: retcode=0
2020-05-25:16:35:57.996849: rigctl_parse: called, interactive=0
2020-05-25:16:35:57.996856: rigctl_parse: debug1
2020-05-25:16:35:57.996861: rigctl_parse: debug5
2020-05-25:16:35:57.996866: rigctl_parse: debug10
2020-05-25:16:35:57.996871: rigctl_parse: vfo_mode=0
2020-05-25:16:35:57.996878: rig_get_ptt called
2020-05-25:16:35:57.996884: elapsed_ms: start = 1590424556,991627000
2020-05-25:16:35:57.996893: elapsed_ms: elapsed_secs=1005.26
2020-05-25:16:35:57.996900: rig_get_ptt: cache check age=1005ms
2020-05-25:16:35:57.996905: rig_get_ptt: cache miss age=1005ms
2020-05-25:16:35:58.016952: dummy_get_ptt called
2020-05-25:16:35:58.016982: elapsed_ms: start = 0,0
2020-05-25:16:35:58.016992: elapsed_ms: after gettime, start = 
1590424558,1699
0
2020-05-25:16:35:58.017007: rigctl_parse: retcode=0
2020-05-25:16:35:58.017016: rigctl_parse: called, interactive=0
2020-05-25:16:35:58.017027: rigctl_parse: debug1
2020-05-25:16:35:58.017036: rigctl_parse: debug3
2020-05-25:16:35:58.017044: rigctl_parse: debug5
2020-05-25:16:35:58.017052: rigctl_parse: debug10
2020-05-25:16:35:58.017061: rigctl_parse: vfo_mode=0
2020-05-25:16:35:59.021154: rigctl_parse: retcode=0
2020-05-25:16:35:59.021194: rigctl_parse: called, interactive=0
2020-05-25:16:35:59.021212: rigctl_parse: debug1
2020-05-25:16:35:59.021226: rigctl_parse: debug5

Re: [wsjt-devel] rc2 UI

[Joe Taylor]

Hi Jim,

On 5/25/2020 3:04 AM, Jim Brown K9YC wrote:

Thanks VERY much for this one:
"Hold Tx frequency no longer cleared when switching between modes."

We're halfway there -- TX frequency defaults to 1500 Hz when I've 
returned from MSK144 to FT8. Is it possible to remember prior setting of 
TX frequency?


As a matter of policy the WSJT-X user interface does not "remember" 
optional user settings after switches between modes.  If you want total 
recall of your mode settings, use a Configuration.



I think the goalpost markers are improved, but I'm not colorblind. :)


-- 73, Joe, K1JT


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 does not work with Icom-IC7300 when using rigctld-wsjtx

[Kari]

FWIW, I'm getting the same error in another computer with another rig ( 
IC-703 ) as well.


Here's the trace:

~/ham/hamlib/hamlib-prefix_20200525/bin$ ./rigctld -m 3055 -r 
/dev/ttyUSB0 -s 19200 -P RTS -v

main: #1 vfo_mode=0
Recommend using --vfo switch for rigctld if client supports it
rigctl and netrigctl will automatically detect vfo mode
rigctld, Hamlib 4.0~git
Report bugs to 

rig_init called
initrigs4_icom: _init called
rig_register called
rig_register: rig_register (3055)
rig_register called
rig_register: rig_register (3009)
rig_register called
rig_register: rig_register (3010)
rig_register called
rig_register: rig_register (3011)
rig_register called
rig_register: rig_register (3013)
rig_register called
rig_register: rig_register (3014)
rig_register called
rig_register: rig_register (3015)
rig_register called
rig_register: rig_register (3019)
rig_register called
rig_register: rig_register (3020)
rig_register called
rig_register: rig_register (3021)
rig_register called
rig_register: rig_register (3022)
rig_register called
rig_register: rig_register (3067)
rig_register called
rig_register: rig_register (3023)
rig_register called
rig_register: rig_register (3046)
rig_register called
rig_register: rig_register (3024)
rig_register called
rig_register: rig_register (3028)
rig_register called
rig_register: rig_register (3030)
rig_register called
rig_register: rig_register (3026)
rig_register called
rig_register: rig_register (3027)
rig_register called
rig_register: rig_register (3047)
rig_register called
rig_register: rig_register (3057)
rig_register called
rig_register: rig_register (3063)
rig_register called
rig_register: rig_register (3029)
rig_register called
rig_register: rig_register (3062)
rig_register called
rig_register: rig_register (3045)
rig_register called
rig_register: rig_register (3056)
rig_register called
rig_register: rig_register (3075)
rig_register called
rig_register: rig_register (3060)
rig_register called
rig_register: rig_register (3070)
rig_register called
rig_register: rig_register (3061)
rig_register called
rig_register: rig_register (3073)
rig_register called
rig_register: rig_register (3078)
rig_register called
rig_register: rig_register (3031)
rig_register called
rig_register: rig_register (3012)
rig_register called
rig_register: rig_register (3016)
rig_register called
rig_register: rig_register (3032)
rig_register called
rig_register: rig_register (3034)
rig_register called
rig_register: rig_register (3044)
rig_register called
rig_register: rig_register (3068)
rig_register called
rig_register: rig_register (3035)
rig_register called
rig_register: rig_register (3081)
rig_register called
rig_register: rig_register (3069)
rig_register called
rig_register: rig_register (3077)
rig_register called
rig_register: rig_register (3036)
rig_register called
rig_register: rig_register (3058)
rig_register called
rig_register: rig_register (3080)
rig_register called
rig_register: rig_register (3037)
rig_register called
rig_register: rig_register (3038)
rig_register called
rig_register: rig_register (3039)
rig_register called
rig_register: rig_register (3040)
rig_register called
rig_register: rig_register (3041)
rig_register called
rig_register: rig_register (3042)
rig_register called
rig_register: rig_register (3079)
rig_register called
rig_register: rig_register (3043)
rig_register called
rig_register: rig_register (3066)
rig_register called
rig_register: rig_register (3003)
rig_register called
rig_register: rig_register (3004)
rig_register called
rig_register: rig_register (3006)
rig_register called
rig_register: rig_register (3007)
rig_register called
rig_register: rig_register (3002)
rig_register called
rig_register: rig_register (3052)
rig_register called
rig_register: rig_register (3053)
rig_register called
rig_register: rig_register (3051)
rig_register called
rig_register: rig_register (3064)
rig_register called
rig_register: rig_register (3065)
rig_register called
rig_register: rig_register (3054)
rig_register called
rig_register: rig_register (3083)
rig_register called
rig_register: rig_register (3084)
rig_register called
rig_register: rig_register (3082)
rig_register called
rig_register: rig_register (3071)
rig_register called
rig_register: rig_register (3072)
rig_register called
rig_register: rig_register (3074)
rig_register called
rig_register: rig_register (3076)
icom_init called
icom_init: done
rig_open called
port_open called
serial_open called
serial_open: OPEN before
serial_open: OPEN after
serial_open: serial_setup before
serial_setup called
serial_setup: tcgetattr
serial_setup: cfmakeraw
serial_setup: cfsetispeed
serial_setup: cfsetospeed
serial_setup: tcsetattr TCSANOW
serial_open: serial_setup after
serial_open: serial_flush before
serial_flush called
serial_flush: tcflush
serial_open: serial_flush before
ser_set_rts called
ser_set_rts: RTS=0
icom_rig_open 724
icom_rig_open: IC-703 v20200519.0
icom_get_usb_echo_off called
icom_get_usb_echo_off: retry temp set to 

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 - 14.071 an unacceptable choice for FT8

[Joe Taylor]

Hi Grant,

Thanks for sharing your concerns about band plans.  Of course we are 
aware that almost any newly suggested frequency may step on some toes. 
As stated in the Release Notes, our currently selected trial frequencies 
follow guidelines being considered by IARU, ARRL, and other amateur 
radio societies.  Some eventual reorganization may need to take place... 
Or perhaps not.  We shall see.


We try to follow world-wide community wishes, not to dictate them.

-- 73, Joe, K1JT

On 5/25/2020 9:25 AM, Grant VK5GR wrote:

Joe,

The choice of 20m extension frequency is going to bring FT8 into direct
conflict with many many PSK and Olivia operators. The choice of 14.071 is
about the worst choice that could have been made.

I know there are a few who still like JT65 on 20m - but the number of users
many evenings on PSK and Olivia on 20m far outweighs the few JT65 operators
(and that is what I can see on air in VK - how busy it is in Europe is hard
to tell from here because only the big stations make it down here).

So, in the case of 20m it would be strongly and firmly recommended that the
extension channel be 14.077, cannibalising the old JT65 segment. If
anything, replan JT65 onto 14.073-14.074. It is more likely to share than
FT8 will with the other HF digital modes given how little use it gets.

In the US you may cop similar criticism for 7071, but at least that is a US
domestic concern only with most global PSK/Olivia occurring around
7040-7045kHz.

Please reconsider

Regards,
Grant VK5GR





-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu]
Sent: Monday, 25 May 2020 7:06 AM
To: WSJT software development
Subject: [wsjt-devel] WSJT-X 2.2.0-rc2

The second candidate release for WSJT-X 2.2.0, WSJT-X 2.2.0-rc2, is now
available for download and use for beta testing.  Nearly all of the bugs
reported in the RC1 release have been fixed.

Be sure to read the Release Notes,
https://physics.princeton.edu/pulsar/k1jt/Release_Notes.txt ,
which include a detailed list of program changes since the RC1 release.

Upgrading from earlier versions of WSJT-X should be seamless.  There is
no need to uninstall a previous version or move any files.  You might
want to install to a different directory from your WSJT-X 2.1.2
installation.

Links to installation packages for Windows, Linux, and Macintosh are
available here:
http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
Scroll down to find "Candidate release:  WSJT-X 2.2.0-rc2".

You can also download the packages from our SourceForge site:
https://sourceforge.net/projects/wsjt/files/
It may take a short time for the SourceForge site to be updated.

WSJT-X is licensed under the terms of Version 3 of the GNU General
Public License (GPL).  Development of this software is a cooperative
project to which many amateur radio operators have contributed.  If you
use our code, please have the courtesy to let us know about it.  If you
find bugs or make improvements to the code, please report them to us in
a timely fashion.

We hope you will enjoy using this beta release of WSJT-X 2.2.0.  One of
your responsibilities as a beta tester is to report bugs by following
instructions found here in the User Guide:
http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.2.0-rc1.
html#_bug_reports

   -- 73 from Joe, K1JT, Steve, K9AN, and Bill, G4WJS,
   for the entire WSJT Development Group


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] trouble keying PTT with com port RTS or DTS

[Ray Golley]

Gentlemen.
Let me begin by thanking the team for all the enjoyment you've brought into the 
amateur radio hobby.

I'm currently running WSJT-X v2.1.2  and keying my sequencer with an 
opto-coupled transistor connected
to PTT com1 RTS. I'm using a Windows 7 pro operating system and a flex 5000 
radio which also serves as 
my IF radio on the upper bands thru 10ghz. I've used this system for at least 
three years without a failure since
I have LNAs on all ten bands. Last week I downloaded and installed WSJT-X 
v2.2.0-rc1 and discovered it wouldn't 
consistently key the PTT via the same com port settings. So, I un-installed the 
rc1 and went back to v2.1.2 and 
everything worked normally. 
I discussed my problem with Joe Taylor via email and he replied telling me they 
were aware of the com port keying 
problem and it would be addressed in the next release candidate. Yesterday I 
downloaded WSJT-X v2.2.0-rc2 and 
after testing it I discovered the same problem. I went to:   
https://physics.princeton.edu/pulsar/K1JT/Release_Notes.txt
and read the notes but didn't see anything regarding this problem. 
Perhaps I'm doing something wrong when I download and install the program so 
I'll continue to come up with a fix at
my end. I'm open to any and all suggestions that can help me get around this 
issue. I've see how well the new version decodes and look forward to running it 
here.

Best 73 de,
N3RG, Ray 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 on macOS defaults to Catalan

[Bill Somerville]

Hi Ryan,

thanks for that clarification. I'm not sure why your system has so many 
languages enabled. The issue is a WSJT-X defect anyway, it is trying to 
do something clever to make life easier for potential translators and 
the code isn't quite right. It will be sorted out for the next release.


Thanks for the issue report.

73
Bill
G4WJS.

On 25/05/2020 14:33, Ryan Woolley wrote:

Hi Bill,

Yes.  Although I haven't specifically installed any additional 
languages, I see 33 languages listed in System Preferences -> Language 
and Region including Catalan.  English is the only one selected as 
primary.  It's possible these were installed by the Xcode installer -- 
that is the only thing I can think of that's remarkable about this 
machine.  I checked two other Macs without Xcode, and those have only 
English listed in Languages and Regions.  On a second Mac with Xcode, 
I installed rc2 and saw the same behavior (default to Catalan).  After 
removing Catalan as an option in Language and Region (by selecting it 
and hitting "-"), then re-launching rc2, it returned to English. 
 Re-adding Catalan caused rc2 to return to using Catalan.  So, the 
behavior I'm observing seems to be: when Catalan support is installed 
in the OS, rc2 defaults to Catalan.


73,
Ryan KC7RW


*From:* Bill Somerville 
*Sent:* Monday, May 25, 2020 6:26 AM
*To:* wsjt-devel@lists.sourceforge.net 
*Subject:* Re: [wsjt-devel] WSJT-X 2.2.0-rc2 on macOS defaults to Catalan
On 25/05/2020 04:07, Ryan Woolley wrote:
After installing rc2 over rc1 on 10.15.4, the language defaults to 
Catalan.  Launching from Terminal with -l en or -l en-us has no 
effect, and System Preferences -> Language and Region -> Apps -> 
wsjtx reports "wsjtx doesn't support additional languages", so no 
apparent way to shift back to English.


Thanks,
Ryan KC7RW


Hi Ryan,

do you have the Catalan language pack installed, even if it is not the 
selected primary language?


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 does not work with Icom-IC7300 when using rigctld-wsjtx

[Kari]

On 25.5.2020 16.01, Kari wrote:

Hi Michael,
On 25.5.2020 15.18, Black Michael via wsjt-devel wrote:

Does it work when WSJT-X is connected to the rig instead?

Yes, direct connection works fine.


... it does indeed work, but these messages show in the terminal
whindow where WSJT-X is started:

Hamlib: icom_set_vfo: unsupported VFO None
Hamlib: rig_set_vfo: set_vfo None failed with 'Invalid parameter'
Hamlib: icom_get_freq: set_vfo failed? retval=Invalid parameter
Hamlib: icom_get_freq: unknown VFO?  VFO=None
Hamlib: icom_set_vfo: unsupported VFO None
Hamlib: rig_set_vfo: set_vfo None failed with 'Invalid parameter'
Hamlib: icom_get_freq: set_vfo failed? retval=Invalid parameter
Hamlib: icom_get_freq: unknown VFO?  VFO=None


I also compiled the latest (20200525) Git snapshot of hamlib, but it gives the 
same
error, trace below:

karza@carole:~/ham/hamlib/hamlib-prefix_20200525/bin$ ./rigctld -m 3073 -r 
/dev/ic7300 -s 19200 -v
main: #1 vfo_mode=0
Recommend using --vfo switch for rigctld if client supports it
rigctl and netrigctl will automatically detect vfo mode
rigctld, Hamlib 4.0~git
Report bugs to 

rig_init called
initrigs4_icom: _init called
rig_register called
rig_register: rig_register (3055)
rig_register called
rig_register: rig_register (3009)
rig_register called
rig_register: rig_register (3010)
rig_register called
rig_register: rig_register (3011)
rig_register called
rig_register: rig_register (3013)
rig_register called
rig_register: rig_register (3014)
rig_register called
rig_register: rig_register (3015)
rig_register called
rig_register: rig_register (3019)
rig_register called
rig_register: rig_register (3020)
rig_register called
rig_register: rig_register (3021)
rig_register called
rig_register: rig_register (3022)
rig_register called
rig_register: rig_register (3067)
rig_register called
rig_register: rig_register (3023)
rig_register called
rig_register: rig_register (3046)
rig_register called
rig_register: rig_register (3024)
rig_register called
rig_register: rig_register (3028)
rig_register called
rig_register: rig_register (3030)
rig_register called
rig_register: rig_register (3026)
rig_register called
rig_register: rig_register (3027)
rig_register called
rig_register: rig_register (3047)
rig_register called
rig_register: rig_register (3057)
rig_register called
rig_register: rig_register (3063)
rig_register called
rig_register: rig_register (3029)
rig_register called
rig_register: rig_register (3062)
rig_register called
rig_register: rig_register (3045)
rig_register called
rig_register: rig_register (3056)
rig_register called
rig_register: rig_register (3075)
rig_register called
rig_register: rig_register (3060)
rig_register called
rig_register: rig_register (3070)
rig_register called
rig_register: rig_register (3061)
rig_register called
rig_register: rig_register (3073)
rig_register called
rig_register: rig_register (3078)
rig_register called
rig_register: rig_register (3031)
rig_register called
rig_register: rig_register (3012)
rig_register called
rig_register: rig_register (3016)
rig_register called
rig_register: rig_register (3032)
rig_register called
rig_register: rig_register (3034)
rig_register called
rig_register: rig_register (3044)
rig_register called
rig_register: rig_register (3068)
rig_register called
rig_register: rig_register (3035)
rig_register called
rig_register: rig_register (3081)
rig_register called
rig_register: rig_register (3069)
rig_register called
rig_register: rig_register (3077)
rig_register called
rig_register: rig_register (3036)
rig_register called
rig_register: rig_register (3058)
rig_register called
rig_register: rig_register (3080)
rig_register called
rig_register: rig_register (3037)
rig_register called
rig_register: rig_register (3038)
rig_register called
rig_register: rig_register (3039)
rig_register called
rig_register: rig_register (3040)
rig_register called
rig_register: rig_register (3041)
rig_register called
rig_register: rig_register (3042)
rig_register called
rig_register: rig_register (3079)
rig_register called
rig_register: rig_register (3043)
rig_register called
rig_register: rig_register (3066)
rig_register called
rig_register: rig_register (3003)
rig_register called
rig_register: rig_register (3004)
rig_register called
rig_register: rig_register (3006)
rig_register called
rig_register: rig_register (3007)
rig_register called
rig_register: rig_register (3002)
rig_register called
rig_register: rig_register (3052)
rig_register called
rig_register: rig_register (3053)
rig_register called
rig_register: rig_register (3051)
rig_register called
rig_register: rig_register (3064)
rig_register called
rig_register: rig_register (3065)
rig_register called
rig_register: rig_register (3054)
rig_register called
rig_register: rig_register (3083)
rig_register called
rig_register: rig_register (3084)
rig_register called
rig_register: rig_register (3082)
rig_register called
rig_register: rig_register (3071)
rig_register called
rig_register

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 on macOS defaults to Catalan

[Ryan Woolley]

Hi Bill,

Yes.  Although I haven't specifically installed any additional languages, I see 
33 languages listed in System Preferences -> Language and Region including 
Catalan.  English is the only one selected as primary.  It's possible these 
were installed by the Xcode installer -- that is the only thing I can think of 
that's remarkable about this machine.  I checked two other Macs without Xcode, 
and those have only English listed in Languages and Regions.  On a second Mac 
with Xcode, I installed rc2 and saw the same behavior (default to Catalan).  
After removing Catalan as an option in Language and Region (by selecting it and 
hitting "-"), then re-launching rc2, it returned to English.  Re-adding Catalan 
caused rc2 to return to using Catalan.  So, the behavior I'm observing seems to 
be: when Catalan support is installed in the OS, rc2 defaults to Catalan.

73,
Ryan KC7RW


From: Bill Somerville 
Sent: Monday, May 25, 2020 6:26 AM
To: wsjt-devel@lists.sourceforge.net 
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc2 on macOS defaults to Catalan

On 25/05/2020 04:07, Ryan Woolley wrote:
After installing rc2 over rc1 on 10.15.4, the language defaults to Catalan.  
Launching from Terminal with -l en or -l en-us has no effect, and System 
Preferences -> Language and Region -> Apps -> wsjtx reports "wsjtx doesn't 
support additional languages", so no apparent way to shift back to English.

Thanks,
Ryan KC7RW


Hi Ryan,

do you have the Catalan language pack installed, even if it is not the selected 
primary language?

73
Bill
G4WJS.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

[Bill Somerville]

Hi Uwe,

RRR, understood. I just wanted to show that as a general concept hiding 
decodes may not be a good strategy unless there was some underlying 
information to base that on. For example we could choose to hide low 
confidence decodes altogether but that would be a regression in 
functionality IMHO because they can often be the difference between 
completing a QSO and not. Who are we to say that a decode discovered 
with AP and low confidence is not genuine and possible critical to a 
user in a QSO who was expecting such a decode, or perhaps even a wanted 
DXCC that is worth joining the contest just to get a QSO in the log.


73
Bill
G4WJS.

On 25/05/2020 14:14, DG2YCB, Uwe wrote:


Hi Bill,

Agreed. Just one clarification: I didn’t want to let all /R decoded be 
discarded unless in a special operation activity mode, ONLY THE AP 
DECODES OF /R CALLSIGNS, so that true /R callsigns are still displayed 
when in normal FT8 mode. The idea is to filter out some more false 
decodes in a clever way.


73 de Uwe, DG2YCB

*Von:*Bill Somerville [mailto:g4...@classdesign.com]
*Gesendet:* Montag, 25. Mai 2020 14:23
*An:* wsjt-devel@lists.sourceforge.net
*Betreff:* Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

Hi Uwe,

that is a possible option but we must be careful. For example a user 
being deprived of sight of messages that happened to contain '/R' 
suffixes may misunderstand that they should be enabling the relevant 
contest mode. Also the same argument would apply to '/P' suffixes, 
would you be happy to have all messages from '/P' stations hidden? As 
I said to Steve, we must be careful not to program in use of 
information not received on air, after all we are dealing with radio 
communications - not sanitizing decoded messages based on outside 
information. IMHO it is better for the operator to understand some of 
the underlying technology and to apply informed decision making to 
comprehend what is displayed. After all the consequences of trying to 
communicate with an invalid station whose callsign was printed in a 
false decode is not serious, maybe some embarrassment and a little 
wasted time.


73
Bill
G4WJS.

On 25/05/2020 13:10, DG2YCB, Uwe wrote:

Bill,

Just an idea: Wouldn't it make sense to discard all the /R ?a2 decodes

unless a special operation mode is set?. My observation also with the prior

WSJT-X versions was, that if there are false decodes, most often they are /R

decodes. Couldn't that significantly reduce rate of false decodes without

reducing the sensitivity? And when only the AP decodes were discarded, a

true /R call would still be decoded. Couldn't that be a solution?

73 de Uwe, DG2YCB



German Amateur Radio Station DG2YCB

Dr. Uwe Risse

eMail:dg2...@gmx.de  

Info:www.qrz.com/db/DG2YCB  

-Ursprüngliche Nachricht-

Von: Bill Somerville [mailto:g4...@classdesign.com]

Gesendet: Montag, 25. Mai 2020 13:43

An:wsjt-devel@lists.sourceforge.net  


Betreff: Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

On 25/05/2020 12:04, Stephen VK3SIR wrote:

Folks,

I just picked  up a false decode that can be replicated when
played back

through WSJT-X 2.2.0 rc2:

104945 -23 -0.5 1623 ~  VK3VM FH9ZZV/R ND49 ? a2

Research suggests this is not a genuine call and is definitely
a false

decode (i.e. ND49 = middle of Southern Ocean). I have noted that many false

decodes in the previous version are reported with /R !

As one cannot send attachments via email I'll reforward this
email plus

the .wav file directly to Bill and Joe for further analysis.

73

Steve I

VK3VM / VK3SIR

Steve,

AP decodes flagged as low confidence ('?' marker) should always be

considered dubious, and unless there is other evidence that the decode

is genuine it should be ignored. Without using knowledge not obtained on

air it is virtually impossible for the decoder to eliminate such false

decodes without damaging the capabilities of the AP decoding mechanism.

AP decodes of the 'a2' category are only detected shortly after a CQ

call IIRC.

The FT8, FT4, and MSK144 decoders give virtually every possible message

equal weight. The message types that allow a '/P' or '/R' (grid rover

station) prefix to a standard callsign have a 50% probability per

possible callsign that random data will unpack as one of those prefixes,

so they will be far more common in false decodes than in genuine

messages where the expected likelihood is far lower.

73

Bill

G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 - 14.071 an unacceptable choice for FT8

[Grant VK5GR]

Joe,

The choice of 20m extension frequency is going to bring FT8 into direct
conflict with many many PSK and Olivia operators. The choice of 14.071 is
about the worst choice that could have been made.

I know there are a few who still like JT65 on 20m - but the number of users
many evenings on PSK and Olivia on 20m far outweighs the few JT65 operators
(and that is what I can see on air in VK - how busy it is in Europe is hard
to tell from here because only the big stations make it down here). 

So, in the case of 20m it would be strongly and firmly recommended that the
extension channel be 14.077, cannibalising the old JT65 segment. If
anything, replan JT65 onto 14.073-14.074. It is more likely to share than
FT8 will with the other HF digital modes given how little use it gets.

In the US you may cop similar criticism for 7071, but at least that is a US
domestic concern only with most global PSK/Olivia occurring around
7040-7045kHz.

Please reconsider

Regards,
Grant VK5GR





-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: Monday, 25 May 2020 7:06 AM
To: WSJT software development
Subject: [wsjt-devel] WSJT-X 2.2.0-rc2

The second candidate release for WSJT-X 2.2.0, WSJT-X 2.2.0-rc2, is now 
available for download and use for beta testing.  Nearly all of the bugs 
reported in the RC1 release have been fixed.

Be sure to read the Release Notes,
https://physics.princeton.edu/pulsar/k1jt/Release_Notes.txt ,
which include a detailed list of program changes since the RC1 release.

Upgrading from earlier versions of WSJT-X should be seamless.  There is 
no need to uninstall a previous version or move any files.  You might 
want to install to a different directory from your WSJT-X 2.1.2 
installation.

Links to installation packages for Windows, Linux, and Macintosh are 
available here:
http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
Scroll down to find "Candidate release:  WSJT-X 2.2.0-rc2".

You can also download the packages from our SourceForge site:
https://sourceforge.net/projects/wsjt/files/
It may take a short time for the SourceForge site to be updated.

WSJT-X is licensed under the terms of Version 3 of the GNU General 
Public License (GPL).  Development of this software is a cooperative 
project to which many amateur radio operators have contributed.  If you 
use our code, please have the courtesy to let us know about it.  If you 
find bugs or make improvements to the code, please report them to us in 
a timely fashion.

We hope you will enjoy using this beta release of WSJT-X 2.2.0.  One of 
your responsibilities as a beta tester is to report bugs by following 
instructions found here in the User Guide:
http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.2.0-rc1.
html#_bug_reports

  -- 73 from Joe, K1JT, Steve, K9AN, and Bill, G4WJS,
  for the entire WSJT Development Group


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

[DG2YCB, Uwe]

Hi Bill,

 

Agreed. Just one clarification: I didn’t want to let all /R decoded be 
discarded unless in a special operation activity mode, ONLY THE AP DECODES OF 
/R CALLSIGNS, so that true /R callsigns are still displayed when in normal FT8 
mode. The idea is to filter out some more false decodes in a clever way.

 

73 de Uwe, DG2YCB 

 

Von: Bill Somerville [mailto:g4...@classdesign.com] 
Gesendet: Montag, 25. Mai 2020 14:23
An: wsjt-devel@lists.sourceforge.net
Betreff: Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

 

Hi Uwe,

 

that is a possible option but we must be careful. For example a user being 
deprived of sight of messages that happened to contain '/R' suffixes may 
misunderstand that they should be enabling the relevant contest mode. Also the 
same argument would apply to '/P' suffixes, would you be happy to have all 
messages from '/P' stations hidden? As I said to Steve, we must be careful not 
to program in use of information not received on air, after all we are dealing 
with radio communications - not sanitizing decoded messages based on outside 
information. IMHO it is better for the operator to understand some of the 
underlying technology and to apply informed decision making to comprehend what 
is displayed. After all the consequences of trying to communicate with an 
invalid station whose callsign was printed in a false decode is not serious, 
maybe some embarrassment and a little wasted time.

 

73
Bill
G4WJS.

 

On 25/05/2020 13:10, DG2YCB, Uwe wrote:

Bill,
Just an idea: Wouldn't it make sense to discard all the /R ?a2 decodes
unless a special operation mode is set?. My observation also with the prior
WSJT-X versions was, that if there are false decodes, most often they are /R
decodes. Couldn't that significantly reduce rate of false decodes without
reducing the sensitivity? And when only the AP decodes were discarded, a
true /R call would still be decoded. Couldn't that be a solution? 
 
73 de Uwe, DG2YCB

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB
 
-Ursprüngliche Nachricht-
Von: Bill Somerville [mailto:g4...@classdesign.com] 
Gesendet: Montag, 25. Mai 2020 13:43
An: wsjt-devel@lists.sourceforge.net
Betreff: Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode
 
On 25/05/2020 12:04, Stephen VK3SIR wrote:

Folks,
 
I just picked  up a false decode that can be replicated when played back

through WSJT-X 2.2.0 rc2:

104945 -23 -0.5 1623 ~  VK3VM FH9ZZV/R ND49 ? a2
 
Research suggests this is not a genuine call and is definitely a false

decode (i.e. ND49 = middle of Southern Ocean). I have noted that many false
decodes in the previous version are reported with /R !

As one cannot send attachments via email I'll reforward this email plus

the .wav file directly to Bill and Joe for further analysis.

73
 
Steve I
VK3VM / VK3SIR

Steve,
 
AP decodes flagged as low confidence ('?' marker) should always be 
considered dubious, and unless there is other evidence that the decode 
is genuine it should be ignored. Without using knowledge not obtained on 
air it is virtually impossible for the decoder to eliminate such false 
decodes without damaging the capabilities of the AP decoding mechanism. 
AP decodes of the 'a2' category are only detected shortly after a CQ 
call IIRC.
 
The FT8, FT4, and MSK144 decoders give virtually every possible message 
equal weight. The message types that allow a '/P' or '/R' (grid rover 
station) prefix to a standard callsign have a 50% probability per 
possible callsign that random data will unpack as one of those prefixes, 
so they will be far more common in false decodes than in genuine 
messages where the expected likelihood is far lower.
 
73
Bill
G4WJS.

 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 does not work with Icom-IC7300 when using rigctld-wsjtx

[Kari]

Hi Michael,

On 25.5.2020 15.18, Black Michael via wsjt-devel wrote:

Does it work when WSJT-X is connected to the rig instead?


Yes, direct connection works fine.

'Kari

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

[Stephen VK3SIR]

Bill,

You are completely preaching to the informed here with knowledge of what, how, 
why and even some of the maths involved ☺ But thanks again.

The issue is that the software picks one of these out and then you respond, 
then abort or manually over-ride to the Tx6.

There is a clear pattern that both myself and others in backchannel comms are 
observing with the /R suffix and how that seems to be almost universally thrown 
up in the process. I cannot explain that as this “consistency” makes no sense !

Hey if we don’t report the good, the bad and the unpredictable back how can we 
get better software?

[ Back to working on some of the Mac-compile issues. For the record on that I 
am observing unpredictable behaviours through an old Mac with Ubuntu 20.04 LTE 
on it as well ! ]

73 (and I note subsequent comms but are unseen !).

Steve I
VK3VM / VK3SIR

From: Bill Somerville 
Sent: Monday, 25 May 2020 10:09 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

Steve,

please don't equate AP assisted decodes with low levels (I prefer the term weak 
signals). AP decoding techniques, like the other FEC mechanisms, allow missing 
information to be recovered. Weak signals are not the only cause of missing 
information, truncated or otherwise interrupted signals are just as likely to 
require FEC, and AP if enabled, to successfully decode them. As I said, it is 
virtually impossible to eliminate this sort of false decode without 
compromising the purpose of AP decoding, unless information not received on air 
is used to make the decisions. That's the operator's job and not something that 
we feel WSJT-X should be attempting.

Yes, examples of false decodes, along with supporting .WAV files, and settings 
necessary to reproduce them, are welcome but unless there is common cause that 
can be detected by the application, like unrealistically low SNR values 
combined with marginal sync detection and maximum FEC required, there's little 
that can be done.

73
Bill
G4WJS.

On 25/05/2020 12:54, Stephen VK3SIR wrote:

Bill,



Fully aware of that :-) Yet you have asked for reports when these occur. I am 
in a far-away land to many where low-level, low confidence signals are the norm 
and not the exception. Around 40% of the 40 contacts made today with the new 
version have been > -18dB. Without the reduced confidence in-use I'd be in 
constant RR/73 loops !



In in the last few minutes I have another  again with a /R ! You want this 
one was well?



114715 -18  0.3  825 ~  VK3VM PA6UES/R R BM44   ? a2



I'll send that one as well as its now 2 in 60-odd minutes of operation.



73



Steve I

VK3VM / VK3SIR



-Original Message-

From: Bill Somerville 

Sent: Monday, 25 May 2020 9:43 PM

To: wsjt-devel@lists.sourceforge.net

Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode



On 25/05/2020 12:04, Stephen VK3SIR wrote:

Folks,



I just picked  up a false decode that can be replicated when played back 
through WSJT-X 2.2.0 rc2:



104945 -23 -0.5 1623 ~  VK3VM FH9ZZV/R ND49 ? a2



Research suggests this is not a genuine call and is definitely a false decode 
(i.e. ND49 = middle of Southern Ocean). I have noted that many false decodes in 
the previous version are reported with /R !



As one cannot send attachments via email I'll reforward this email plus the 
.wav file directly to Bill and Joe for further analysis.



73



Steve I

VK3VM / VK3SIR

Steve,



AP decodes flagged as low confidence ('?' marker) should always be considered 
dubious, and unless there is other evidence that the decode is genuine it 
should be ignored. Without using knowledge not obtained on air it is virtually 
impossible for the decoder to eliminate such false decodes without damaging the 
capabilities of the AP decoding mechanism.

AP decodes of the 'a2' category are only detected shortly after a CQ call IIRC.



The FT8, FT4, and MSK144 decoders give virtually every possible message equal 
weight. The message types that allow a '/P' or '/R' (grid rover

station) prefix to a standard callsign have a 50% probability per possible 
callsign that random data will unpack as one of those prefixes, so they will be 
far more common in false decodes than in genuine messages where the expected 
likelihood is far lower.



73

Bill

G4WJS.




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

[Bill Somerville]

Hi Uwe,

that is a possible option but we must be careful. For example a user 
being deprived of sight of messages that happened to contain '/R' 
suffixes may misunderstand that they should be enabling the relevant 
contest mode. Also the same argument would apply to '/P' suffixes, would 
you be happy to have all messages from '/P' stations hidden? As I said 
to Steve, we must be careful not to program in use of information not 
received on air, after all we are dealing with radio communications - 
not sanitizing decoded messages based on outside information. IMHO it is 
better for the operator to understand some of the underlying technology 
and to apply informed decision making to comprehend what is displayed. 
After all the consequences of trying to communicate with an invalid 
station whose callsign was printed in a false decode is not serious, 
maybe some embarrassment and a little wasted time.


73
Bill
G4WJS.

On 25/05/2020 13:10, DG2YCB, Uwe wrote:

Bill,
Just an idea: Wouldn't it make sense to discard all the /R ?a2 decodes
unless a special operation mode is set?. My observation also with the prior
WSJT-X versions was, that if there are false decodes, most often they are /R
decodes. Couldn't that significantly reduce rate of false decodes without
reducing the sensitivity? And when only the AP decodes were discarded, a
true /R call would still be decoded. Couldn't that be a solution?

73 de Uwe, DG2YCB

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail:dg2...@gmx.de
Info:www.qrz.com/db/DG2YCB

-Ursprüngliche Nachricht-
Von: Bill Somerville [mailto:g4...@classdesign.com]
Gesendet: Montag, 25. Mai 2020 13:43
An:wsjt-devel@lists.sourceforge.net
Betreff: Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

On 25/05/2020 12:04, Stephen VK3SIR wrote:

Folks,

I just picked  up a false decode that can be replicated when played back

through WSJT-X 2.2.0 rc2:

104945 -23 -0.5 1623 ~  VK3VM FH9ZZV/R ND49 ? a2

Research suggests this is not a genuine call and is definitely a false

decode (i.e. ND49 = middle of Southern Ocean). I have noted that many false
decodes in the previous version are reported with /R !

As one cannot send attachments via email I'll reforward this email plus

the .wav file directly to Bill and Joe for further analysis.

73

Steve I
VK3VM / VK3SIR

Steve,

AP decodes flagged as low confidence ('?' marker) should always be
considered dubious, and unless there is other evidence that the decode
is genuine it should be ignored. Without using knowledge not obtained on
air it is virtually impossible for the decoder to eliminate such false
decodes without damaging the capabilities of the AP decoding mechanism.
AP decodes of the 'a2' category are only detected shortly after a CQ
call IIRC.

The FT8, FT4, and MSK144 decoders give virtually every possible message
equal weight. The message types that allow a '/P' or '/R' (grid rover
station) prefix to a standard callsign have a 50% probability per
possible callsign that random data will unpack as one of those prefixes,
so they will be far more common in false decodes than in genuine
messages where the expected likelihood is far lower.

73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

[DG2YCB, Uwe]

Bill,
Just an idea: Wouldn't it make sense to discard all the /R ?a2 decodes
unless a special operation mode is set?. My observation also with the prior
WSJT-X versions was, that if there are false decodes, most often they are /R
decodes. Couldn't that significantly reduce rate of false decodes without
reducing the sensitivity? And when only the AP decodes were discarded, a
true /R call would still be decoded. Couldn't that be a solution? 

73 de Uwe, DG2YCB

German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB

-Ursprüngliche Nachricht-
Von: Bill Somerville [mailto:g4...@classdesign.com] 
Gesendet: Montag, 25. Mai 2020 13:43
An: wsjt-devel@lists.sourceforge.net
Betreff: Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

On 25/05/2020 12:04, Stephen VK3SIR wrote:
> Folks,
>
> I just picked  up a false decode that can be replicated when played back
through WSJT-X 2.2.0 rc2:
>
> 104945 -23 -0.5 1623 ~  VK3VM FH9ZZV/R ND49 ? a2
>
> Research suggests this is not a genuine call and is definitely a false
decode (i.e. ND49 = middle of Southern Ocean). I have noted that many false
decodes in the previous version are reported with /R !
>
> As one cannot send attachments via email I'll reforward this email plus
the .wav file directly to Bill and Joe for further analysis.
>
> 73
>
> Steve I
> VK3VM / VK3SIR

Steve,

AP decodes flagged as low confidence ('?' marker) should always be 
considered dubious, and unless there is other evidence that the decode 
is genuine it should be ignored. Without using knowledge not obtained on 
air it is virtually impossible for the decoder to eliminate such false 
decodes without damaging the capabilities of the AP decoding mechanism. 
AP decodes of the 'a2' category are only detected shortly after a CQ 
call IIRC.

The FT8, FT4, and MSK144 decoders give virtually every possible message 
equal weight. The message types that allow a '/P' or '/R' (grid rover 
station) prefix to a standard callsign have a 50% probability per 
possible callsign that random data will unpack as one of those prefixes, 
so they will be far more common in false decodes than in genuine 
messages where the expected likelihood is far lower.

73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

[Reino Talarmo]

Hi Steve,
Have you analyzed how many of the low level decodes, say below -18 dB, are
false positives compared to all decodes? That figure will be a nice
educational information. It requires some manual treatment of ALL.TXT file,
but most of the work can be automated.
73, Reino OH3mA

-Original Message-
From: Stephen VK3SIR [mailto:vk3...@hotmail.com] 
Sent: 25. toukokuuta 2020 14:05
To: WSJT software development 
Subject: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

Folks,

I just picked  up a false decode that can be replicated when played back
through WSJT-X 2.2.0 rc2:

104945 -23 -0.5 1623 ~  VK3VM FH9ZZV/R ND49 ? a2

Research suggests this is not a genuine call and is definitely a false
decode (i.e. ND49 = middle of Southern Ocean). I have noted that many false
decodes in the previous version are reported with /R !

As one cannot send attachments via email I'll reforward this email plus the
.wav file directly to Bill and Joe for further analysis.

73

Steve I
VK3VM / VK3SIR


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

[Bill Somerville]

Steve,

please don't equate AP assisted decodes with low levels (I prefer the 
term weak signals). AP decoding techniques, like the other FEC 
mechanisms, allow missing information to be recovered. Weak signals are 
not the only cause of missing information, truncated or otherwise 
interrupted signals are just as likely to require FEC, and AP if 
enabled, to successfully decode them. As I said, it is virtually 
impossible to eliminate this sort of false decode without compromising 
the purpose of AP decoding, unless information not received on air is 
used to make the decisions. That's the operator's job and not something 
that we feel WSJT-X should be attempting.


Yes, examples of false decodes, along with supporting .WAV files, and 
settings necessary to reproduce them, are welcome but unless there is 
common cause that can be detected by the application, like 
unrealistically low SNR values combined with marginal sync detection and 
maximum FEC required, there's little that can be done.


73
Bill
G4WJS.

On 25/05/2020 12:54, Stephen VK3SIR wrote:

Bill,

Fully aware of that:-)  Yet you have asked for reports when these occur. I am in a 
far-away land to many where low-level, low confidence signals are the norm and not 
the exception. Around 40% of the 40 contacts made today with the new version have 
been > -18dB. Without the reduced confidence in-use I'd be in constant RR/73 
loops !

In in the last few minutes I have another  again with a /R ! You want this 
one was well?

114715 -18  0.3  825 ~  VK3VM PA6UES/R R BM44   ? a2

I'll send that one as well as its now 2 in 60-odd minutes of operation.

73

Steve I
VK3VM / VK3SIR

-Original Message-
From: Bill Somerville  
Sent: Monday, 25 May 2020 9:43 PM

To:wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

On 25/05/2020 12:04, Stephen VK3SIR wrote:

Folks,

I just picked  up a false decode that can be replicated when played back 
through WSJT-X 2.2.0 rc2:

104945 -23 -0.5 1623 ~  VK3VM FH9ZZV/R ND49 ? a2

Research suggests this is not a genuine call and is definitely a false decode 
(i.e. ND49 = middle of Southern Ocean). I have noted that many false decodes in 
the previous version are reported with /R !

As one cannot send attachments via email I'll reforward this email plus the 
.wav file directly to Bill and Joe for further analysis.

73

Steve I
VK3VM / VK3SIR

Steve,

AP decodes flagged as low confidence ('?' marker) should always be considered 
dubious, and unless there is other evidence that the decode is genuine it 
should be ignored. Without using knowledge not obtained on air it is virtually 
impossible for the decoder to eliminate such false decodes without damaging the 
capabilities of the AP decoding mechanism.
AP decodes of the 'a2' category are only detected shortly after a CQ call IIRC.

The FT8, FT4, and MSK144 decoders give virtually every possible message equal 
weight. The message types that allow a '/P' or '/R' (grid rover
station) prefix to a standard callsign have a 50% probability per possible 
callsign that random data will unpack as one of those prefixes, so they will be 
far more common in false decodes than in genuine messages where the expected 
likelihood is far lower.

73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

[Stephen VK3SIR]

Bill,

Fully aware of that :-) Yet you have asked for reports when these occur. I am 
in a far-away land to many where low-level, low confidence signals are the norm 
and not the exception. Around 40% of the 40 contacts made today with the new 
version have been > -18dB. Without the reduced confidence in-use I'd be in 
constant RR/73 loops !

In in the last few minutes I have another  again with a /R ! You want this 
one was well?

114715 -18  0.3  825 ~  VK3VM PA6UES/R R BM44   ? a2  

I'll send that one as well as its now 2 in 60-odd minutes of operation.

73

Steve I
VK3VM / VK3SIR

-Original Message-
From: Bill Somerville  
Sent: Monday, 25 May 2020 9:43 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

On 25/05/2020 12:04, Stephen VK3SIR wrote:
> Folks,
>
> I just picked  up a false decode that can be replicated when played back 
> through WSJT-X 2.2.0 rc2:
>
> 104945 -23 -0.5 1623 ~  VK3VM FH9ZZV/R ND49 ? a2
>
> Research suggests this is not a genuine call and is definitely a false decode 
> (i.e. ND49 = middle of Southern Ocean). I have noted that many false decodes 
> in the previous version are reported with /R !
>
> As one cannot send attachments via email I'll reforward this email plus the 
> .wav file directly to Bill and Joe for further analysis.
>
> 73
>
> Steve I
> VK3VM / VK3SIR

Steve,

AP decodes flagged as low confidence ('?' marker) should always be considered 
dubious, and unless there is other evidence that the decode is genuine it 
should be ignored. Without using knowledge not obtained on air it is virtually 
impossible for the decoder to eliminate such false decodes without damaging the 
capabilities of the AP decoding mechanism. 
AP decodes of the 'a2' category are only detected shortly after a CQ call IIRC.

The FT8, FT4, and MSK144 decoders give virtually every possible message equal 
weight. The message types that allow a '/P' or '/R' (grid rover
station) prefix to a standard callsign have a 50% probability per possible 
callsign that random data will unpack as one of those prefixes, so they will be 
far more common in false decodes than in genuine messages where the expected 
likelihood is far lower.

73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

[Bill Somerville]

On 25/05/2020 12:04, Stephen VK3SIR wrote:

Folks,

I just picked  up a false decode that can be replicated when played back 
through WSJT-X 2.2.0 rc2:

104945 -23 -0.5 1623 ~  VK3VM FH9ZZV/R ND49 ? a2

Research suggests this is not a genuine call and is definitely a false decode 
(i.e. ND49 = middle of Southern Ocean). I have noted that many false decodes in 
the previous version are reported with /R !

As one cannot send attachments via email I'll reforward this email plus the 
.wav file directly to Bill and Joe for further analysis.

73

Steve I
VK3VM / VK3SIR


Steve,

AP decodes flagged as low confidence ('?' marker) should always be 
considered dubious, and unless there is other evidence that the decode 
is genuine it should be ignored. Without using knowledge not obtained on 
air it is virtually impossible for the decoder to eliminate such false 
decodes without damaging the capabilities of the AP decoding mechanism. 
AP decodes of the 'a2' category are only detected shortly after a CQ 
call IIRC.


The FT8, FT4, and MSK144 decoders give virtually every possible message 
equal weight. The message types that allow a '/P' or '/R' (grid rover 
station) prefix to a standard callsign have a 50% probability per 
possible callsign that random data will unpack as one of those prefixes, 
so they will be far more common in false decodes than in genuine 
messages where the expected likelihood is far lower.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJT-X 2.2.0-rc2 False Decode

[Stephen VK3SIR]

Folks,

I just picked  up a false decode that can be replicated when played back 
through WSJT-X 2.2.0 rc2:

104945 -23 -0.5 1623 ~  VK3VM FH9ZZV/R ND49 ? a2

Research suggests this is not a genuine call and is definitely a false decode 
(i.e. ND49 = middle of Southern Ocean). I have noted that many false decodes in 
the previous version are reported with /R !

As one cannot send attachments via email I'll reforward this email plus the 
.wav file directly to Bill and Joe for further analysis.

73

Steve I
VK3VM / VK3SIR


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.2.0-rc2 on macOS defaults to Catalan

[Bill Somerville]

On 25/05/2020 04:07, Ryan Woolley wrote:
After installing rc2 over rc1 on 10.15.4, the language defaults to 
Catalan.  Launching from Terminal with -l en or -l en-us has no 
effect, and System Preferences -> Language and Region -> Apps -> wsjtx 
reports "wsjtx doesn't support additional languages", so no apparent 
way to shift back to English.


Thanks,
Ryan KC7RW


Hi Ryan,

do you have the Catalan language pack installed, even if it is not the 
selected primary language?


73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] rc2 UI

[Alan Groups]

Hi, in my view goalposts are fine with the white line beneath the RX one 
and the waterfall background no longer quite black.


Window resize issue on turning menus off has gone.

Nothing else checked yet.

Alan G0TLK




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X v2.2.0-rc2 Problem

[Frank Hunger]

> Am 25.05.2020 um 02:40 schrieb Jim Charboneau :
> 
> This version has dropped the connection to my radio 5 time in 30 minutes.
> 
> Radio --- Flex 6300
> SDR Software -- SmartSDR v. 1.11.12
> 
> Thought you should know.
> 
> 73
> Jim
> KC1BB
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Hi Jim, try to set in mode Data/Point. 73 de Frank DM5KK


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] rc2 UI

[Jim Brown]

Thanks VERY much for this one:
"Hold Tx frequency no longer cleared when switching between modes."

We're halfway there -- TX frequency defaults to 1500 Hz when I've 
returned from MSK144 to FT8. Is it possible to remember prior setting of 
TX frequency?


I think the goalpost markers are improved, but I'm not colorblind. :)

Thanks and 73, Jim K9YC


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel