[FADCA] Re: Status of BER evaluation on UHF Mitreks

[bud thompson]

NOTE:  This is an off-list topic that I'm now bringing to the list- though
my testing is far from complete!

See my comments to Chuck's response below:

bud

Original Message
from N0IA

Sunday June 12 2000Hrs E

I got the test/tuning jig back in place, adding the analog SINAD meter and
an event counter.  More fun and more stuff on the work bench!  The jig
allows using the 9.6kHz TXA from a Tiny 2 to drive the external modulator
input of the service monitor and to tune the radio for best eye pattern-.

1.  The analog SINAD meter makes basic receiver tuning a breeze! (My old
Motorola service monitor has a very slow A/D converter; the time lag makes
it impossible to tune precisely.) The Mitrek under test today was the
Melbourne-to-Orlando 446.125MHz unit which we had previously tuned/tweaked.
The -12db SINAD was 0.7uv - now it is under 0.5uv.  The 9.6kb sensitivity
improved from 0.7uv to under 0.6uv to light the DCD steadily, though the BER
at that S/N is not good - (see below.)  Squelch sensitivity is below 0.1uv -
we've not seen that before with these UHF Mitreks.

The measured-12db SINAD  (as compared to the standard 1Khz tone at 3kHz
deviation) may be questionable as I'm using RXAudio from the preamplifier
which has had a couple of caps removed from the input circuit to enhance low
frequency response.  The RXA does not go through the Mitrek audio amplifier
which has shaping/enhancement for voice frequencies where 1Khz is enhanced.
However, using the best SINAD for tuning is a satisfactory method no matter
the resulting measured value.

I believe Doug suggested that the reported SINAD this way is lesser than
conventional by -7 to -10dbm.  (Doug?)

The SINAD meter is not useable to tweak for 9.6kb as the SINAD meter
circuitry/computation response is tied to the1Khz tone.  I don't see any
intuitive way to use the SINAD meter for this purpose - and don't know how
to express SINAD values for BER testing, etc. using a 9.6kb signal.  (NOTE:
The ARRL Lab does express S/N in SINAD for BER testing!)

2.  BER measurement as described in the PacComm 9.6kb modem manual (page 7 -
1995 manual) involves counting the number of events representing errors.
The text indicates there are three events per actual bit error.  During BER
testing the RXA line is LOW and when there is an error there should be three
successive blips to HI (+ 5v).  My assumption is that the three blips would
be equal-pulse width.  What I anticipated observing was a LOW moving to a
three blip high back to a low for every error.

What I actually see on the scope (with a good S/N so as to not have events
very often) clearly does not include three pulses every time.  Sometimes I
see a single pulse - sometimes two, sometimes three.  Actually there are
fewer three-pulse groups than others!  With the help of an additional pair
of eyes (Sally's) we have determined the counter is counting every blip I
see on the 'scope whether a single, a double or a triple.

The pulse width should not be too short for the counter, per se, as the
counter is spec'd to 60Hz and at good S/N testing there is often three or
four seconds between events! At poor S/N the blips on the 'scope and the
counter go crazy.  I'm guessing the counter registers every +5v blip.

The problem is: Why do I not see standard three events for each error?
Without understanding this, calculating BER is more than tentative.

Or - are the three blips not necessarily evenly spaced?

PacComm's manual is confusing.. Here is what the manuals sez:

"If there are N counts in T seconds, the channels bit error rate is (N/3)
(T*9600).  For example a count of 30 in 10 seconds would equate to an error
rate of approximately 1 in 10000 bits (10E-4)"

That is verbatim, line for line.

The problem is where the typesetting broke the first and second line!  To
make this work out to a BER of one in 10E-4 the actual equation would be

BER = ((N/3/T))/(bits sent)

The PacComm way is to count the number of events in 10 seconds (about 10,000
bits), and divide by 3.  That would give

BER = [(N/3)/10] 10E-4.

Which would yield PacComm's BER of 1 example.

If we count for 100 seconds

BER = [(N/3)/100]  10E-5

If we count for 1000 seconds

BER = [(N/3)/1000] 10E-6.

Should I actually divide the number of counts by 3 since I'm not seeing 3
blips on the 'scope every time? What if some of the single counts were
really three?  My resultant BER below would be too optimistic.

I ran the following tests for ten seconds at 3kHz deviation:

0.5uv (-113.0dbm)
1.0uv (-107.0dbm)
1.5uv (103.5dbm)

Each was run five times and average counts determined assuming 3 blips for
each bit error.

I then ran the 1.5uv level for 100 seconds which gave a good confirmation.

These tests were made with what ever IF tuning Charlie and I had done two
months ago -

Then, with fear and trepidation I tweaked on the IFs and discriminator coil
for 'best eye pattern", still an elusive objective.

Repeating the above tests did not make much difference.  I then re-tweaked
the IFs/discriminator using the -12db SINAD system - and the 9.6kb tests
were about the same as before.

Just because I could- I set the deviation for 2.7Khz, signal level to 1.0uv
(-107dbm) and timed the count for 1000 seconds (16 min 40 seconds.)  That
resolves to 3.5 errors in 10E-5 (not impressive?)  On the other hand, we may
have as much as 2.0uv of signal on most of our links.. an additional sum
6db - that is about the same a quadrupling the amount of iron in an
antenna - or doubling the amount of iron in each antenna in the path.

All tests at 3Khz deviation except for the 1000 second test-

(NOTE- The table does not work in plan text mode required for
the list.)  Here is a quick short form:

-dbm  Signal     N          T         BER
          level uv  counts  sec
paccom example:
                       30         10        1 x 10E-4
113   0.50       90         10        3 x 10E-4
107   1.00         7         10        2.3 x 10E-5
107   1.00      1050    1000       3.5 x 10E-5
103   1.50        6          10         2 x 10E-5
103   1.50       60         100       2 x 10E-5

Conclusion (though perhaps influenced by the lateness of the day) :

1.  Tuning the IFs for best eye pattern may not make improvement for 9.6kb
over -12db SINAD tuning.

I want to take a virgin UHF Mitrek and leave it on the commercial frequency
it was tuned for:

1.  Measure -12db SINAD
2.  Measure BER

Then replace the IF filters and repeat 1 and 2 w/o retuning the IFs.

Then do some tuning of the IFs wit the eye pattern and repeat 1 and 2

We'll learn (1) if all this effort is worth it - and (2) if we really have a
data radio when we finish!

bud N0IA
386 574 4124

----- Original Message ----- 
From: "Chuck Hast" <wchast at gmail.com>
> The problem is: Why do I not see standard three events for each error?
> Without understanding this, calculating BER is more than tentative.

There should be 3 they just may be going by too fast to see them. Remember
that 1 bit is only 1 ms long.


bud:
Of that is the case, I'm either not seeing all the bits on the 'scope (and 
consequently not by the counter), or the three bits are not evenly spaced 
the same for each error. If the former, my BER calculations are optimistic; 
if the latter then they are okay.

<snip>

>Should I actually divide the number of counts by 3 since I'm not seeing 3
> blips on the 'scope every time? What if some of the single counts were
> really three?  My resultant BER below would be too optimistic.

Yes unless there is something really wrong with your mode. Remember the
way the scrambler works is what causes the 3 bit count/error. So they have
to be there or the scrambler is not working right.

bud:  Okay.. If these counts are not necessarily supposed to be evenly 
spaced, then my BER calculations are appropriate.

All that said, the main thing is to minimize the BER - being able to 
actually calculate it is only a plus. I can certainly see increase in counts 
with lower signal levels, etc.

<snip>

Here is a excerpt from some of G3RUH' work. I am trying to find the original
document on the modem, but this will give a bit more info

---------------------- From G3RUH ----------------------
B.E.R.T. TESTING
  A particularly useful by-product of scramblers is "bit error rate
testing" or BERT for short.  Suppose the transmitted data is held to all
"1"s.  Then a receiver's error-free output should also be all "1"s even
though the transmitted data is quite random.  So to test the quality of a
link one merely sends all "1"s and attaches a counter at the other end.

If one bit is corrupted due to channel noise, the error will in fact appear
exactly 3 times at the receiver output, because there are 3 versions of the
scrambled stream exored together.  Even though one error creates two more,
this doesn't matter because just the single error is enough for a packet to
be rejected.

Incidentally, randomisers/scramblers don't really violate rules concerning
codes and ciphers any more than do ASCII, Baudot or Morse.  Since the
scrambling algorithm is freely published, the meaning of the data is not
obscured.
---------------------------------- END ------------------------
Here is a web page from the ARRL that deals with equipment testing and
has a piece about BERT testing.

http://www.nlrs.org//Aurora-2002/W0ZQ/testproc.pdf


-- 
Chuck Hast

Thanks, Chuck - That helps my knowledge base!  I think the next thing is to 
learn if those errors (1s in my case) are supposed to be evenly spaced.

bud