[RTTY] More GRITTY observations

David G3YYD g3yyd at btinternet.com
Mon Apr 27 11:41:23 EDT 2015


2Tone does vary its character synchronisation to cope with various stop bit
lengths. It works best with stop bits at 1.5 bit time. If the stop bit is
longer than 2.2 bit times it will go to asynchronous, which means that
character sync is not as good and the error rate will be higher.

Best decode performance is obtained by sending exactly at the set speed that
is 45.454545.. or 50 or 75 baud with diddles on, unshift on space on and
stop bit at 1.5 data bit length. Ideally 2Tone DOOK mode (or Fldigi) should
be used as this matches how modern decoders work. They are not FSK decoders
anymore they are long gone. They are on-off keying decoders for two tones
oppositely keyed, i.e. Differential On-Off Keying (DOOK).

I have in test a revised version of AFC. I am not sure whether to let it
loose as the tones are AFC separately from each other. They are constrained
so individually will not depart from each other by more than 60Hz and no
further than 60Hz from the set tone frequency. If you would like to test it
for me please email me direct with an email account that excepts zipped .exe
files.

One thing I noticed is some transmissions that always send a ltrs shift
after a space character. What a waste of transmission time and the extra
unnecessary characters adds to the potential for errors. Anyone know which
software/hardware is doing this?

73 David G3YYD

-----Original Message-----
From: RTTY [mailto:rtty-bounces at contesting.com] On Behalf Of Joe Subich,
W4TV
Sent: 27 April 2015 15:09
To: rtty at contesting.com
Subject: Re: [RTTY] More GRITTY observations


> Do you have any insight into the source of those slowish 
> transmissions? A particular RTTY program or product? Or a particular 
> hardware device?

(1) The K3 paddle to RTTY mode where the user is not "leading" the rig.  (2)
MMTTY where the user has set Char. Wait/Diddle Wait higher than the very
left edge of the slider.  (3) MMTTY with "Limiting Speed" - character pacing
is 170 ms instead of 165 ms/stop bit is
~40 ms. (4) any software with Diddle = OFF and hand typing (most users can't
maintain 60 WPM).

> IF I remember correctly, Joe W4TV write a summary about serial port 
> UARTs several years ago, describing the compromises inherent in 
> getting 45.45 baud FSK from a serial port. Perhaps Joe can refresh my 
> memory?

In my testing, a lot of UARTs appear to be generating 2 stop bits instead of
1.5 stop bits.  That, in addition to the Windows API which forces integer
baud rates which makes 45.45 into 45 baud.

> It seems like 2Tone and GRITTY have "flywheels" that don't necessarily 
> wait for the start bit - this works well for full-speed signals, but 
> when the gap between stop and start bit is stretched it doesn't work 
> so well.

IIRC, G3YYD disables the "flywheel" if the stop bit is stretched.  He will
need to confirm that.

73,

    ... Joe, W4TV


On 2015-04-27 10:43 AM, Larry Gauthier (K8UT) wrote:
> Tim,
>
> Thanks for sharing. I am particularly interested in your statement 
> that "MMTTY works better on "slowish RTTY" senders", which lends 
> credence to the notion that the best way to improve RTTY reception is 
> to improve RTTY transmission. Do you have any insight into the source 
> of those slowish transmissions? A particular RTTY program or product? 
> Or a particular hardware device?
>
> IF I remember correctly, Joe W4TV write a summary about serial port 
> UARTs several years ago, describing the compromises inherent in 
> getting
> 45.45 baud FSK from a serial port. Perhaps Joe can refresh my memory?
>
>
> and, no - GRITTY would not decode BARTG75. I ended up with just 2tone 
> and MMTTY in that contest yesterday.
>
> -larry (K8UT)
> -----Original Message----- From: Tim Shoppa
> Sent: Monday, April 27, 2015 10:02 AM
> To: rtty at contesting.com
> Subject: [RTTY] More GRITTY observations
>
> Used three decoders in SP DX contest this past weekend. One each of 
> MMTTY, 2Tone, and GRITTY.
>
> The fabulous 15M openings to JA and YB we've had the past couple weeks 
> in my mornings, were a real treat.
>
> The signals that 2Tone worked well on, GRITTY worked well on too. Hard 
> to pick a clear winner, glad to have all three up and in play. I 
> especially paid attention on weak signals.
>
> I usually completely disable squelch in other simpler decoders but 
> have not really arrived at the right squelch setting for GRITTY. 
> Probably I shouldn't mess with it. Clearly there is some interaction 
> between bandwidth and GRITTY decoding squelch that I haven't quite gotten
the feel of.
>
> The dynamic range of the GRITTY waterfall is superb. It is good for 
> "Seeing" weak signals in the noise.
>
> GRITTY AFC is superb. I hate hate hate MMTTY AFC, if I leave it on all 
> the time it wanders off to infinity. 2Tone AFC works well on longer 
> transmissions but with short contest exchanges it often doesn't have 
> time to keep up. GRITTY AFC was just superb for the off-frequency callers.
> Correct me if I'm wrong, but it looks like it could "back-decode" 
> after switching AFC frequency.
>
> I have noticed there are some "slowish RTTY" senders out there with 
> odd longer no-deedle idles between characters. MMTTY decodes these 
> well, but 2Tone and GRITTY struggled with these. It seems like 2Tone 
> and GRITTY have "flywheels" that don't necessarily wait for the start 
> bit - this works well for full-speed signals, but when the gap between 
> stop and start bit is stretched it doesn't work so well.
>
> I did succesfully adjust MMTTY and 2Tone for the 75 baud BARTG. I 
> don't think GRITTY supports 75 baud, but I've never been good at 
> reading documentation :-).
>
> Tim N3QE
> _______________________________________________
> RTTY mailing list
> RTTY at contesting.com
> http://lists.contesting.com/mailman/listinfo/rtty
> _______________________________________________
> RTTY mailing list
> RTTY at contesting.com
> http://lists.contesting.com/mailman/listinfo/rtty
>
_______________________________________________
RTTY mailing list
RTTY at contesting.com
http://lists.contesting.com/mailman/listinfo/rtty



More information about the RTTY mailing list