Re: [time-nuts] Airraft Ping Timing
n1...@dartmouth.edu said: I am surprised it took them this long. A number of satellite telemetry systems can use doppler as a matter of course for locating transmitters, such as Iridium and Argos. It's more complicated than just computing the Doppler. You also have to figure out what the base frequency is and maybe how it changes over time. If you assume the transmit frequency is stable and that the plane is flying in a straight line and you have several samples on a broad enough angle/Doppler spread, you can probably work it all out. For Iridium, the target is fixed (or moving slowly relative to the satellite) and the satellite is moving fast so it gets a lot of angle/Doppler change to work with. -- These are my opinions. I hate spam. ___ 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.
Re: [time-nuts] NIST time services
In message e1wsemc-000dz8...@stenn.ntp.org, Harlan Stenn writes: I'm actually not certain that it helps, even if you document it. It's sort of an administrative distance and it unfairly penalizes any GNSS in favour of terrestial if you calibrate it according to the original intent... I'm game to come up with a better plan. Original intent is good, and follow-on improvements are even better. Internal to NTPns I used a different scheme to pick refclock, each refclock got one vote for each independent source it had. This means that GPS almost always wins, since it has one vote for each sat not thrown out of the solution, whereas for instance DCF77 or WWVB would only get one vote, there being only one transmitter. Propagating something like that directly out of the S1 server is probably not sound, we don't want everybody to use the furthest server in TTL, just because it has a 24 channel GPS receiver. Likewise, NIST and USNO may have significantly more faith in their coax cable than the rest of us should have in over-the-air signals. So all in all, I'm not really sure what we can do automatically with the root dispersion at S1 level. At lower levels I think it works more or less as is should. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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.
Re: [time-nuts] Hanging bridge question
In message CACYeN9zf-UO1sCTCRMHSDPN4u=ye0xb9+x71eLxBnbT=xgw...@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 p...@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.
Re: [time-nuts] Hanging bridge question
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 p...@phk.freebsd.dk wrote: In message CACYeN9zf-UO1sCTCRMHSDPN4u=ye0xb9+x71eLxBnbT=xgw...@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 p...@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. ___ 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.
Re: [time-nuts] Hanging bridge question
In message 6b362a4d-834a-4733-bed8-fcfec0ccb...@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 p...@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.
Re: [time-nuts] Hanging bridge question
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 p...@phk.freebsd.dk wrote: In message 6b362a4d-834a-4733-bed8-fcfec0ccb...@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 p...@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.
Re: [time-nuts] Hanging bridge question
The lowest cost solution is a DS chip in combination with a PIC. How ever has any one thought about a fix by going to the source of the problem. The TCXO. Use a DDS with internal multiplier like the AD9851 or AD 9913 and use the sawtooth message from the GRS receiver and change the frequency. An other alternative would be to use the sawtooth word to fine tune a TCXO or any VCXO for that matter. Bert Kehren In a message dated 3/25/2014 7:28:11 A.M. Eastern Daylight Time, p...@phk.freebsd.dk writes: In message 6b362a4d-834a-4733-bed8-fcfec0ccb...@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 p...@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. ___ 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.
Re: [time-nuts] NIST time services
On Mon, Mar 24, 2014 at 4:26 AM, Poul-Henning Kamp p...@phk.freebsd.dkwrote: In message CABbxVHuQc0144==21mDa_R8ErKov= em+9rvrbpggexnzztj...@mail.gmail.com , Chris Albertson writes: Yes. NTP calls it root distance [...] And it is generally useless, because people don't calibrate it. How do you calibrate root distance assuming that it's one-half the roundtrip root delay plus the root dispersion plus minor error contributions not considered here? ___ 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.
Re: [time-nuts] NIST time services
In message CAKyJ6kajBO=yvkg44s_sdo5owruzem4tzx8atvcirkmgcn8...@mail.gmail.com , Paul writes: On Mon, Mar 24, 2014 at 4:26 AM, Poul-Henning Kamp p...@phk.freebsd.dkwrote: And it is generally useless, because people don't calibrate it. How do you calibrate root distance assuming that it's one-half the roundtrip root delay plus the root dispersion plus minor error contributions not considered here? You key in the number for the light-speed delay from whatever radio-transmitter you're listening to. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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.
Re: [time-nuts] Hanging bridge question
Thanks for all the helpful replies! Lots to learn. 73 jim ab3cv ___ 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.
Re: [time-nuts] Airraft Ping Timing
Yes, and there was an early military positioning system, roughly 1960s / 1970s that worked on Dopplar also. The name escapes me at the moment. -John = This is how ELT locating satellites work (when not relaying the newer GPS data bursts). Several on another list I watch suggested this pretty early on and I guess INMARSAT got the message. I'd be curious to know if AFRCC pointed INMARSAT in that direction. Really shows the value of precise and stable time references! Date: Mon, 24 Mar 2014 16:06:14 -0700 (PDT) From: J. Forsterj...@quikus.com To:time-nuts@febo.com Subject: [time-nuts] Airraft Ping Timing Message-ID: 13855.12.226.214.5.1395702374.squir...@popaccts.quikus.com Content-Type: text/plain;charset=iso-8859-1 According to a report on FOX, INMARSAT was able to determine the Malasia Air followed the southern traectory from the Dopplar of the pings. They verified their model by tracking other planes. -John = ___ 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.
Re: [time-nuts] Airraft Ping Timing
Hi, Yes, and there was an early military positioning system, roughly 1960s / 1970s that worked on Dopplar also. The name escapes me at the moment. I think it is Transit. See http://en.wikipedia.org/wiki/Transit_(satellite) Greetings, Pieter. -John = This is how ELT locating satellites work (when not relaying the newer GPS data bursts). Several on another list I watch suggested this pretty early on and I guess INMARSAT got the message. I'd be curious to know if AFRCC pointed INMARSAT in that direction. Really shows the value of precise and stable time references! Date: Mon, 24 Mar 2014 16:06:14 -0700 (PDT) From: J. Forsterj...@quikus.com To:time-nuts@febo.com Subject: [time-nuts] Airraft Ping Timing Message-ID: 13855.12.226.214.5.1395702374.squir...@popaccts.quikus.com Content-Type: text/plain;charset=iso-8859-1 According to a report on FOX, INMARSAT was able to determine the Malasia Air followed the southern traectory from the Dopplar of the pings. They verified their model by tracking other planes. -John = ___ 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. ___ 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.
Re: [time-nuts] Airraft Ping Timing
Could well be. I never saw the bird, of course. The portable ground station was roughly the same size as an OD Manpak radio of the period and read out Lat/Long on LED digital readouts. In retrospect, it may have been in the early 1980s. -John == Hi, Yes, and there was an early military positioning system, roughly 1960s / 1970s that worked on Dopplar also. The name escapes me at the moment. I think it is Transit. See http://en.wikipedia.org/wiki/Transit_(satellite) Greetings, Pieter. -John = This is how ELT locating satellites work (when not relaying the newer GPS data bursts). Several on another list I watch suggested this pretty early on and I guess INMARSAT got the message. I'd be curious to know if AFRCC pointed INMARSAT in that direction. Really shows the value of precise and stable time references! Date: Mon, 24 Mar 2014 16:06:14 -0700 (PDT) From: J. Forsterj...@quikus.com To:time-nuts@febo.com Subject: [time-nuts] Airraft Ping Timing Message-ID: 13855.12.226.214.5.1395702374.squir...@popaccts.quikus.com Content-Type: text/plain;charset=iso-8859-1 According to a report on FOX, INMARSAT was able to determine the Malasia Air followed the southern traectory from the Dopplar of the pings. They verified their model by tracking other planes. -John = ___ 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. ___ 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.
[time-nuts] TSIP protocol for T-Bolt
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.
Re: [time-nuts] TSIP protocol for T-Bolt
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 t...@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.
___
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.
Re: [time-nuts] Hanging bridge question
On Tue, Mar 25, 2014 at 5:44 AM, ewkeh...@aol.com wrote: The lowest cost solution is a DS chip in combination with a PIC. How ever The lowest cost solution is to do the correct entirely in software. After the measure the phase, simply add the correction. All you need to know is the phase. There is not point in correcting the pulse, you don't need a corrected pulse. What you want is a measurement of the phase. Chris Albertson Redondo Beach, California ___ 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.
Re: [time-nuts] Airraft Ping Timing
On 3/24/14 10:18 PM, David McGaw wrote: I am surprised it took them this long. A number of satellite telemetry systems can use doppler as a matter of course for locating transmitters, such as Iridium and Argos. Those are actually designed for measuring Doppler.. That's really the difference.. This was probably figured out after the fact in an ad hoc way. ___ 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.
Re: [time-nuts] Airraft Ping Timing
On 3/25/14 11:38 AM, J. Forster wrote: Could well be. I never saw the bird, of course. The portable ground station was roughly the same size as an OD Manpak radio of the period and read out Lat/Long on LED digital readouts. In retrospect, it may have been in the early 1980s. Transit, transmitted signals at 400 MHz. Had really high performance Quartz oscillators on board (in a dewar, etc.) made by APL. those oscillators became the basis of the Ultrastable oscillators we use in space now. From an oscillator standpoint, not a whole lot different than back then. There's a whole lot of attention paid to how the crystal is mounted, what the aging characteristic is, etc. USO manufacture is definitely a way to be paid to be a time-nut, because that's what it's really about. Finding all the possible ways that might degrade it and driving them all as small as possible. ___ 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.
Re: [time-nuts] Airraft Ping Timing
On Mon, Mar 24, 2014 at 06:15:57PM -0700, Chris Albertson wrote: Yes, word is that they were able to determine the Doppler shift in the plane's signal. I'm surprised this was even recorded but it must have been in the satellite's telemetry downlink. Projecting radial velocity and constraining it to be close to the earth's surface, I guess determines one path and the direction on it. Perhaps some of the readers here are unaware that the INMARSAT F3 in question is a bent pipe repeater in both directions. It takes a C band uplink from the ground and turns it around to L band, and turns L band uplinks around to a C band downlink. It has 8 spot beams, and one regional beam. Channelization of the uplink and downlink bandwidth and an board switch matrix allows various allocations of frequencies and bandwidth to the 9 beams varying with load and demand. There is no on satellite signal demodulation/modulation or protocol processing for the classic AERO signals to/from the plane ... that is ALL done on ground at the GES (in Perth Australia AFAIK). This would make it possible for INMARSAT (and others in the region tasked with monitoring such things) to capture the actual repeated RF from the plane and digitize it - this happens in the ground equipment as part of the normal processing anyway - and dumping it to a disk array somewhere is certain to be going on, either both inside INMARSAT at the GES or at least at other (less public) sites such as Alice Springs. The C band downlinks are global beams BTW and can be received anywhere that sees the satellite. As such the quality of the recovered Doppler and other signal parameters is very much a function of the stability of the various LOs (and sample clocks) involved, which I believe can correctly be presumed to be really high grade both in space and certainly on the ground. AES (plane) timing and frequency may be less good, but it is more or less locked to the L band downlink timing and frequency signals as reference. The newer INMARSAT F4 birds do have DSP processing on the satellite, but apparently NOT used for demodulating and processing the various control channel signals on the satellite - but just for doing beam forming and power allocation for the 120 spot beams these birds support. This of course would impact delay through the satellite for precision timing and ranging. But so far there are no reports that the F4 POR satellite was involved. The high gain antennas on the AES (plane) are fairly directional and if they were in use there might not be a lot of signal seen on the POR bird. Not sure if those pings would have been sent via a low gain antenna on the AES, but I suspect normally not. -- Dave Emery N1PRE/AE, d...@dieconsulting.com DIE Consulting, Weston, Mass 02493 An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either. ___ 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.
Re: [time-nuts] Airraft Ping Timing
Certainly, if it's a bent-pipe repeater, that makes extracting the Dopplar a whole lot easier. Furthermore, since it's unlikely that the missing plane was the only signal, you can essentially do a differential Dopplar measurement against other sorces, stationary or moving in a know trajectory. -John == On Mon, Mar 24, 2014 at 06:15:57PM -0700, Chris Albertson wrote: Yes, word is that they were able to determine the Doppler shift in the plane's signal. I'm surprised this was even recorded but it must have been in the satellite's telemetry downlink. Projecting radial velocity and constraining it to be close to the earth's surface, I guess determines one path and the direction on it. Perhaps some of the readers here are unaware that the INMARSAT F3 in question is a bent pipe repeater in both directions. It takes a C band uplink from the ground and turns it around to L band, and turns L band uplinks around to a C band downlink. It has 8 spot beams, and one regional beam. Channelization of the uplink and downlink bandwidth and an board switch matrix allows various allocations of frequencies and bandwidth to the 9 beams varying with load and demand. There is no on satellite signal demodulation/modulation or protocol processing for the classic AERO signals to/from the plane ... that is ALL done on ground at the GES (in Perth Australia AFAIK). This would make it possible for INMARSAT (and others in the region tasked with monitoring such things) to capture the actual repeated RF from the plane and digitize it - this happens in the ground equipment as part of the normal processing anyway - and dumping it to a disk array somewhere is certain to be going on, either both inside INMARSAT at the GES or at least at other (less public) sites such as Alice Springs. The C band downlinks are global beams BTW and can be received anywhere that sees the satellite. As such the quality of the recovered Doppler and other signal parameters is very much a function of the stability of the various LOs (and sample clocks) involved, which I believe can correctly be presumed to be really high grade both in space and certainly on the ground. AES (plane) timing and frequency may be less good, but it is more or less locked to the L band downlink timing and frequency signals as reference. The newer INMARSAT F4 birds do have DSP processing on the satellite, but apparently NOT used for demodulating and processing the various control channel signals on the satellite - but just for doing beam forming and power allocation for the 120 spot beams these birds support. This of course would impact delay through the satellite for precision timing and ranging. But so far there are no reports that the F4 POR satellite was involved. The high gain antennas on the AES (plane) are fairly directional and if they were in use there might not be a lot of signal seen on the POR bird. Not sure if those pings would have been sent via a low gain antenna on the AES, but I suspect normally not. -- Dave Emery N1PRE/AE, d...@dieconsulting.com DIE Consulting, Weston, Mass 02493 An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either. ___ 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.
Re: [time-nuts] Hanging bridge question
Yes if you want to use it only in a GPSDO and it is being done but if you are a time nut you may want the 1 PPS.. Bert Kehren In a message dated 3/25/2014 6:33:12 P.M. Eastern Daylight Time, albertson.ch...@gmail.com writes: On Tue, Mar 25, 2014 at 5:44 AM, ewkeh...@aol.com wrote: The lowest cost solution is a DS chip in combination with a PIC. How ever The lowest cost solution is to do the correct entirely in software. After the measure the phase, simply add the correction. All you need to know is the phase. There is not point in correcting the pulse, you don't need a corrected pulse. What you want is a measurement of the phase. Chris Albertson Redondo Beach, California ___ 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.
Re: [time-nuts] NIST time services
On Tue, Mar 25, 2014 at 5:52 AM, Paul tic-...@bodosom.net wrote: On Mon, Mar 24, 2014 at 4:26 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message CABbxVHuQc0144==21mDa_R8ErKov= em+9rvrbpggexnzztj...@mail.gmail.com , Chris Albertson writes: Yes. NTP calls it root distance [...] And it is generally useless, because people don't calibrate it. How do you calibrate root distance assuming that it's one-half the roundtrip root delay plus the root dispersion plus minor error contributions not considered here? Peole here have very much mis-understood the term Root Distance. People don't calibrate it because It is NOT a user input. It is an internal variable that NTP uses. It is not something you can input.Perhaps people are confusing NTP's use of this term from the same term used in a different context? root distance is equal to the root dispersion plus half the root delay This is a DEFINTION. One does not calibrate a definition. These are measured values done in real-time. It has nothing to do with how one server connects to the others or how many source of time are used. It has noting to do wight eh number of network hops or if GPS or an uncalibrated source is used for time.All NTP cares about are the delay in round trip ping time and the variance in those times. I have seen NTP reject a local GPS receiver in favor on an Internet connected pool server because the very old handheld Garmin GPS had such poor timing. This is not uncommon with older nav receivers. Read how it is used here http://www.eecis.udel.edu/~mills/ntp/html/cluster.html Read another definition of root distance here: http://www.eecis.udel.edu/~mills/ntp/html/select.html -- Chris Albertson Redondo Beach, California ___ 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.
Re: [time-nuts] TSIP protocol for T-Bolt
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.
Re: [time-nuts] Hanging bridge question
Hi If you are building a GPSDO, then the 1 pps out of the GPSDO should be much better than the pps out of the GPS. Making that happen is part of the control optimization. Bob On Mar 25, 2014, at 7:46 PM, ewkeh...@aol.com wrote: Yes if you want to use it only in a GPSDO and it is being done but if you are a time nut you may want the 1 PPS.. Bert Kehren In a message dated 3/25/2014 6:33:12 P.M. Eastern Daylight Time, albertson.ch...@gmail.com writes: On Tue, Mar 25, 2014 at 5:44 AM, ewkeh...@aol.com wrote: The lowest cost solution is a DS chip in combination with a PIC. How ever The lowest cost solution is to do the correct entirely in software. After the measure the phase, simply add the correction. All you need to know is the phase. There is not point in correcting the pulse, you don't need a corrected pulse. What you want is a measurement of the phase. Chris Albertson Redondo Beach, California ___ 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. ___ 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.
Re: [time-nuts] TSIP protocol for T-Bolt
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.
Re: [time-nuts] TSIP protocol for T-Bolt
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 ___ 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.
Re: [time-nuts] Hanging bridge question
The lowest cost solution is to do the correct entirely in software. After the measure the phase, simply add the correction. All you need to know is the phase. There is not point in correcting the pulse, you don't need a corrected pulse. What you want is a measurement of the phase. Chris I'm baffled as to how one would do this in software without a ton of expensive hardware to give phase information. Could you provide in words a simple block diagram of where you would get phase information without a Ghz TIC to read? Thanks Jim ___ 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.
Re: [time-nuts] Hanging bridge question
Hi There have been multiple posts about analog TDC’s of various designs that get you into the sub 100 ps range without costing very much money. I believe the cheapest posted so far adds 50 cents to a basic PIC based design. Bob On Mar 25, 2014, at 7:38 PM, Jim Miller j...@jtmiller.com wrote: The lowest cost solution is to do the correct entirely in software. After the measure the phase, simply add the correction. All you need to know is the phase. There is not point in correcting the pulse, you don't need a corrected pulse. What you want is a measurement of the phase. Chris I'm baffled as to how one would do this in software without a ton of expensive hardware to give phase information. Could you provide in words a simple block diagram of where you would get phase information without a Ghz TIC to read? Thanks Jim ___ 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.
Re: [time-nuts] Airraft Ping Timing
One thing I don't fully understand are the spot beams. If this is a bent pipe, how do they control which beam serves the terminal? And if ground based command, would they not have a record of which spot beam that MH370 was utilizing, therefore know approximate location and direction ? -- Joe Leikhim Leikhim and Associates Communications Consultants Oviedo, Florida jleik...@leikhim.com 407-982-0446 WWW.LEIKHIM.COM ___ 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.
Re: [time-nuts] Airraft Ping Timing
Hi Joe: It's my understanding that the spot beams are only used for air phones where they need more gain and MH370 had no first class, i.e. no phones. Have Fun, Brooke Clarke http://www.PRC68.com http://www.end2partygovernment.com/2012Issues.html Joe Leikhim wrote: One thing I don't fully understand are the spot beams. If this is a bent pipe, how do they control which beam serves the terminal? And if ground based command, would they not have a record of which spot beam that MH370 was utilizing, therefore know approximate location and direction ? ___ 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.
Re: [time-nuts] Airraft Ping Timing
On Tue, Mar 25, 2014 at 6:22 PM, Joe Leikhim jleik...@leikhim.com wrote: One thing I don't fully understand are the spot beams. If this is a bent pipe, how do they control which beam serves the terminal? And if ground based command, would they not have a record of which spot beam that MH370 was utilizing, therefore know approximate location and direction ? The spot beams are only used for high speed data, like for example a phone call. The data rate for status reporting is very low, Only a few hundred baud if I remember right. I think they have to request a spot beam connection via the low speed link to get one. -- Chris Albertson Redondo Beach, California ___ 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.
Re: [time-nuts] NIST time services
[I apologize in advance] On Tue, Mar 25, 2014 at 7:47 PM, Chris Albertson albertson.ch...@gmail.comwrote: Peole here have very much mis-understood the term Root Distance. I don't think Poul-Henning Kamp should be accused of misunderstanding NTP. My question was answered (I wondered why I had a clock with rootdisp=0) so I'll move on now. ___ 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.
Re: [time-nuts] Hanging bridge question
Right now I'm planning to use a DS1123 driven by the PIC in my system to provide sawtooth correction. The phase measurement is strictly binary with a D FF. The PIC reads the value once a second and integrates with a bit of feedforward for stability. The numerical result will be fed to a DAC which controls the OCXO. The DS1123 is about $14, not unreasonable. The same PIC is used to setup the M12+T and read the status and sawtooth info, do the math for the PI filter, drive the D/A and communicate optionally with a PC to log D/A commands and relay any M12+T communication. It will also maintain a few simple indicator lights for status. Jim ___ 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.
Re: [time-nuts] Hanging bridge question
Bob I'm not sure who you're responding to but I have a couple of questions: TDC = Time Delay Correlator? Could you point me to one of these 50 cent threads? I've read a ton of this list from 2007 forward but must have missed that. Thanks jim ab3cv (much to learn) Hi There have been multiple posts about analog TDC's of various designs that get you into the sub 100 ps range without costing very much money. I believe the cheapest posted so far adds 50 cents to a basic PIC based design. Bob ___ 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.
Re: [time-nuts] Hanging bridge question
If you are building a GPSDO, then the 1 pps out of the GPSDO should be much better than the pps out of the GPS. Bob, That's only true for time scales less than the cross-over point. Beyond that, the 1 PPS from the GPS receiver is actually better (more accurate). That's why the LO is disciplined by GPS, not the other way around. For example, when monitoring the performance of a cesium clock at 1 Hz, there is no need to use a GPSDO -- a sawtooth-corrected 1PPS from a GPS timing receiver is the more accurate way to measure. A GPSDO can only make the quality of the 1PPS worse for tau beyond the crossover point. /tvb ___ 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] RC TIC linearity correction?
I hadn't given any thought to correcting the linearity of the TIC I built, but my PLL plots tell me I should do it now. Explanation: when I arrange things so that the phase point is near the top of my TIC's range, it requires a smaller movement than when the phase point is in the middle: Presumably the difference is even greater near the bottom. Can anyone give me a reference of some type for doing this? I looked around a few weeks ago, but my google-foo wasn't up to the challenge. The schematic is essentially this, except that C1 doesn't really exist. It was a place-holder on my board in case the caps in the PIC weren't up to it by themselves - which they were. And, not that it matters, but the level shifter (Q1,Q2) was also not needed. http://www.evoria.net/AE6RV/TIC/TIC2.bmp Bob - AE6RV ___ 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.
Re: [time-nuts] NIST time services
I think I figured it out. rootdisp=0 refers to Root Dispersion which is quite different from Root Distance. They do look a little alike. One is the distance from the local clock to the root of the NTP tree and the other is something different, internal to NTP that is not exposed to a user. On Tue, Mar 25, 2014 at 6:12 PM, Paul tic-...@bodosom.net wrote: [I apologize in advance] On Tue, Mar 25, 2014 at 7:47 PM, Chris Albertson albertson.ch...@gmail.comwrote: Peole here have very much mis-understood the term Root Distance. I don't think Poul-Henning Kamp should be accused of misunderstanding NTP. My question was answered (I wondered why I had a clock with rootdisp=0) so I'll move on now. ___ 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. -- Chris Albertson Redondo Beach, California ___ 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] Isotemp OCXO107-10 Internal Photos
FYI, I've posted a few pictures of the inside of this oscillator. Noteworthy is the tiny Dewar flask. http://s701.photobucket.com/user/edpalmer42/library/Isotemp%20OCXO107-10%20Oscillator If you click on the magnifying glass at the bottom of the picture and then do it again, you'll get the full size picture. After about a week of operation, aging was 5e-10/day (spec is 2e-10/day). An impressive result for such a short run time. Adev with drift removed at Tau 100 sec. is stuck at ~1e-11 as measured against a Tbolt. I can't find a spec for it. The Tbolt and measurement system are capable of much better performance than that so the Isotemp appears to be the limiting factor. Maybe longer run time would bring it down. Ed ___ 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.
Re: [time-nuts] Hanging bridge question
The lowest cost solution is to do the correct entirely in software. After the measure the phase, simply add the correction. All you need to know is the phase. There is not point in correcting the pulse, you don't need a corrected pulse. What you want is a measurement of the phase. This depends on the goal. There are two types of GPS timing products. Those which output time frequency and those which output time only. For time and frequency you design a GPSDO, in which case you have a choice of h/w or s/w sawtooth correction. Most people choose s/w since, as you correctly assume, a GPSDO already includes some sort of phase or time interval measurement circuit along with a microprocessor to do the math. But for a timing only GPS product (e.g., the base models from www.cnssys.com) the goal is just a precise 1PPS output. This class of product tends to use h/w sawtooth correction, since by design there is no TIC or OCXO in the box. There's also a third way to do it -- sawtooth correction provided by PC software tools like Tac32Plus or DSPmon (similar to TBoltmon). In this case the PC reads correction messages from the receiver and measurements from an external TIC and applies the sawtooth correction before writing the composite result to a log file. DSPmon has support for the hp 5334 and 53132. I hope this helps more than it confuses. /tvb ___ 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.
Re: [time-nuts] RC TIC linearity correction?
Bob wrote: I hadn't given any thought to correcting the linearity of the TIC I built, but my PLL plots tell me I should do it now. You are using a resistor to charge the integrating capacitance, so it charges with the classic exponential curve and you get a nonlinear time-to-voltage conversion. You need to charge the integrating capacitance with a constant current if you want a linear time-to-voltage function. The current source will probably need to be connected to a supply that is higher than 5v, because it needs some headroom. There may be secondary errors, as well, due to the leakage of the tri-state buffers in their hi-Z state and/or nonlinearity in the ADC's internal capacitors. Often you can improve things by using sufficient external capacitance to swamp the ADC's internal capacitance and increasing the charging current. Best regards, Charles ___ 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] NIST / NIST+ATIS Seminars and Workshops in June - Anyone attending?
Hi, I'm new to the list. I'm curious if anyone will be attending the NIST Time and Frequency seminar in Boulder in June, and / or the following week's NIST-ATIS workshop on Telco Sync in San Jose. http://www.nist.gov/pml/div688/seminars.cfm . Thanks... --Brett ___ 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.
