Ultrasound pulses and reflection problems

I am building a whiteboard to track the position of its pen. I have n ultrasound receivers placed on the periphery of the whiteboard, and an ultrasound emitter in the pen. The pen emits pulses the receivers detect. A microprocessor gathers the arrival times of the pulses for each receiver, and with the time differences of arrival (TDOA) it makes an estimate of the position of the pen following a multilateration algorithm.

Ultrasounds reflect on surfaces, which can cause interference. This is a restriction on the frequency of the pulses. At the moment, I pulse the pen at 10Hz, which is enough for the reflections to die off and not interfere. Unfortunately, 10Hz is not fast enough a sampling for my purposes. Ideally the pen would pulse at 100Hz. (The pen emitter is connected to a microcontroller, so I can control the shape and frequency of the pulse.)

What tricks can I use to tackle the reflection issue? What are some standard filtering techniques? Could using different pulse patterns in a cycle help filter out the reflections?

-
What is the form of the pulse (a sinusoid, some modulated signal, etc.)? What is each pulse's duration? What bandwidth is available for the end-to-end ultrasound system? One scheme that might work would be to cycle through a set of different orthogonal pulse shapes for subsequent transmissions; this would help prevent inter-pulse interference. It would require some level of time synchronization between the whiteboard and the pen, but that could potentially be resolved. – Jason R Dec 8 '12 at 20:49
I get to choose the form of the pulse, and the duration (the transmitter is connected to a fully programmable microprocessor DAC). The ultrasonic bandwidth is 40kHz +/- 1kHz. What exactly do you mean by "orthogonal pulse shapes"? – Randomblue Dec 8 '12 at 20:57
@Justin an orthogonal family of pulse shapes are for example, pulses/signals whose dot product with each other gives 0. For example one cycle of a sin wave and one cycle of a cosine wave, when their dot product taken, give zero. – Mohammad Dec 9 '12 at 0:54
@Justin: What amount of processing resources are available on the backend that is connected to the array of ultrasound receivers? – Jason R Dec 11 '12 at 19:12
@JasonR: There are two layers of processing. The first is an ARM chip that simply does the data acquisition (sends the readings from the receivers to the internet). I then have a powerful server to receive the data and process it. – Randomblue Dec 12 '12 at 9:55

It would appear that your problem lends itself very nicely to using a CDMA scheme.

Let starts with some properties of (DSSS) CDMA. (Direct Sequence Spread Spectrum, Code-Division Multiple Access). Its a mouthful, but it is really easy to implement.

In CDMA, your pulse (at baseband) is actually made up of many concatenated 'chips' as they are called. The chips are just 1s or -1s, of a fixed duration. For example, your chipping sequence might be [1 -1 1 -1 -1 -1 1]. You would use this chipping sequence to modulate your carrier.

However, you cannot just make up your chipping code. What you want to do is use chipping codes that have the very nice property, that their autocorrelation function is a delta function like so:

(Equivalently, their power spectral density is white). For example, you can look into using Barker Sequences as your chipping code, (usually used in radar), or you can also look at using Gold Codes. Practically speaking however, this means that you get the maximum correlation score in your receiver, ONLY when the receivers' code, exactly lines up with the transmitted code, and zero otherwise.

How does this help you? In your receiver, you would be running a correlator continuously. The correlator would be performing a running dot-product of its own local code, with whatever is received. Now imagine that you receive a transmitted waveform from your pen, and a second waveform from a reflection. As your receivers' correlator runs, it will give a peak when its own codeword exactly alligns with your code from the pen. This will cause your detector to 'lock' onto that specific delay value. Now, here is where you reap the benefits of a near-delta autocorrelation function of your code: The reflected signal will also be present, and will also have its dot product taken with the receivers' locked code, but it will give zero, or near zero score, since it is orthoginal or near-orthogonal to the delayed code that your receiver has already locked onto.

In contrast, if you had send out a un-coded carrier pulse, you would be at the mercy of constructive or destructive interference throwing off when exactly your pulse peaked at the detector level of your receiver, and thus get erroneous TDOAs.

-
Any problems with Doppler effect due to the pen moving around? – endolith Dec 9 '12 at 4:12
I don't understand how the detector can 'lock' onto a specific delay value. The pen is moving, so the delay will vary. – Randomblue Dec 9 '12 at 20:14
@endolith Yes, depending on how quickly the pen moves around though, although it might be correctable with a PLL. – Mohammad Dec 9 '12 at 22:40
@Justin Yes, it will lock on to a specific delay for that main pulse. Then your pen sends out another pulse, and it locks onto a new delay, etc etc. Your pen is always making new pulses, and the receivers always receiving them, and computing a new TDOA. The point is for the multipaths not to be able to destructively interfere with your main line if sight signal. – Mohammad Dec 9 '12 at 22:43
@endolith Yes, I agree. The bandwidth has to be wide enough. I back of the napkin calculation I made shows doppler delta at approx 100Hz, while bandwidth 2Khz... and yes, would have to simulate to see if good enough. – Mohammad Dec 10 '12 at 19:40