Hacker News new | past | comments | ask | show | jobs | submit login

I love how we used to use a bunch of very clever "code book" systems like 8b/10b which did a lot of careful work with small runs of bits to ensure the clock was recoverable and to avoid line capacitance issues.

Then we just moved to things like 64/66b which takes a giant chunk of bits, adds a short header to guarantee a clock transition, then runs everything through a pseudorandom scrambler.




Against adversaries, scrambling schemes can produce some very perplexing behaviour. See the "weak sectors" used for CD copy protection for one infamous example.


A sprinkle of entropy improves everything


They do a similar thing for GPS data recovery. It is so far below the noise floor that normally speaking the signal is not recoverable. But then you inject some (known) noise and suddenly the noise modulated by the (unknown) signal starts to drown out the noise in the rest of the system and that in turn allows you to recover bits from the signal.


It's not only below the noise floor, but all satellites transmit the code on the same frequencies, so it's several signals all at once below the noise floor. Which makes the known noise unique to each satellite, and you dredge out the same frequency repeatedly with different sets of known noise to recover multiple signals.

Gold sequences are really neat, which is precisely the same pseudorandom scrambling technique, but where each sequence is selected to have low correlation with all other sequences in use, which is what enables the frequency sharing property of the system.



That's a great article, you should post it separately.



This thread brings back fond memories from electronics and digital signal processing.


QR codes do this too, as explained by yesterday’s front page post about decoding QR codes by hand.


The PCIe standards kept moving to longer codes, and nowadays they're able to do "1b/1b" (no header at all)


Not really accurate. The switch from NRZ to PAM4 actually massively increased the bit error rate. They switched away from the 8b/10b style line code and replaced it with forwards error correction.

PCIe 6.0 uses 256 Byte frames, with 242 Bytes of data, 8 Bytes or CRC and 3 Bytes of error correction.

So it actually has way more overhead than the older versions and their 128b/130b line coding, It's just at a slightly different layer.


Thanks! Did not know they added FEC, that makes more sense :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: