Paul B. Webster wrote:

>Ken Webster wrote:
>
>> Well, if this is true (and it does sound reasonable to me after
>> thinking about it), then wouldn't this do the trick?  Simply XOR with
>> a pseudorandom sequence on the transmitting end and then XOR with the
>> same sequence on the receiving end to cancel most of the noise.
>
>  It will indeed "do the trick", but is impractical for the reasons I
>and others have mentioned; it introduces a large high-frequency (wide
>bandwidth) component, and necessitates a more reliable link than a DAC
>to transmit and ADC to receive.


I must disagree with you here.

1). The bandwidth needn't excede the Nyquist frequency .. if your sample
rate is 8kHz then a full-scale transition can be represented by a 4kHz
sinusoidal component of maximum amplitude.  True that the output of the DAC
will transition rapidly and thus have much higher frequency components, but,
by limiting the bandwidth to 4kHz (by passing the DAC output through a
lowpass filter or a bandwidth-limited channel) you are not loosing any
information .. the signal will still swing from one voltage to the other
within one sampling interval (125 microseconds for an 8kHz sample rate) and
be correctly sampled by the A/D on the other end.

2). Link reliability (noise and imperfect frequency response) will merely
result in some of the introduced pseudo-random noise not being completely
cancelled at the receive end.  If you cancel most of it, however, you should
still be able to recover an intelligable version of the original signal.
Digitally filtering the PRN on the recieve end to match the transfer
function of the channel would definitely help if the channel doesn't have a
flat response.  A small amount of imperfection should not prove disastorous,
though ... it should merely result in a small amount of added noise.



>> Sampling errors would merely add a little noise (or perhaps a lot of
>> noise .. I just realized that some small errors could cause the result
>> of the XOR on the receiver to wrap around from near zero to near 0xff
>> or vice-versa .. depending on how frequently this happens the
>> recovered signal could be quite noisy).
>
>  That's right.
>
>> What about limiting the amplitude of the voice signal to a signed
>> 7-bit value and likewise limiting the amplitude of the PRN to 7-bits
>> and adding the two (rather than XORing) so that the noise is
>> superposed and never causes low values to wrap around to high values
>> or vice-versa?
>
>  If you think about it, adding and XOR-ing are almost the same.  But
>the real problem is still that it is the PRBS *itself* that contains
>these "wrap-arounds" (rapid change of MSB) already.


I must have had a big brain fart when I thought about this before -- XOR
will only toggle a few bits .. noise in the channel would only offset the
value a little but not prevent the XOR on the receive end from largely
undoing what the XOR on the transmit end had done.

Adding 8-bit values, however, would sometimes result in a small error
wrapping the value around, for example:

original signal:    0xff
PRN added:          0x01
transmitted signal: 0x00
noise/error:        0x01
received signal:    0x01
PRN subtracted:     0x01
result:             0x00
error:              0xff

It was the above scenario that I had in mind.  Gotta get out of the habit of
having several beers before chatting on this group :o)

XOR, on the other hand, would do much better:

original signal:    0xff
PRN xor'd:          0x01
transmitted signal: 0xfe
noise/error:        0x01
received signal:    0xff
PRN xor'd:          0x01
result:             0xfe
error:              0x01


So, after reconsidering, I would expect XOR to work quite nicely.



>> If large errors are introduced by the bandwidth limits of the channel
>> (limits on slew-rate, etc.) then couldn't you run the PRN through a
>> lowpass filter and still get good results?
>
>  If you low-pass it and combine with the signal, it will no longer
>fully mask the signal. :)


Yes but do you think you could make any sense of a conversation if the only
unmasked components were above 2kHz?



>> If you did the above (adding PRN at transmitter and subtracting it at
>> receiver) then the signal amplitude should be continuously very high
>> unless you are synchronized.  As long as your original data has some
>> silent or quiet parts then you should be able to slew the phase of the
>> PRN at the receiver until the average amplitude drops
>
>  That's close to the method.  I think there's something sneaky in the
>maths; if you XOR (auto-correlate) the PRBS with itself out-of-phase,
>the resultant has, I suspect, some interesting properties.


Hmm.. this sounds interesting.  I would be quite interested in any method
that works better than the brute-force slew-and-correlate technique(which
works alright with a large window and many phases being correlated
simultaneously but still takes a significant amount of time to lock with a
long PRN sequence).


>> This sounds fun to try!  I'd be interested in hearing about the
>> results if anyone tries this.
>
>  The theory has as I say, already been nutted out.  I'd just like to
>see a good article...


Hmm... if I get a few moments free I might whip up a simulator in C++ ...
simulate the communications channel with an editable transfer function plus
some noise sources.

I didn't think I was very interested in this before but all this talk of
slew-rate and bandwidth limitations rendering the technique unusable has got
me going.  I really do think this would work quite nicely.  It would
certainly be challenging to get the receiver to reliably lock with an
unknown transfer function for the communications channel, but, nevertheless,
it is quite feasible IMO.

BTW -- who started this thread originally?  Are you interested in trying out
this technique? (if the C++ simulation gives good results)

Ken