I do not know what prompted a gratuitous diatribe about the origins,
strengths, and limitations of WSJT, WSJT-X, and MAP65 on this email
reflector. Your forum hosts hardly need instruction on these topics,
since we developed these referenced programs and the digital protocols
that power them.
For the record:
Over the past 20 years EME has been one (but only only one) of the
weak-signal communication modes motivating the development of WSJT and
its sister programs. A basic timeline of development work looks like this:
2000: Meteor scatter with FSK441
2002: EME (JT44)
2003: EME with reliable error correction (JT65)
2007: EME with JT65 and adaptive polarization (MAP65)
2008: World-wide QRP propagation probing (WSPR)
2013: Small-station EME at 10 and 24 GHz (JT4)
2017: Meteor scatter with reliable error correction (MSK144)
2017: World-wide QRP DXing near sunspot minimum, on HF bands (FT8)
2020: Intercontinental DX on 2200, 630, and 160 m bands (FST4, FST4W)
2021: Ionoscatter, troposcatter, rainscatter, and EME (Q65)
It's hard to estimate the number of active users of some of these
developments. JT44 has long since disappeared, and FSK441 is probably
on its way out, being replaced by MSK144. JT65 had an extended fling on
the HF bands but is now again mostly used for EME, where it started.
There remain perhaps a few hundred MAP65 users, but for many EME
enthusiasts WSJT-X has become a more flexible, frequently more capable
alternative with much simpler hardware requirements. FST4 and FST4W are
rapidly becoming the favorite modes for digital communication on the
2200 and 630 m bands. Finally, Q65 - who knows? With its wide range of
capabilities and excellent performance, it may replace both JT65 and JT4
for most digital EME work.
-- 73, Joe, K1JT
On 2/17/2021 9:30 AM, Alex Artieda, HB9DRI wrote:
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
_______________________________________________
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
