Frank, Pete - thanks very much for your interest and help. I'll tell you what I know so far. I'm on a steep learning curve...
Each Eurofix "Message" format is 210 bits long - that's 30 times 7 bit characters. Its structure is 70 bits of Application Data, followed by 140 bits of Reed-Solomon FEC. The Application Data is composed of MESSAGE_TYPE (4 bits), MESSAGE_CONTENT (52 bits), CRC (14 bits). Total MESSAGE Application Data equals 70 bits, and the CRC is protecting just the 56 bits previous.
The 7 bit characters are elements of a Galois Field GF(128) - that's how a purist mathematician would describe them. I would simply refer to these as the hexadecimal set from 0 to 7F. There is a table mapping from "6 symbols" of modulation to hex (e.g. "0 0 + - - +" equals 0x2D) but I already perform this translation inside Teensy on the fly, so I hold the 7 bit data as a hex number in a byte array. I simply drop the hex into an 8 bit byte, which is then part of a larger "data array" of type byte. In real time, its easier to do it this way now rather than to try concatenate a long bit string adding 7 bits each time. There is a lot happening in real time inside an ISR (not least of which is a precision phase locked 100 KHz sq wave), but that may change in the future. The spec says that the least significant symbol is transmitted first - so I'm hoping that I have performed the translation correctly (but it could be the other way around). You would expect "little endian" for serial data.
So the test data I can give you is a list of bytes, where the m.s. bit is never set. This list is in time order of arrival. But I cannot yet say where in this list sits the CRC - reason: I don't have any "start" or "stop" information of where a MESSAGE begins and ends. Its a 14 bit CRC, so there will be two of my bytes that make it up. It is possible that the "Message" sits within a DATA LINK layer (as Ethernet stuff does with the "01111110" flags) and there may be 7 bit characters wrapped around the "Message", but I don't have that spec, and its not obvious from inspecting the data that this is so. I cannot see an obvious pattern.
My strategy therefore is to trawl through the data testing pairs of 7 bits as a possible CRC for the 56 bits which precede them (56 bits followed by CRC of 14 bits). There should be a pattern emerge if I can find it, but its a little like looking for "needles in a haystack".
The CRC14 uses this polynomial... x^14 + X^13 + x^7 + x^5 + x^4 + 1. I calculate this to be "0x60B1" or "110000010110001".
Here is some data in time order and lines of 30 Bytes... (I was hoping to see a pattern but I can't. There should be at least six messages in here.)... There may be some errors too (its a very noise channel), but I'm using averaging of 20 cycles of pulse per 6 symbols in making phase decisions, so I don't expect many...
0x18,0x18,0x07,0x50,0x5D,0x5D,0x61,0x4D,0x63,0x64,0x7C,0x15,0x42,0x01,0x1D,0x6C,0x59,0x2A,0x60,0x59,0x35,0x35,0x59,0x68,0x70,0x58,0x32,0x66,0x49,0x2B,
0x15,0x0A,0x41,0x27,0x70,0x55,0x47,0x37,0x4A,0x5D,0x0F,0x45,0x4F,0x2B,0x59,0x16,0x35,0x7B,0x36,0x3F,0x47,0x75,0x4D,0x51,0x67,0x21,0x6D,0x4D,0x1D,0x4D,
0x4F,0x14,0x77,0x7F,0x2E,0x5A,0x3A,0x11,0x11,0x35,0x1A,0x6A,0x2C,0x6A,0x52,0x41,0x3A,0x31,0x34,0x3F,0x52,0x40,0x1E,0x22,0x20,0x41,0x6E,0x14,0x15,0x22,
0x27,0x0D,0x73,0x59,0x5D,0x2B,0x67,0x1A,0x39,0x1D,0x45,0x7C,0x5B,0x1B,0x76,0x29,0x3E,0x65,0x25,0x56,0x03,0x72,0x60,0x1C,0x53,0x64,0x09,0x4E,0x53,0x2E,
0x4D,0x4E,0x75,0x52,0x31,0x32,0x0B,0x2A,0x3F,0x18,0x5B,0x57,0x59,0x34,0x76,0x1A,0x0A,0x5E,0x5F,0x3B,0x56,0x59,0x4C,0x6B,0x5B,0x59,0x79,0x77,0x3A,0x71,
0x7A,0x48,0x41,0x4D,0x1F,0x2E,0x7D,0x42,0x2B,0x5A,0x58,0x2C,0x16,0x25,0x59,0x35,0x3F,0x2C,0x3F,0x52,0x24,0x7B,0x58,0x62,0x11,0x34,0x62,0x2A,0x31,0x7D,
0x7B,0x32,0x7D,0x35,0x14,0x28,0x57,0x47,0x33,0x59,0x1F,0x11,0x18,0x39,0x1B,0x31,0x56,0x4F,0x38,0x6B,0x60,0x43,0x2B,0x6A,0x16,0x27,0x2F,0x7E,0x1A,0x7E
It would pay me to have some simple test data first for the CRC14, and that's what I'm looking at currently using Pete's software algorithm.
regards, Bill