Hi, Now I'm slightly confused:
> > > 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: In the above I assumed no data length checking is employed. > > > > - 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. Sure, I assume you refer to the case when you check the data length as well? I meant that the <Checksum><cr><lf><@><@> byte string could also potentially exist in the data itself, but only in very rare cases (from there the 95% thumb suck). > > > - 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. Again, the checksum could be part of the data string - so without checking the data length you'll be waiting for the @@ (less probable to exist in data). > > > Thus, I agree: The only real reliable way is to have a lookup of header > > bytes and data length. Disappointing protocol I must add. > Stephan _______________________________________________ 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.
