0
$\begingroup$

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:

enter image description here

(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?

(I hope my question is clear enough. If not, please leave a comment and I will clarify)

$\endgroup$
5
  • $\begingroup$ 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. $\endgroup$ Apr 19, 2020 at 19:45
  • $\begingroup$ 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. $\endgroup$
    – divB
    Apr 19, 2020 at 21:52
  • $\begingroup$ 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. $\endgroup$ Apr 19, 2020 at 22:00
  • $\begingroup$ 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. $\endgroup$
    – divB
    Apr 19, 2020 at 22:06
  • $\begingroup$ 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. $\endgroup$ Apr 19, 2020 at 22:09

1 Answer 1

1
$\begingroup$

With CDMA everything you would traditionally do with a symbol such as timing and carrier recover still applies- but in CDMA the symbol is the series of many “chips”.

So yes you could certainly add any higher level coding to the symbols where in CDMA the symbol may represent a data bit such as +1 and -1 only (perhaps), but each of these data bits after such coding would then be expanded to the CDMA sequence.

There is no motivation to change the sequence itself other than its cross correlation properties to the other codes used and the overall processing gain required. Timing and carrier recovery is done after despreading.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.