I have updated the project's cover picture to reflect the changes brought from the last logs.

It does not represents everything but gives a rough idea.

The #miniPHY  is not yet determined, the granularity (size of the nibbles) is not fixed yet (and may still change later) so the nibble Mux is not accurate either.

Having a size that is 3×3×2 makes some things a bit easier, compared to 17 (which is a prime).

The config/counter boxes represent the max size of the chunks, depending on the packet's length and the BER.

Here we see that GrayPar does not expand the words, only scrambles and increases avalanche. Using 5+5+5+3 reduces the depth of the Vs at the decoding side. I have no yet thought about the 3+3=>3 LUT.

gPEAC is expanded to 18 bits to include the C/D bit, which provides its own safety mechanism at the receiver end.

.

_________________________________________

.

Now there are certain things to consider.

• GrayPar is now "just" a 18-to-18 bit transform to increase avalanche. It doesn't even report an error (lesson learned). It could even be left out or short-circuited but it should speed up error detection.
• BUT the 18 bits at the input could be any combination of the actual data AND other stuff, such as other bits of the hidden gPEAC register (after permutation/scrambling). At the receiving end, the same operation can be applied to recover the actual data and feed the descrambler. Tests must determine if this actually increases error detection.
• A solid scrambling/descrambling 6->3 LUT and deLUT is required, see 75. Better markers
• gPEAC criteria have changed, the modulus should be closest to 2^17. So 78. gPEAC18 is somewhat obsolete.

That's a lot of work in perspective.