Hanging bridge question
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.
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.
--
WBW,
V.P.