k6sti
06-14-2009, 08:56 PM
RDSP is my working name for a proposed RDS decoder implemented with
digital signal processing. The DSP code runs on your PC using the
composite stereo signal from your tuner. You obtain the composite either
from the tuner's horizontal scope output or from an internal connection
to its FM detector. The system would not work with tuners like the Sony
XDR-F1HD or Sangean HDT-1X that provide no access to the composite
signal. The composite connects either to a 192-ksps sound card or to a
small interface circuit of a few chips that feeds any sound card. The
system probably would be designed to use one or the other, not both.
The main purpose of RDSP is to decode the RDS PI callsign for extremely
unfavorable signals. It should be possible to improve decoding
sensitivity and speed by one to two orders of magnitude over existing
decoders. The software would be able to decode meteor pings as well
as utilize coherent signal integration to increase S/N 10-20 dB for
longer-lasting signals. This means that you should be able to reliably
decode a PI callsign even for weak, noisy signals. Simultaneous decoding
with multiple time constants and filtering options is possible, with
results presented in a way that allows quick visual interpretation in
complex situations. It should be possible to classify, track, and
integrate multiple swapping signals on one frequency. Although the RDS
protocol uses powerful error correction, it may be possible to extend
sensitivity for corrupted codes by making maximum-likelihood estimates
of clobbered bits, perhaps with the help of a callsign dictionary. The
program could save all output in a time- and frequency-stamped log file
for later review.
I have been thinking of implementing something like this for several
years, but a recent Es opening provided further impetus. It took my
HDT-1X nearly a half hour of interrupted monitoring to finally decode
KCND in North Dakota on what I thought was a pretty clean signal. This
was frustrating. The station was identifying itself eleven times per
second, but the tuner couldn't recover the information. I wondered how
many weak signals I had tuned past during the opening were transmitting
RDS that I never saw. How many of them were double-hop? I know it's
possible to do a great deal better.
I'm not at all sure I want to expend the time and effort necessary to
create RDSP. But I'm curious how many people might be interested in
such a system. If I decide not to do it, perhaps this might inspire
someone else. If I do decide to go ahead, my goal would be to have
something available by the 2010 summer Es season.
Brian
digital signal processing. The DSP code runs on your PC using the
composite stereo signal from your tuner. You obtain the composite either
from the tuner's horizontal scope output or from an internal connection
to its FM detector. The system would not work with tuners like the Sony
XDR-F1HD or Sangean HDT-1X that provide no access to the composite
signal. The composite connects either to a 192-ksps sound card or to a
small interface circuit of a few chips that feeds any sound card. The
system probably would be designed to use one or the other, not both.
The main purpose of RDSP is to decode the RDS PI callsign for extremely
unfavorable signals. It should be possible to improve decoding
sensitivity and speed by one to two orders of magnitude over existing
decoders. The software would be able to decode meteor pings as well
as utilize coherent signal integration to increase S/N 10-20 dB for
longer-lasting signals. This means that you should be able to reliably
decode a PI callsign even for weak, noisy signals. Simultaneous decoding
with multiple time constants and filtering options is possible, with
results presented in a way that allows quick visual interpretation in
complex situations. It should be possible to classify, track, and
integrate multiple swapping signals on one frequency. Although the RDS
protocol uses powerful error correction, it may be possible to extend
sensitivity for corrupted codes by making maximum-likelihood estimates
of clobbered bits, perhaps with the help of a callsign dictionary. The
program could save all output in a time- and frequency-stamped log file
for later review.
I have been thinking of implementing something like this for several
years, but a recent Es opening provided further impetus. It took my
HDT-1X nearly a half hour of interrupted monitoring to finally decode
KCND in North Dakota on what I thought was a pretty clean signal. This
was frustrating. The station was identifying itself eleven times per
second, but the tuner couldn't recover the information. I wondered how
many weak signals I had tuned past during the opening were transmitting
RDS that I never saw. How many of them were double-hop? I know it's
possible to do a great deal better.
I'm not at all sure I want to expend the time and effort necessary to
create RDSP. But I'm curious how many people might be interested in
such a system. If I decide not to do it, perhaps this might inspire
someone else. If I do decide to go ahead, my goal would be to have
something available by the 2010 summer Es season.
Brian