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@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.