On 03/06/2019 20:44, David Gilbert wrote:
You're talking to a wall.
This "wall" listens, and has opinions, and explains the reasoning behind
itsopinions. Insofar as my opinions deviate from "generally perceived
wisdom" (my quotes), they are often derided or unwelcome.
Paul always does this stuff ... if you don't view ham radio the way he
does you aren't doing ham radio.
Only to the extent that I don't accept that everything done in the name of
ham radio, by ham-radio operators, is invariably or necessarily ham radio.
What Paul is never able to grasp is that "ham radio" covers a much
broader scope than he perceives, and that includes contesting. As
long as contest sponsors are thoughtful enough to properly categorize
activities, I can find no problem at all with there being CW contests,
SSB contests, RTTY contests, FT4 contests, etc.
What I cannot "grasp" or accept is that automated machine-to-machine
contacts represent ham radio, even when a ham-radio operator or
contester has fired up the station and computer, and set the
appropriateapp going.
They simply require different combinations of skills, and having
different types of contests simply serves the broader interests of
hams in general. It's still ham radio.
No skill is needed for automated machine-to-machine contacts.
That includes FT8 and/or FT4. YouTube has examples.
It's ridiculous and purely arbitrary to assert that the only valid
contests are those where hams do their own decoding (which of course
leaves out the very popular RTTY mode).
Equally, it's ridiculous and arbitrary to give contesting or DXCC
credit for automated contacts - ones that take place and are logged
with no human intervention whatsoever.
What about encoding? I would bet that most contesters today don't
send their own information, at least not on CW and RTTY. We push a
button on the keyboard and the logger does it for us. Why should only
one direction of the communication path need to fit Paul's narrow
view? I have literally done entire major CW contests without ever
touching the paddle (and had half the received callsigns/reports
auto-filled for me by the logger to boot).
Ward N0AX explained it better than I could - in April 2008.
"Dealing with automated reception differently than automated
transmission is appropriate because only reception can initiate
a QSO; whether in response to a solicitation (CQ) or from
tuning to a solicitation (S&P). Reception is qualitatively
different in this regard than transmission."
http://lists.contesting.com/pipermail/cq-contest/2008-April/079851.html
and -
"You can cast the lure as much as you want, but if no fish
bites, you have not caught a fish. There must be a reception
event to trigger the process by which a QSO is conducted.
Both reception and transmission are necessary, but neither
is sufficient. Transmission events soliciting QSOs typically
outnumber reception events many-to-one. (Which key on your
keyboard is the most worn - F1 or Insert?) Thus, reception
is the critical element in allowing the transaction to
proceed."
http://lists.contesting.com/pipermail/cq-contest/2008-April/079860.html
I wouldn't like to see contests lump fully automated QSOs with
non-automated ones,
We're agreed on that, at least :-)
but the signal processing argument is bogus.
That's a misquote. I introduced the term "data processing" (the
data exchanged in a data-mode contact) - not "signal processing".
The ability for FT4 to copy weak signals comes at the cost of speed,
and I can list other disparities between stations as well. If I have a
rig with better DSP capabilities I'm going to be able to hear stations
somebody with a lesser rig won't. It's not my proficiency that makes
a difference ... it's PROCESSING that does.
Signal processing helps us all, and operating proficiency never goes
to waste.
If I have narrower filters than somebody else does I can pick out
stations from a pack better than somebody else could. It's not my
proficiency that makes a difference ... it's PROCESSING.
They both make a difference.
FT4 is simply a digital mode
Not quite! It's a digital data mode with data processing and error
checking capabilities - a mode which can easily be fully automated.
with different processing tradeoffs, and why Paul thinks that the
possibilities being "limitless" is a problem is beyond me.
Nowhere did I suggest the possibilities were "limitless". What
Isaid was "the potential combinations (for new data modes) are
limitless". I look forward to FT4 Release Candidate 8 in the near
future.
The DSP found in almost all modern rigs is itself "processing". It
takes the analog signal from the antenna, slices and dices it to bits,
runs it through various software algorithms, transforms it in both
time and frequency domains, and reconstructs it to audio.
Agreed, but it's not data processing in the sense I intended - text
transmission/reception with automatic error correction.
And what is so special about audio? It is merely one of our senses.
Here we go again - another misquote. I suggested "ham-radio operators
do their own decoding", and was careful to not specify a sense.
<snip>
Diversity is healthy.
That's a trite, feel-good statement that means nothing in particular.
Competitive swimming doesn't "diversify" by permitting flippers.
New technology is generally deemed to be inappropriate when its effects
aredisproportionate or when its use would change the nature of the
competitive activity concerned.
I suggest we're there now with fully-automated FT8 and FT4 - and
I can't help feeling AB7E agrees :-)
73,
Paul EI5DI
73,
Dave AB7E
p.s. I can't wait to see what kind of private message Paul will send
me this time.
On 6/3/2019 9:25 AM, Chuck Dietz wrote:
I don’t have any idea what you are saying here. Are you just bad
mouthing
digital modes?
Chuck W5PR
On Mon, Jun 3, 2019 at 6:55 AM Paul O'Kane <pokane@ei5di.com> wrote:
Great - we have yet another data mode. There is no single data mode
that
is
"best" in all respects. It's always a compromise between time, signal
rate,
bandwidth and number of discrete channels or tones - the potential
combinations
are limitless.
What all data modes (including RTTY) have in common is that they
require
machine decoding. It seems to me that ham-radio contesters do their
own
decoding, whether it's CW or Phone. Everything else is data processing
and,
increasingly, fully-automated data processing.
Let's leave data modes to the Data-Processing-over-RF apps.
73,
Paul EI5DI
On 02/06/2019 19:49, Jim Brown wrote:
-------- Forwarded Message --------
Subject: [wsjtgroup] WSJT-X 2.1.0-rc6
Date: Sun, 2 Jun 2019 14:32:20 -0400
From: Joe Taylor joe@Princeton.EDU [wsjtgroup]
<wsjtgroup-noreply@yahoogroups.com>
Reply-To: Joe Taylor <joe@Princeton.EDU>
To: wsjtgroup@yahoogroups.com <wsjtgroup@yahoogroups.com>
To: Users of WSJT-X -- especially those interested in radio
contesting
From: WSJT Development Group
As you know, we have been developing a protocol called FT4 for use in
radio contesting. A new version of FT4 is now available for testing
in WSJT-X 2.1.0-rc6.
PLEASE NOTE THAT FT4 IN RELEASE CANDIDATE 6 IS NOT COMPATIBLE WITH
THAT IN ANY PREVIOUS RELEASE.
Therefore: Please stop using WSJT-X 2.1.0-rc5. If you wish to use FT4
after today or to take advantage of other recent program corrections
or enhancements, you should use WSJT-X 2.1.0-rc6.
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
|