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

Brooke Clarke brooke at pacific.net
Thu Nov 20 17:04:51 UTC 2008


Hi Stephan:

I've heard from Art at Synergy that the latest i-Lotus versions of the M12+T 
receivers have NMEA enabled.  That's to say you can switch to that protocol.

Have Fun,

Brooke Clarke
http://www.prc68.com

Stephan Sandenbergh wrote:
> Hi,
> 
> NMEA would have been nice - but this is a timing application.
> 
> Stephan.
> 
> 2008/11/19 Stanley Reynolds <stanley_reynolds at yahoo.com>
> 
>> Looking at the user guide which is the extent of my experience. Would the
>> position version of the M12+ be a better choice for your application ? That
>> is trade NMEA-0183 for all the timing features ?
>>
>> Stanley
>>
>> Link to user guide :
>> http://www.synergy-gps.com/images/stories/guides/m12+userguide.pdf
>>
>>
>>
>>
>>
>>
>> ________________________________
>> From: Stephan Sandenbergh <stephan at rrsg.ee.uct.ac.za>
>> To: Discussion of precise time and frequency measurement <
>> time-nuts at febo.com>
>> Sent: Wednesday, November 19, 2008 8:29:59 AM
>> Subject: [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.
>>
> _______________________________________________
> 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