Empathy List Archives

D

dan@irtelemetrics.com

Sun, Dec 14, 2014 4:08 AM

Hi,

What have you observed, out of the GPS, with the temperature variations?

The test was simple. A couple of seconds of warm air from a hair dryer
on low setting (the air coming out is 15C above ambient, so not very
much heat at all) through a paper tube blowing on the GPS. That little
change causes the phase to shift about 200nS in just a few seconds.
That is, the GPS PPS phase compared to the OCXO phase shifts 200nS, and
it happens over only a few seconds, literally almost instantly. It's an
enormous change!

I have checked that it's not electrical noise from the hair dryer, and
I have repeated the test multiple times.

Also, when you say "the GPS temperature," what, exactly, are you
measuring/reporting? Is the GPS's own time base varying with
temperature?** And how much thermal isolation is there between the
various subsystems (GPS, PLL circuitry, OCXO, etc.) in your test setup?

** I'm assuming that the GPS does not use the OCXO output for its
own timing. That is such a good idea, I can't understand why more
designers don't do it.

Currently to measure the GPS temperature I have a K type TC taped to
the top of the GPS RF shield. Since the temperature sensitivity was
noticed, the GPS has been sitting under a wool sock with a 1Lb roll of
solder sitting on that (That does help a bunch). Since the TC and GPS
are under the wool sock the TC gets pretty good coupling to the GPS
module itself. The GPS is mounted to a pine board right now, so has
insulation underneath. The rest of the stuff (OXCO, GPSDO board, linear
regulators/heatsink etc.) is sitting out in the open on the bench.
Exposed to every possible air current, and even the front door being
left open by my kids as they run in and out.

The small temperature cycles on the GPS are about 5 to 7 minutes long.
The HVAC cycles are about 45 minutes apart. So I believe these two are
not related. I can clearly see the HVAC cycles and the 'ramp'
waveform. As for what's causing the ramp in temperature on the GPS
module, I have no idea. Any guess as to what is going on would be just
that. It was just an interesting thing to note.

The setup is a prototype and pretty ugly, but things are spaced out
enough to be able to blow hot air on them with out hitting the other
components. I can also cover and uncover individual components with a
wool sock if need be. I've tried blowing the hot air on every other
part of the system, and the GPS is the one that responds now.
Previously the GPSDO DAC itself caused a similar response, but that has
since been resolved.

I'm well aware of the difference between cause/effect and
correlation. (Everyone who ever eats Broccoli will die, you know. ;) )
It's the reason I've been been blowing hot air on stuff, to be sure
there is a cause and effect relationship...

It adds to the cost. If the end-user only needs XO or TCXO quality

timing, there's no incentive to increase the size and cost and power of
the GPSDO product with a OCXO.

But, you're right, it is a really good idea, and of course we all

know the Trimble Thunderbolt does it this way. One reason why it's
always the #1 favorite GPSDO among time nuts.

Note that most high-end GNSS timing receivers go one better and

simply have an external input for the clock. That way you feed your own
lab clock into the receiver. If you have Rb/Cs/maser you would use that
as the reference. It's what the national timing labs do, along with
dual-frequency and post-processing and all the other tricks of the
trade.

I think it would be agreat idea also. It's a wonder that more of the
'timing' receivers don't have that external clock option! I wonder what
these Ublox parts use for a clock? Is it something frequency
compatible with a 10Mhz source??? (Hmm, can we pry one apart to figure
it out! ;) )
As for the GNSS units, are these receivers something that an average
person can afford to get their hands on, or do you have to sell your
house to buy one? :)

Thanks,
Dan

Hi, > What have you observed, out of the GPS, with the temperature variations? The test was simple. A couple of seconds of warm air from a hair dryer on low setting (the air coming out is 15C above ambient, so not very much heat at all) through a paper tube blowing on the GPS. That little change causes the phase to shift about 200nS in just a few seconds. That is, the GPS PPS phase compared to the OCXO phase shifts 200nS, and it happens over only a few seconds, literally almost instantly. It's an enormous change! I have checked that it's not electrical noise from the hair dryer, and I have repeated the test multiple times. > Also, when you say "the GPS temperature," what, exactly, are you > measuring/reporting? Is the GPS's own time base varying with > temperature?** And how much thermal isolation is there between the > various subsystems (GPS, PLL circuitry, OCXO, etc.) in your test setup? > > ** I'm assuming that the GPS does not use the OCXO output for its > own timing. That is such a good idea, I can't understand why more > designers don't do it. Currently to measure the GPS temperature I have a K type TC taped to the top of the GPS RF shield. Since the temperature sensitivity was noticed, the GPS has been sitting under a wool sock with a 1Lb roll of solder sitting on that (That does help a bunch). Since the TC and GPS are under the wool sock the TC gets pretty good coupling to the GPS module itself. The GPS is mounted to a pine board right now, so has insulation underneath. The rest of the stuff (OXCO, GPSDO board, linear regulators/heatsink etc.) is sitting out in the open on the bench. Exposed to every possible air current, and even the front door being left open by my kids as they run in and out. The small temperature cycles on the GPS are about 5 to 7 minutes long. The HVAC cycles are about 45 minutes apart. So I believe these two are not related. I can clearly see the HVAC cycles and the 'ramp' waveform. As for what's causing the ramp in temperature on the GPS module, I have no idea. Any guess as to what is going on would be just that. It was just an interesting thing to note. The setup is a prototype and pretty ugly, but things are spaced out enough to be able to blow hot air on them with out hitting the other components. I can also cover and uncover individual components with a wool sock if need be. I've tried blowing the hot air on every other part of the system, and the GPS is the one that responds now. Previously the GPSDO DAC itself caused a similar response, but that has since been resolved. I'm well aware of the difference between cause/effect and correlation. (Everyone who ever eats Broccoli will die, you know. ;) ) It's the reason I've been been blowing hot air on stuff, to be sure there is a cause and effect relationship... > It adds to the cost. If the end-user only needs XO or TCXO quality timing, there's no incentive to increase the size and cost and power of the GPSDO product with a OCXO. > > But, you're right, it *is* a really good idea, and of course we all know the Trimble Thunderbolt does it this way. One reason why it's always the #1 favorite GPSDO among time nuts. > > Note that most high-end GNSS timing receivers go one better and simply have an external input for the clock. That way you feed your own lab clock into the receiver. If you have Rb/Cs/maser you would use that as the reference. It's what the national timing labs do, along with dual-frequency and post-processing and all the other tricks of the trade. I think it would be agreat idea also. It's a wonder that more of the 'timing' receivers don't have that external clock option! I wonder what these Ublox parts use for a clock? Is it something frequency compatible with a 10Mhz source??? (Hmm, can we pry one apart to figure it out! ;) ) As for the GNSS units, are these receivers something that an average person can afford to get their hands on, or do you have to sell your house to buy one? :) Thanks, Dan

CS

Charles Steinmetz

Sun, Dec 14, 2014 6:07 AM

Dan wrote:

The test was simple. A couple of seconds of warm air from a hair
dryer on low setting (the air coming out is 15C above ambient, so
not very much heat at all) through a paper tube blowing on the GPS.
That little change causes the phase to shift about 200nS in just a
few seconds. That is, the GPS PPS phase compared to the OCXO phase
shifts 200nS, and it happens over only a few seconds, literally
almost instantly. It's an enormous change!

LOL. A couple of seconds of warm air at 15C above ambient is a HUGE
temperature transient for any sensitive electronics, especially
anything with an oscillator. I would venture a guess that the lion's
share of the drift you see is the GPS time base shooting
off-frequency, but there are probably other effects, too (voltage
regulators, to name just one).

To me, a "little change" in this context might be blowing one warm
breath toward the GPS unit from 18" away and seeing what happens over
the next minute or two.

But the GPS temperature sensitivity shouldn't be a big factor in
actual use. The GPS should be thermally isolated from anything that
changes temperature rapidly, and enclosed such that external
temperature changes are integrated over at least tens of
minutes. Then, the inside of the enclosure will reach its own
thermal equilibrium and any external changes will be slowed enough to
be tracked out by the GPS discipline. My recommendation would be to
put it in a cast aluminum box (search the archives for "cast aluminum
box"), but there are others who think you need to build a two foot
cube out of cinderblocks and fire brick against a wall in the deepest
external corner of your basement.

OR, if my suspicion is correct that the temperature sensitivity is
mostly the GPS time base, figure out a way to kludge the GPS to
accept the disciplined OCXO as its time base.

Best regards,

Charles

Dan wrote: >The test was simple. A couple of seconds of warm air from a hair >dryer on low setting (the air coming out is 15C above ambient, so >not very much heat at all) through a paper tube blowing on the GPS. >That little change causes the phase to shift about 200nS in just a >few seconds. That is, the GPS PPS phase compared to the OCXO phase >shifts 200nS, and it happens over only a few seconds, literally >almost instantly. It's an enormous change! LOL. A couple of seconds of warm air at 15C above ambient is a HUGE temperature transient for any sensitive electronics, especially anything with an oscillator. I would venture a guess that the lion's share of the drift you see is the GPS time base shooting off-frequency, but there are probably other effects, too (voltage regulators, to name just one). To me, a "little change" in this context might be blowing one warm breath toward the GPS unit from 18" away and seeing what happens over the next minute or two. But the GPS temperature sensitivity shouldn't be a big factor in actual use. The GPS should be thermally isolated from anything that changes temperature rapidly, and enclosed such that external temperature changes are integrated over at least tens of minutes. Then, the inside of the enclosure will reach its own thermal equilibrium and any external changes will be slowed enough to be tracked out by the GPS discipline. My recommendation would be to put it in a cast aluminum box (search the archives for "cast aluminum box"), but there are others who think you need to build a two foot cube out of cinderblocks and fire brick against a wall in the deepest external corner of your basement. OR, if my suspicion is correct that the temperature sensitivity is mostly the GPS time base, figure out a way to kludge the GPS to accept the disciplined OCXO as its time base. Best regards, Charles

SM

Simon Marsh

Sun, Dec 14, 2014 9:26 AM

On 14/12/2014 04:08, dan@irtelemetrics.com wrote:

Note that most high-end GNSS timing receivers go one better and

simply have an external input for the clock. That way you feed your
own lab clock into the receiver. If you have Rb/Cs/maser you would use
that as the reference. It's what the national timing labs do, along
with dual-frequency and post-processing and all the other tricks of
the trade.

I think it would be agreat idea also. It's a wonder that more of the
'timing' receivers don't have that external clock option! I wonder
what these Ublox parts use for a clock? Is it something frequency
compatible with a 10Mhz source??? (Hmm, can we pry one apart to figure
it out! ;) )

Ublox modules have a 48mhz internal clock.

There is the following interesting paragraph in at least the 7 & 8 data
sheets:

1.8.2 Aiding
The EXTINT pin can be used to supply time or frequency aiding data to
the receiver.

For time aiding, hardware time synchronization can be achieved by
connecting an accurate time pulse to the EXTINT pin.

Frequency aiding can be implemented by connecting a periodic rectangular
signal with a frequency up to 500 kHz and arbitrary duty cycle (low/high
phase duration must not be shorter than 50 ns) to the EXTINT pin.
Provide the applied frequency value to the receiver using UBX messages.

I haven't been able to find any information about what this actually
does though. Anyone know ?

Cheers

Simon

On 14/12/2014 04:08, dan@irtelemetrics.com wrote: > > Note that most high-end GNSS timing receivers go one better and > simply have an external input for the clock. That way you feed your > own lab clock into the receiver. If you have Rb/Cs/maser you would use > that as the reference. It's what the national timing labs do, along > with dual-frequency and post-processing and all the other tricks of > the trade. > I think it would be agreat idea also. It's a wonder that more of the > 'timing' receivers don't have that external clock option! I wonder > what these Ublox parts use for a clock? Is it something frequency > compatible with a 10Mhz source??? (Hmm, can we pry one apart to figure > it out! ;) ) Ublox modules have a 48mhz internal clock. There is the following interesting paragraph in at least the 7 & 8 data sheets: --- 1.8.2 Aiding The EXTINT pin can be used to supply time or frequency aiding data to the receiver. For time aiding, hardware time synchronization can be achieved by connecting an accurate time pulse to the EXTINT pin. Frequency aiding can be implemented by connecting a periodic rectangular signal with a frequency up to 500 kHz and arbitrary duty cycle (low/high phase duration must not be shorter than 50 ns) to the EXTINT pin. Provide the applied frequency value to the receiver using UBX messages. --- I haven't been able to find any information about what this actually does though. Anyone know ? Cheers Simon

BC

Bob Camp

Sun, Dec 14, 2014 2:43 PM

Hi

There is also a little note down in the (many) notes section:

Not all features are available with all firmware versions.

It applies to all of the external inputs (like USB and SPI).

Since the oscillator in the uBlox is a TCXO and not a VCTCXO, the aiding feature would not help in the case of biasing the unit with a hot air gun. It would still loose lock as the TCXO went nuts.

The ideal outcome would be a system that reported against the external input rather than the internal TCXO. Since they digitize the external pin with the TCXO, the outcome is pretty coarse (10’s of ns). That’s not going to help us much.

Bob

On Dec 14, 2014, at 4:26 AM, Simon Marsh subscriptions@burble.com wrote:

On 14/12/2014 04:08, dan@irtelemetrics.com wrote:

Note that most high-end GNSS timing receivers go one better and simply have an external input for the clock. That way you feed your own lab clock into the receiver. If you have Rb/Cs/maser you would use that as the reference. It's what the national timing labs do, along with dual-frequency and post-processing and all the other tricks of the trade.

I think it would be agreat idea also. It's a wonder that more of the 'timing' receivers don't have that external clock option! I wonder what these Ublox parts use for a clock? Is it something frequency compatible with a 10Mhz source??? (Hmm, can we pry one apart to figure it out! ;) )

Ublox modules have a 48mhz internal clock.

There is the following interesting paragraph in at least the 7 & 8 data sheets:

1.8.2 Aiding
The EXTINT pin can be used to supply time or frequency aiding data to the receiver.

For time aiding, hardware time synchronization can be achieved by connecting an accurate time pulse to the EXTINT pin.

Frequency aiding can be implemented by connecting a periodic rectangular signal with a frequency up to 500 kHz and arbitrary duty cycle (low/high phase duration must not be shorter than 50 ns) to the EXTINT pin. Provide the applied frequency value to the receiver using UBX messages.

I haven't been able to find any information about what this actually does though. Anyone know ?

Cheers

Simon

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.

Hi There is also a little note down in the (many) notes section: Not all features are available with all firmware versions. It applies to all of the external inputs (like USB and SPI). Since the oscillator in the uBlox is a TCXO and not a VCTCXO, the aiding feature would not help in the case of biasing the unit with a hot air gun. It would still loose lock as the TCXO went nuts. The ideal outcome would be a system that reported against the external input rather than the internal TCXO. Since they digitize the external pin with the TCXO, the outcome is pretty coarse (10’s of ns). That’s not going to help us much. Bob > On Dec 14, 2014, at 4:26 AM, Simon Marsh <subscriptions@burble.com> wrote: > > > On 14/12/2014 04:08, dan@irtelemetrics.com wrote: >> > Note that most high-end GNSS timing receivers go one better and simply have an external input for the clock. That way you feed your own lab clock into the receiver. If you have Rb/Cs/maser you would use that as the reference. It's what the national timing labs do, along with dual-frequency and post-processing and all the other tricks of the trade. > >> I think it would be agreat idea also. It's a wonder that more of the 'timing' receivers don't have that external clock option! I wonder what these Ublox parts use for a clock? Is it something frequency compatible with a 10Mhz source??? (Hmm, can we pry one apart to figure it out! ;) ) > > Ublox modules have a 48mhz internal clock. > > There is the following interesting paragraph in at least the 7 & 8 data sheets: > > --- > > 1.8.2 Aiding > The EXTINT pin can be used to supply time or frequency aiding data to the receiver. > > For time aiding, hardware time synchronization can be achieved by connecting an accurate time pulse to the EXTINT pin. > > Frequency aiding can be implemented by connecting a periodic rectangular signal with a frequency up to 500 kHz and arbitrary duty cycle (low/high phase duration must not be shorter than 50 ns) to the EXTINT pin. Provide the applied frequency value to the receiver using UBX messages. > > --- > > I haven't been able to find any information about what this actually does though. Anyone know ? > > Cheers > > > Simon > _______________________________________________ > 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.

NS

Neil Schroeder

Sun, Dec 14, 2014 2:46 PM

The oscillator in he m8f is a vctcxo and can be steered with feedback or
controlled by the host.

Also the m8f can send compliant DAC words to a TLV8515 and and MCP part via
i2c for external
VCXOs. It accepts their return signal on what would normally be its
feedback in ports.

On Sunday, December 14, 2014, Bob Camp kb8tq@n1k.org wrote:

Hi

There is also a little note down in the (many) notes section:

Not all features are available with all firmware versions.

It applies to all of the external inputs (like USB and SPI).

Since the oscillator in the uBlox is a TCXO and not a VCTCXO, the aiding
feature would not help in the case of biasing the unit with a hot air gun.
It would still loose lock as the TCXO went nuts.

The ideal outcome would be a system that reported against the external
input rather than the internal TCXO. Since they digitize the external pin
with the TCXO, the outcome is pretty coarse (10’s of ns). That’s not going
to help us much.

Bob

On Dec 14, 2014, at 4:26 AM, Simon Marsh <subscriptions@burble.com

javascript:;> wrote:

On 14/12/2014 04:08, dan@irtelemetrics.com javascript:; wrote:

Note that most high-end GNSS timing receivers go one better and

simply have an external input for the clock. That way you feed your own lab
clock into the receiver. If you have Rb/Cs/maser you would use that as the
reference. It's what the national timing labs do, along with dual-frequency
and post-processing and all the other tricks of the trade.

I think it would be agreat idea also. It's a wonder that more of the

'timing' receivers don't have that external clock option! I wonder what
these Ublox parts use for a clock? Is it something frequency compatible
with a 10Mhz source??? (Hmm, can we pry one apart to figure it out! ;) )

Ublox modules have a 48mhz internal clock.

There is the following interesting paragraph in at least the 7 & 8 data

sheets:

1.8.2 Aiding
The EXTINT pin can be used to supply time or frequency aiding data to

the receiver.

For time aiding, hardware time synchronization can be achieved by

connecting an accurate time pulse to the EXTINT pin.

Frequency aiding can be implemented by connecting a periodic rectangular

signal with a frequency up to 500 kHz and arbitrary duty cycle (low/high
phase duration must not be shorter than 50 ns) to the EXTINT pin. Provide
the applied frequency value to the receiver using UBX messages.

I haven't been able to find any information about what this actually

does though. Anyone know ?

Cheers

Simon

time-nuts mailing list -- time-nuts@febo.com javascript:;
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 javascript:;
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

The oscillator in he m8f is a vctcxo and can be steered with feedback or controlled by the host. Also the m8f can send compliant DAC words to a TLV8515 and and MCP part via i2c for external VCXOs. It accepts their return signal on what would normally be its feedback in ports. On Sunday, December 14, 2014, Bob Camp <kb8tq@n1k.org> wrote: > Hi > > There is also a little note down in the (many) notes section: > > Not all features are available with all firmware versions. > > It applies to all of the external inputs (like USB and SPI). > > Since the oscillator in the uBlox is a TCXO and not a VCTCXO, the aiding > feature would not help in the case of biasing the unit with a hot air gun. > It would still loose lock as the TCXO went nuts. > > The ideal outcome would be a system that reported against the external > input rather than the internal TCXO. Since they digitize the external pin > with the TCXO, the outcome is pretty coarse (10’s of ns). That’s not going > to help us much. > > Bob > > > On Dec 14, 2014, at 4:26 AM, Simon Marsh <subscriptions@burble.com > <javascript:;>> wrote: > > > > > > On 14/12/2014 04:08, dan@irtelemetrics.com <javascript:;> wrote: > >> > Note that most high-end GNSS timing receivers go one better and > simply have an external input for the clock. That way you feed your own lab > clock into the receiver. If you have Rb/Cs/maser you would use that as the > reference. It's what the national timing labs do, along with dual-frequency > and post-processing and all the other tricks of the trade. > > > >> I think it would be agreat idea also. It's a wonder that more of the > 'timing' receivers don't have that external clock option! I wonder what > these Ublox parts use for a clock? Is it something frequency compatible > with a 10Mhz source??? (Hmm, can we pry one apart to figure it out! ;) ) > > > > Ublox modules have a 48mhz internal clock. > > > > There is the following interesting paragraph in at least the 7 & 8 data > sheets: > > > > --- > > > > 1.8.2 Aiding > > The EXTINT pin can be used to supply time or frequency aiding data to > the receiver. > > > > For time aiding, hardware time synchronization can be achieved by > connecting an accurate time pulse to the EXTINT pin. > > > > Frequency aiding can be implemented by connecting a periodic rectangular > signal with a frequency up to 500 kHz and arbitrary duty cycle (low/high > phase duration must not be shorter than 50 ns) to the EXTINT pin. Provide > the applied frequency value to the receiver using UBX messages. > > > > --- > > > > I haven't been able to find any information about what this actually > does though. Anyone know ? > > > > Cheers > > > > > > Simon > > _______________________________________________ > > time-nuts mailing list -- time-nuts@febo.com <javascript:;> > > 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 <javascript:;> > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. >

BC

Bob Camp

Sun, Dec 14, 2014 3:10 PM

On Dec 14, 2014, at 9:46 AM, Neil Schroeder gigneil@gmail.com wrote:

The oscillator in he m8f is a vctcxo and can be steered with feedback or
controlled by the host.

Also the m8f can send compliant DAC words to a TLV8515 and and MCP part via
i2c for external
VCXOs. It accepts their return signal on what would normally be its
feedback in ports.

The oscillator in the LEA-6T is not a VCTCXO and it’s got the same notes on it.

Bob

On Sunday, December 14, 2014, Bob Camp kb8tq@n1k.org wrote:

Hi

There is also a little note down in the (many) notes section:

Not all features are available with all firmware versions.

It applies to all of the external inputs (like USB and SPI).

Since the oscillator in the uBlox is a TCXO and not a VCTCXO, the aiding
feature would not help in the case of biasing the unit with a hot air gun.
It would still loose lock as the TCXO went nuts.

The ideal outcome would be a system that reported against the external
input rather than the internal TCXO. Since they digitize the external pin
with the TCXO, the outcome is pretty coarse (10’s of ns). That’s not going
to help us much.

Bob

On Dec 14, 2014, at 4:26 AM, Simon Marsh <subscriptions@burble.com

javascript:;> wrote:

On 14/12/2014 04:08, dan@irtelemetrics.com javascript:; wrote:

Note that most high-end GNSS timing receivers go one better and

simply have an external input for the clock. That way you feed your own lab
clock into the receiver. If you have Rb/Cs/maser you would use that as the
reference. It's what the national timing labs do, along with dual-frequency
and post-processing and all the other tricks of the trade.

I think it would be agreat idea also. It's a wonder that more of the

'timing' receivers don't have that external clock option! I wonder what
these Ublox parts use for a clock? Is it something frequency compatible
with a 10Mhz source??? (Hmm, can we pry one apart to figure it out! ;) )

Ublox modules have a 48mhz internal clock.

There is the following interesting paragraph in at least the 7 & 8 data

sheets:

1.8.2 Aiding
The EXTINT pin can be used to supply time or frequency aiding data to

the receiver.

For time aiding, hardware time synchronization can be achieved by

connecting an accurate time pulse to the EXTINT pin.

Frequency aiding can be implemented by connecting a periodic rectangular

signal with a frequency up to 500 kHz and arbitrary duty cycle (low/high
phase duration must not be shorter than 50 ns) to the EXTINT pin. Provide
the applied frequency value to the receiver using UBX messages.

I haven't been able to find any information about what this actually

does though. Anyone know ?

Cheers

Simon

time-nuts mailing list -- time-nuts@febo.com javascript:;
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 javascript:;
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.

> On Dec 14, 2014, at 9:46 AM, Neil Schroeder <gigneil@gmail.com> wrote: > > The oscillator in he m8f is a vctcxo and can be steered with feedback or > controlled by the host. > > Also the m8f can send compliant DAC words to a TLV8515 and and MCP part via > i2c for external > VCXOs. It accepts their return signal on what would normally be its > feedback in ports. The oscillator in the LEA-6T is not a VCTCXO and it’s got the same notes on it. Bob > > On Sunday, December 14, 2014, Bob Camp <kb8tq@n1k.org> wrote: > >> Hi >> >> There is also a little note down in the (many) notes section: >> >> Not all features are available with all firmware versions. >> >> It applies to all of the external inputs (like USB and SPI). >> >> Since the oscillator in the uBlox is a TCXO and not a VCTCXO, the aiding >> feature would not help in the case of biasing the unit with a hot air gun. >> It would still loose lock as the TCXO went nuts. >> >> The ideal outcome would be a system that reported against the external >> input rather than the internal TCXO. Since they digitize the external pin >> with the TCXO, the outcome is pretty coarse (10’s of ns). That’s not going >> to help us much. >> >> Bob >> >>> On Dec 14, 2014, at 4:26 AM, Simon Marsh <subscriptions@burble.com >> <javascript:;>> wrote: >>> >>> >>> On 14/12/2014 04:08, dan@irtelemetrics.com <javascript:;> wrote: >>>>> Note that most high-end GNSS timing receivers go one better and >> simply have an external input for the clock. That way you feed your own lab >> clock into the receiver. If you have Rb/Cs/maser you would use that as the >> reference. It's what the national timing labs do, along with dual-frequency >> and post-processing and all the other tricks of the trade. >>> >>>> I think it would be agreat idea also. It's a wonder that more of the >> 'timing' receivers don't have that external clock option! I wonder what >> these Ublox parts use for a clock? Is it something frequency compatible >> with a 10Mhz source??? (Hmm, can we pry one apart to figure it out! ;) ) >>> >>> Ublox modules have a 48mhz internal clock. >>> >>> There is the following interesting paragraph in at least the 7 & 8 data >> sheets: >>> >>> --- >>> >>> 1.8.2 Aiding >>> The EXTINT pin can be used to supply time or frequency aiding data to >> the receiver. >>> >>> For time aiding, hardware time synchronization can be achieved by >> connecting an accurate time pulse to the EXTINT pin. >>> >>> Frequency aiding can be implemented by connecting a periodic rectangular >> signal with a frequency up to 500 kHz and arbitrary duty cycle (low/high >> phase duration must not be shorter than 50 ns) to the EXTINT pin. Provide >> the applied frequency value to the receiver using UBX messages. >>> >>> --- >>> >>> I haven't been able to find any information about what this actually >> does though. Anyone know ? >>> >>> Cheers >>> >>> >>> Simon >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts@febo.com <javascript:;> >>> 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 <javascript:;> >> 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@lists.febo.com

Re: [time-nuts] Linear voltage regulator hints...