On 20/11/2018 14:24, Brian Waterworth wrote:
Would adding another contest to the list of supported wsjtx contests
remove the restriction you cited? And granted, I get that this would
take more time to develop than broadening the allowable characters for
the current ARRL Field Day contest.
Hi Brian,
the source encoding of the WSJT-X messages is fundamental to the
protocols, due to the extreme compression algorithms used to pass the
maximum message content within the fixed constraint of fixed length code
word. There is virtually no room for changes and a change is likely to
mean a whole new protocol has to be rolled out. There are 3 bits
allocated for the FD class in the block of message encodings used for FD
exchanges, 3 bits can store a maximum of 8 different values and that
cannot be changed without changing the number of bits allocated. The
number of bits allocated is constrained by the overall codeword size
(77-bits) and the other parts of a message like the callsigns, the
message type flags, and the rest of the FD exchange.
Looking at it a different way, a single character (A through Z all the
same case) can be encoded as an ASCII code which takes 7-bits, or it can
be reduced to as few as 6 bits because we are not allowing for the other
case or numbers or common punctuation (6 bits allows for 64 possible
combinations which is enough for the 26 character alphabet and more). 5
bits is also enough for alphabetic letters with 32 combinations but 4
bits is not enough as it only has 16 combinations. 4 bits could be used
for A through P, but we only had 3 spare bits to encode the FD class, so
that limits us to 8 combinations which covers A through F with two
unused spares.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
