From: Dave Platt <dplatt@radagast.org>
To: "David A. Ranch" <dranch@trinnet.net>
Cc: Linux-Hams <linux-hams@vger.kernel.org>
Subject: Re: Fldigi and RTTY decodes
Date: Sat, 05 Sep 2009 19:43:55 -0700 [thread overview]
Message-ID: <4AA321EB.4080807@radagast.org> (raw)
In-Reply-To: <4AA309E9.3040004@trinnet.net>
David A. Ranch wrote:
>
> Hello Everyone,
>
> I'm a new HAM but not new to Linux. I've been using Fldigi for
> monitoring BPSK31, etc. with good luck but I've been finding that RTTY
> rarely works. It maybe decodes 10% of the time even with a strong
> signal. It also seems the good decodes are specific to a given remote
> handle's QSO.
>
> I stumbled upon something today which I bet has a major impact on the
> RTTY decoding and I was curious about the group's thoughts.
#snip#
> So my questions for the net are:
>
> 1. What's more common on the digital bands? FSK RTTY or AFSK RTTY?
> If it's FSK RTTY, are people using TNCs to do RTTY vs. soundcard-based
> solutions?
My guess is that direct FSK is more common among hams who have
been on the air for decades and are using older radios. Most
newer setups probably use TNCs (or soundcard equivalents) fed
into SSB modulators, and are thus AFSK.
As I understand the math: there is no actual difference in the RF
waveform and content, between:
(1) a "true FSK" signal - e.g. one in which a single oscillator is
directly "pulled" by a certain amount (the frequency shift) by
a baseband signal (the one/zero bit), and
(2) a sideband-synthesized signal, in which a non-changing RF
carrier is modulated (SSB) via an AFSK signal whose audio
frequency shift is equal to the desired RF shift and where
the shift is controlled by the one/zero-bit baseband signal.
Now, this equivalence assumes that the sideband modulation process
is perfect - that is, that the carrier is completely suppressed, and
that the opposite sideband is completely filtered out.
This isn't ever actually the case, of course... no sideband modulator
is perfect. So, in that sense, a "true" or direct-FSK RTTY signal may
produce a more "pure" modulated RF signal.
On the other hand, it may be easier to get exactly the right frequency
shift with an AFSK process - "pulling" a crystal or VCO by an exact
amount isn't always easy.
This equivalence also assumes that you've got your shift convention
correct... i.e. is a 1-bit signified by a higher RF frequency than
a 0-bit, or by a lower RF frequency? If the receiving station tries
to use the incorrect shift convention for a given QSO, the signal won't
decode - it'll be gibberish.
You can transmit *either* shift convention with either FSK or
AFSK-into-SSB.
FLdigi "prefers" to use AFSK, since that's what a soundcard-
into-audio-input system is naturally set up for. The auxiliary
circuit is FSK is interesting, and would be primarily of use (I
imagine) with special-function RTTY radios set up for baseband-
controlled FSK and which don't have a mic (or which have a poor
SSB modulator which doesn't handle AFSK cleanly).
> 2. Is there a way to determine if a given RTTY transmission is FSK vs.
> AFSK? I have fairly good ears but maybe it's impossible to hear the
> difference with background noise?
You could look at a wider area (say, 10 kHz) around the signal center
frequency with some sort of spectrum analyzer. If you can see a
residual bit of carrier a few kHz away from the RTTY tones, and perhaps
even see a "ghost image" of the RTTY tones twice as far away, then it's
a good bet that you're looking at an AFSK signal fed into an SSB
modulator, and the modulator has imperfect carrier and opposite-
sideband suppression.
On the other hand, if the RF signal appears pure (no suppressed
carrier or opposite-sideband residue), then it could be FSK, or
it could be a really good SSB modulator transmitting an AFSK
signal.
>
> 3. Can FLdigi still decode FSK-based RTTY? Maybe this is only a Tx
> limitation?
FLdigi should be able to decode either with equal clarity, as long as
you get the shift direction correct, because they're essentially the
same signals in the RF domain.
If you fail to decode a soecific signal, try reversing the shift
direction on receive. You might be able to do this within FLdigi
(I imagine it has an option for this), or could do it by switching
from USB to LSB (or vice versa) and re-tuning to reacquire the signal.
next prev parent reply other threads:[~2009-09-06 2:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-31 14:27 AX25 help site Douglas Cole
2009-08-31 22:48 ` Curt, WE7U
2009-09-01 1:06 ` Bob Nielsen
2009-09-01 22:06 ` w8iss
2009-09-01 22:59 ` Dave Platt
2009-09-05 1:32 ` Curt, WE7U
2009-09-05 16:04 ` Matti Aarnio
2009-09-05 18:14 ` Dave Platt
2009-09-06 1:01 ` Fldigi and RTTY decodes David A. Ranch
2009-09-06 2:43 ` Dave Platt [this message]
2009-09-06 3:29 ` David A. Ranch
2009-09-06 4:52 ` Dave Platt
2009-09-05 20:40 ` AX25 help site David Ranch
2009-09-05 22:20 ` Dave Platt
2009-09-05 1:01 ` Curt, WE7U
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AA321EB.4080807@radagast.org \
--to=dplatt@radagast.org \
--cc=dranch@trinnet.net \
--cc=linux-hams@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox