SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Qualcomm Incorporated (QCOM)
QCOM 171.25-1.6%10:45 AM EST
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Ramus who wrote (24592)3/22/1999 12:01:00 AM
From: Clarksterh  Read Replies (1) of 152472
 
Walt - The long code itself is a PN sequence generator polynomial of length 2^42-1 bits. The mask is a sequence of 42 bits that are XOR'd with this PN sequence creating a new sequence.

First, a disclaimer having read back through this thread and my various posts on this subject. Originally I started out discussing CDMA in CineComm, on which I was/am pretty confident, and gradually we have moved to eavesdropping and cloning on which I was confident but am now considerably less confident (I did some more research).

That being said, you and I are saying the same thing - the XORing of the PRN generator is the same as a time shift of the generator. This is done to prevent two handsets from producing the same 'code' sequence at the same time and interfering with one another. It also has the effect of making it harder to lock onto the Reverse link if you don't know the time shift (you have to search through the various times although it should be noted that this is not an issue with the forward link which, if I remember correctly, does not use the long code although surprisingly my books conflict on this.). My mistake in earlier posts was that I assumed that there were quick ways to lock up to this long code even without knowing the time offset (I've worked with such PRN codes), but in this case I now believe this to be wrong. The implication of this is that it is probably not as easy to listen to the reverse link in real-time as I thought without a lot of computing power (somewhat like decrypting a 42 bit code in real-time). I need to think more on how long it would take with how many MIPS, but it should be noted that 42 bits is not that many by modern encryption standards.

Clark

PS Note that if the forward link does not use the long code (I have to find another spec to decide between conflicting specs), the forward link will be considerably easier to scan than the reverse link.
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  

HomeMailHotSubjectMarksPeopleMarksKeepersSettings
Terms Of UseContact UsCopyright/IP PolicyPrivacy PolicyAbout UsFAQAdvertise on SI
© 2025 Knight Sac Media.  Data provided by Twelve Data, Alpha Vantage, and CityFALCON News