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@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.