[time-nuts] TSIP protocol for T-Bolt

[d0ct0r]

Much thanks Tom and Mike ! I missed that point. In another word, T-Bolt 
sending DLE data "wrapped" by another byte ! Now I know !

On 2014-03-25 19:55, mike cook wrote:
> Le 25 mars 2014 à 22:43, d0ct0r a écrit :
> 
>> Today I spent good part of my time to figure out that my version of
>> Thunderbolt has some issue with the TSIP protocol definition. I am
>> using following document: "ThunderBolt GPS Disciplined Clock User
>> Guide, Version 5.0, Part Number: 35326-30, November 2003"
>> 
>> In that particular PDF file, there is definition for 0x8F-AB TSIP
>> packet [section A.10.30 Report Packet 0x8F-AB Primary Timing
>> Packet].
>> 
>> Here is the structure of 8F-AB, translated to plain C-code:
>> 
>> typedef struct tb_8f_ab {
>> uint8_t sub; //0 : 1
>> uint32_t tow; //1-4 : 4
>> uint16_t wn; //5-6 : 2
>> int16_t ls; //7-8 : 2
>> uint8_t tflag; //9 : 1
>> uint8_t sec; //10 : 1
>> uint8_t min; //11 : 1
>> uint8_t hr; //12 : 1
>> uint8_t day; //13 : 1
>> uint8_t month; //14 : 1
>> uint16_t year; //15-16 : 2
>> } mytb_8f_ab;
>> 
>> Here is the dump I get from my MCU:
>> 
>> //0x10 0x8F 0xAB 0x0 0x3 0x92 0x88 0x6 0xF9 0x0 0x10 0x10 0x3 0x2C
>> 0x1 0x11 0x19 0x3 0x7 0xDE 0x10 0x3
>> //0x10 0x8F 0xAB 0x0 0x3 0xCC 0x16 0x6 0xF9 0x0 0x10 0x10 0x3 0x12
>> 0x7 0x15 0x19 0x3 0x7 0xDE 0x10 0x3
>  ____________
>  how are you dumping this?
>  you have an imbedded (stuffed)DLE, which is sent as DLE/DLE but the
> second is to be ignored.
> 
>> Which is conform to TSIP standard packet definition:
>> 
>> TSIP packet structure is the same for both commands and reports. The
>> packet format is:
>> <DLE> <id> <data string bytes> <DLE> <ETX>
>> Where:
>> • <DLE> is the byte 0x10
>> • <ETX> is the byte 0x03
>> • <id> is a packet identifier byte, which can have any value
>> excepting
>> <ETX> and <DLE>.
> 
>  Ex: In the tsip developer tool kit , from TsipParser.c
> 
>  case TSIP_IN_PARTIAL:
>  // The parser is in this state if a previous character was
>  // a part of the TSIP data. As noted above, a DLE character
>  // can be a part of the TSIP data in which case another DLE
>  // character is present in the data stream. So, here we look
>  // at the next character in the stream (currently loaded in
>  // ucByte). If it is a DLE character, we just encountered
>  // a stuffed DLE byte. In that case, we ignore this byte
>  // and go back to the TSIP_DLE state. That way, we will log
>  // only one DLE byte which was a part of the TSIP data.
>  //
>  // All other non-DLE characters are placed in the TSIP packet
>  // buffere.
>  if (ucByte == DLE)
>  {
>  nParseState = TSIP_DLE;
> 
>  }
>  else
>  {
>  ucPkt[nPktLen++] = ucByte;
>  }
>  break;
> 
>> However, its appeared that my T-Bolt throwing one "extra" byte for
>> the so-called "Timing Flags".
>> There is 19 bytes coming from my T-Bolt, instead of expected 18. I
>> found that actual length of TFLAG is 16 bit - not 8. Interesting
>> enough, that Lady Heather works perfectly fine with that T-Bolt !
>> 
>> Can somebody confirm that there is different version of T-Bolt on
>> the market ? If so, where I need to look for the documentation for
>> my version ?
>> 
>> --
>> WBW,
>> 
>> V.P.
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts [1]
>> and follow the instructions there.
> 
> 
> 
> Links:
> ------
> [1] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

-- 
WBW,

V.P.