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

Tom Van Baak tvb at LeapSecond.com
Wed Nov 19 19:05:44 UTC 2008


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





More information about the time-nuts mailing list