Dear Bill
You said “I am still not understanding what you are doing”
I’m doing EME, not HF, we, the EME community, make JT protocol famous,
since more than 15 years I was devote, together with aprox, 300 people
to use an ADAPTIVE POLARIZATION SYSTEM, MAP65 appears later (10 years
ago aprox) as the facto suite for Adaptive Polarization, and more and
more people was able to do EME because with the JT protocol you don’t
need big antennas and illegal power (like many EME stations did for
decades), we jump from 100 EME stations in 144MHz to more than 2,000
or more in few years. The big contribution of the JT protocol was “the
democratization of the technology”, big antennas, TV transmitters with
illegal power and budgets reserve only for millionaire people was not
necessary any more to do EME.
Then the CW / DIGITAL war start, and WE, the EME people who believe in
technology evolution becomes the defenders of what Joe did……with the
years Joe abandoned MAP65, means a lot of people was relegated to use
a software with many problems, ok I don’t judge Joe, I consider him my
friend and some kind of mentor and I respect him and I will always
admire it, it was his decision and I respect that, I don’t accept but
I respect, looks like 20,000 HF users are more important than 300
crazy EME “founding fathers”., always will be a matters of numbers,
big numbers., unfortunate.
To circumvent the poor performance of a defunct software like MAP65 me
and few other create a system based in 1 Linrad MASTER as and input
with 4 Linrad SLAVES, feeding 4 WSJT instances, the initial test I did
in 2007 with WSJT 5.9.8 (r558) and the initial result was promising
but we abandoned temporary the idea because MAP65 arrive and was the
solution, solution for what? FARADAY ROTATION IN LOWER BANDS.
In a multiple WSJT system you receive 4 different angles H, V +45 and
+135, then you will have the best decode in the WSJT instance who
match better the RX angle configure in the independent Linrad SLAVE, a
monster and complex configuration, but MAP65 solve all our problems
because MAP65 did a weight sum of all signals creating a single
optimized decode and the system in multiple instances was relegated
and abandoned. Just a single master piece of software, efficient,
simple to operate without “nice to have” functions, that WAS MAP65
Later the Adaptive polarization system based in several Linrad and
WSJT 10.0 at that time becomes and demonstrate to have much better
performance, WHY? Because Joe decide to not upgrade anymore and
dedicate his effort to something more relevant, JT protocol for the
masses in HF. I did a presentation in the 17th EME Conference in
Venice in 2016 about how to configure:
here the link:
http://www.eme2016.org/wp-content/uploads/2016/08/EME-2016-Complete-Proceedings.pdf
<http://www.eme2016.org/wp-content/uploads/2016/08/EME-2016-Complete-Proceedings.pdf>
(search for my presentation done with my South African call ZS6EME)
at that time was difficult to see the advantage but within the years I
personal assist at least 50 different stations and in HB9Q is the
facto configuration for many years, today I’m operating in Bangkok as
HS0ZOP with 1 Linrad MASTER, 4 Linrad Slaves and 4 WSJT-X AND MAP65 in
parallel, 90 % of the time MAP65 DECODES NIL, and if decodes is 1 to 3
dB lower than any other WSJT-X, I never work from Bangkok single
Yagi’s with MAP65 in 432MHz, all my difficult DX come from a multi
instance of WSJT-x, I don’t care in witch polarization angle you TX, I
always will have your decode in one of the WSJT-X instances and if
your signals is inside my S/N ratio.
Most of us we are using the adaptive polarization system with
dedicated SDR radio receivers and ADC converters, we don’t use
commercial radios for RX because they are not good enough, only the TX
part of any commercial transceiver. And this configuration exist
before WSJT-X appears, means don’t think we are doing bizarre things
with the suite, I think is revers, from our perspective the suite is
doing bizarre things with was the REAL original functions in the
software, at the point than today many serious EME stations REFUSE to
use WSJT-X and prefer to use WSJT 9 or 10.0, and I understand why
because what ever you want to tell me I never ever see better
WATERFALL than the embedded in WSJT 10, the waterfall in WSJT-X is far
away from the waterfall of WSJT 10 and the excess of HF functions in
the software make the suite much complicate than the original WSJT.
And I place this story here not to create controversial points, just
to educate and inform and share with you and others probably what no
body share, WE, “the founding fathers “ of adaptive polarization” the
fierce defenders of the JT protocol, of the technology innovation for
years against the stagnation of the dinosaurs (CW) we are TIRED to
invoke, talk, write, beg, plead Joe Taylor to do something for our
small, insignificant and irrelevant group of EME people and the answer
was always, I cannot be until my dead doing programing, MAP65 is good
enough (really?), a impossible task just for few people, and the worst
of the worst of the worst answers: well if you complain so much take
the opensource repository and doit by your self etc, etc, etc….
You want a probe of that, grab in the Moon-net reflector and see how
many people ask for the future of MAP65 plus the hundreds of emails
many of us receive off-reflector telling we must do something, well I
try everything possible in terms of communication to explore, search
for a possible solution, personal I pass the source code to many
developers near my IT job unfortunate is difficult from the
perspective of a developer to understand things related to FFT, bin
etc, etc, if you don’t have a Radio background, I’m IT Engineer and
Electronic Engineer in Infrastructure, means I cannot go more far away
from some Arduino Sketch, sorry is my limitations, but I can build for
you a state of the art SSPA, SDR radio or ADC like I did and after all
this unproductive discussion I GIVE UP WITH MAP65 and all what it
means and search for my own solution with multiple WSJT, WSJT-X.
But please do not misunderstand me, this is a hobby, the software is
for free, means nobody have obligation with no body, really?, at least
a moral obligation exist in my modest opinion.
Now Bill I hope you and this forum understand clearly what we are
doing and how bad we feel, we are running in “extension mode” year by
year more segments of the MW RF spectrum are ripped out, we are
condemn to disappear and if the “authors” don’t take care then they
will contribute indirectly to the already announced extension of EME
communication, is a matter of time and what make me furious is I’m
young enough to see that extinction in the next 50 years when 95% of
the actual EME people will be just history, a good one or bad one, we
will see.
Sorry for the extensive bandwidth but who doesn’t know his History
cannot project his own future
73 de Alex
OA4CRK, HK3TAS, HB9DRI, ZS6EME, HS0ZOP
*From:* Bill Somerville <g4...@classdesign.com>
*Sent:* Wednesday, February 17, 2021 6:36 PM
*To:* wsjt-devel@lists.sourceforge.net
*Subject:* Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port
Alex,
the PTT sharing was only ever designed to work with setups not using
CAT control. Currently the only supported way to have CAT control
shared by multiple applications is to use a CAT server application
like the Hamlib rigctld or similar, that will implicitly share the PTT
so this should be a non-issue. It looks like your introduction of
Omni-Rig is the source of your problem if it does not support PTT sharing.
I am still not understanding what you are doing. Are all your WSJT-X
instances using a single transceiver? If so then using rigctld is an
easy solution, you can also configure rigctld to share the separate
COM port used for PTT so other applications without CAT capability
like WSJT and MAP65 can share.
73
Bill
G4WJS.
On 17/02/2021 11:07, Alex Artieda, HB9DRI wrote:
Hello Bill
I can omit to work with Omnirig BUT the IC-9700 config embedded in
WSJT-X have the same behavior that the PTT, only the 1^st WSJT-X
instance can manage, the only way to have SHARE CAT com port was
using Omnirig.
Regards
Alex, HB9DRI
*From:* Bill Somerville <g4...@classdesign.com>
<mailto:g4...@classdesign.com>
*Sent:* Wednesday, February 17, 2021 5:20 PM
*To:* wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
*Subject:* Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1 COM port
Hi Alex,
thanks for that.
OK, I now understand what is happening. The Hamlib configuration
overrides do not currently apply when using any form of CAT
control other than Hamlib, including via Omni-Rig. I will change
that for the next release.
Another option is not to use Omni-Rig, which may be dependent on
other applications you use. The Hamlib rigctld (which we ship a
version of with WSJT-X called rigctld-wsjtx) also supports the PTT
sharing configuration option.
73
Bill
G4WJS.
On 17/02/2021 08:07, Alex Artieda, HB9DRI wrote:
Hello Bill
Sorry but the file you send me is exact to the code propose by
Mike, the code is the same and I copied in ALL WSJT-X
instances I have and I cannot share the PTT port.
My config in Radio tab in ALL WSJT-X instances:
For RIG: I use Omni Rig 2 where CAT is configure over a
separate port, this works ok ( I never succeed to use the
IC-9700 option in WSJT-X)
For PTT: I use com port 2 RTS, that works good v2.2.2 or in
2.3 and 2.4rc1 if only one instance open the port
Mode: None
Split Operation: RIG
I don’t use CAT for PTT because I need to PTT first my
sequencer, then the sequencer PTT the radio as last event.
Alex, HB9DRI
*From:* Bill Somerville <g4...@classdesign.com>
<mailto:g4...@classdesign.com>
*Sent:* Tuesday, February 16, 2021 7:50 PM
*To:* wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
*Subject:* Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and 2.4rc1
COM port
Hi Alex,
the file I sent was different from the text Mike suggested.
What settings are you using on the "Settings->Radio" tab of
your WSJT-X instances?
73
Bill
G4WJS.
On 16/02/2021 12:45, Alex Artieda, HB9DRI wrote:
Hello Bill
The file you send me has the same code send to me from the
beginning, I delete the file I create and I confirm your
file was installed into the log directory in each WSJT-X
instance I had, doesn’t work.
To confirm the problem I install in another computer two
WSJT-X and use your file and doesn’t work.
As you mention in one of your last emails you will back in
the next release to sharing the PTT port, something make
totally sense if you consider it was working ok in version
2.2.2.
Regards
Alex, HB9DRI
*From:* Bill Somerville <g4...@classdesign.com>
<mailto:g4...@classdesign.com>
*Sent:* Tuesday, February 16, 2021 5:31 PM
*To:* wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
*Subject:* Re: [wsjt-devel] FW: BUG in WSJT-X 2.3 and
2.4rc1 COM port
Hi Alex,
the file I attached was the correct one. Others have used
it without issues. Please double check the file is
correctly named and has not been mangled by Windows in
some way. Note the file name must be hamlib_settings.json
73
Bill
G4WJS.
On 16/02/2021 04:29, Alex Artieda, HB9DRI 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 <g4...@classdesign.com>
<mailto:g4...@classdesign.com>
*Sent:* Monday, February 15, 2021 6:29 PM
*To:* wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
*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 placethis 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
<wsjt-devel@lists.sourceforge.net>
<mailto:wsjt-devel@lists.sourceforge.net>
*Sent:* Monday, February 15, 2021 11:11 AM
*To:* wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
*Cc:* Black Michael <mdblac...@yahoo.com>
<mailto:mdblac...@yahoo.com>
*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 <hb9...@emeham.com
<mailto:hb9...@emeham.com>> 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
