Using a cube to map and distribute the codes, I get this result:

It is not radically different and yes, I have completely broken the symmetries but it's OK. There are indeed many constraints:

• 111 must map to +
• 110 must map to -
  
• 000 and 111 should not be mapped to ++ and/or -- (to prevent long strings of identical trits)
• a Hamming distance of 2 is required for any change of 1 trit (there are 2 unavoidable exceptions only)

Encoding is not a difficult task, each group of 3 bits gets decoded as 2 pairs of bits, alternatively (depending on the clock phase)

bits  trits
000    - 0
001    0 -
010    + +
011    - -
100    + 0
101    0 +
110    - +
111    + -

Fun fact : the LSB of the bits swaps the order of the trits! The two MSB give 4 bits and the LSB will swap them... except for 01x :-/

Decoding:

trits   pos  neg
 - -    011  010
 - 0    000  100
 - +    110  111
 0 -    001  101
 0 +    101  001
 + -    111  110
 + 0    100  000
 + +    010  011

There is no need to apply "logic" to the negative (swapped) version : a simple XOR or swap at the output of the comparators will just do the trick.  So the table does not need symmetry...

This code satisfies the need for the sync word +-+-+-+-+-+- to mean something else when the polarity is reversed:

• 111 111 111 111 111 xxx is the normal sync word
• 110 110 110 110 110 xxx is the "change parity" control word

.

So I have now mooted the need for central symmetry of the LUT or constellation. In fact, the apparent scrambling is what keeps the symbols maximally apart and will create more bit errors if one symbol is altered. These bits will more efficiently cascade through the CRC than if I used a simple, linear mapping.

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

discussion moved to 1. Rotating constellations