I've spent a good part of the afternoon looking at all the plots, websites and the few papers I could find mentioning the hanging bridge. As far as I can tell as long as one is correcting for sawtooth there's nothing additional to do about hanging bridges. They merely show up as funny waveforms in the data that has not been corrected for sawtooth. Am I correct? Thanks jim ab3cv (still learning...)

In message <CACYeN9zf-UO1sCTCRMHSDPN4u=ye0xb9+x71eLxBnbT=Xgw+pA@mail.gmail.com> , Jim Miller writes: >I've spent a good part of the afternoon looking at all the plots, websites >and the few papers I could find mentioning the hanging bridge. As far as I >can tell as long as one is correcting for sawtooth there's nothing >additional to do about hanging bridges. The sawtooth correction *is* the correction for the hanging bridge. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Hi Exactly correct, the sawtooth corrects for the hanging bridges. Since that’s what it does, sawtooth correction error is not totally random. Hanging bridges are not totally random. One looks like the other. Sawtooth correction errors can / will have hanging bridges in them. If you are doing sawtooth correction, it’s best to do it with decent accuracy. Bob On Mar 25, 2014, at 3:27 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > In message <CACYeN9zf-UO1sCTCRMHSDPN4u=ye0xb9+x71eLxBnbT=Xgw+pA@mail.gmail.com> > , Jim Miller writes: > >> I've spent a good part of the afternoon looking at all the plots, websites >> and the few papers I could find mentioning the hanging bridge. As far as I >> can tell as long as one is correcting for sawtooth there's nothing >> additional to do about hanging bridges. > > The sawtooth correction *is* the correction for the hanging bridge. > > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > 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.

In message <6B362A4D-834A-4733-BED8-FCFEC0CCBA6C@rtty.us>, Bob Camp writes: I should add here, that you _can_ do a little bit better than the sawtooth correction. We know, or at least assume, that the GPS's internal clock is step-less and slowly changing, so if you put a predictive filter on this stuff, it can actually do a reasonable job at estimating which way the rounding of the sawtooth correction went (since it is integral ns). This reduces the random rounding error on the sawtooth correction from +/- 0.5 ns to something like +/- 0.3 ns. Totally not worth it, but a cool and educational project :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Hi Most of the more modern receivers don’t stop at one ns resolution on the correction. You can go well below the ns level with them. If you are doing it in software, it’s pretty much free. Bob On Mar 25, 2014, at 7:27 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > In message <6B362A4D-834A-4733-BED8-FCFEC0CCBA6C@rtty.us>, Bob Camp writes: > > I should add here, that you _can_ do a little bit better than the > sawtooth correction. > > We know, or at least assume, that the GPS's internal clock is step-less > and slowly changing, so if you put a predictive filter on this stuff, > it can actually do a reasonable job at estimating which way the rounding > of the sawtooth correction went (since it is integral ns). > > This reduces the random rounding error on the sawtooth correction > from +/- 0.5 ns to something like +/- 0.3 ns. > > Totally not worth it, but a cool and educational project :-) > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence.

Thanks for all the helpful replies! Lots to learn. 73 jim ab3cv

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

Besides the header and trailer you need to unescape any embedded DLE's in the data stream. /tvb (i5s) > On Mar 25, 2014, at 2:43 PM, d0ct0r <time@patoka.org> wrote: > > > 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 > > 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>. > > 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.

                                                                                  ____________
     how are you dumping this?
     you have an imbedded (stuffed)DLE, which is sent as DLE/DLE but the second is to be ignored.

        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;

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.

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

> Besides the header and trailer you need to unescape any embedded DLE's in the data stream. There are a number of code examples on the web showing how to decode TSIP packets. The oldest (original source code from Trimble), is file TSIP_IFC.C from the TSIPCHAT program. You can google for archived copies. Or have a look at the source code to LH. Or you can also see how I do it in my binary-to-text TSIP logging program: http://www.leapsecond.com/tools/tbtalk.c /tvb

Am 25.03.2014 22:43, : > > 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" > but beware, no single document related to Thunderbolt from Trimbles website is complete nor fully correct. As a reference you may use my code of a simple Tbolt-Monitor you will here: http://www.romahn.info/tbolt2lcd/ regards Götz

You can play with my Thunderbolt Simulator: http://www.ko4bb.com/Timing/GPSMonitor/TBoltSim.php (Windows only, sorry...) It lets you create arbitrary packets (including setting fault conditions and arbitrary GPS time or coordinates) and properly escapes the embedded DLEs. The actual string that is sent is displayed in Hex at the bottom of the screen. (Warning: It is work in progress, so not all menu selections actually work) On Tue, Mar 25, 2014 at 7:11 PM, d0ct0r <time@patoka.org> wrote: > > 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@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. > _______________________________________________ > 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. >

Thanks ! As soon as I figured out about "double" DLE bytes - everything is back to right track. Regards, V.P. On 2014-03-26 04:46, Götz Romahn wrote: > Am 25.03.2014 22:43, : >> >> 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" >> > > but beware, no single document related to Thunderbolt from Trimbles > website is complete nor fully correct. > As a reference you may use my code of a simple Tbolt-Monitor you will > here: > http://www.romahn.info/tbolt2lcd/ > regards Götz > _______________________________________________ > 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. -- WBW, V.P.

Speaking about legacy T-Bolt devices and modern development: Here is paragraph from Trimble Thunderbolt User guide: Week Number: This field represents the current GPS week number. GPS week number 0 started on January 6, 1980. Unfortunately, the GPS system has allotted only 10-bits of information to carry the GPS week number and therefore it rolls-over to 0 in just 1024 weeks (19.6 years,) and there is no mechanism built into GPS to tell the user to which 1024 week epoch the week number refers. The first week number roll-over will occur as August 21, 1999 (GPS) transitions to August 22, 1999 (GPS). The ThunderBolt adjusts for this week rollover by adding 1024 to any week number reported by GPS which is less that week number 936 which began on December 14, 1997. With this technique, the ThunderBolt will provide an accurate translation of GPS week number and TOW to time and date until July 30, 2017. How that "week number" will affect the functionality of whole device ? Its probably time to think to put some workaround to the code or even eliminate to use that time information received from T-Bolt. I already met that challenge when I was working with BC637PCI card. The work around was quite simple then - just to add 619315200 seconds to the current value [1024*7*24*60*60]. I would like to be little proactive here. ;-) Also, does anybody knows if new Trimble Thunderbolt "E" is backward compatible with legacy HW ? I mean the replacement will still works on most of existed setups. For example, I did compare the packet definition for 8F-AC and looks like Thunderbolt "E" has some extensions, but its backward compatible. Regards, V.P. On 2014-03-26 08:38, Didier Juges wrote: > You can play with my Thunderbolt Simulator: > > http://www.ko4bb.com/Timing/GPSMonitor/TBoltSim.php [2] > > (Windows only, sorry...) > > It lets you create arbitrary packets (including setting fault > conditions and arbitrary GPS time or coordinates) and properly escapes > the embedded DLEs. The actual string that is sent is displayed in Hex > at the bottom of the screen. > > (Warning: It is work in progress, so not all menu selections actually > work) > > On Tue, Mar 25, 2014 at 7:11 PM, d0ct0r <time@patoka.org> wrote: > >> 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@febo.com >> To unsubscribe, go to >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts [1] [1] >> >> and follow the instructions there. >> >> Links: >> ------ >> [1] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts [1] > > -- > 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 [1] > and follow the instructions there. > > > Links: > ------ > [1] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > [2] http://www.ko4bb.com/Timing/GPSMonitor/TBoltSim.php -- WBW, V.P.