I've been looking at 2 different methods to acquire a known prn code in a CDMA signal. The first trys Xor prn code chip to I sign data. Then average the result over a time period to determine the data bit. I have not had reliable success with this method. The second which I am going to try performs a real multiply of a the code chip and the sign then adds or subtracts the I data magnitude value over a time span. Is one method known to be more reliable than the other? I'm typing on phone so I can't post any coding right now. If it would help I can update this question later. Thanks


CDMA signals typically have a pilot that is sent along with the data. This pilot is a known chip sequence that is transmitter over and over again. Receivers can use the pilot to lock onto the signal by correlating the received signal with the expected pilot.

The autocorrelation is typically done by FFT'ing the received signal, multiplying it by the FFT'ed expected pilot, and IFFT'ing the result. This is done both for computational efficiency and because the circular correlation that you get with FFT's is actually helpful in this case because the pilot is repeated. Thus you should be able to "catch" the pilot no matter which phase it starts at in your captured signal.

Once you have locked onto the pilot you know the signal's phase and it should be pretty straightforward at that point to despread the signal and recover the data, providing you know the data's spreading sequence.

| improve this answer | |
  • $\begingroup$ I realize that using an FFT to correlate may well be the best and is by far the quickest way to get the prn phase estimate to start, I'm trying to implement this in an FPGA. So ideally I would like to use a threshhold value to determine if a code lock is present. I'm thinking the second method using the magnatude will produce a wider spread in summed value between lock and not locked than the sign only way. I'm just not sure. $\endgroup$ – J Hinton May 18 '14 at 3:24
  • $\begingroup$ You can do FFT's and IFFT's in FPGA's. I have done the approach that I described in an FPGA. $\endgroup$ – Jim Clay May 18 '14 at 20:14
  • $\begingroup$ I'll have to look into how to go about implementing that. Currently I am using a Cyclone 4 development board kit so my single search/tracking channel uses just under half the Logic Elements on the chip. I am searching the old fashioned way, rotating by chip delay the full prn code in 1000 frequency shifts to account for +/- 5 KHz carrier doppler shift. I am using the boards leds as my only diagnostic. Right now I can tell when I have a near lock as a led flashes every summed 1000 matching IF sign / code sign matches. So far switching over and staying in tracking has eluded me. $\endgroup$ – J Hinton May 19 '14 at 4:01
  • $\begingroup$ Algorithm experiments in FPGA's are very time consuming and frustrating. I suggest capturing snapshots of the signal into a file and then working out the algorithm experiments in Matlab, Octave, or NumPy. $\endgroup$ – Jim Clay May 19 '14 at 13:59
  • $\begingroup$ I've figured out that I cannot seem to lock on the pilot code. Finally bought an osciliscope. I've set up a second fpga board to act as a transmitter and currently have it just outputting a PRN code. My receiver is now just trying to match the code. I did get a lock once after just hitting the fpga board reset and rebooting the start sequence but it seems to have been a fluke. I can't tell if my delay code is actual functioning correctly or not. $\endgroup$ – J Hinton Jun 19 '14 at 4:11

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.