That would be wonderful, Will. But, I understand the expense obstacle.73,Ed
W0YK
Original message From: Will Shattuck
Date: 3/2/23 17:17 (GMT-08:00) To: e...@w0yk.com Cc: rttydigi...@groups.io,
r...@groups.io, m...@wsjtx.groups.io, WSJT software development
Subject: Re: [R
On Fri, Jan 17, 2020 at 3:01 PM David Gilbert
wrote:
>
> I realize that you aren't proposing "changing RTTY", but that is
> essentially what you would have to do if you wanted to make use of the
> majority of FTx's better sensitivity ... so clearly you still do not
> understand.
>
I do understan
I realize that you aren't proposing "changing RTTY", but that is
essentially what you would have to do if you wanted to make use of the
majority of FTx's better sensitivity ... so clearly you still do not
understand. I'm not sure what your degree is in, but I'm pretty sure it
wasn't signal p
On Fri, Jan 17, 2020 at 8:21 AM Frank Kirschner wrote:
> All I suggested was that improving the software discriminator in a RTTY
> program might produce a useful improvement in noise performance.
>
Frank, in my opinion you are lobbying the wrong developers here. If there
are ideas in WSJT-X that
On Wed, Jan 15, 2020 at 1:44 PM David Gilbert
wrote:
>
> You're assuming that the algorithms used in WSJT-X would be adaptable to
> RTTY to give better performance than what is already out there.
>
It is certainly true that the algorithms used in WSLT-X for discriminating
frequencies could be ad
You're assuming that the algorithms used in WSJT-X would be adaptable to
RTTY to give better performance than what is already out there. I don't
think there is any evidence of that being the case, given the very rigid
constraints that every single WSJT-X mode requires. The appeal of RTTY
fo
On Wed, Jan 15, 2020 at 2:27 AM Neil Zampella wrote:
> 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.
>
And to make contest operation more convenient.
>The other
On Wed, Jan 15, 2020 at 5:41 AM Wolfgang wrote:
> Hello Dwayne,
>
> adding RTTY to WSJT-X is like:
>
> "... can I add a Diesel engine to my advanced hydrogen driven car."
>
> Then why do they allow WSJT-X to be used in RTTY contests?
73,
Frank
KF6E
___
On Tue, Jan 14, 2020 at 11:32 PM David Gilbert
wrote:
>
> 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.
>
> No one
Title: Re: [wsjt-devel] RTTY
Hello Dwayne,
adding RTTY to WSJT-X is like:
"... can I add a Diesel engine to my advanced hydrogen driven car."
RTTY needs a complete different user interface, complete different
decoding and transmission, RTTY is doing it character by character.
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 cost
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 to
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 inste
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
KF6E
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 u
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 kn
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 all
A reminder when submitting your log. If you made any FT contacts in the
contest that makes you Unlimited and you should answer this question with a
Yes:
"At any time during the contest, did you use spotting assistance of any
kind,
or software capable of simultaneously decoding multiple call signs?
Hi Ron:
Thank you very much. Yes, that was my feeling from last year. Always a
confirmation is a plus. Also, I am somehow new to contests.
73'
Edfel
KP4AJ
On Mon, Jan 6, 2020 at 10:25 PM Ron WV4P wrote:
> FT-X is Always Assisted because it's decoding multiple signals.
> Ron, WV4P
>
> On Mon
FT-X is Always Assisted because it's decoding multiple signals.
Ron, WV4P
On Mon, Jan 6, 2020, 9:09 PM Edfel Rivera wrote:
> Hi Again:
>
> One last question, FT4 Mode is assisted or non-assisted" I mean the
> answer to this question:
>
> At any time during the contest, did you use spotting assi
Hi Again:
One last question, FT4 Mode is assisted or non-assisted" I mean the answer
to this question:
At any time during the contest, did you use spotting assistance of any kind,
or software capable of simultaneously decoding multiple call signs?
Finally, my experience is that FT4 took over FT
Hi Ron:
Thank you very much, deleted the QSO. I guess some stations try to
capitalize from the contest activity and advance their contacts. I tried to
ignore, but with the hours someone can make into the log.
73'
Edfel
KP4AJ
On Mon, Jan 6, 2020 at 9:19 PM Ron WV4P wrote:
> Delete them, other
Delete them, otherwise it will be a busted Q... Could red flag the log if
there are more than a few. You won't get credit for them so no harm
deleting (I'd make a backup file with them in it first)
As for why so many non contest stations make it hard... The Developers gave
WAY to much credit to ma
Hi:
Probably not related with WSJTX. Browsing the contest log, I have detected
some DX stations sent report with no serial. I did'nt noticed they were CQ
and not CQ RU
Question is how should I proceed as upload form is reporting:
number of fields in QSO line less than mininum expected(11)
> On Jan 6, 2019, at 23:13, Edfel Rivera wrote:
>
> Seems I missed resetting title. Any idea how to change Contest name and what
> is the correct contest name. Previous to the contest I reset log but name of
> previous contest is still there.
I’m not sure the title change is all it needs.
Apologies, I meant to ask: does the wsjtx_log.adi file show DX +
serial numbers for all QSO exchange data which you transmitted? Not
the exchange data which you received from the QSO, rather what
exchange data you sent for the QSO.
On 1/7/19, Edfel Rivera wrote:
> Hi All:
>
> My first contest sor
Quick question: Does the wsjtx_log.adi file display serial numbers for
all of your QSOes?
On 1/7/19, Edfel Rivera wrote:
> Hi All:
>
> My first contest sorry for some simple questions. First, I figured how to
> edit Contest Name, at Log Export just use ARRL-RTTY. I do have a specific
> problem,
Hi All:
My first contest sorry for some simple questions. First, I figured how to
edit Contest Name, at Log Export just use ARRL-RTTY. I do have a specific
problem, have to set RTTY RU EXC to DX (Advance Settings).
After uploading my log, I am receiving warnings "copied exchange
(qthserial) is
Hi:
Seems I missed resetting title. Any idea how to change Contest name and
what is the correct contest name. Previous to the contest I reset log but
name of previous contest is still there.
BTW, great contest for FT8 and WSJTX. For those who were skeptical about
contesting compliance capabil
I have configured wsjtx to not allow a change in frequency during transmit.
During the RTTY RU contest, the receive frequency was locked as well as the
transmit frequency. It was a bit annoying that I could not move the receive
bracket during transmission. Sometimes the receive bracket would not up
I ran into the same issue during the RTTY RU contest. The work-around which
I used was to click on TX6 (CQ) and reenable the transmit in advance of
getting an answer back from the other station. If they were successful in
receiving my RR73, I aborted the CQ and chose my next QSO partner.
On Sun, J
Working as "search, not CQ" station there is one thing in RTTY RU
actions that I would like to change.
When I pick a CQ calling station, send "RST NR" and get "R RST NR" as
return my next TX will be "RR73".
But when that happens the radio button "Next" jumps to TX_6. Always, not
depending ha
Hi,
My participation in the "2230-2300 UTC, Friday, 5 January - FT8 focus"
session went very very smoothly and I was able to complete 10 QSO in little
above 30 mins on 40 m.
Some observations (all positive) :
* received one popup dialog with an "Invalid Rcvd Exch" for a station
re
I write the QST results article for the RTTY Roundup.
The article is only as good as the input I receive from all of you, the
operators that participated.
I'll be asking for your thoughts on the contest when it is over. Stories of
your trials, tribulations, and your successes and milestones. Peop
Hi all,
I'm relaying the message copied below for Jeff, WK6I.
-- 73, Joe, K1JT
Please share this notice with your local groups, as appropriate.
Same time and same drill as in recent years. This coming Friday, l
Hi Phil and Ed,
Thanks for sharing your views.
We thought long and hard about backward-compatibility issues before
concluding that a change in the FT8 protocol was highly desirable.
Among the most important motivations were these:
1. Message formats optimized for North American VHF contests,
Hi Phil.
This question is really for the WSJT development team to address. But, my
personal opinion as a user differs a bit from yours. I'll offer it here as
another perspective.
In general, I agree with your stated principle of backward compatibility.
At the same time I tolerate breaking the p
to hear that RC5
will report dupes independently, based on a contest-by-contest effort.
It just keeps getting better. :)
From: John Kludt [mailto:johnnykl...@gmail.com]
Sent: Tuesday, November 20, 2018 8:54 AM
To: WSJT-Dev
Subject: Re: [wsjt-devel] RTTY roundup dups
David
David,
Actually I found JTAlters very useful for exactly that reason - dup
checking. But see Joe's note - already handled in RC5 or the GA release.
John
On Tue, Nov 20, 2018 at 11:19 AM David Kjellquist
wrote:
> Has anyone come up with ideas for avoiding dups when using FT8 in a
> large conte
Joe, Steve et al -- thanks for your good work here. Last night I believe I
was able to complete QSOs more reliably than in the past, and other people
seemed to be able to decode me at the same power level that had not been
very effective recently with 1.9.1.
On Tue, Nov 20, 2018 at 11:36 AM Joe Ta
Hi Dave and all,
On 11/20/2018 11:11 AM, David Kjellquist WB5NHL wrote:
Has anyone come up with ideas for avoiding dups when using FT8 in a
large contest? JTAlert checks B4 but its display matrix is limited and
not really designed for contest use. N1MM log integration works well but
I don't se
Has anyone come up with ideas for avoiding dups when using FT8 in a
large contest? JTAlert checks B4 but its display matrix is limited and
not really designed for contest use. N1MM log integration works well but
I don't see that it checks for dups prior actual log entry (not much
help). But, I'
Morning:
Again, I had fun last night..as another stated, it was a "hoot"
Thanks.
Stephen Duncheskie, W4PPC
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Bill,
Thanks for the reply. I am running current versions of N1MMLogger+, WSJT-X
and JT Alerts under Win7. First, and I am sure this is where I need some
help, I have never been able to log directly from WSJT-X into N1MM. I use
JTAlerts as a "bridge' if you will between WSJT-X and N1MMLogger+.
Other than the contest log displaying in local time (with AM/PM!), everything
seemed to work fine in the mock contest. No crashes, no unexpected operation.
MacOS Mojave, Flex6600.
George J Molnar
KF2T - Virginia, USA
___
wsjt-devel mailing list
wsj
Lots of fun on a chilly November evening. My feet were cold but the band was
hot. Lots of signals. It mostly went pretty smoothly. 42 logged instances of 77
bit goodness.
Just a few comments, some of which may be expected behavior.
When calling a station with TX2, if the other op responds with
On 20/11/2018 04:04, John Kludt wrote:
John,
One question since you were using N1MM as well in the test. On the
Modes tab in N1MM Config I checked "Always RTTY." Logging directly
from WSJT-X/JTAlerts into the ARRLRTTY each Q hit the N1MM log fine.
Each Q was logged as an FT8 Q. Unfortunately
John,
One question since you were using N1MM as well in the test. On the Modes
tab in N1MM Config I checked "Always RTTY." Logging directly from
WSJT-X/JTAlerts into the ARRLRTTY each Q hit the N1MM log fine. Each Q was
logged as an FT8 Q. Unfortunately N1MM seems rather fussy as it gave all
o
Win10, IC-7300, WSJT-X V2.0.0 rc4
As others have reported the "contest log" window and the Cabrillo file show
local date and time 11-19-18, 9:15.
I renamed the Cabrillo log before the contest to avoid confusion. No cabrillo
file was created during the test. The Cabrillo file was created after th
Evening:
Overall perfect operation. No crashes with WSJTx or JTAlert combination
with N3FLP's ACL 6.4 logging WSJT-x directly without issues to time
UTC/Local...(other issue with time on earlier email was already
noted).. running on Window's 7 Pro.
Enjoyed the time.
Thank you.
Sincerely:
Everything worked marvelously here, though I noticed the WSJT-X Contest Log was
recording local times. Moot for me since N1MM+ was doing the primary
logging/tracking mults/etc. Happy camper here; tnx so very much to all the
WSJT-X team.
73 John W7CD
ARRLRTTY Summary Sheet
Start Dat
Overall perfect operation. No crashes with WSJTx or JTAlert combination
with HRD LB logged from WSTJx directly. Win 10 Pro w/plenty of SSD RAM and
system memory. All current versions.
Problems:
1) Time logged as local not UTC (already noted by many others)
2) Entry sequence (left column) 1-9 ok
Hardware: iMac, IC-7300, 80m OCF Dipole
Software: macOS Mojave, WSJT-X 2.0 RC3, JTBridge, MacLoggerDX
In general I found my participation in the Mock "FT8 Roundup" Contest to be
quite successful and highly enjoyable. I made 22 contacts and only encountered
one issue of significance:
After on
_
From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
Sent: Wednesday, September 26, 2018 10:28 PM
To: WSJT Software Development
Cc: Black Michael
Subject: [wsjt-devel] RTTY Roundup sig reports
All signal reports came up with -13/-02 when logged.
What's t
All signal reports came up with -13/-02 when logged.
What's the intent for the signal reports to be logged?
de Mike W9MDB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Don, I was also wondering about logging in a mixed-mode contest. In RTTY
roundup, if I'm using FT8 and RTTY I'd like to know dupes based on any
contact mode. I set things up last night with that in mind. In JT alert, I
turned off logging to DX keeper, and started a new ADI file. That way JT
alert w
Hi Don,
On 9/25/2018 10:03 AM, Don AA5AU wrote:
I have some questions in trying to set up for tomorrow night's FT8
Roundup test.
1. Will the QSO get logged automatically to the Cabrillo file or will I
have to manually log it? Typically is use JTAlert to log into DXKeeper
but I don't think I
I have some questions in trying to set up for tomorrow night's FT8 Roundup test.
1. Will the QSO get logged automatically to the Cabrillo file or will I have to
manually log it? Typically is use JTAlert to log into DXKeeper but I don't
think I want to do that for a contest. It seems the QSO shoul
60 matches
Mail list logo
