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

[Stephan Sandenbergh]

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.

- 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).

- 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)

Thus, I agree: The only real reliable way is to have a lookup of header
bytes and data length. Disappointing protocol I must add.

I so hoped that this won't be the case. Such is life.

Regards,

Stephan.

2008/11/19 Tom Van Baak <tvb at leapsecond.com>

> Stephan,
>
> Ah, it's not a stupid question -- I think all of us who have written
> code to interface with GPS receivers have had to deal with this.
>
> Some GPS protocols use escape characters, but the Oncore
> binary protocol doesn't. There are five clues to robustly parsing
> a complete message:
>
> 1) starts with @@
> 2) ends with <cr><lf>
> 3) message length is known, based on message header
> 4) valid checksum
> 5) there may be a pause between sentences
>
> You can use all of these clues to "sync" to a serial data stream
> and accurately determine the start of the next message.
>
> As you already observed, just looking for @@ or <cr><lf> is
> not sufficient. Checking for <cr><lf>@@ is better, but still not
> perfect. To do it right you also need to include message length
> and checksum into the calculation. The length is knowable by
> looking at the message type in the header as it arrives.
>
> If you use a millisecond-level serial timeout that can help even
> more (since if the first two bytes after a pause are @@ you
> know it is a message start, not 16-bits of 0x4040 embedded
> binary data). There is a timing gap between some, but not all
> messages, so use this technique with care. You can also use
> the 1PPS pulse as a start of message hint.
>
> True, a robust solution is not FPGA-friendly, but probably not
> impossible, either. If you can't solve it, consider using a $1
> microcontroller (where this sort of message handling is trivial)
> between the receiver and your FPGA which would parse, edit,
> or reformat the messages to the FPGA's liking.
>
> /tvb
>
>
> > Hi All,
> >
> > Up until now we've been interfacing my Motorola M12+T's using the Oncore
> > software. However, at this point we are trying to have it interfaced
> > directly to a FPGA. To my mind this should be simple - the commands are
> > discriminated (framed) by looking at the start and terminating bytes
> > sequences when they enter the FIFO, check summed, decoded etc.
> >
> > However, I noted something very peculiar about the motorola ASCII
> protocol:
> > The start bytes @@ and he terminating byte <CR><LF> aren't unique with
> > respect to the data bytes. For instance one could receive a time of 13hrs
> > and 10mins which would look identical to the terminating characters.
> > Initially I thought it made sense since the data is also sent in ascii
> > format. It appears not to be the case.
> >
> > It seems to me that the only way in which a command could be robustly
> > identified and check summed is when the interface knows the length of the
> > expected return.  Obviously, the data lengths are dependent on both the
> > actual command and the specific request. This type of intelligence is
> > cumbersome to implement in FPGAs.
> >
> > It would be of great help if you could point me in the right direction
> here.
> > I feel rather stupid in asking such a simple question, but at this point
> I
> > can't seem to see the light. I'm flabbergasted...
> >
> > Best regards,
> >
> > 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.
>