Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!mordor!sri-spam!nike!ucbcad!ucbvax!shasta.stanford.edu!kaufman From: kaufman@shasta.stanford.edu (Marc Kaufman) Newsgroups: mod.protocols Subject: RF modem problem / CRC Message-ID: <8607252354.AA15690@ucbvax.Berkeley.EDU> Date: Fri, 25-Jul-86 18:04:27 EDT Article-I.D.: ucbvax.8607252354.AA15690 Posted: Fri Jul 25 18:04:27 1986 Date-Received: Fri, 25-Jul-86 23:48:23 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Approved: protocols@red.rutgers.edu Newsgroups: mod.protocols Subject: Re: PROB CRC-FAIL on VMSHARE Summary: Expires: References: Sender: Reply-To: kaufman@Shasta.UUCP (Marc Kaufman) Followup-To: Distribution: Organization: Stanford University Keywords: CRC-16 is extremely susceptible to even-number-of-bit errors. For example, the following error pattern will not change the CRC: 10000100000010001 (binary), where '1' indicates a bit error. The newer high-speed modems use 64-QAM or 256-QAM modulation schemes, so the right kind of error in 2 or 3 adjacent frames can cause a problem that still passes CRC. The solution is to post-scramble the bits before the modem sees them, so that adjacent bits are separated by many frames, thereby reducing the chances that a burst error of a few frames will allow the CRC to pass. Unfortunately there is no hardware to do this that I know of. Marc Kaufman (kaufman@shasta.stanford.edu)