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

[Brooke Clarke]

Hi Stephan:

I was wrong about the stuffing.  Got confused with other protocols.
All the Motorola @@ packets are a fixed length.

Have Fun,

Brooke Clarke
http://www.prc68.com

Brooke Clarke wrote:
> Hi Stephan:
> 
> Check the manual for "stuffing", it's not a Thanksgiving term here but has to 
> do with what happens when a byte in a binary data stream (the data in the 
> Motorola protocol is all binary, not ASCII) is the same as the ASCII "@" 
> character.  This means that the length of a packet is variable and depends on 
> the actual data inside the packet.  But you know the minimum length if you know 
> the packet ID.
> 
> To start look for the string <CR><LF>@@ and the next characters (maybe 2 or 4 
> hex characters) are the packet ID.  Sometimes this happens inside a packet 
> because that's what the data looks like.  But go with it and if it's wrong the 
> program will cycle around to where you are on packet boundaries.
> 
> 
> Have Fun,
> 
> Brooke Clarke
> http://www.prc68.com
> 
> Stephan Sandenbergh wrote:
>> 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.
>