[time-nuts] TSIP protocol for T-Bolt

[mike cook]

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
> and follow the instructions there.