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

[Stephan Sandenbergh]

Hi Ulrich,

Sure - among other things the FPGA keeps a real-time clock. It ticks away on
a disciplined clock, but the time and date value is constantly kept in sync
with what the GPS spits out as UTC.

So, the FPGA catches some of the GPS messages, but also allow for a straight
path through to a PC. Everything that comes in is passed on the the PC -
this way existing software could still be used to interface with the GPS
etc.

Stephan.

2008/11/20 Ulrich Bangert <df6jb at ulrich-bangert.de>

> Stephan,
>
> can you give us a clue what it is all about? What happens with the data
> after being decoded by the FPGA?
>
> Best regards
> Ulrich Bangert
>
> > -----Ursprungliche Nachricht-----
> > Von: time-nuts-bounces at febo.com
> > [mailto:time-nuts-bounces at febo.com] Im Auftrag von Stephan Sandenbergh
> > Gesendet: Mittwoch, 19. November 2008 15:30
> > An: Discussion of precise time and frequency measurement
> > Betreff: [time-nuts] M12+T ASCII interface - I'm confused?
> >
> >
> > 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.
> >
>
>
> _______________________________________________
> 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.
>