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

Stephan Sandenbergh stephan at rrsg.ee.uct.ac.za
Fri Nov 21 13:06:23 UTC 2008


Hi,

Thanks all - I think I've got a pretty good grasp of the protocol now.
Ulrich thanks for the rule set. I'm quite sure the remaining issues are just
us speaking past one another. Maybe the [time-nuts] could get a white board
for block diagrams? :)

One more thing: The M12+ automatically throws out faulty messages - does it
remove those messages from the input buffer to make space for valid ones?
Or, are the faulty messages kept in the buffer but not processed?

The reason I'm asking: If the former is true I will be able to have the M12+
share the RX part of the RS232 link with another device. Messages destined
for the other device will be discarded. Same goes for the other device. If
the latter is true the M12+ buffer would probably always be full with
garbage destined for the other device.

Does anyone know the answer to this?

Regards,

Stephan

On 21/11/2008, Ulrich Bangert <df6jb at ulrich-bangert.de> wrote:
>
> 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.
> >
>
>
> _______________________________________________
> 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_lists.febo.com mailing list