# Combining CDMA with differential Manchester-like encoding?

I wonder to which extend it is possible to combine a self-clocking code (like Differential Manchester encoding) with synchronous CDMA, and how it would be done?

Suppose I want to receive some bits from devices where each of them has sufficiently synchronized clocks but the receiver of the bits does not (and hence suffers from clock drift, delays etc).

Right now (without CDMA) I do not even need to care about the clock ... I just detect the transitions at the receiver and can infer the bits (because there is a guaranteed transition every bit). I wonder if something similar can be done while still using CDMA?

Take for example 3 IoT devices which send data in parallel via 4-order Walsh-Haddamard code.

The code matrix is:

$$\begin{bmatrix} 1 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 \\ 1 & 0 & 1 & 0 \\ 1 & 1 & 1 & 1 \\ \end{bmatrix}$$

and the three devices send bits $$001011010101$$, $$001010110011$$ and $$001010001111$$. The waveform as seen at the receiver looks like:

(as per assumption above they sum up nicely in the channel and preserve orthogonality of the data bits but the receiver does not know the clock). We can see that there is not necessarily a transition (or at least change of sample value) every bit/symbol. I tried replacing each 1 with $$[1, 0]$$ and each 0 with $$[0, 1]$$ in the code matrix but this doesn't change anything significantly.

What would be the best way to implement this?

• what would be the motivation to do this? your hard problem is the separation of the CDMA users in absence of synchronization using a scheme that doesn't allow that (Walsh isn't orthogonal under shift). So, your Manchester coding doesn't contribute anything to the multiuser detection problem. If it solves your per-user symbol clock recovery, nice, but even then it would be not something I'd recommend in a wireless system. Apr 19 '20 at 19:45
• The assumption is that the parties sending the data have sufficiently synchronized clocks (such that orthogonality is preserved when the signals are summed in the channel) but the receiver not. I’ll clarify this in the question.
– divB
Apr 19 '20 at 21:52
• But then, why the manchester? you could do clock recovery simply by observing the transitions in the CDMA sum signal. manchester just doubles the bandwidth, with no benefits. Apr 19 '20 at 22:00
• Because it's IoT: Limited resources, simplicity, ... I do not want to invest many bits for clock recovery. Receiving bits by just looking at adjacent sample points is much more robust and simpler than trying to find the right sampling times and hoping that all of them fall onto the optimal sample time... that's the reason why Diff. Manchester is used in the first place. PS: Edited question.
– divB
Apr 19 '20 at 22:06
• but you don't win anything by having manchester encoding in there, you have chip transitions anyway – and no, it's not more robust, at all, to use manchester encoding (which is pretty much impossible to transport over the air in constrained bandwidth – IoT restrictions, especially!) than to use proper pulse shaping. Apr 19 '20 at 22:09