Order Tray | Contact Us | Home | SIG Lists

[hfsig] Performance of 24/192 soundcards? USB Soundcards

Anthony.N.Martin at marconiselenia.com Anthony.N.Martin at marconiselenia.com
Wed Sep 22 00:11:17 UTC 2004


> There is a 17-stage scrambler that could give you a run of
> 16 or 17 bits without transitions.  Now we're down to 50 Hz or so.

I had wondered if it could have an effect. 17 bit run-lengths would
be very rare. I'm not entirely convinced that these numbers are
correct; run-length of any scrambler is infinite for freely contrived
input data; for zero-stuffed HDLC it needs extensive analysis.
17 bits is the number for a PN-code generator.

I've seen scramblers placed before the HDLC coding in some systems.

After a short search I could not find the G3RUH circuit although
I'm sure I've seen it before somewhere.

I found the KD2BD take on the 9600.
http://www.amsat.org/amsat/articles/kd2bd/9k6modem/9k6modem.html

It appears to me that the action of the descrambler is to XOR
the incoming data with a bit from the shift-register to produce
the output NRZI HDLC data bit.

This "XOR" operation could be done on the analogue signal *before*
doing the data slicing and retiming, which would then be done
on plain old HDLC. We can apply our own HPF before the slicer
knowing the max run-length is 6 bits. This would eliminate the
LF-response extension issue. The known data would then be used to
generate the input to the shift register, to descramble later bits.

As I said, it's a modem implementation issue :-)

I suppose one has to ask what good properties of the scrambling
have also been eliminated in this process. If the matched LPF is
already done at the input, I can't think of any.

> James is a very careful engineer, and he did some pretty
> extensive work with all this when he designed the modem and
> specified the required passband response.  The BER goes up
> pretty quickly as the LF response of the system degrades.

If he noted that the LF demands are increased compared to plain
old HDLC, why didn't he care to fix it?

Now if I actually had a G3RUH modem or AGWPE sourcecode I'd test the
fix, but I don't so I can't. Over to you guys... Oh, we've got
our HF hats on! Never mind.

This really does appear to be a practical issue as people do want to
stick 9600 through AC-coupled soundcards and line transformers and
it causes grief.



Actually, the paper at the URL above by KD2BD on his version of the
K9NG/G3RUH modem is self-contradictory on the LF issue.

First we get:
<<
Steve [K9NG] also realized that the unsymmetrical waveshape of AX.25
baseband data carried a significant DC component that needed to pass
without distortion through the RF communications link between transmitter
and receiver. ...
Steve tackled this problem by passing all transmitted data through a
scrambling or randomization circuit
>>

Then we get:
<<
...since it has been shown that even randomized 9600 baud baseband data
contains a DC component that is ignored in many other 9600 baud modem
designs, DC coupling is used throughout the modulator and demodulator
sections of the KD2BD 9600 Baud Modem
>>
So he fixed it with a scrambler, but gee, it's still no good, so
let's fudge it again. Yeah, great.

When I see such contradictory reasoning, my immediate thoughts are
either that the guy is waffling as he doesn't know, or that there
is something very not right here.

FYI, the reasoning KD2BG quotes above (whether from K9NG or not)
for using a scrambler is bogus.

The purpose of a scrambler is to make 1's and 0's equiprobable to ensure
that the textbook analysis of BER, ISI, the nyquist criteria, and matched
filters holds. If the spectrum is not what is expected for "random data"
then all bets are off for our calculations of occupied BW and adjacent
channel interference.

Another reason for scrambling is to ensure sufficient transitions for
clock extraction; but this is only a statistical likelihood, not a
guarantee. In the case of NRZI HDLC, it already provides a guarantee.


Ant M1FDE

-----------------------------------------------
This email and any attached files contains company confidential information
which may be legally privileged.  it is intended only for the person(s) or
entity to which it is addressed and solely for the purposes set forth
therein.  If you are not the intended recipient or have received this email
in error please notify the sender by return, delete it from your system and
destroy any local copies.  It is strictly forbidden to use the information
in this email including any attachment or part thereof including copying,
disclosing, distributing, amending or using for any other purpose.

In addition the sender excludes all liabilities (whether tortuous or common
law) for damage or breach arising or related to this email including but
not limited to viruses and libel.







More information about the hfsig mailing list