Stephan, for me the following rules have turned to be optimal for M12+ decoding:
1) Program the M12+ to auto-send all information that you are interested in at a one second update rate. 2) During serial reception do nothing else than to put the received data into a buffer of sufficient length. 3) Wait for the PPS to appear. After the positive slope of the PPS you can be sure that EVERYTHING that relates to the second which's start is indicated by the PPS is in your buffer. 4) Start a counter that addresses bytes in your buffer and search for "@@". Don't look for "<cr><lf>@@", that would make it necessary that the end of the messages of the LAST second is still in the buffer in order to detect the first first new packet, what you do not want. Note: Since you will reset the pointer that indicates where in the buffer the next received byte will be written to the start of the buffer after having decoded all packets it is very likely that your buffer starts with "@@" and no lengthy search is necessary. 5) If a "@@" is detected read the next two charcters and using a table decide whether they make a correct packet header and find out the length of the according packet. 6) Use the packet length information to find out whether the <cr><lf> sequence is to be found at a matching location of your buffer. If that is the case then perform the crc calculation. If this is ok too you have found a valid packet and may decode it's contents. 7) Set your "@@" search counter to the end of this packet and goto 4) 8) Repeat this until all packets of interest have been found or until you have reached the end of your buffer. 9) Reset the pointer which indicates where the next received byte shall be written in the buffer to the start of the buffer. Also important: Set all bytes in your buffer to an known initial state, otherwise artefacs of the LAST transmission could pretend a succesfull reception for the current second. Then goto 3) For the whole action you have abt. 30 ms time (an eternity for today technology) because abt. 30 ms after the positive slope of the PPS the M12+ starts to transmit packets belonging to the NEXT PPS. If one of the conditions for a valid packet is NOT given simply disregard it and increment the counter until the next "@@". In my GPSDO I use a log mechanism that logs errors in packet detection & decoding. Sometimes there ARE errors. It does not need a pulled cable or a direct lighning stroke. Any sufficient big spike on your power lines will do. For that reason you should not rely on the idea that the serial reception is practically error-free. However, errors of that kind are very seldom. For me they appear once every few months. Best regards Ulrich > -----Ursprungliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Stephan Sandenbergh > Gesendet: Donnerstag, 20. November 2008 16:17 > An: Discussion of precise time and frequency measurement > Betreff: [time-nuts] Fwd: M12+T ASCII interface - I'm confused? > > > 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. > _______________________________________________ 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.
