The only reason you'd add RTTY to WSJT-X is if there were some way to
improve it for weak signal work, the program and its protocols were not
designed for any other reason. The other reason is one you overlooked
in Dave's post:
Quote:
3. Each candidate development task has an "opportunity
Re: Dwayne Sinclair 2020-01-14 <1a7fafe0-f3f3-45ff-8ec9-a0f3e1f60...@gmail.com>
> I would like to propose adding RTTY to WSJT-X for two reasons 1. As a means
> to reframe the DXCC discussion away from FT8 itself to “it’s just a UI for
> managing QSO’s”, and 2. I believe WSJT-X would be a great
What would that be? FT8/FT4 uses a better detection scheme than RTTY
precisely because of the constraints that FT8/FT4 require. Those
constraints are what allow the better decoding ... there is no "magic"
involved here. If you lock the signal to predetermined time windows,
use 8 tones
On Tue, Jan 14, 2020 at 8:23 PM Dave AA6YQ wrote:
> 1. RTTY is a well-defined protocol; the result of any modifications to
> this protocol would not be RTTY.
>
>
> I don't understand. No one suggested modifying RTTY, just using a better
discrimination technique on the receive end.
73,
Frank
1. RTTY is a well-defined protocol; the result of any modifications to this
protocol would not be RTTY.
2. Significant work has been done to improve RTTY decoding; see
https://www.rttycontesting.com/downloads/2tone/ (David G3YYD)
http://www.dxatlas.com/Gritty/ (Alex VE3NEA)
Some digital mode
I'm not suggesting changing the RTTY FSK standard. I'm suggesting a better
detection scheme for the existing RTTY standard.
73,
Frank
KF6E
On Tue, Jan 14, 2020 at 7:54 PM David Gilbert
wrote:
>
> I'm not so sure it would be that easy. All of the WSJT-X modes require
> some pretty rigid rules,
I'm not so sure it would be that easy. All of the WSJT-X modes require
some pretty rigid rules, not the least of which is fixed time frames
closely locked to the same reference. They also require some pretty
narrowly constrained message formats. I really doubt that very many
current RTTY
Dwayne,
That's what I suggested some time ago. Not only would it put all the
digital modes I use together in one program, but it would provide an
opportunity to implement a really good RTTY detection algorithm. Some of
the current programs require a very high S/N, and with the signal
processing
Hey all,
My background is IT infrastructure with some code development and I although I
have been active in the amateur radio community for less than a year, given my
software, IT infrastructure background, and electronics background I have been
assisting my local amateur radio community in
I read the email thread from a while back with interest.
Let me add my to cents (or less). A XMLRPC interface like FLDIGI and
FLRIG uses is implemented easily. And would allow other related
applications (like loggers) to interface with WSJT-X. I am especially
interested in that I am writing a
10 matches
Mail list logo
