[RTTY] More GRITTY observations

Joe Subich, W4TV lists at subich.com
Mon Apr 27 11:08:53 EDT 2015


> 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
>


More information about the RTTY mailing list