> Tom, > > Thank you for the valuable inputs. I was quietly hoping that I was > misunderstanding the protocol in some way. > > My gut tells me that <Checksum><cr><lf><@><@> would be believable more than > say 95% (if not 99%) of the time. I've got the following observations: > > - 95% is a bad number in accurate timing applications.
You misunderstand. You can get as close to 100% as you want. Some of us have logged data from M12+ receivers without error for weeks or months -- gigabytes, error-free. > - the checksum is one of the few things that are easy to do in VHDL. > > - one would always miss the first most data stream at startup (not a > problem). Correct, not a problem. Note NMEA, TSIP, and any other GPS protocol has the same feature, right? > - the last message in the data stream will always only be decoded on the > next second when the new streams are coming through (a potential problem) Not true. You can process the entire message as soon as the checksum matches. Do you see why? If you're brave you can process the message, byte by byte, field by field, as it arrives in real time and use the checksum as a commit. > Thus, I agree: The only real reliable way is to have a lookup of header > bytes and data length. Disappointing protocol I must add. A protocol like NMEA (ascii at 4800 baud) doesn't have sufficient bandwidth to accomodate all the data from a timing receiver. So Motorola (and Trimble, etc.) all have binary protocols (~2x the density of ascii) and higher baudrates. > I so hoped that this won't be the case. Such is life. > > Regards, > > Stephan. /tvb _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
