update 2025/11/8 : this scheme is extended and moved lower in the protocol. Now, every transition of C/D must come with a 0 word. This simplifies and strengthens everything.

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

While writing the last log (Unit swap (2)), something struck me and it will reduce the pressure on the design of the protocol.

Currently, the control protocol is simply : send the 16-bit control payload with the C/D bit set, followed by a zero/null payload. The thinking is: if the trailing word is not null, then the gPEAC has accumulated line errors.

Or maybe: the protocol uses more words but they are not recognised by the receiver.

So what about multi-word control sequences ? This would help for future expansions, and early implementation would catch unsupported commands with the non-null word.

Some kind of Golomb-Rice coding can indicate the number of control words, though it is inherent/implicit with the C/D bit. I'm mostly concerned with 1-word and 2-word control messages because I want to send a 16-bit datum: an index takes a lot of room and reduces the number of available instructions. Furthermore, this also limits the data packet's size to 2K words or so, which may be a handicap later.

So the length is a matter of checking the MSB of the first control word. More MSB can later be allocated to encode longer sequences.

All control sequences have the C/D bit set (1) followed by C/D cleared and payload of zero, to validate that the sequence has no accumulated error. The last zero word does not count as data, but C/D is required to be cleared to separate consecutive control sequences, which can be simple NOPs anyway.

Since control words (or sequences) can interrupt a data stream without closing it (they are multiplexed), extra NOPs can be sent regularly for extra error detection and early error correction, though this is not necessary since the extra-stronger parity of the last log takes 7 words to reduce the chance of error down to 1E-6. Add another word due to latency and it's well within 1 millionth for 8 words.

So here is a one-word control message:

dddd dddd dddd dddd dddd 0mpp  <= previous word in the stream

dddd dddd dddd dddd ddd1 1mpp  <= 1-word control message
0000 0000 0000 0000 0000 0mpp  <= Zero word/trailer

dddd dddd dddd dddd dddd Xmpp  <= whatever follows

And a two-word control message:

dddd dddd dddd dddd dddd 0mpp  <= previous word in the stream

dddd dddd dddd dddd dd10 1mpp  <= 1st half of control message: opcode/type
dddd dddd dddd dddd dddd 1mpp  <= 2nd half, containing raw data
0000 0000 0000 0000 0000 0mpp  <= Zero word/trailer

dddd dddd dddd dddd dddd Xmpp  <= whatever follows

Using unary coding in the MSB (reminiscent of UTF-8) the protocol can be extended to more words, if the need ever arises, though it should remain minimalist and it's not recommended.

But at least now it's possible to encode more precise error reporting and longer data packets, at least 64Kword long. And the protocol is not stuck to only 16 bits per control message.