SNR improvement algorithms
Gary Coffman
In article <32F6FB00...@ba-stuttgart.de> Uli Schnaidt <usch...@ba-stuttgart.de> writes:
>I'm looking for any algorithm that improves the SNR.
>Is there anything available? I'm especially interested in
>algorithms that gives a improvement in Morse decoding.
Well, we have to be a bit careful with terms here. There
are three quantities which we sometimes use interchangably,
but which aren't necessarily the same things at all. Those
are CNR, SNR, and Eb/No.
The basic algorithm for improving CNR is
while (CNR < desired)
{
transmitter_power++;
}
That will also work to increase SNR and Eb/No. :-)
Now we can also do some CNR improvement in the receiver by
such things as improving the receiver noise figure and limiting
the receiver passband to the occupied bandwidth of the desired
signal. If you are doing DSP at IF, a FIR filter algorithm would
be useful here. Again, this will also improve SNR and Eb/No.
We can go a step further with SNR. Here we are interested in
improving the intelligence bearing signal's power ratio vs
channel noise rather than the gross carrier power to noise
ratio. The demodulator of the receiver can play a role here.
It should be optimized to recover as much signal power as
possible while rejecting as much noise power as possible.
A synchronous detector is an example of this. This takes
advantage of coherency in the signal and redundancy in its
spectrum versus the random nature of noise. This can offer
a 3 db improvement in SNR vs CNR in the simplest case of
a DSB modulation. We can also employ post-detection baseband
filtering to further enhance SNR. This is where DSP filtering
is most commonly used today.
Now finally, we can increase Eb/No for some codes. If the signal
is coherent, synchronous, and uses uniform symbols, we can use
a perfect matched filter in the baseband, and an integrate and
dump symbol detector. This takes advantage of the fact that symbol
power will add over the symbol duration while noise power will tend
to sum to zero. We can also use other demodulation methods for certain
modulations to take advantage of the Hamming distance of various symbols
in signal space versus the random noise spectrum in signal space. This
can often yield another 6 db over raw SNR. We can also take advantage
of FEC to achieve symbol gain vs noise. This is extremely powerful,
and can allow process gains of in excess of 30 db in some cases.
Unfortunately, Morse isn't a uniform code, and is normally also not
sent in a synchronous or coherent fashion, and it doesn't support
FEC coding. Thus we can't improve its SNR or Eb/No over the raw CNR
value. That's why machine detection of Morse can be no better than
ordinary aural detection of Morse. Using other modulations and codes,
we can achieve Eb/No of 40 db or better over CNR in some cases. That's
why Morse is generally a very poor choice for weak signal coding.
Gary
--
Gary Coffman KE4ZV | You make it, | Due to provider problems
Destructive Testing Systems | we break it. | with previous uucp addresses
534 Shannon Way | Guaranteed! | Email to ke...@radio.org
Lawrenceville, GA 30244 | |
Bob Doyle
Gary Coffman wrote:
>
> In article <32F6FB00...@ba-stuttgart.de> Uli Schnaidt <usch...@ba-stuttgart.de> writes:
> >I'm looking for any algorithm that improves the SNR.
> >Is there anything available? I'm especially interested in
> >algorithms that gives a improvement in Morse decoding.
>
{cut}
>
> Unfortunately, Morse isn't a uniform code, and is normally also not
> sent in a synchronous or coherent fashion, and it doesn't support
> FEC coding. Thus we can't improve its SNR or Eb/No over the raw CNR
> value. That's why machine detection of Morse can be no better than
> ordinary aural detection of Morse. Using other modulations and codes,
> we can achieve Eb/No of 40 db or better over CNR in some cases. That's
> why Morse is generally a very poor choice for weak signal coding.
Wasn't there something called "coherent cw" in the '70s that did exactly
this? As I recall, the system used a keyer which enforced 3:1 dah/dit
ratios and was phase-locked to the carrier frequency (maybe it was
just crystal controlled -- it's been a while). I also believe that
the receiver used an analog integrate and dump detector since the
dot/dash/space timings were exactly known and integrally related.
Basically to establish communications you had to agree on a
frequency (maybe to the nearest few Hz) and a morse speed...
Gasp.
You're right though, none of that high tech stuff would help a
straight key... especially if your fist is as bad as mine...
> Gary
> --
Bob Doyle
WA3TGF
Gary Coffman
In article <32F94D2B...@primenet.com.DELETE-FOR-EMAIL> Bob Doyle <do...@primenet.com.DELETE-FOR-EMAIL> writes:
>Gary Coffman wrote:
>> Unfortunately, Morse isn't a uniform code, and is normally also not
>> sent in a synchronous or coherent fashion, and it doesn't support
>> FEC coding. Thus we can't improve its SNR or Eb/No over the raw CNR
>> value. That's why machine detection of Morse can be no better than
>> ordinary aural detection of Morse. Using other modulations and codes,
>> we can achieve Eb/No of 40 db or better over CNR in some cases. That's
>> why Morse is generally a very poor choice for weak signal coding.
>
>Wasn't there something called "coherent cw" in the '70s that did exactly
>this? As I recall, the system used a keyer which enforced 3:1 dah/dit
>ratios and was phase-locked to the carrier frequency (maybe it was
>just crystal controlled -- it's been a while). I also believe that
>the receiver used an analog integrate and dump detector since the
>dot/dash/space timings were exactly known and integrally related.
>
>Basically to establish communications you had to agree on a
>frequency (maybe to the nearest few Hz) and a morse speed...
>Gasp.
>
>You're right though, none of that high tech stuff would help a
>straight key... especially if your fist is as bad as mine...
Yeah, Bob, coherent CW is a big improvement, but it still suffers
because of the different dot and dash frequencies, IE you still
can't form an ideal matched filter for the channel because of the
different symbol timings (that costs you an average 2.39 db). You
can use integrate and dump, and that's a big win. But you've also
still got the problem that you're only transmitting energy for 40%
of the required coding information, and you've still got the problem
that the signal isn't antipodal in signal space. Combined, those two
latter factors cost you 6 db compared to a uniform code using an active
two state modulation.
Andrew Plumb
Gary Coffman <ga...@ke4zv.atl.ga.us> wrote in article
<1997Feb6.1...@ke4zv.atl.ga.us>...
[other messages deleted]
> Yeah, Bob, coherent CW is a big improvement, but it still suffers
> because of the different dot and dash frequencies, IE you still
> can't form an ideal matched filter for the channel because of the
> different symbol timings (that costs you an average 2.39 db). You
> can use integrate and dump, and that's a big win. But you've also
> still got the problem that you're only transmitting energy for 40%
> of the required coding information, and you've still got the problem
> that the signal isn't antipodal in signal space. Combined, those two
> latter factors cost you 6 db compared to a uniform code using an active
> two state modulation.
Just to toss some thoughts out there... Morse code is basically a
four-symbol, variable length code set. The four symbols being dots,
dashes, letter-spaces and word-spaces. If you pass it through the
integrate'n'dump you'll get something like QAM (4 Amplitude levels - I
think I've got the right name) offset by about half a dash pulse of
integration.
It's not a nice, "predictable" digital-type signal, but you do have leading
and trailing edges to synchronize on every dash and dot. What may help is
to pass the raw audio through some noise filtering, then pick off the
edges. You can always make the software more intelligent, have it adapt to
some of the mutual information/common letter and number combinations.
After all, CW conversations are rarely about anything more than the
weather, right? ;-)
Does this help any?
Andrew.
--
NOTE: My domain name is now io.com
Andrew Plumb, VE3SLG
E-mail: Tek...@io.com
3a...@qlink.queensu.ca
WWW: http://www.io.com/~tekmage/
Surfing digital oceans astride an analog dolphin...
Gary Coffman
In article <01bc165f$d0789980$82810f82@tekmage> "Andrew Plumb" <Tek...@io.com> writes:
>Gary Coffman <ga...@ke4zv.atl.ga.us> wrote in article
><1997Feb6.1...@ke4zv.atl.ga.us>...
>[other messages deleted]
>> Yeah, Bob, coherent CW is a big improvement, but it still suffers
>> because of the different dot and dash frequencies, IE you still
>> can't form an ideal matched filter for the channel because of the
>> different symbol timings (that costs you an average 2.39 db). You
>> can use integrate and dump, and that's a big win. But you've also
>> still got the problem that you're only transmitting energy for 40%
>> of the required coding information, and you've still got the problem
>> that the signal isn't antipodal in signal space. Combined, those two
>> latter factors cost you 6 db compared to a uniform code using an active
>> two state modulation.
>
>Just to toss some thoughts out there... Morse code is basically a
>four-symbol, variable length code set. The four symbols being dots,
>dashes, letter-spaces and word-spaces. If you pass it through the
>integrate'n'dump you'll get something like QAM (4 Amplitude levels - I
>think I've got the right name) offset by about half a dash pulse of
>integration.
Actually, there are 5 states to Morse, you left out the intra-letter
space. But only 2 of the states are transmitted when OOK is used, the
dot and the dash. So you don't get a QAM-like constellation. Instead
you get two detectable states and three unknown states that you have to
*infer* from context. This is a horrible code design for a gaussian noise
environment. (Of course OOK Morse was designed for the landline where a
high SNR is guaranteed by the nature of the transmission medium. It was
never intended to be used by radio.)
>It's not a nice, "predictable" digital-type signal, but you do have leading
>and trailing edges to synchronize on every dash and dot. What may help is
>to pass the raw audio through some noise filtering, then pick off the
>edges. You can always make the software more intelligent, have it adapt to
>some of the mutual information/common letter and number combinations.
>After all, CW conversations are rarely about anything more than the
>weather, right? ;-)
The problem with using differentiation to do edge detection is that
the edges contain very little energy, so for weak signal work they
are easily obscured by noise, and any attempt at noise filtering rounds
off the edges and destroys timing information. You need to integrate the
energy of the whole element to get it above the gaussian noise floor. But
you can't do that unless you know its timing, and you can't know that
because the code doesn't have equal length elements, so you can't be sure
a priori where one element will end and another start.
The solution to that problem for Morse is out of band clocking. By
synchronizing transmitter and receiver to an external timing reference,
the element edges can be precisely lined up on dot interval boundaries.
You can then integrate each dot interval separately and piece together
all the elements of the characters. This is what coherent CW does.
For example, an 'E' is a letter space followed by transmitted energy for
one dot interval, followed by another letter space. A 'T' is a letter space
followed by *3* consecutive dot intervals of transmitted energy followed
by another letter space. An 'A' is a letter space followed by one dot
interval of transmitted energy, one dot interval of no transmitted
energy (the intra-character space), 3 consecutive dot intervals of
transmitted energy, and finally by a letter space. Etc. Letters with
more than one element have a complicated timing sequence, but the
principle is easily implemented *provided* you know where the interval
boundaries are. That's what the external clocking does for you.
Wniform codes can carry their own embedded clock in every element, but
Morse carries it only in transmitted dots. Since you can't know a priori
when a dot is coming instead of a dash or one of the space intervals, you
can't do a good DPLL to recover the clocking information from the received
code. But using out of band clocking can solve that problem. Coherent CW
enthusiasts use a standard time signal as their external timing reference,
IE WWV, CHU, or some other standard source available to both the sending
station and the receiving station.
The other problem remains that only 2 of 5 of the states of the code are
transmitted, and the other 3 have to be inferred against the gaussian
background. This gives a serious SNR penalty for the decoder when signals
are weak or fading. With strong signals, differentiation can be used on
edges, as you suggest, and that lets you derive a clock, and lets you
synchronize your slicer to the middle of a dot interval. This makes the
decision point of whether transmitted energy is present or not in that
interval more noise immune, but that merely gets you orthogonality and
not antipodal signaling. For weak and fading signals, even an externally
clocked Morse signal suffers a 10*log(.4) = -3.98 db penalty on average
compared to a code which transmits energy for every element in an antipodal
fashion. Depending on the text being transmitted, the penalty can be worse,
but it can never be better than -3 db. Without the external clock, the
penalty is much worse.
Lacking the advantage of the out of band clocking of coherent CW,
about the best you can do is to sample the incoming signal at a
rate above the Nyquist limit for a continous dot string at the fastest
keying speed you expect to receive, then use a sliding window to examine
the energy of the signal over groups of samples to try to find where the
element edges *should* be. Then you can go back and resample the signal
using that information.
You need to be able to hold several seconds worth of samples in memory
to make this work. Once you have a trial decoding, you can use contextual
clues to evaluate it to see if it "makes sense", IE forms valid letters.
If it doesn't, you can displace the clock phase and try again. (You can do
this very quickly at machine speeds, so the reception lag is essentially
only the lag attributable to the amount of sample you hold in memory at
any given time. This is a serious case of "copying behind". A manual
operator can't hold this much information in his head, so he can't copy
this far behind.)
This can get you the most probable alphabetic sequence which was sent,
but there is no deterministic way of gauging a confidence factor for
that probability. You can't know whether an element was corrupted by
channel impairments, or whether it was actually transmitted in error,
IE the other operator made a keying error (you can use a soft decision
heuristic in the slicer to give you clues about when you might have
experienced a channel impairment however). You can then apply a heuristic
to see if the alphabetic string *spells* something which makes sense, or
whether it is just gibberish. If it is gibberish, you've probably made
an error in element timing extraction, but it could be that the sending
operator is just a chronic misspeller. (This is where the human operator
has an advantage, he can apply a more complex heuristic to determining
if what is spelled, or misspelled, makes sense.)
There is no absolute assurance possible that you've received and
decoded the message properly because there is no explicit error
check sequence sent. Nor can simple repetition of a message assure
you of eventually getting it through error free. Every attempt
could have one or more errors, distributed in different parts
of the message, but you have no idea *where*, so you can't combine
the retries to form a complete message. If FEC were used, however,
you could know where the errors were in each attempt, and if there
weren't too many consecutive errors, correct them on the fly. You
could expect with confidence to be able to eventually piece together
the entire correct message. And you can statistically expect to
do it with many fewer retries than if you only know an error exists.
If you can't even know an error exists, then the situation becomes
hopeless. That's the case with hand sent Morse, you can never be 100%
sure you've copied what the other operator intended to send. (With
fairly strong signals, you can be *pretty* sure you've copied it
correctly, but never 100% sure.)
Modern codes and protocols *can* give you 100% assurance that you
have a correct copy of the message sent. And antipodal modulations
give you a *minimum* 6 db advantage in gaussian noise over OOK.
Combining FEC coding gain with the coherent antipodal signaling
of a modern signaling system, you can expect to operate (with some
level of retries) at signal levels as much as 30 db (raw SNR number)
below where OOK Morse operation (at the same rate) is possible.
The advantage acrued in Eb/No is much less, *but* because you don't
know where the bits *are*, you can't exploit Morse beyond raw SNR,
so you can't realize the full Eb/No potential of the Morse signal.
You can exploit the full Eb/No potential with a modern coding, and
that's where the big coding gain advantage occurs for modern techniques.
Note that the integrate and dump technique gives you a Eb/No
gain which is proportional to the square root of the bit time.
In other words, for every 4x you slow the code rate, you get
a 3 db improvement in Eb/No. Now in practice, a human operator
cannot work much below 5 WPM in a gaussian noise channel. The
mental integrator doesn't have a long enough time constant.
But machine sent codes can be slowed to an arbitrary degree.
This is exploited by the Lowfers in systems where a bit time
is up to 100 seconds in duration. That gives a 13.9 db improvement
in Eb/No over the best which a human operator can achieve by ear
with Morse. Combined with the other factors listed above, this
can allow signals to be copied which are 50 db (raw SNR) below
the threshold of audible copy for Morse. (And that's with zero
decoding errors too.)
Now that may not sound very useful, but using a compression technique
called "common codebook compression", it is easily possible to compress
20 WPM text into a 3.33 bps transmission rate, IE a compression factor
of 7.2:1. So instead of taking 2,400 seconds to send 20 words, you can
send them in 333 seconds. That's slow, but for the low content of the
typical amateur QSO, it isn't intolerably slow given that the SNR can
be more than 50 db below the weakest level usable by ordinary by hand
and by ear OOK Morse. (Note that's raw SNR in a fixed bandwidth capable
of holding either emission. The Eb/No can't go negative, at least not
more negative than -1.6 db, because of the Shannon limit. What's being
exploited here is the gross difference between OOK Morse and a better
technique in the *utilization* of the available Eb/No.)
Note too, that if you *don't* slow things down, IE if you maintain
the 20 WPM information rate, this technique is also a way to pack
many more QSOs into a given amount of spectrum than achievable using
ordinary OOK Morse. As noted in another post, 20 WPM OOK Morse occupies
about 83 Hz, this emission can be coded efficiently into 1.665 Hz. That
gives a band packing density of 50x what is possible with OOK Morse.
And since it is antipodal and coherent, and can use FEC, it can still
operate at least 30 db (raw SNR) below the level at which 20 WPM OOK
Morse becomes unusable. This means less QRM because everyone can run
less power, and that can improve frequency reuse, so packing densities
beyond 50x become practical. Who said our bands are too crowded?
They are only crowded if we persist in using inferior techniques.
Paul E. Campbell
Gary Coffman (ga...@ke4zv.atl.ga.us) wrote:
: In article <01bc165f$d0789980$82810f82@tekmage> "Andrew Plumb" <Tek...@io.com> writes:
: >Gary Coffman <ga...@ke4zv.atl.ga.us> wrote in article
: ><1997Feb6.1...@ke4zv.atl.ga.us>...
: >[other messages deleted]
[likewise]
: The problem with using differentiation to do edge detection is that
: the edges contain very little energy, so for weak signal work they
: are easily obscured by noise, and any attempt at noise filtering rounds
: off the edges and destroys timing information. You need to integrate the
: energy of the whole element to get it above the gaussian noise floor. But
: you can't do that unless you know its timing, and you can't know that
: because the code doesn't have equal length elements, so you can't be sure
: a priori where one element will end and another start.
True enough...you are much better if you want to go this route to try to
detect the "middle" of a pulse..that's precisely how the newer GRAPES
modems work..they estimate the timing for the middle of the pulse and do
their sampling at that point.
: The solution to that problem for Morse is out of band clocking. By
: synchronizing transmitter and receiver to an external timing reference,
: the element edges can be precisely lined up on dot interval boundaries.
: You can then integrate each dot interval separately and piece together
: all the elements of the characters. This is what coherent CW does.
This is all a problem of SYNCHRONIZATION. You've mentioned an external
synchronization mechanism here.
: The other problem remains that only 2 of 5 of the states of the code are
: transmitted, and the other 3 have to be inferred against the gaussian
: background. This gives a serious SNR penalty for the decoder when signals
: are weak or fading. With strong signals, differentiation can be used on
: edges, as you suggest, and that lets you derive a clock, and lets you
: synchronize your slicer to the middle of a dot interval. This makes the
: decision point of whether transmitted energy is present or not in that
: interval more noise immune, but that merely gets you orthogonality and
: not antipodal signaling. For weak and fading signals, even an externally
: clocked Morse signal suffers a 10*log(.4) = -3.98 db penalty on average
: compared to a code which transmits energy for every element in an antipodal
: fashion. Depending on the text being transmitted, the penalty can be worse,
: but it can never be better than -3 db. Without the external clock, the
: penalty is much worse.
There is something else you can look for though...assuming that your CW
keyer uses a gated oscillator, then you can lock onto the phase/timing of
the oscillator. It's not antipodal signalling, but it will still work very
well because you can eliminate a lot of noise by a simple deconvolution.
Better yet..if the "edge" shapes on the pulses are well known, you may also
be able to combat pulse noise and/or fading with knowledge of what a pulse
edge is supposed to look like vs. that choppy spike and/or slow fadeout
that you see.
Also, you are dealing with a channel with erasures here. So you get three
possible states: keyed, not keyed, erased. There's an ambiguity with the
not keyed/erased case. So what you do is try both cases and see which one
makes the most sense (has the highest probability of being correct).
: Lacking the advantage of the out of band clocking of coherent CW,
: about the best you can do is to sample the incoming signal at a
: rate above the Nyquist limit for a continous dot string at the fastest
: keying speed you expect to receive, then use a sliding window to examine
: the energy of the signal over groups of samples to try to find where the
: element edges *should* be. Then you can go back and resample the signal
: using that information.
This is an application of the Viterbi algorithm. You just need to insert
feedback which estimates timing. The Viberbi algorithm provides the
maximum likelihood function of the state tree with controllable complexity.
: You need to be able to hold several seconds worth of samples in memory
: to make this work.
Nope..the Viterbi algorithm gives you a general structure for that problem.
Tree coders and such also work the same way.
: Once you have a trial decoding, you can use contextual
: clues to evaluate it to see if it "makes sense", IE forms valid letters.
: If it doesn't, you can displace the clock phase and try again. (You can do
: this very quickly at machine speeds, so the reception lag is essentially
: only the lag attributable to the amount of sample you hold in memory at
: any given time. This is a serious case of "copying behind". A manual
: operator can't hold this much information in his head, so he can't copy
: this far behind.)
Do it in two stages. First make estimates on the "carrier present/no carrier
present" decision. Then move up to contextual decoding. The reason for two
stages is that you really cut down on the amount of data by time you get to
the context stage of the game.
: This can get you the most probable alphabetic sequence which was sent,
: but there is no deterministic way of gauging a confidence factor for
: that probability. You can't know whether an element was corrupted by
: channel impairments, or whether it was actually transmitted in error,
: IE the other operator made a keying error (you can use a soft decision
: heuristic in the slicer to give you clues about when you might have
: experienced a channel impairment however). You can then apply a heuristic
: to see if the alphabetic string *spells* something which makes sense, or
: whether it is just gibberish. If it is gibberish, you've probably made
: an error in element timing extraction, but it could be that the sending
: operator is just a chronic misspeller. (This is where the human operator
: has an advantage, he can apply a more complex heuristic to determining
: if what is spelled, or misspelled, makes sense.)
Actually there is. It's called "soft decoding". Unfortunately, a screwed
up transmission is harder to judge..but the same soft decoding algorithm
will still make a best guess. You may dip into the realm of synchronization
errors (missed "dot") for instance, but the principle is the same.
: There is no absolute assurance possible that you've received and
: decoded the message properly because there is no explicit error
: check sequence sent. Nor can simple repetition of a message assure
: you of eventually getting it through error free. Every attempt
: could have one or more errors, distributed in different parts
: of the message, but you have no idea *where*, so you can't combine
: the retries to form a complete message. If FEC were used, however,
: you could know where the errors were in each attempt, and if there
: weren't too many consecutive errors, correct them on the fly. You
: could expect with confidence to be able to eventually piece together
: the entire correct message. And you can statistically expect to
: do it with many fewer retries than if you only know an error exists.
: If you can't even know an error exists, then the situation becomes
: hopeless. That's the case with hand sent Morse, you can never be 100%
: sure you've copied what the other operator intended to send. (With
: fairly strong signals, you can be *pretty* sure you've copied it
: correctly, but never 100% sure.)
There are ways to combine results. With hard decisions, do the old "best 2
out of 3" approach. With soft decisions, you can weight the received data
according to how good it looks.
: Modern codes and protocols *can* give you 100% assurance that you
: have a correct copy of the message sent.
Nope. This is never true. But you can reduce the probability of error to
say somewhat less probable than the chance of all of the electrons in your
radio tunnelling out into space simultaneously.
: And antipodal modulations give you a *minimum* 6 db advantage in gaussian
: noise over OOK.
At the expense of synchronization problems. There are some heavy advantages
to orthogonal modulations, such as robustness in the face of noise and
trivial suboptimal or nearly optimal receivers.
: Combining FEC coding gain with the coherent antipodal signaling
: of a modern signaling system, you can expect to operate (with some
: level of retries) at signal levels as much as 30 db (raw SNR number)
: below where OOK Morse operation (at the same rate) is possible.
True enough...then if you go to a turbo code, you can operate at 0.5 dB
or even a little below that (negative decibels) at a coding rate of around
0.25. And at that point, even using computers and some serious horsepower
to beat out human operators, they're not even close to error rates of less
than 1%.
: The advantage acrued in Eb/No is much less, *but* because you don't
: know where the bits *are*, you can't exploit Morse beyond raw SNR,
: so you can't realize the full Eb/No potential of the Morse signal.
: You can exploit the full Eb/No potential with a modern coding, and
: that's where the big coding gain advantage occurs for modern techniques.
Ahem...realize that in almost ALL of the information that you are quoting
from, they conveniently IGNORE the problem of synchronization. Synchronization
is NOT necessarily a trivial and/or solved problem, especially if you want
burst and/or packet transmission. Morse code is an orthogonal, not antipodal,
code, so you can't trivially make the "on/off/erasure" decision, but it's
not as bad as you make it out to be. Remember...antipodal signals get you
a net gain of only 3dB (assuming coherence in both cases). And quadrature
signalling gets you double the bandwidth at the same SNR.
The reason I'm harping on synchronization is that I've been working on
designing a high speed packet relay in the range of 1 mbps with packet
sizes on the order of less than 10,000 bits (for switching
purposes). At that size, if you were going to go for say spread spectrum with
a spreading rate of say 100, without a matched filter and lots of other
tricks, you are dead in the water because a sliding synchronizer which takes
a half second or so is just way too slow. And that's a typical implementation.
Paul Keinänen
peca...@mtu.edu (Paul E. Campbell) wrote:
>Gary Coffman (ga...@ke4zv.atl.ga.us) wrote:
>: In article <01bc165f$d0789980$82810f82@tekmage> "Andrew Plumb" <Tek...@io.com> writes:
>: >Gary Coffman <ga...@ke4zv.atl.ga.us> wrote in article
>: ><1997Feb6.1...@ke4zv.atl.ga.us>...
>: >[other messages deleted]
>
>[likewise]
<deleted>
>: Once you have a trial decoding, you can use contextual
>: clues to evaluate it to see if it "makes sense", IE forms valid letters.
>: If it doesn't, you can displace the clock phase and try again. (You can do
>: this very quickly at machine speeds, so the reception lag is essentially
>: only the lag attributable to the amount of sample you hold in memory at
>: any given time. This is a serious case of "copying behind". A manual
>: operator can't hold this much information in his head, so he can't copy
>: this far behind.)
>
>Do it in two stages. First make estimates on the "carrier present/no carrier
>present" decision.
How many levels should this decision produce, 2 , 4 or, say 10 ? (e.g.
99 % certainity carrier present, 75 % certainity carrier present, 75 %
certainity no carrier or 99 % certainity no carrier).
> Then move up to contextual decoding. The reason for two
>stages is that you really cut down on the amount of data by time you get to
>the context stage of the game.
It helps a lot if you can concentrate on the most "suspect" decisions.
Paul OH3LWR
Andrew Plumb
[other stuff deleted]
> >Just to toss some thoughts out there... Morse code is basically a
> >four-symbol, variable length code set. The four symbols being dots,
> >dashes, letter-spaces and word-spaces. If you pass it through the
> >integrate'n'dump you'll get something like QAM (4 Amplitude levels - I
> >think I've got the right name) offset by about half a dash pulse of
> >integration.
>
> Actually, there are 5 states to Morse, you left out the intra-letter
> space. But only 2 of the states are transmitted when OOK is used, the
> dot and the dash. So you don't get a QAM-like constellation. Instead
> you get two detectable states and three unknown states that you have to
> *infer* from context. This is a horrible code design for a gaussian noise
> environment. (Of course OOK Morse was designed for the landline where a
> high SNR is guaranteed by the nature of the transmission medium. It was
> never intended to be used by radio.)
[rest deleted]
Gary,
You make a lot of good points and clearly understand communications and
information theory; I think I should clarify/elaborate on my thoughts.
Yes, there are two OOK format signaling states in CW (the signaling
"alphabet" - 0,1); symbols are generated by combinations of these states
over time. I'm thinking of the dots, dashes, letter-spaces and word-spaces
symbols as variable length codewords. The empty/off portion separating
dots from dashes is a suffix of the symbol. If you think of it in Digital
terms, a dot is (111111100000), a dash is (11111111111100000), a
letter-space is (00000000000) and a word-space is "longer than a
letter-space".
You may have noise in the sampling instances, but the ADC usually samples
much more frequently than the human hand sends the code. Dashes have more
1's than dots and about the same number of trailing 0's; letter-spaces have
more 0's than dots and dashes and word-spaces have more 0's than all the
others. It's just a little adaptive filtering; there are known average
dot, dash, letter-space and word-space that can be used as starting points.
The QAM-like constellation I was referring to is what you'd get after
sending this VLC through your sample-and-hold/periodic-integrator. You
would need to bias the decision threshold so that dashes appear above dots
above the "zero", with the letter-spaces above the word-space, both below
the "zero".
It's all software and very sharp band-pass filtering. ;-)
Yes, signaling systems like QPSK are significantly more efficient, IF you
have the equipment to encode and decode the signals in the first place.
The beauty lies in the fact that you don't NEED a computer to encode or
decode CW; it's the most "flexible" human-computer, computer-computer,
human-human information transmission mode I know of. Voice wastes
bandwidth, voice-recognition on a computer is MUCH more computationally
intensive and computer voices leave a great deal to be desired. I propose
we convert all voice bands to digital and keep the CW portions since
obviously they are far more efficient. (Just kidding. hi hi :-)
It's all a matter of perspective. Most people I know can't listen to an
ASCII bit stream, even at slow speed, and determine what the computer is
transmitting. ;-)
Gary Coffman
In article <3304ef53....@news.sci.fi> kein...@sci.fi (Paul Keinänen) writes:
>peca...@mtu.edu (Paul E. Campbell) wrote:
>>Gary Coffman (ga...@ke4zv.atl.ga.us) wrote:
>>: Once you have a trial decoding, you can use contextual
>>: clues to evaluate it to see if it "makes sense", IE forms valid letters.
>>: If it doesn't, you can displace the clock phase and try again. (You can do
>>: this very quickly at machine speeds, so the reception lag is essentially
>>: only the lag attributable to the amount of sample you hold in memory at
>>: any given time. This is a serious case of "copying behind". A manual
>>: operator can't hold this much information in his head, so he can't copy
>>: this far behind.)
>>
>>Do it in two stages. First make estimates on the "carrier present/no carrier
>>present" decision.
>
>99 % certainity carrier present, 75 % certainity carrier present, 75 %
>certainity no carrier or 99 % certainity no carrier).
It depends on the channel quality, of course. For most HF channels,
4 levels, or at most 8, reach the point of diminishing returns for
FEC armored data transmissions.
>> Then move up to contextual decoding. The reason for two
>>stages is that you really cut down on the amount of data by time you get to
>>the context stage of the game.
>
>It helps a lot if you can concentrate on the most "suspect" decisions.
That's true for data communications which is using FEC. An erasure
is much more valuable to the algorithm than a suspect bit. But for
Morse copy, there is no FEC, and erasures are much less valuable.
You may be more effective just using contextual clues to see if the
element "makes sense" rather than depending on a soft decision
decoder's flagging of suspect carrier sense. Remember, with non-
coherent Morse, you aren't even sure you are sampling during an
element interval at this point, so the soft decision isn't really
telling you anything useful.
Paul Keinänen
ga...@ke4zv.atl.ga.us (Gary Coffman) wrote:
>In article <3304ef53....@news.sci.fi> kein...@sci.fi (Paul Keinänen) writes:
<deleted>
>>
>>It helps a lot if you can concentrate on the most "suspect" decisions.
>
>That's true for data communications which is using FEC. An erasure
>is much more valuable to the algorithm than a suspect bit.
True.
>But for
>Morse copy, there is no FEC, and erasures are much less valuable.
>You may be more effective just using contextual clues to see if the
>element "makes sense" rather than depending on a soft decision
>decoder's flagging of suspect carrier sense.
Morse code is an early form of text compression using the shortest
codes for the most common characters. There was an article in Wireless
World "Did Morse get it right" (or a similar title) showing the
effectiveness for encoding plain text in certain languages and not so
effective, when encoding plain text in other languages.
Anyway, the problem with compression and in particular variable length
coding is that it requires a reliable transport medium, either with a
high SNR or some form of FEC. OOK Morse is a vulnerable form of
variable length coding, since it is very easy to loose character synch
due to a single bit failure. If you have a short sequence of dots and
dashes with some suspect dots, dashes or spaces in the middle, you can
start from both ends (where you had a solid copy) and scanning towards
the suspect area in the middle. Playing around with the suspect
elements, you can then try to determine by contextual clues, if there
is an inter character space at all in the suspect area and if so,
where exactly it is. This will help to reduce the possibilities in the
contextual search.
>Remember, with non-
>coherent Morse, you aren't even sure you are sampling during an
>element interval at this point, so the soft decision isn't really
>telling you anything useful.
When receiving Morse code sent with an electronic keyer, it does not
take a lot of characters to determine the dot rate and then rescanning
the message with the correct dot rate and only have to adjust the bit
time with +/- 0.5 dot time for each character or word (depending of
the habits of the operator). To effectively decode signals sent with a
straight key, you need a much larger sample to determine the "fist" of
the operator and then rescanning the message from the beginning.
Paul OH3LWR
Gary Coffman
In article <330ff0b6....@news.sci.fi> kein...@sci.fi (Paul Keinänen) writes:
>ga...@ke4zv.atl.ga.us (Gary Coffman) wrote:
><deleted>
>>But for
>>Morse copy, there is no FEC, and erasures are much less valuable.
>>You may be more effective just using contextual clues to see if the
>>element "makes sense" rather than depending on a soft decision
>>decoder's flagging of suspect carrier sense.
>
>Morse code is an early form of text compression using the shortest
>codes for the most common characters. There was an article in Wireless
>World "Did Morse get it right" (or a similar title) showing the
>effectiveness for encoding plain text in certain languages and not so
>effective, when encoding plain text in other languages.
Yes, Morse used the printer's typebox count to determine frequency,
but 1840s prose doesn't map terribly well to the sorts of messages
we typically send via radio. Worse, the most frequently used letters
are encoded with the least amount of transmitted information, thus
making them the least likely to be decoded correctly in noise (the
more information conveyed about a character, the more of it we can
lose without totally being unable to recover the character). That's
a ghastly decision for weak signal work.
With a uniform code, every character is encoded with the same amount
of transmitted information, so frequently used letters are as likely
to be decoded correctly as the least frequently used letters. With Morse,
the least frequently used characters are conveyed with the greatest amount
of transmitted information while the most frequently used characters are
transmitted with the least. Thus the most frequent characters are also
the ones most frequently decoded in error. Bad plan.
>Anyway, the problem with compression and in particular variable length
>coding is that it requires a reliable transport medium, either with a
>high SNR or some form of FEC. OOK Morse is a vulnerable form of
>variable length coding, since it is very easy to loose character synch
>due to a single bit failure. If you have a short sequence of dots and
>dashes with some suspect dots, dashes or spaces in the middle, you can
>start from both ends (where you had a solid copy) and scanning towards
>the suspect area in the middle. Playing around with the suspect
>elements, you can then try to determine by contextual clues, if there
>is an inter character space at all in the suspect area and if so,
>where exactly it is. This will help to reduce the possibilities in the
>contextual search.
Sounds like "turbo" coding. :-)
You're right, scanning and rescanning is a very helpful method of
extracting the most information from the signal. The Morse Code's
design is *not* helpful in this regard, however. It offers no
consistent built in clues to aid the process.
>>Remember, with non-
>>coherent Morse, you aren't even sure you are sampling during an
>>element interval at this point, so the soft decision isn't really
>>telling you anything useful.
>
>When receiving Morse code sent with an electronic keyer, it does not
>take a lot of characters to determine the dot rate and then rescanning
>the message with the correct dot rate and only have to adjust the bit
>time with +/- 0.5 dot time for each character or word (depending of
>the habits of the operator). To effectively decode signals sent with a
>straight key, you need a much larger sample to determine the "fist" of
>the operator and then rescanning the message from the beginning.
The latter can be nearly impossible with some of the ragged fists
heard on the air. Uniformity of timing is essential to good weak
signal extraction, and most hand sent Morse is remarkably lacking
in uniformity. Even with an electronic keyer, character and word
pacing can vary wildly from one letter or word to another. This
really hurts the ability to extract the signal from noise. Morse
sent from a keyboard buffer is much easier to process in noise
than hunt and peck text, and that's better than hand sent text.
Gary Coffman
In article <01bc1aa7$971aae20$75810f82@tekmage> "Andrew Plumb" <Tek...@io.com> writes:
>Gary Coffman <ga...@ke4zv.atl.ga.us> wrote in article
>> >four-symbol, variable length code set. The four symbols being dots,
>> >dashes, letter-spaces and word-spaces. If you pass it through the
>> >integrate'n'dump you'll get something like QAM (4 Amplitude levels - I
>> >think I've got the right name) offset by about half a dash pulse of
>> >integration.
>>
>> Actually, there are 5 states to Morse, you left out the intra-letter
>> space. But only 2 of the states are transmitted when OOK is used, the
>> dot and the dash. So you don't get a QAM-like constellation. Instead
>> you get two detectable states and three unknown states that you have to
>> *infer* from context. This is a horrible code design for a gaussian noise
>
>> environment. (Of course OOK Morse was designed for the landline where a
>> high SNR is guaranteed by the nature of the transmission medium. It was
>> never intended to be used by radio.)
>
>You make a lot of good points and clearly understand communications and
>information theory; I think I should clarify/elaborate on my thoughts.
Thanks.
>Yes, there are two OOK format signaling states in CW (the signaling
>"alphabet" - 0,1); symbols are generated by combinations of these states
>over time. I'm thinking of the dots, dashes, letter-spaces and word-spaces
>symbols as variable length codewords. The empty/off portion separating
>dots from dashes is a suffix of the symbol. If you think of it in Digital
>terms, a dot is (111111100000), a dash is (11111111111100000), a
>letter-space is (00000000000) and a word-space is "longer than a
>letter-space".
Well, lets clarify this a bit. OOK has two states, call them 1 and 0,
but there is no information transmitted about the 0 state. That we are
in a 0 state has to be *inferred*. This costs us 3 db compared to a
system which transmits energy for both states orthogonally (or 6 db if
the states are transmitted antipodally) against a gaussian noise background.
So OOK has a deficit in performance versus better modulations. That holds
whether the encoding of characters is done in ASCII or Morse.
In fact some clever tests have shown that humans can be trained to
understand FSK modulated Morse under weaker conditions than they can
OOK modulated Morse. This isn't just a machine decoding artifact, it
is universally true.
Now any encoding which uses a binary transmission medium has to depend
on timing to convey more than a single 1 or 0, yes or no, mark or space
statement about its condition. Morse requires information be conveyed
about when timing edges occur, and what state the system transitions
to at that moment. Other codes, such as Manchester, don't care what
state the system is in, only that a transition has occurred at a
particular time.
We can copy Morse with a sounder because we get a distinctly different
sound when the sounder transitions from the 0 to the 1 state than from
the sound we get when the sounder transitions from the 1 to the 0 state.
The order of the "click" and the "clack" give us transition *direction*.
If we were copying Manchester code by ear, all we'd need is the "click"
to tell us a transition occurred. We wouldn't care which direction the
transition took. This is useful because it reduces the amount of state
information we *have* to recover and retain to make a decoding decision.
Uniform codes provide these transitions at intervals which can be precisely
determined a priori, Morse does not. This is a major win for the uniform code
in a gaussian noise environment. That's because we can tailor a perfect
matched channel filter for the uniform code. We cannot do that for a
variable length code like Morse. This perfect matched filter maximizes
Eb/No, and hence our probability of making a correct decoding decision.
>You may have noise in the sampling instances, but the ADC usually samples
>much more frequently than the human hand sends the code. Dashes have more
>1's than dots and about the same number of trailing 0's; letter-spaces have
>more 0's than dots and dashes and word-spaces have more 0's than all the
>others. It's just a little adaptive filtering; there are known average
>dot, dash, letter-space and word-space that can be used as starting points.
The ADC *must* sample faster than the code is sent. At minimum, it must
obey the Nyquist limit. Now the faster we sample, the more *noise* we
sample, because noise has a gaussian distribution. During the 0 intervals,
*all* we sample is noise. During the 1 intervals, we get noise plus signal
in our sample. To maximize correct decoding probability we have to maximize
the ratio of signal energy to noise energy, IE Eb/No. We can't do that during
the 0 periods, because all we get is No/No. Thus the 0 periods don't
contribute to information about the signal in a positive fashion.
Now we can attempt to use adaptive filtering on the signal, but there
are several frequencies we must filter, not just the one of a uniform
code. Let me illustrate this using your notation. A dot is 111111000000.
That is a symmetrical signal and can be resolved to a single discrete
frequency, IE a Fourier transform will show a single energy peak. We
can form a matched filter around that frequency, and resolve it
maximally against gaussian noise. But now we have the dash, it is
111111111111111111000000. That is *not* symmetrical, and when we
Fourier transform it, it does *not* resolve to a single frequency
around which we can form a matched filter. The filter we can form
will have more noise energy than the filter we formed for the dot.
You say that's Ok, the dash has more signal energy than the dot.
That's true, but now lets see what happens when we mix dots and
dashes. To the dot filter, the last 12 intervals of the dash look
like a perfect dot. It is going to declare to the decision circuit
that a dot is present. The dash filter is going to declare that a
dash is present. The decision circuit is not offered a clear choice.
Now lets look at the reverse case. Lets have two dots transmitted.
111111000000111111000000. The dot filter is going to declare two
dots, but the dash filter is going to report a 66.67% probability
of a dash being decoded, IE a somewhat corrupted dash. The decision
circuit must choose, was it 2 dots, or a channel impaired dash?
It has no good information on which to base a choice. This is
why multiple symbol lengths pose a decoding problem.
And finally, we *cannot* form a matched filter for the space states.
Any filter we form returns a uniform DUH! because there is no way to
discriminate between a letter space or a word space or an intracharacter
space against a channel fade or other impairment because *no* signal is
being recovered. It is all the same gaussian spectrum in each case.
>The QAM-like constellation I was referring to is what you'd get after
>sending this VLC through your sample-and-hold/periodic-integrator. You
>would need to bias the decision threshold so that dashes appear above dots
>above the "zero", with the letter-spaces above the word-space, both below
>the "zero".
But you *cannot* do that. You don't have any basis on which to
discriminate, you have no idea where to set a slice level, and
the spaces all resolve to the same value anyway.
>It's all software and very sharp band-pass filtering. ;-)
There's a computer term which applies here. It is GIGO. Without
a clear basis for decisions, you might as well flip a coin. Now
you *can* form a basis for decisions if you can recover a clock.
This allows you to align your samples with the various timing
states of Morse, and lets you *build* a decision tree which will
lead you to the correct decodings. The tree will be impaired by
the reduced Eb/No because of the inability to form a single
perfect matched filter, but it will work if the SNR is good
enough.
Once you get past the deficits encountered by using OOK and by
the inability to form a perfect matched filter, clock recovery
is the *major* problem of a code like Morse as compared to a
uniform code. Clock recovery, and clock *phasing* is a daunting
problem with a variable length code. It can be hard enough with
a uniform code buried in gaussian noise. It can be darn near
impossible for a hand sent variable length code.
Note that again this is not just a machine decoding artifact.
A human faces the same quandry trying to determine where signal
edges occur against a gaussian environment.
>Yes, signaling systems like QPSK are significantly more efficient, IF you
>have the equipment to encode and decode the signals in the first place.
>The beauty lies in the fact that you don't NEED a computer to encode or
>decode CW; it's the most "flexible" human-computer, computer-computer,
>human-human information transmission mode I know of. Voice wastes
>bandwidth, voice-recognition on a computer is MUCH more computationally
>intensive and computer voices leave a great deal to be desired. I propose
>we convert all voice bands to digital and keep the CW portions since
>obviously they are far more efficient. (Just kidding. hi hi :-)
>
>It's all a matter of perspective. Most people I know can't listen to an
>ASCII bit stream, even at slow speed, and determine what the computer is
>transmitting. ;-)
That's because they've never *tried* it. If you spent as much time
and effort conditioning the wetware to copy a slow ASCII FSK signal
as you spent conditioning the wetware to copy OOK Morse, then I
contend you'd be able to do it, and be able to do it against a
harsher gaussian noise background. Signaling and information theory
say so, and some human perceptual experiments tend to reinforce that
conclusion. Though I wouldn't choose ASCII as an ideal code against
the gaussian noise either. There are even better codes which can
be used against that.
There are basically three reasons why people don't do that.
1) Machine modes are generally sent way too fast for human decoding.
2) It never occurred to anyone to try since machines did it first.
3) And machines do it faster and with a lower BER than humans ever
could anyway, so why bother?
I believe that if all our text encodings were sent as slowly as
Morse, we would quickly abandon Morse as inferior. It is an artifact
of history that Morse came before the better codes, and that the
better codes were first used at much higher speeds via machines.
Today, there is little point to slowing the superior codes down
to speeds humans can handle because the machines to do it are
obviously faster and widely and inexpensively available. Morse
hangs on as a regulatory artifact of distant times.
Paul Keinänen
ga...@ke4zv.atl.ga.us (Gary Coffman) wrote:
>In article <330ff0b6....@news.sci.fi> kein...@sci.fi (Paul Keinänen) writes:
>
>Yes, Morse used the printer's typebox count to determine frequency,
>but 1840s prose doesn't map terribly well to the sorts of messages
>we typically send via radio. Worse, the most frequently used letters
>are encoded with the least amount of transmitted information, thus
>making them the least likely to be decoded correctly in noise (the
>more information conveyed about a character, the more of it we can
>lose without totally being unable to recover the character). That's
>a ghastly decision for weak signal work.
>
>With a uniform code, every character is encoded with the same amount
>of transmitted information, so frequently used letters are as likely
>to be decoded correctly as the least frequently used letters. With Morse,
>the least frequently used characters are conveyed with the greatest amount
>of transmitted information while the most frequently used characters are
>transmitted with the least. Thus the most frequent characters are also
>the ones most frequently decoded in error. Bad plan.
OTOH, forgetting the character synch problem for a moment, if the
channel has a constant bit error rate, the shorter the character code,
the less likely it will be hit by the bit error. If the most common
characters have the shortest codes (roughly true for Morse _plain_
text English), the character error rate will be lower than with
uniform codes with the same BER. This of course ignores the problem
with character synch.
>>When receiving Morse code sent with an electronic keyer, it does not
>>take a lot of characters to determine the dot rate and then rescanning
>>the message with the correct dot rate and only have to adjust the bit
>>time with +/- 0.5 dot time for each character or word (depending of
>>the habits of the operator). To effectively decode signals sent with a
>>straight key, you need a much larger sample to determine the "fist" of
>>the operator and then rescanning the message from the beginning.
>
>The latter can be nearly impossible with some of the ragged fists
>heard on the air. Uniformity of timing is essential to good weak
>signal extraction, and most hand sent Morse is remarkably lacking
>in uniformity. Even with an electronic keyer, character and word
>pacing can vary wildly from one letter or word to another. This
>really hurts the ability to extract the signal from noise. Morse
>sent from a keyboard buffer is much easier to process in noise
>than hunt and peck text, and that's better than hand sent text.
Some operators have a guite distinguised way of sending certain
characters, such as Ls, Qs etc., so it might be possible to fine tune
the decoder :-).
The problem with non-uniform timing with manual sent Morse is that you
have to get each _transition_ of the keying waveform and this requires
a quite high dV/dt in presense of noise to get a reasonable timing for
each dot or dash. A hight dV/dt also means that you have to get the
3rd or even the 5th harmonic of the baseband signal, thus requiring a
bandwidth 3 - 5 larger than what would otherwise be required for
machine reception. The larger bandwidth OTOH, will reduce the SNR by 5
- 7 dB.
Paul OH3LWR
Gary Coffman
In article <331408a7....@news.sci.fi> kein...@sci.fi (Paul Keinänen) writes:
>ga...@ke4zv.atl.ga.us (Gary Coffman) wrote:
>
>>In article <330ff0b6....@news.sci.fi> kein...@sci.fi (Paul Keinänen) writes:
>>With a uniform code, every character is encoded with the same amount
>>of transmitted information, so frequently used letters are as likely
>>to be decoded correctly as the least frequently used letters. With Morse,
>>the least frequently used characters are conveyed with the greatest amount
>>of transmitted information while the most frequently used characters are
>>transmitted with the least. Thus the most frequent characters are also
>>the ones most frequently decoded in error. Bad plan.
>
>OTOH, forgetting the character synch problem for a moment, if the
>channel has a constant bit error rate, the shorter the character code,
>the less likely it will be hit by the bit error. If the most common
>characters have the shortest codes (roughly true for Morse _plain_
>text English), the character error rate will be lower than with
>uniform codes with the same BER. This of course ignores the problem
>with character synch.
Well, it also depends on the nature of the channel errors. If the
primary error source is similar to impulse noise with a pulse width
much less than one dot time, you have a point. But if you're facing
a gaussian noise distribution, the shorter characters suffer more
because you'll recover less energy to contrast against the noise.
And if the channel impairment is multipath fading on the order of
22 mS (common), you have yet another situation, and you can lose
whole short characters to the fade. And you might not even know
you'd lost it because letter space duration is often ill defined
in manual Morse.
>The problem with non-uniform timing with manual sent Morse is that you
>have to get each _transition_ of the keying waveform and this requires
>a quite high dV/dt in presense of noise to get a reasonable timing for
>each dot or dash. A hight dV/dt also means that you have to get the
>3rd or even the 5th harmonic of the baseband signal, thus requiring a
>bandwidth 3 - 5 larger than what would otherwise be required for
>machine reception. The larger bandwidth OTOH, will reduce the SNR by 5
>- 7 dB.
Exactly right. I was reading a review of one of the new DSP filter
boxes last night and the reviewer was complaining that he couldn't
use the narrowest settings with a noisy signal because "the code
blurred together". That's because he was cutting off the harmonics
responsible for the element timing edges and the edges were blurring
into the gaussian noise. He had to go to a setting 5x greater than
the basic baud would indicate to get good copy, and that reduces SNR
by -6.99 db.
With a uniform code and a known clock phase (either recovered or
externally referenced) a machine could sample the center of the
bit interval and not need to use a filter of 5x the basic baud,
and thus wouldn't give away that -6.99 db. But even a machine
can't do that with manual Morse. You have to locate those edges,
and that costs you nearly 7 db in achievable SNR.
Andrew Plumb
It's nice to have an intelligent discussion about Amateur radio topics
every once in a while. :-)
Gary Coffman <ga...@ke4zv.atl.ga.us> wrote in article
<1997Feb16.2...@ke4zv.atl.ga.us>...
[deletia]
> >Yes, there are two OOK format signaling states in CW (the signaling
> >"alphabet" - 0,1); symbols are generated by combinations of these states
> >over time. I'm thinking of the dots, dashes, letter-spaces and
word-spaces
> >symbols as variable length codewords. The empty/off portion separating
> >dots from dashes is a suffix of the symbol. If you think of it in
Digital
> >terms, a dot is (111111100000), a dash is (11111111111100000), a
> >letter-space is (00000000000) and a word-space is "longer than a
> >letter-space".
>
> Well, lets clarify this a bit. OOK has two states, call them 1 and 0,
> but there is no information transmitted about the 0 state. That we are
> in a 0 state has to be *inferred*. This costs us 3 db compared to a
> system which transmits energy for both states orthogonally (or 6 db if
> the states are transmitted antipodally) against a gaussian noise
background.
> So OOK has a deficit in performance versus better modulations. That holds
> whether the encoding of characters is done in ASCII or Morse.
True, but the mean value of a "0-state" is of zero energy, while the mean
of a "1-state" is non-zero/above-threshold energy ((A^2)/2). I'll tackle
this bit a little further on.
Getting a little philosophical, the lack of information is information in
itself. Yes, I'd much prefer to use something other than OOK, where the
low and high states are distinguishable, but on the transmitter side of
things, transmit/no-transmit is better (in terms of over-all power
consumption) for, say, a QRP set-up, than transmit/transmit/off of other
modes. That is assuming all other factors are equal, which they rarely are
anyhow. :-)
> In fact some clever tests have shown that humans can be trained to
> understand FSK modulated Morse under weaker conditions than they can
> OOK modulated Morse. This isn't just a machine decoding artifact, it
> is universally true.
Oh, no doubt about it! As a musician myself I can fully appreciate this.
The human ear is quite the versatile tool when trained. Half the battle is
coming in on cue after several bars of rest; "playing" the rests.
[stuff about uniform codes deleted - all very true]
> >You may have noise in the sampling instances, but the ADC usually
samples
> >much more frequently than the human hand sends the code. Dashes have
more
> >1's than dots and about the same number of trailing 0's; letter-spaces
have
> >more 0's than dots and dashes and word-spaces have more 0's than all the
> >others. It's just a little adaptive filtering; there are known average
> >dot, dash, letter-space and word-space that can be used as starting
points.
>
> The ADC *must* sample faster than the code is sent. At minimum, it must
> obey the Nyquist limit. Now the faster we sample, the more *noise* we
> sample, because noise has a gaussian distribution. During the 0
intervals,
> *all* we sample is noise. During the 1 intervals, we get noise plus
signal
> in our sample. To maximize correct decoding probability we have to
maximize
> the ratio of signal energy to noise energy, IE Eb/No. We can't do that
during
> the 0 periods, because all we get is No/No. Thus the 0 periods don't
> contribute to information about the signal in a positive fashion.
I think this is where our perspectives are differing somewhat; I don't
think I was clear in what I was trying to get across. What I was trying to
say was that the sampling rate is significantly higher (by several orders
of magnitude) than the morse code symbol rate (dots, dashes and both
spaces); oversampling can work wonders.
Yes, you are sampling more noise, but that noise is (usually) of zero mean
relative to both OOK states. If you average the samples over a
sufficiently small (so you don't kill the actual OOK signal) moving window,
you'll knock out a great deal of that noise. That gets rid of the "pure"
noise; after that you just pass the signal through a very tight BPF to
knock out the adjacent signals, square the resulting values to get them
positive and use the resulting "rectified" numbers as your bits/no-bits
values based on some energy threshold. It's these bits/no-bits values that
you use to generate your decision Markov chains; Neural Networks,
Kalman-Bucy Filter, <insert_algorithm_here> from here on in.
[other true communications facts deleted]
> There's a computer term which applies here. It is GIGO. Without
> a clear basis for decisions, you might as well flip a coin. Now
> you *can* form a basis for decisions if you can recover a clock.
> This allows you to align your samples with the various timing
> states of Morse, and lets you *build* a decision tree which will
> lead you to the correct decodings. The tree will be impaired by
> the reduced Eb/No because of the inability to form a single
> perfect matched filter, but it will work if the SNR is good
> enough.
Have to disagree with you on this one. A fair coin tells you nothing, but
any bias will show up over time if your algorithm/filter is designed to
accommodate the temporal variance. We already know ahead of time that we
expect to see four discrete symbols evolve over time. One "coin" is dots
versus dashes, the other is letter-spaces versus word spaces. Morse code
symbols themselves are your clock. No one said it was going to be easy.
:-)
By the way, wasn't the original question asking how to build a better
algorithm for decoding morse code? We've gotten a bit side-tracked, but
it's been fun. :-) Think we've scared off the original poster?
Rodney S Baker
Gary Coffman wrote:
> =
> In article <331408a7....@news.sci.fi> kein...@sci.fi (Paul Kein=
=E4nen) writes:
> >ga...@ke4zv.atl.ga.us (Gary Coffman) wrote:
> >
> >>In article <330ff0b6....@news.sci.fi> kein...@sci.fi (Paul Ke=
in=E4nen) writes:
>>>[...snip...] =
> Well, it also depends on the nature of the channel errors. If the
> primary error source is similar to impulse noise with a pulse width
> much less than one dot time, you have a point. But if you're facing
> a gaussian noise distribution, the shorter characters suffer more
> [...snip...]
> =
> Gary
> --
> Gary Coffman KE4ZV | You make it, | Due to provider pro=
blems
> Destructive Testing Systems | we break it. | with previous uucp =
addresses
> 534 Shannon Way | Guaranteed! | Email to ke4zv@radi=
o.org
> Lawrenceville, GA 30244 | |
Guys, this has been a really interesting thread and I've learned a lot
reading it but there's one thing I'm not clear on and that's what's
meant by the term "Gaussian Noise Distribution"...is this referring to
what is basically random or pseudo-random noise, white noise, pink noise
or something else entirely?
Please pardon my asking but I'd really appreciate an explanation on this
in as basic terms as possible (without over-simplifying).
Thanks,
-- =
Rodney S Baker
rsb...@dove.net.au
"All wiyht...rho sritched mg kegtops awound???!!!