Since you are putting it back to what didn't work for a couple of users how
about a checkbox to enable/disable sharing?
Mike W9MDB
On Tuesday, February 16, 2021, 05:20:45 AM CST, Bill Somerville
<[email protected]> wrote:
Alan,
that is a completely unreasonable request, WSJT-X uses many supporting
libraries and on some platforms the version used is dependent on the operating
system version rather than what we specify. Nevertheless we do include a
summary change history for both WSJT-X and Hamlib with every release.
For example review the change log for WSJT-X v2.3.0 which you can find here
next to the release notes:
https://sourceforge.net/projects/wsjt/files/wsjtx-2.3.0/
Search for change: 4faad82da727e908cfc79d856f391d9feed46e7e
and for change: 4faad82da727e908cfc79d856f391d9feed46e7e
to see the two changes related to this issue.
Note that a Hamlib developer made a change to fix an issue, we took that
change on good faith. We also asked for an option to revert to the old
behaviour for users that needed it. You would have us not take the fix for the
problem so you can remain a Luddite, sorry that's not the way things work.
I have changed WSJT-X for the next release to override the Hamlib behaviour
and enable PTT sharing for all users, that will mean that if the original
problem is real then unsuspecting users will have problems even if they have no
use or knowledge of PTT sharing between Hamlib clients. Let's see how that goes?
73
Bill
G4WJS.
On 16/02/2021 10:59, Alan Groups wrote:
And if I may chip in most importantly please make sure *all* changes are listed
in release notes, with a link to release notes for libraries that are used - so
users can see them intuitively.
Leaving users to find out about changes unexpectedly in what is becoming a
large and complex app leads to unnecessary bug reports and
frustration/irritation all round!
Alan G0TLK On 16/02/2021 10:49, tom wrote:
Thanks for the update Bill
I have no issue with options being configurable but as Alex put it - ’never
touch a running system’ - tidy up coding to make it more robust yes but
removing a feature IMO is same as altering a default - it no longer works the
same.
Also as with Alex just deleted a chuck of this reply so the thread does not
go down hill fast.
Expressed my point I hope some more consideration may be given if this sort
of issue arrises in the future.
Tom GM8MJV
On 16 Feb 2021, at 10:32, Bill Somerville <[email protected]> wrote:
Hi Alex and Tom,
the Hamlib change was not a change of defaults, it was a removal of a feature
that apparently was causing issues. I asked that it not be removed and the
option offered was to make it a configuration option.
73
Bill
G4WJS.
On 16/02/2021 10:26, Alex Artieda, HB9DRI wrote:
Totally in agree with Tom
I delete part of my previous email to avoid start arguments BUT in IT we always
said “never touch a running system” and for programming also apply, why change
the previous default for something doesn’t works? And create just problems?
PTT and associated routines was working great up to WSJT-X 2.2.2, why change
that?, the proof of the pudding is in the eating, for sure exist a valid reason
by “the authors” but unfortunate this time maybe wrong.
Alex, HB9DRI
From: tom <[email protected]>
Sent: Tuesday, February 16, 2021 4:18 PM
To: Black Michael <[email protected]>; WSJT software development
<[email protected]>
Subject: Re: [wsjt-devel] BUG in WSJT-X 2.3 and 2.4rc1 COM port
Hi All
Don’t want to start an argument and please feel free to ignore my comments.
It seems a LOT of the errors recently seem to be because HamLib have altered
defaults and others have to pick up the flack.
It always used to be the case ’never alter the default’ - yes add new features
but never change the default.
There has been the issue of powering rigs on - default changed, shared ptt -
default changed.
There are more than a ‘couple of complains’ on this mailing list alone to keep
the status quo.
Please Please Please DO NOT start to toss the blame around - oh it up to xyz to
change their software to over-ride the changes we made. Just keep defaults as
they were and all will be happy.
End of rant
Tom
GM8MJV
On 16 Feb 2021, at 04:54, Black Michael via wsjt-devel
<[email protected]> wrote:
A couple of complaints from those who were using a single instance were having
problems with the constant open/close of the serial port.
So it was changed to support the simple case and those that want the more
complex case of multiple apps have to use the additional file as WSJT-X authors
have decided to not include any options in the rig control user interface.
I'm looking at the sharing now to see if there is a problem going on.
Mike W9MDB
On Monday, February 15, 2021, 10:33:13 PM CST, Alex Artieda, HB9DRI
<[email protected]> wrote:
Hello Bill
Following your instructions I use your file (looks the same as I use before)
and I place in the properly log directory for each of the WSJT-X (totally 4)
and doesn’t work, the PTT is not share.
I wonder why if in WSJT-X 2.2.2 the PTT com port was share by default now is
not?
Regards
Alex, HB9DRI
From: Bill Somerville <[email protected]>
Sent: Monday, February 15, 2021 6:29 PM
To: [email protected]
Subject: Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port
Hi Alex,
try the attached file. It needs to go in the log files directory of each WSJT-X
instance ("Settings->File->Open log directory").
73
Bill
G4WJS.
On 15/02/2021 05:41, Alex Artieda, HB9DRI wrote:
Hello Mike
Sorry I didn’t answer to the list;
I create a file named hamlib_settings.json and paste inside the code you send
me:
{
"config": {
"ptt_share": 1
}
}
Then place this file in C:\Users\[username]\AppData\Local\WSJT-X and in
Each of the 4 WSJT-X folders but doesn’t work,
Alex, HB9DRI
From: Black Michael via wsjt-devel <[email protected]>
Sent: Monday, February 15, 2021 11:11 AM
To: [email protected]
Cc: Black Michael <[email protected]>
Subject: Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port
The PTT port is no longer shareable by default.
Place this file in C:\Users\[username]\AppData\Local\WSJT-X
{
"config": {
"ptt_share": 1
}
}
Mike W9MDB
On Sunday, February 14, 2021, 07:43:47 PM CST, Alex Artieda, HB9DRI
<[email protected]> wrote:
Just to inform you, I found a bug regarding COM port for PTT, it appears in
WSJT-X 2.3 and in 2.4 RC1, let me explain.
I run 4 WSJT-X at the same time, I use Omnirig to control my IC9700 but PTT is
manage via a COM port, this is a must for me to TX first a Sequencer via the
COM port and later TX the radio, I cannot use CAT for PTT, that guarantee me
no RF spikes etc. 4 WSJT-X plus MAP65 plus WSJT10 are all configure to use COM3
for PTT, in this configuration I can TX with ANY of the 6 programs, more
precise I can TX with the program were the decodes or best decode happens,
unfortunate since WSJT-X 2.3 and 2.4RC1 I can TX ONLY with the FIRST program
who opens the PTT COM port, the other ones don’t work and MAP65 give a opening
COM port ERROR, the other WSJT-X simple don’t TX, would be great to fix this
bug because when you run multiple WSJT-X is a must to work with all instance
capable of TX, WSJT-X 2.2.2 works perfect.
To confirm this bug I roll back to 2.2.2 and install 2.3 and later 2.4RC1, the
bug appear in 2.3
73 de Alex, HB9DRI
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
