A Discussion on Tone Injection
by
K0SM, Ko0u, VE5UF and K2KXB.
Date: Sun, 19 Oct 1997 13:55:00 +0000
From: K0SM's Home Page
Subject: [HSMS] The right tone
I put together a little calculator in a Microsoft Excel 5.0 sheet. You
can get it at:
Excel Calculator
You type in the the speed in LPM and tone in Hz, and the sheet will
calculate just about everything you'd want to know. The sheet will also
generate a list of 'perfect' tones for the speed entered. (That is,
freqencies at which the dot ends at 0 deg.)
Have a look.
Andy K0SM EN10
Date: Sun, 19 Oct 1997 01:58:49 +0000
From: Andrew Flowers, K0SM
To: hsms@tree.net
Subject: [HSMS] Tone injection (again...)
Has anyone addressed the idea of proper tone vs sending speed?
It seems that it would be best to use a speed at which the length of
the 'dot' is a whole number of sine waves of the audio freqency. This
way there isn't a strong 'pop' at the end of the CW elements. If the CW
element is ended in the middle of a crest or a trough of audio sine
wave, the voltage instantaneously returns to zero, causing an anoying
'pop', and could cause a problem for those of us using CoolEdit to
decode the waveform. It may also be possible that this 'pop' could
splatter onto adjacent channels.
I have came up with a formula to see if the tone being used is
appropriate--I hope I did my math right!
C= sin(2Pi*f*l)
where f =the audio frequency in Hz
l= the dot length in seconds
C= a number between -1 and 1. The closer it is to
zero the better the tone is, and less 'pop'.
The idea is to put a tone into the transmitter so there is not any
distortion on the transmit side.
Andy K0SM EN10
K0SM Web Page
Date: Sun, 19 Oct 1997 03:28:40 +0100
To: hsms@tree.net
From: Steve Harrison, Ko0u
Subject: Re: [HSMS] Tone injection (again...)
At 01:58 AM 10/19/97 +0000, Andy wrote:
Has anyone addressed the idea of proper tone vs sending speed?
It seems that it would be best to use a speed at which the length of
the 'dot' is a whole number of sine waves of the audio freqency. This
way there isn't a strong 'pop' at the end of the CW elements. If the CW
element is ended in the middle of a crest or a trough of audio sine
wave, the voltage instantaneously returns to zero, causing an anoying
'pop', and could cause a problem for those of us using CoolEdit to
decode the waveform. It may also be possible that this 'pop' could
splatter onto adjacent channels.
The bandwidth of any "pop" will be restricted to the bandwidth of the SSB
transmitting filter, so it *should* not cause adjacent channel splatter any
worse than a voice might.
As far as the receive side is concerned, using CoolEdit, one can easily see
phase changes in the middle of received code characters. This is what causes
a character to have a pronounced dip somewhere in the character, causing,
for example, dahs to look like a pair of dits. I have several recordings
where the received tone frequency was 2320 Hz so that there were more than 6
cycles per dit and dahs contained over 18 cycles. Throughout the recording,
one can see the regular phase reversals very clearly. I have another
recording of a different day but again, with the tone frequency at 2300 Hz,
where there are almost no phase changes obvious through dahs.
In any case, it woul be necessary to phase-lock the keying speed with the
tone frequency to avoid the non-coherency Andy mentions above. This would
not be difficult to do, and raises the question of whether somebody could
design such a transmitter keyer using some kind of microcontroller, such as
one of those PIC things (I bet the fallacy with that idea is their clock
speed is not fast enough, though).
Failing that, the answer may be to write a program to generate the keying
and tones using the computer's processor itself so that the clock for both
is the same (I suppose the sound boards likely have separate clocks..you
know anything about this, Doug??).
And aren't there supposed to be motherboards with built-in game ports with
A/Ds?? Perhaps one of those can be used to accept the receiver audio,
thereby completely avoiding the need for a separate sound board and
simultaneously achieving complete compatibility of all hardware!
A byproduct of this would be the possibility of phase-locking both the
receiver and transmitter tones.
I better be careful with my thinking here: I believe that I'm beginning to
approach something like our nemesis, "packet"!
73, Steve Ko0U/1
Date: Sun, 19 Oct 1997 00:15:29 -0600
To: hsms@tree.net
From: Doug Freeston, VE5UF
Subject: Re: [HSMS] Tone injection (again...)
At 03:28 AM 10/19/97 +0100, Steve Harrison wrote:
>At 01:58 AM 10/19/97 +0000, Andy wrote:
>>Has anyone addressed the idea of proper tone vs sending speed?
>>
>> It seems that it would be best to use a speed at which the length of
>>the 'dot' is a whole number of sine waves of the audio freqency. This
>>way there isn't a strong 'pop' at the end of the CW elements. If the CW
>>element is ended in the middle of a crest or a trough of audio sine
>>wave, the voltage instantaneously returns to zero, causing an anoying
>>'pop', and could cause a problem for those of us using CoolEdit to
>>decode the waveform. It may also be possible that this 'pop' could
>>splatter onto adjacent channels.
First, a (possibly) naive comment on the above point raised by Andy...
Seems to me if you drive the mic input with a perfect step, the actual
voltage change at the SSB modulator will have a rise or fall time of
approximately 0.32/F where F is the upper 3dB point in the amplitude
response curve of the rig's audio processing stage(s). This softening of
the step, plus the additional rejection of the crystal filter which
typically follows the SSB modulator should keep out-of-band products
generated in the SSB modulator fairly low. But I'm sure there are
differences between rigs such that the mic audio does other things
like feed some part of strange ALC circuits which may also affect the
purity of the emitted RF. In my IC271, for example, the little ripples
in the CW RF envelope change visibly as the injection tone is moved around
between 1800 Hz and 2400 Hz. I have no idea why this happens, but I'm
sure that if the little ripples on the RF envelope are changing, then the
emitted RF spectrum is also changing - how much, I have no way to measure.
The above test was done with MS_DSP sending a repeating series of "5"
characters i.e. just dots. I intend to repeat these tests using Andy's
tone files as a source so that the dots are more consistent.
>
And Steve continued:
>The bandwidth of any "pop" will be restricted to the bandwidth of the SSB
>transmitting filter, so it *should* not cause adjacent channel splatter any
>worse than a voice might.
So I guess I'm agreeing with Steve, so long as the mic audio ONLY drives
the SSB modulator.
>
>As far as the receive side is concerned, using CoolEdit, one can easily see
>phase changes in the middle of received code characters. This is what causes
>a character to have a pronounced dip somewhere in the character, causing,
>for example, dahs to look like a pair of dits. I have several recordings
I have also seen significant phase changes but I would attribute most of
these to phase distortion inherent in the transmission path. However...
human computer to the rescue. Those dashes which often "look" like a pair
of dots still "sound" like a dash - to me, at least.
>
>In any case, it woul be necessary to phase-lock the keying speed with the
>tone frequency to avoid the non-coherency Andy mentions above. This would
MS_DSP does strange things with the start-stop phase of the generated
sine waves. It *should* begin a new dot or dash at precisely 0 degrees
but often simply begins at the phase angle where the previous element
was terminated. This behavior gives rise to the generation of some low
frequency components in the audio which are readily removed with a simple
first-order hi-pass filter. One hopes that this timing problem will be
corrected in a future version. OTOH, Andy's tone generation scheme could
be (or should be) perfectly free from this effect since characters are
built from individual "perfect" dot and dash elements. Also in MS_DSP,
there is significant visible distortion in dash elements caused by the
attempt to build a perfect dash element by making three successive calls
to the routine which creates the dot element. There is a slight software
delay between calls and this manifests itself as two small glitches in the
otherwise perfect continuity of the dash sine waves. The glitches are
about 150 uSec long each and 150uSec is a significant portion of a
single 2000 Hz sinewave. This glitch time is on a 486SCL2-66 and should be
way less on a Pentuim box and worse on a DX33.
>
>Failing that, the answer may be to write a program to generate the keying
>and tones using the computer's processor itself so that the clock for both
>is the same (I suppose the sound boards likely have separate clocks..you
>know anything about this, Doug??).
That's what MS_DSP already does, Steve. The successive sine values WRT
time are computed and sent as a data block to the DSP chip in the Blaster
where they are clocked into an output DAC by the DSP clock which may or may
not be slaved to the PC bus clock. Regardless where the DSP clock comes from,
the phase of the sine wave is completely controlled by the stream of bytes
which are passed to the DSP chip for D/A conversion and which define the
successive amplitude steps of the output waveform.
>
>And aren't there supposed to be motherboards with built-in game ports with
>A/Ds?? Perhaps one of those can be used to accept the receiver audio,
>thereby completely avoiding the need for a separate sound board and
>simultaneously achieving complete compatibility of all hardware!
But aren't these just another name for "built-in SoundBlaster-compatible
audio system"?? Like the ones in notebook computers which have no discreet
sound card. The continuing problem for software is that one vendor's idea
of "SoundBlaster-compatible" is not the same as the next guy's. Some
standards are needed beyond the de facto SB "standard".
>
>A byproduct of this would be the possibility of phase-locking both the
>receiver and transmitter tones.
>
>I better be careful with my thinking here: I believe that I'm beginning to
>approach something like our nemesis, "packet"!
Could be, Steve. A few more steps and the 212 modem will have been
re-invented. :^) And what would you get? A signaling scheme that will do
approximately 7000LPM and (I'm guessing here) be totally incapable of
surviving the phase hits contributed by a meteor trail as a transmission
medium assuming one could solve the fast-train-on-short-pings problem.
73, Doug VE5UF
Subject: [HSMS] Tone injection (again...)
Date: 19 Oct 97 00:25
From: Russell C. Pillsbury, K2TXB
In message <34495B49.4AA@navix.net>, Andrew Flowers K0SM
wrote:
> The idea is to put a tone into the transmitter so there is not any
> distortion on the transmit side.
Yeah, good idea, but why not put a zero crossing detector on the audio
tone, and use it to determine when to start / end the dots and dashes.
The maximum error will 2 hz per code element, so at 2000 hz it will be
2/1000 of a second per element.
At 400 lpm, you have approx 3440 bits / min (using the average number of
bits per letter in the standard word PARIS), so you have 3440/60 =
57.333 bits / second. At 2000 hz tone freq, there will then be 2000 /
57.333 approx = 35 hz per bit. For single bit elements (dots, character
spaces), this would result in a max error of 2/35 * 100 = 5.7%. for
longer elements (dashes, character spaces), the max error will be
significantly less (about 2%). Remember that these are max errors, the
average error will be about half, depending upon exact tone and speed.
I seriously doubt that it will make any difference in copyability, but
it would eliminate the problem of the 'popping' completely and allow you
to set your tone, and transmit speed wherever you want. Another thing
is that it will produce a much cleaner signal on the air, with less
splatter (key clicks).
Now someone check MY math!
73, Russ K2TXB
Return
Comments: Rein, W6/PA0ZN