The last log has shown that the running disparity of a whole word can be computed in parallel but at high costs.

Wouldn't it be better to compute only one word's disparity then deduce the correction ?

That's what the previous systems (NRZ and MLT3) enabled, with simple parity as well as mod4. Yet it was still not satisfying.

The baseline wander can be attributed to a "random walk" with no limit on the excursion, and the limit requires extra coding, which I'd like to minimise. This is the territory of 4B3T and its cousin 8B/6T with a very short range disparity, very low excursion, hence high overhead. I'd like to keep it at or below 3 bits/8 codes per 20-bit word so the idea of tweaking the data from the source is pretty interesting.

I don't know why but what I imagine right now is the bias evaluation starting from the middle of the word, going in both directions, seeing how the wander evolves, then at 1/4, 1/2 and 3/4, "swap" something to invert the bias slope. Thus the disparity counter can get higher values but clumps can be broken up. I think. Aaaand it looks a bit (from afar) like Knuth's idea. (D.E. Knuth, “Efficient Balanced Codes”, IEEE transactions on Information Theory, vol it-32, no.1, January 1986)

And there are 7 trits so it's not as easy.

------------------

3B2T is very efficient, 4B3T is less dense but provides relatively easy and very short-term DC balance, which would be good for the analog front-end. There is a tension/compromise between coding efficiency (bandwidth usage) and BLW resilience...

BLW and code disparity is fortunately studied in length. Howard Johnson has an interesting analysis at https://sigcon.com/vault/pdf/7_09_addenda.pdf

https://imapsource.org/api/v1/articles/57229-line-coding-methods-for-high-speed-serial-links.pdf

But one thing I have not yet seen covered is "clipping". Applying a clipping with a pair of diodes adds some non-linearity and some hysteresis but it reduces the absolute excursion. Another trick is to use the midpoint tap of the transformer. Absolute levels don't seem to really matter, but the amplitude and direction of the pulses count the most.

For now, the emphasis is on the simplicity of the analog front-end, where a good portion of the manufacturing complexity and costs lies. In fact at this stage, even Manchester coding (like 10Base-T) would be nice, though would it work at a higher speed (at, say, 30MHz), and how is it possible to apply this principle to ternary coding ?