[time-nuts] Fwd: M12+T ASCII interface - I'm confused?

Ulrich Bangert df6jb at ulrich-bangert.de
Fri Nov 21 10:56:04 UTC 2008


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: time-nuts-bounces at febo.com 
> [mailto:time-nuts-bounces at febo.com] 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 -- time-nuts at febo.com
> To unsubscribe, go to 
> https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts
> and 
> follow the instructions there.
> 




More information about the time-nuts mailing list