Discussion:
Upgrading TS2100 from TCXO to OCXO
(too old to reply)
Robert Watzlavick
2011-03-25 04:38:26 UTC
Permalink
I've been able to successfully upgrade my Datum TS2100 to an OCXO from
the stock TCXO. I didn't see it in the archives so I thought I'd post
my findings. I noticed that the same firmware was used regardless of
oscillator configuration so there must either be jumpers or a hidden set
of commands. The newer versions of the ET6000 have jumpers to select
the oscillator but I couldn't find anything similar on the TS2100.
However, in the back of the manual, 8500-0033 Rev K, Appendix I
describes how to reconfigure the unit to output GPS instead of UTC for
NTP. I'm not interested in that but there are some hints about a hidden
menu structure (root eng ee) which allows you to change EEPROM
settings. Here's the hidden menu items:

root eng:
start net interface
timing tools /
serial tools /
eeprom tools /
spi tools /
flash tools /
display tools /
memory tools /
intrinsic help

Going further into one of them, root eng eeprom:
ethernet address
board serial number
gain default
filter constant
low filter constant
precision
set eeprom
get eeprom
read serial eeprom
write serial eeprom
tx 16 bits to eeprom
location for image
info value
eeprom_select
intrinsic help

So that's where the default gain and filter constants are set. You have
to jumper across J4 on the PC board to allow EEPROM writes or you get an
error. Not sure what the "precision" setting is for (it's currently -19).

I don't have the proper OCXO (yet) but I do have an MV89A OCXO that I
was able to wire into the circuit temporarily. There is 12V on the
board and the 0.5-4.5V EFC range works well with the MV89A. I used a
gain of +20 and a filter setting of 0.9994965 based on Jason Rabel's
post from 9/26/2010 (note the sign change on the gain). The EFC
algorithm had a pretty good overshoot during the first adjustment cycle
and took over an hour to completely settle in but eventually the front
panel Locked LED turned on. I couldn't find a way to change the
starting value for EFC (d/a) value.

I *think* an Abracon AOCJY1A-10.000MHz-E-SW part will be pin compatible
on the board. Unfortunately nobody has that one in stock and it's a 10
week lead time so I may end up installing one off-board. The MV89A is
too tall to fit with the lid on so it's not a long term option. I
traced out the two SMA pads on the board and they are for the EFC out
and RF in so I could always run them to the back of the unit and put the
OCXO outside the unit.

-Bob
K5RLW
Hal Murray
2011-03-25 07:11:34 UTC
Permalink
Post by Robert Watzlavick
Not sure what the "precision" setting is for (it's currently -19).
That's probably for NTP. Roughly, it's how many useful bits of data you get
when you read the clock. I can probably find a description if anybody is
curious.

-19 is 2 microseconds which is a reasonable ballpark for an embedded system.
--
These are my opinions, not necessarily my employer's. I hate spam.
Robert Watzlavick
2011-03-26 04:02:13 UTC
Permalink
Ok, thanks. I was so focused on the IRIG and 10 MHz parts I didn't
think about the NTP function (which is what the unit is for after all).

BTW - I had some misinformation in my original post. The Abracon
AOCJY1A is probably pin compatible with the TS2100 but it's not voltage
compatible. The OCXO supply voltage on PC board pads is 12 not 5
volts. So unless I can get the same MTI 240 OCXO, then I'm looking at
just putting one in the case somewhere and running wires to it. I'd
prefer not to cut traces. Anybody know of an inexpensive OCXO that
meets the following criteria?

10 MHz sine output
12V or 5V supply voltage (either will work since it will be installed
off board)
5V EFC (TS2100 DAC is 0.5-4.5V)
Small enough to fit in a 1U rack enclosure (the Morion MV89A is too tall)

I'm not striving for perfection, just some that is significantly better
than the stock TCXO.

-Bob
Post by Hal Murray
Post by Robert Watzlavick
Not sure what the "precision" setting is for (it's currently -19).
That's probably for NTP. Roughly, it's how many useful bits of data you get
when you read the clock. I can probably find a description if anybody is
curious.
-19 is 2 microseconds which is a reasonable ballpark for an embedded system.
Greg Broburg
2011-03-26 05:14:03 UTC
Permalink
I have MTI 240 OCXOs

Greg
Post by Robert Watzlavick
Ok, thanks. I was so focused on the IRIG and 10 MHz parts I didn't
think about the NTP function (which is what the unit is for after all).
BTW - I had some misinformation in my original post. The Abracon
AOCJY1A is probably pin compatible with the TS2100 but it's not voltage
compatible. The OCXO supply voltage on PC board pads is 12 not 5
volts. So unless I can get the same MTI 240 OCXO, then I'm looking at
just putting one in the case somewhere and running wires to it. I'd
prefer not to cut traces. Anybody know of an inexpensive OCXO that
meets the following criteria?
10 MHz sine output
12V or 5V supply voltage (either will work since it will be installed
off board)
5V EFC (TS2100 DAC is 0.5-4.5V)
Small enough to fit in a 1U rack enclosure (the Morion MV89A is too tall)
I'm not striving for perfection, just some that is significantly better
than the stock TCXO.
-Bob
Post by Hal Murray
Post by Robert Watzlavick
Not sure what the "precision" setting is for (it's currently -19).
That's probably for NTP. Roughly, it's how many useful bits of data you get
when you read the clock. I can probably find a description if anybody is
curious.
-19 is 2 microseconds which is a reasonable ballpark for an embedded system.
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Robert Watzlavick
2011-03-27 22:53:58 UTC
Permalink
If anybody has a TS2100 that came from the factory with an OCXO, can you
telnet into the unit and run the following command?

root eng ee info

This appears to be some sort of factory-configured personality of the
board. My TS2100-GPS unit with a TCXO has an info value of 00000024. A
TS2100-IRIG unit (no GPS) with a TCXO has a value of 00000000. I'm
curious whether any of those bits correspond to the oscillator type or
if all that needs to be changed is the gain.

Thanks,
-Bob
Greg Dowd
2011-03-29 00:28:16 UTC
Permalink
I think a couple of those bits do correspond to the oscillator type installed but I think you can ignore them. If I remember right, those oscillator bits were only used to calculate the dispersion update for ntp packets when flywheeling through a loss of signal. As far as I recall, you just need to change gain and filter. And the setting for the current d/a value should have been accessible in root tim utils as d2a.

As someone pointed out, the default ovenized for those boxes was the MTI 240 low profile.


-----Original Message-----
From: time-nuts-bounces-***@public.gmane.org [mailto:time-nuts-bounces-***@public.gmane.org] On Behalf Of Robert Watzlavick
Sent: Sunday, March 27, 2011 3:54 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Upgrading TS2100 from TCXO to OCXO

If anybody has a TS2100 that came from the factory with an OCXO, can you
telnet into the unit and run the following command?

root eng ee info

This appears to be some sort of factory-configured personality of the
board. My TS2100-GPS unit with a TCXO has an info value of 00000024. A
TS2100-IRIG unit (no GPS) with a TCXO has a value of 00000000. I'm
curious whether any of those bits correspond to the oscillator type or
if all that needs to be changed is the gain.

Thanks,
-Bob

_______________________________________________
time-nuts mailing list -- time-nuts-***@public.gmane.org
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Greg Broburg
2011-03-29 02:53:05 UTC
Permalink
I have MTI 240s if you need one.

Greg
Post by Greg Dowd
I think a couple of those bits do correspond to the oscillator type installed but I think you can ignore them. If I remember right, those oscillator bits were only used to calculate the dispersion update for ntp packets when flywheeling through a loss of signal. As far as I recall, you just need to change gain and filter. And the setting for the current d/a value should have been accessible in root tim utils as d2a.
As someone pointed out, the default ovenized for those boxes was the MTI 240 low profile.
-----Original Message-----
Sent: Sunday, March 27, 2011 3:54 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Upgrading TS2100 from TCXO to OCXO
If anybody has a TS2100 that came from the factory with an OCXO, can you
telnet into the unit and run the following command?
root eng ee info
This appears to be some sort of factory-configured personality of the
board. My TS2100-GPS unit with a TCXO has an info value of 00000024. A
TS2100-IRIG unit (no GPS) with a TCXO has a value of 00000000. I'm
curious whether any of those bits correspond to the oscillator type or
if all that needs to be changed is the gain.
Thanks,
-Bob
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Robert Watzlavick
2011-03-29 02:58:29 UTC
Permalink
That's good to know. I've been running the TS2100 for a few days with a
Morian MV89A (too big to fit into the case though) and it seems to work
well, definitely more stable than the TCXO. A test that I haven't run
yet is to pull the GPS antenna and see how long the NTP server reports
Stratum 1 performance and what the dispersion values are.

You're correct about the d/a setting - it seems all you have to is set
it and it stores it in NVRAM.

-Bob
Post by Greg Dowd
I think a couple of those bits do correspond to the oscillator type installed but I think you can ignore them. If I remember right, those oscillator bits were only used to calculate the dispersion update for ntp packets when flywheeling through a loss of signal. As far as I recall, you just need to change gain and filter. And the setting for the current d/a value should have been accessible in root tim utils as d2a.
As someone pointed out, the default ovenized for those boxes was the MTI 240 low profile.
-----Original Message-----
Sent: Sunday, March 27, 2011 3:54 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Upgrading TS2100 from TCXO to OCXO
If anybody has a TS2100 that came from the factory with an OCXO, can you
telnet into the unit and run the following command?
root eng ee info
This appears to be some sort of factory-configured personality of the
board. My TS2100-GPS unit with a TCXO has an info value of 00000024. A
TS2100-IRIG unit (no GPS) with a TCXO has a value of 00000000. I'm
curious whether any of those bits correspond to the oscillator type or
if all that needs to be changed is the gain.
Thanks,
-Bob
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Joseph M Gwinn
2011-03-28 13:20:36 UTC
Permalink
There are some hidden configuration parameters in the TS2100 that vary by
oscillator type (between TCXO,OCXO, and Rb), and include some control loop
parameters. It matters a lot that the firmware uses the correct algorithm
and parameters. The Rubidiums are quite far from the crystals, but I
assume that there is a smaller difference between crystal types.

Joe




From:
Robert Watzlavick <rocket-2baSUx0Sg/***@public.gmane.org>
To:
time-nuts-***@public.gmane.org
Date:
03/25/2011 12:39 AM
Subject:
[time-nuts] Upgrading TS2100 from TCXO to OCXO
Sent by:
time-nuts-bounces-***@public.gmane.org



I've been able to successfully upgrade my Datum TS2100 to an OCXO from
the stock TCXO. I didn't see it in the archives so I thought I'd post
my findings. I noticed that the same firmware was used regardless of
oscillator configuration so there must either be jumpers or a hidden set
of commands. The newer versions of the ET6000 have jumpers to select
the oscillator but I couldn't find anything similar on the TS2100.
However, in the back of the manual, 8500-0033 Rev K, Appendix I
describes how to reconfigure the unit to output GPS instead of UTC for
NTP. I'm not interested in that but there are some hints about a hidden
menu structure (root eng ee) which allows you to change EEPROM
settings. Here's the hidden menu items:

root eng:
start net interface
timing tools /
serial tools /
eeprom tools /
spi tools /
flash tools /
display tools /
memory tools /
intrinsic help

Going further into one of them, root eng eeprom:
ethernet address
board serial number
gain default
filter constant
low filter constant
precision
set eeprom
get eeprom
read serial eeprom
write serial eeprom
tx 16 bits to eeprom
location for image
info value
eeprom_select
intrinsic help

So that's where the default gain and filter constants are set. You have
to jumper across J4 on the PC board to allow EEPROM writes or you get an
error. Not sure what the "precision" setting is for (it's currently -19).

I don't have the proper OCXO (yet) but I do have an MV89A OCXO that I
was able to wire into the circuit temporarily. There is 12V on the
board and the 0.5-4.5V EFC range works well with the MV89A. I used a
gain of +20 and a filter setting of 0.9994965 based on Jason Rabel's
post from 9/26/2010 (note the sign change on the gain). The EFC
algorithm had a pretty good overshoot during the first adjustment cycle
and took over an hour to completely settle in but eventually the front
panel Locked LED turned on. I couldn't find a way to change the
starting value for EFC (d/a) value.

I *think* an Abracon AOCJY1A-10.000MHz-E-SW part will be pin compatible
on the board. Unfortunately nobody has that one in stock and it's a 10
week lead time so I may end up installing one off-board. The MV89A is
too tall to fit with the lid on so it's not a long term option. I
traced out the two SMA pads on the board and they are for the EFC out
and RF in so I could always run them to the back of the unit and put the
OCXO outside the unit.

-Bob
K5RLW

_______________________________________________
time-nuts mailing list -- time-nuts-***@public.gmane.org
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Jason Rabel
2011-03-30 21:19:42 UTC
Permalink
To all:

I ran the "root eng ee info" on my two TS2100s, both were originally IRIG units but I upgraded them myself to GPS models...

Both my OCXO unit and TCXO unit reported "00000000"

As for the parameters in my "timing / utils" directory, here's both models:

OCXO (MTI 240-0530-D)
---------------------
gain = -20
filter = 0.9995000
low = 0.0000000 (Manual says this isn't used, but figured I would post it)
d/a = 0xa05d
tfp 0 = 0xa005
tfp 6 & 7 = 0.9994965



TCXO
-------------------
gain = 2
filter = 0.9500000
low = 0.0000000
d/a = 0x85c0
tfp 0 = 0x85a4
tfp 6 & 7 = 0.9499970


My OCXO model came from Yahoo!, it still has the asset sticker on the side. It was in free-run mode when I got it. As mentioned
above, the OCXO is a MTI with the following info:

Model: 240-0530-D
PN: 010285-0530

If you want to see some hi-res images:

http://www.rabel.org/archives/Images/TS2100/


Time to poke around the eng directory and see if I can fix that pesky offset compared to my other time servers... There used to be a
command in the earlier firmware versions but it appears they removed it.

remote refid st t when poll reach delay offset jitter
================================================================
+NET4501-1 .GPS. 1 u 37 64 17 0.714 -0.029 0.087
*NET4501-2 .GPS. 1 u - 64 77 0.820 -0.022 0.129
+PRAECIS .GPS. 1 u 61 64 37 0.712 0.052 0.058
-TS2100-1 .GPS. 1 u 63 64 37 4.937 -0.406 0.025
-TS2100-2 .GPS. 1 u - 64 77 4.976 -0.366 0.046

The "root / eng / timing / offset" shows:

Current offset : -5 at offset unit (100ns)

I wonder if that might do the trick? Hmmm...
Robert Watzlavick
2011-03-31 01:40:19 UTC
Permalink
Assuming your OCXO unit came from the vendor pre-configured that way,
that means there are no changes required to the info field to convert it
from a TCXO to OCXO, just the gain and filter setting. This also seems
to match what Greg Dowd mentioned yesterday.

My unit (TCXO/GPS originally) has the root/eng/timing/offset set to
-100. A TCXO-IRIG unit that I looked at has an offset value of 0. When
I was first bringing up my unit with the OCXO, I was comparing the 10
MHz output against a stabilized Thunderbolt and I noticed the TS2100 EFC
voltage seemed to stabilize but there was an offset in the 10 MHz
output. The lock LED wasn't turning on either. I got impatient and
started poking around and that's when I noticed the "offset" parameter
was set to -100. I changed it to 0 and the lock LED immediately turned
on but then the EFC started heading the other direction. I put it back
at -100, let it sit for a few hours, and it eventually locked without a
frequency offset. I'll set my offset back to 0 and see where it ends up
overnight.

I believe the bc635PCI has a very similar timing engine and its manual
has an entry for Command 0x29, Set/Request Advance/Retard Clock Value
which may be a similar function. The description says "This command
sets the value of the advance/retard clock that is used to slew the
timing the 1PPS epoch. This command will allow the user to speed up, or
slow down, the on-board oscillator while the TFP is in a flywheel state
or Freewheel Mode. The TFP adjusts up to 100 msec per second. Each
count is 10 us." If it was the same timing engine, then you would think
the units would be the same though.

-Bob
Post by Jason Rabel
I ran the "root eng ee info" on my two TS2100s, both were originally IRIG units but I upgraded them myself to GPS models...
Both my OCXO unit and TCXO unit reported "00000000"
OCXO (MTI 240-0530-D)
---------------------
gain = -20
filter = 0.9995000
low = 0.0000000 (Manual says this isn't used, but figured I would post it)
d/a = 0xa05d
tfp 0 = 0xa005
tfp 6& 7 = 0.9994965
TCXO
-------------------
gain = 2
filter = 0.9500000
low = 0.0000000
d/a = 0x85c0
tfp 0 = 0x85a4
tfp 6& 7 = 0.9499970
My OCXO model came from Yahoo!, it still has the asset sticker on the side. It was in free-run mode when I got it. As mentioned
Model: 240-0530-D
PN: 010285-0530
http://www.rabel.org/archives/Images/TS2100/
Time to poke around the eng directory and see if I can fix that pesky offset compared to my other time servers... There used to be a
command in the earlier firmware versions but it appears they removed it.
remote refid st t when poll reach delay offset jitter
================================================================
+NET4501-1 .GPS. 1 u 37 64 17 0.714 -0.029 0.087
*NET4501-2 .GPS. 1 u - 64 77 0.820 -0.022 0.129
+PRAECIS .GPS. 1 u 61 64 37 0.712 0.052 0.058
-TS2100-1 .GPS. 1 u 63 64 37 4.937 -0.406 0.025
-TS2100-2 .GPS. 1 u - 64 77 4.976 -0.366 0.046
Current offset : -5 at offset unit (100ns)
I wonder if that might do the trick? Hmmm...
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Robert Watzlavick
2011-03-31 13:24:17 UTC
Permalink
I changed the root/eng/timing/offset parameter from -100 to 0 on my unit
and let it sit overnight. This morning, it is locked and without a
frequency offset. So I wonder why my unit would have had a 100 ns
offset programmed into it? I cannot figure out how to get the 0 value
to stick though. When I power cycle it, it returns back to -100.

I programmed various values into to the info field, restarted the unit,
and read the following results for the offset parameter:

0x00000000 -5
0x00000010 -5
0x00000021 -5
0x00000022 -5
0x00000024 -100
0x00000028 -5

This is interesting for a couple of reasons. First, it matches what
Jason is seeing in his units with the -5 ns value for offset. However,
a different TS2100-IRIG unit I looked had an info value of 0 and its
offset was also 0. Maybe the presence of the GPS unit makes it think it
needs an extra offset? We know that bit 6 is used for GPS vs. UTC for
the NTP time (from the manual). I suspect bits 2 and 5 are for GPS
since my unit was delivered that way. I would think at least 2 bits
would be for the osc type but which ones? And if Jason's unit came
delivered as an OCXO, why aren't any bits set to signify that? Maybe
the TCXO/OCXO is one configuration and the Rubidium is another. It
someone had a factory configured Rubidium unit, it would be interesting
to know if there are any bits that correspond to it.

-Bob
Post by Robert Watzlavick
My unit (TCXO/GPS originally) has the root/eng/timing/offset set to
-100. A TCXO-IRIG unit that I looked at has an offset value of 0.
When I was first bringing up my unit with the OCXO, I was comparing
the 10 MHz output against a stabilized Thunderbolt and I noticed the
TS2100 EFC voltage seemed to stabilize but there was an offset in the
10 MHz output. The lock LED wasn't turning on either. I got
impatient and started poking around and that's when I noticed the
"offset" parameter was set to -100. I changed it to 0 and the lock
LED immediately turned on but then the EFC started heading the other
direction. I put it back at -100, let it sit for a few hours, and it
eventually locked without a frequency offset. I'll set my offset back
to 0 and see where it ends up overnight.
Greg Dowd
2011-03-31 16:44:12 UTC
Permalink
The offset command in the TS2100 is just a phase stepper in 100ns steps. Usage was originally targeted at compensating for the GPS antenna cable length (~ns/ft). As it turned out, we used it for another purpose as well. The very first models of the 2100 used an external GPS receiver (Trimble Acutime) which had an open collector 1PPS. Because of that, we triggered the phase capture on the falling edge of the input signal. When we migrated the design to support an internal receiver (CM3 IIRC), somebody forgot that and we didn't have an extra inverter available at the right spot. What I ended up doing was some conniptions inside the box where we would still trigger on the falling edge and I would use the different default values of offset as compensation for the pulse width. Unfortunat
ely, as we changed GPS modules (CM3->Ace->AceII), the pulse width changed and I don't think anyone ever went back and fixed it. So, between all the different models, and due to the availability of add-on GPS conversion kits, many of these units ended up with different values of info which corresponded to difference GPS receivers and some phase offsets. I'd say just set it to whatever works.

-----Original Message-----
From: time-nuts-bounces-***@public.gmane.org [mailto:time-nuts-bounces-***@public.gmane.org] On Behalf Of Robert Watzlavick
Sent: Thursday, March 31, 2011 6:24 AM
To: Discussion of precise time and frequency measurement
Cc: Jason Rabel
Subject: Re: [time-nuts] Upgrading TS2100 from TCXO to OCXO

I changed the root/eng/timing/offset parameter from -100 to 0 on my unit
and let it sit overnight. This morning, it is locked and without a
frequency offset. So I wonder why my unit would have had a 100 ns
offset programmed into it? I cannot figure out how to get the 0 value
to stick though. When I power cycle it, it returns back to -100.

I programmed various values into to the info field, restarted the unit,
and read the following results for the offset parameter:

0x00000000 -5
0x00000010 -5
0x00000021 -5
0x00000022 -5
0x00000024 -100
0x00000028 -5

This is interesting for a couple of reasons. First, it matches what
Jason is seeing in his units with the -5 ns value for offset. However,
a different TS2100-IRIG unit I looked had an info value of 0 and its
offset was also 0. Maybe the presence of the GPS unit makes it think it
needs an extra offset? We know that bit 6 is used for GPS vs. UTC for
the NTP time (from the manual). I suspect bits 2 and 5 are for GPS
since my unit was delivered that way. I would think at least 2 bits
would be for the osc type but which ones? And if Jason's unit came
delivered as an OCXO, why aren't any bits set to signify that? Maybe
the TCXO/OCXO is one configuration and the Rubidium is another. It
someone had a factory configured Rubidium unit, it would be interesting
to know if there are any bits that correspond to it.

-Bob
Post by Robert Watzlavick
My unit (TCXO/GPS originally) has the root/eng/timing/offset set to
-100. A TCXO-IRIG unit that I looked at has an offset value of 0.
When I was first bringing up my unit with the OCXO, I was comparing
the 10 MHz output against a stabilized Thunderbolt and I noticed the
TS2100 EFC voltage seemed to stabilize but there was an offset in the
10 MHz output. The lock LED wasn't turning on either. I got
impatient and started poking around and that's when I noticed the
"offset" parameter was set to -100. I changed it to 0 and the lock
LED immediately turned on but then the EFC started heading the other
direction. I put it back at -100, let it sit for a few hours, and it
eventually locked without a frequency offset. I'll set my offset back
to 0 and see where it ends up overnight.
_______________________________________________
time-nuts mailing list -- time-nuts-***@public.gmane.org
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Robert Watzlavick.com
2011-03-31 16:57:36 UTC
Permalink
Thanks-that explains it. But I can't make an arbitrary offset value stick across a power cycle. Is that what the info field does?

I was trying to compare the 1 PPS from my ts2100 to the Thunderbolt but my HP 5316 only has 100 ns resolution. I would think the offset should show up as a skew on the PPS output.

-Bob
Post by Greg Dowd
The offset command in the TS2100 is just a phase stepper in 100ns steps. Usage was originally targeted at compensating for the GPS antenna cable length (~ns/ft). As it turned out, we used it for another purpose as well. The very first models of the 2100 used an external GPS receiver (Trimble Acutime) which had an open collector 1PPS. Because of that, we triggered the phase capture on the falling edge of the input signal. When we migrated the design to support an internal receiver (CM3 IIRC), somebody forgot that and we didn't have an extra inverter available at the right spot. What I ended up doing was some conniptions inside the box where we would still trigger on the falling edge and I would use the different default values of offset as compensation for the pulse width. Unfortun
ately, as we changed GPS modules (CM3->Ace->AceII), the pulse width changed and I don't think anyone ever went back and fixed it. So, between all the different models, and due to the availability of add-on GPS conversion kits, many of these units ended up with different values of info which corresponded to difference GPS receivers and some phase offsets. I'd say just set it to whatever works.
Post by Greg Dowd
-----Original Message-----
Sent: Thursday, March 31, 2011 6:24 AM
To: Discussion of precise time and frequency measurement
Cc: Jason Rabel
Subject: Re: [time-nuts] Upgrading TS2100 from TCXO to OCXO
I changed the root/eng/timing/offset parameter from -100 to 0 on my unit
and let it sit overnight. This morning, it is locked and without a
frequency offset. So I wonder why my unit would have had a 100 ns
offset programmed into it? I cannot figure out how to get the 0 value
to stick though. When I power cycle it, it returns back to -100.
I programmed various values into to the info field, restarted the unit,
0x00000000 -5
0x00000010 -5
0x00000021 -5
0x00000022 -5
0x00000024 -100
0x00000028 -5
This is interesting for a couple of reasons. First, it matches what
Jason is seeing in his units with the -5 ns value for offset. However,
a different TS2100-IRIG unit I looked had an info value of 0 and its
offset was also 0. Maybe the presence of the GPS unit makes it think it
needs an extra offset? We know that bit 6 is used for GPS vs. UTC for
the NTP time (from the manual). I suspect bits 2 and 5 are for GPS
since my unit was delivered that way. I would think at least 2 bits
would be for the osc type but which ones? And if Jason's unit came
delivered as an OCXO, why aren't any bits set to signify that? Maybe
the TCXO/OCXO is one configuration and the Rubidium is another. It
someone had a factory configured Rubidium unit, it would be interesting
to know if there are any bits that correspond to it.
-Bob
Post by Robert Watzlavick
My unit (TCXO/GPS originally) has the root/eng/timing/offset set to
-100. A TCXO-IRIG unit that I looked at has an offset value of 0.
When I was first bringing up my unit with the OCXO, I was comparing
the 10 MHz output against a stabilized Thunderbolt and I noticed the
TS2100 EFC voltage seemed to stabilize but there was an offset in the
10 MHz output. The lock LED wasn't turning on either. I got
impatient and started poking around and that's when I noticed the
"offset" parameter was set to -100. I changed it to 0 and the lock
LED immediately turned on but then the EFC started heading the other
direction. I put it back at -100, let it sit for a few hours, and it
eventually locked without a frequency offset. I'll set my offset back
to 0 and see where it ends up overnight.
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Greg Dowd
2011-04-01 19:34:29 UTC
Permalink
I'll try to take a look and see if there is a way to set an arbitrary value that is stored across boot cycles. I would have thought it would work that way already but if it's not, I'll have to check.

And you are correct that any offset you program into the offset field should show up if you compare a baseline GPS pps against the output 1pps from the device.

I would caution against using the lock light if you are playing with different control values. The lock light is a simple aggregation indicator of signal source available + phase offset < x microseconds + phase offset / time < x nanoseconds / second. I think the values of x and y were set based on reference source but there isn't much in the way of hysteresis and I've occasionally had tests where I tweaked variables which resulted in large overshoot and the lock light toggling for a while.



-----Original Message-----
From: time-nuts-bounces-***@public.gmane.org [mailto:time-nuts-bounces-***@public.gmane.org] On Behalf Of Robert Watzlavick.com
Sent: Thursday, March 31, 2011 9:58 AM
To: Discussion of precise time and frequency measurement
Cc: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Upgrading TS2100 from TCXO to OCXO

Thanks-that explains it. But I can't make an arbitrary offset value stick across a power cycle. Is that what the info field does?

I was trying to compare the 1 PPS from my ts2100 to the Thunderbolt but my HP 5316 only has 100 ns resolution. I would think the offset should show up as a skew on the PPS output.

-Bob
Post by Greg Dowd
The offset command in the TS2100 is just a phase stepper in 100ns steps. Usage was originally targeted at compensating for the GPS antenna cable length (~ns/ft). As it turned out, we used it for another purpose as well. The very first models of the 2100 used an external GPS receiver (Trimble Acutime) which had an open collector 1PPS. Because of that, we triggered the phase capture on the falling edge of the input signal. When we migrated the design to support an internal receiver (CM3 IIRC), somebody forgot that and we didn't have an extra inverter available at the right spot. What I ended up doing was some conniptions inside the box where we would still trigger on the falling edge and I would use the different default values of offset as compensation for the pulse width. Unfortun
ately, as we changed GPS modules (CM3->Ace->AceII), the pulse width changed and I don't think anyone ever went back and fixed it. So, between all the different models, and due to the availa
bility of add-on GPS conversion kits, many of these units ended up with different values of info which corresponded to difference GPS receivers and some phase offsets. I'd say just set it to whatever works.
Post by Greg Dowd
-----Original Message-----
Sent: Thursday, March 31, 2011 6:24 AM
To: Discussion of precise time and frequency measurement
Cc: Jason Rabel
Subject: Re: [time-nuts] Upgrading TS2100 from TCXO to OCXO
I changed the root/eng/timing/offset parameter from -100 to 0 on my unit
and let it sit overnight. This morning, it is locked and without a
frequency offset. So I wonder why my unit would have had a 100 ns
offset programmed into it? I cannot figure out how to get the 0 value
to stick though. When I power cycle it, it returns back to -100.
I programmed various values into to the info field, restarted the unit,
0x00000000 -5
0x00000010 -5
0x00000021 -5
0x00000022 -5
0x00000024 -100
0x00000028 -5
This is interesting for a couple of reasons. First, it matches what
Jason is seeing in his units with the -5 ns value for offset. However,
a different TS2100-IRIG unit I looked had an info value of 0 and its
offset was also 0. Maybe the presence of the GPS unit makes it think it
needs an extra offset? We know that bit 6 is used for GPS vs. UTC for
the NTP time (from the manual). I suspect bits 2 and 5 are for GPS
since my unit was delivered that way. I would think at least 2 bits
would be for the osc type but which ones? And if Jason's unit came
delivered as an OCXO, why aren't any bits set to signify that? Maybe
the TCXO/OCXO is one configuration and the Rubidium is another. It
someone had a factory configured Rubidium unit, it would be interesting
to know if there are any bits that correspond to it.
-Bob
Post by Robert Watzlavick
My unit (TCXO/GPS originally) has the root/eng/timing/offset set to
-100. A TCXO-IRIG unit that I looked at has an offset value of 0.
When I was first bringing up my unit with the OCXO, I was comparing
the 10 MHz output against a stabilized Thunderbolt and I noticed the
TS2100 EFC voltage seemed to stabilize but there was an offset in the
10 MHz output. The lock LED wasn't turning on either. I got
impatient and started poking around and that's when I noticed the
"offset" parameter was set to -100. I changed it to 0 and the lock
LED immediately turned on but then the EFC started heading the other
direction. I put it back at -100, let it sit for a few hours, and it
eventually locked without a frequency offset. I'll set my offset back
to 0 and see where it ends up overnight.
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
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-***@public.gmane.org
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Jason Rabel
2011-04-01 17:20:38 UTC
Permalink
Greg,

I guess I had to wait until my coffee kicked in this morning before it clicked that it was in nanoseconds... I'm trying -3000 to see
where that gets me, it seems to be nudging the time more in-line with my other NTP servers.

As others have asked, how do we get this value to be persistent across reboots? Is there a way to write it to the eeprom or nvram or
whatever?

Is there any documentation on all the various commands in the eng/ directory? I want to tinker but I don't want to break my unit!


Thanks as always,
Jason
Greg Dowd
2011-04-01 19:41:23 UTC
Permalink
Well the units are 100ns each so if you set offset to 3, it should shift the 1pps output by 300ns. Another point is that there is significant asymmetry in the ntp packet processing if you are looking at accuracy. For the 1996 time of day requirement of 100ms, it was moot. If you set the box up in GPS mode and look at the 1pps output from the box, and set the offset so that the 1pps is within 1 usec of a known UTC reference, you will see that the transmit timestamps on ntp replies are a few ms late due to the tx latency in the device. The rx timestamps errors are more interrupt latency (10-100 microseconds). The net result is that your network clients will see a bias in the TS2100 clock (bias = rt/2). If you use the offset command, you can correct this bias but it will be at the cost
of moving your hardware 1pps output off an equivalent amount in the opposite direction.


-----Original Message-----
From: time-nuts-bounces-***@public.gmane.org [mailto:time-nuts-bounces-***@public.gmane.org] On Behalf Of Jason Rabel
Sent: Friday, April 01, 2011 10:21 AM
To: time-nuts-***@public.gmane.org
Subject: Re: [time-nuts] Upgrading TS2100 from TCXO to OCXO

Greg,

I guess I had to wait until my coffee kicked in this morning before it clicked that it was in nanoseconds... I'm trying -3000 to see
where that gets me, it seems to be nudging the time more in-line with my other NTP servers.

As others have asked, how do we get this value to be persistent across reboots? Is there a way to write it to the eeprom or nvram or
whatever?

Is there any documentation on all the various commands in the eng/ directory? I want to tinker but I don't want to break my unit!


Thanks as always,
Jason


_______________________________________________
time-nuts mailing list -- time-nuts-***@public.gmane.org
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Jason Rabel
2011-04-02 14:36:42 UTC
Permalink
Post by Greg Dowd
If you use the offset command, you can correct this bias but it will
be at the cost of moving your hardware 1pps output off an equivalent
amount in the opposite direction.
Greg, that's understandable. I don't use the PPS output from these boxes so that isn't really a concern for me. Besides being a NTP
server for my little network I use the IRIG signal to feed to an old NTS-100, which in turn converts UTC time to local 12 hr time
for my IRIG clocks. Even though the NTS-100 is very old (you have to set "version 3" explicitly if you want modern NTP to recognize
it), it's very customizable in relation to daylight savings start/end and 12/24 hr display. :)

If the TS-2100's were my only time servers, I probably wouldn't even mess with it because the time is so close, certainly better
than what could be achieved syncing over the Internet.

I think an offset of -4000 on the ts2100 seems to be pretty close to my other time servers.

remote refid st t when poll reach delay offset jitter
==================================================================
*NET4501-1 .GPS. 1 u 22 64 377 0.744 0.027 0.099
+NET4501-2 .GPS. 1 u 66 64 377 0.825 -0.009 0.107
+PRAECIS .GPS. 1 u 7 64 377 0.761 0.043 0.061
+TS2100-1 .GPS. 1 u 26 64 377 5.039 0.023 0.034
+TS2100-2 .GPS. 1 u 50 64 377 5.142 -0.015 0.037
Hal Murray
2015-03-26 19:25:16 UTC
Permalink
I want to develop a tracking system for an amateur rocket ...
Do you need the position in real time, or just after the rocket returns so
you can find it?
I had thought 100 ns of timing accuracy in the received signals would be
good enough but I think I need to get down less than 40 ns to keep the
algorithms from blowing up
40 ns is 25 MHz. It shouldn't be hard to find a uP with counter/timer that
runs faster than that.


I think you can get away without fancy oscillators.

I'm assuming you can use GPS to get the the initial position of the rocket
and the receiving stations. I'm also assuming that the rocket can start
transmitting a few seconds/minutes before launch to calibrate things.

Suppose the receiver puts out a pulse. Feed that to a uP with a
counter/timer module that gives you a time stamp. Feed all the time-stamps
to a central PC that will sort things out.

If the pulses are far enough apart it will be easy to figure out which
time-stamps go together. [1] The clocks used to make the time stamps don't
need to agree on a base time. You can sort that out at the PC with data from
before the rocket leaves the ground.

How accurate do the oscillators need to be? If you can listen for a while
before launch you can calibrate the individual oscillators. So the question
becomes how long does it take to do the calibration?

How stable do the oscillators need to be? How long does the flight last?
The calibration error and noise/wander from calibration is part of your error
budget.

If a flight lasts 100 seconds (handy number for back of napkin calculations)
and the calibration/drift is off by 1E9, that's 100 ns. So you will need an
oscillator that is stable to better than 1E10 over 100 seconds.
Ballpark/handwave.

You can also calibrate the receiver oscillators again after the rocket lands.
Does the transmitter survive the landing? Does the antenna survive well
enough?
measurements would then be used to determine x, y, z, and t
Is Z interesting? I'm assuming you are firing rockets in flat desert
terrain. All the receivers will be in the same plane. I'll bet the math has
troubles if you try to calculate the Z when the rocket is near the plane of
the receivers. Have you looked into a different set of algorithms that
assume the rocket is on the ground?

-----

1) If you need more data, you can still sort things out if the transmitter
sends pulses with non-uniform spacing. I think there is a whole branch of
math for that problem but I don't know the name/term.
--
These are my opinions. I hate spam.



_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Robert Watzlavick
2015-03-27 02:55:39 UTC
Permalink
Post by Hal Murray
I want to develop a tracking system for an amateur rocket ...
Do you need the position in real time, or just after the rocket returns so
you can find it?
Near real-time would be nice but I guess not an absolute requirement.
Post by Hal Murray
40 ns is 25 MHz. It shouldn't be hard to find a uP with counter/timer that
runs faster than that.
I think you can get away without fancy oscillators.
I'm assuming you can use GPS to get the the initial position of the rocket
and the receiving stations. I'm also assuming that the rocket can start
transmitting a few seconds/minutes before launch to calibrate things.
Suppose the receiver puts out a pulse. Feed that to a uP with a
counter/timer module that gives you a time stamp. Feed all the time-stamps
to a central PC that will sort things out.
If the pulses are far enough apart it will be easy to figure out which
time-stamps go together. [1] The clocks used to make the time stamps don't
need to agree on a base time. You can sort that out at the PC with data from
before the rocket leaves the ground.
Good idea - I hadn't thought about that. As long as they don't drift
too far, I can calibrate out the initial drift.
Post by Hal Murray
If a flight lasts 100 seconds (handy number for back of napkin calculations)
and the calibration/drift is off by 1E9, that's 100 ns. So you will need an
oscillator that is stable to better than 1E10 over 100 seconds.
Ballpark/handwave.
Powered flight will be less than 30 seconds. Depending on when the
chute deploys, it may take a few minutes or tens minutes to make it all
the way down. If the chute doesn't open (a common occurrence), then it
will come down much faster :)
Post by Hal Murray
You can also calibrate the receiver oscillators again after the rocket lands.
Does the transmitter survive the landing? Does the antenna survive well
enough?
If I get the rocket back in a small number of pieces, it will be an
achievement. The recovery success rate with large amateur liquids isn't
that grea
Post by Hal Murray
Is Z interesting? I'm assuming you are firing rockets in flat desert
terrain. All the receivers will be in the same plane. I'll bet the math has
troubles if you try to calculate the Z when the rocket is near the plane of
the receivers. Have you looked into a different set of algorithms that
assume the rocket is on the ground?
Altitude (z) is not too important for finding it but will be useful in
confirming the performance. From the multilateration simulations I've
done so far, there are some "bad" areas and yes, near the ground isn't
too good if all them are in the same plane. Maybe I can put one or more
of the ground stations on a big hill or something. Good point though -
if they're nearly in the same plane, the equations may be a bit simpler.

-Bob
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bill Hawkins
2015-03-27 16:01:06 UTC
Permalink
NASA uses the Doppler effect for deep space navigation, by integrating
the velocity.

You'd need a very stable oscillator, but you don't need a powered oven,
due to the short duration of the flight.
You only need one receiver. In fact, if it's possible for the rocket to
hear a ground signal and return it at some offset or fractional
frequency, you don't need an oscillator on the rocket.

But if you do need a stable oscillator, consider enclosing it in
aerogel, as we were discussing a few months ago. Bring it up to temp
with ground power and let it go.

There is still the matter of acceleration. If the oscillator can be
calibrated, then the frequency versus acceleration is known and can be
used to get the rocket's acceleration during powered flight. Double
integration yields position. Taking the Doppler shift out of the
integral could be tricky.

Disclaimer: The last time I had anything to do with a rocket was 1959,
with an Aerobee-Hi launched from White Sands, NM. We used Doppler to get
altitude for upper air density measurement. The rocket went off course
horizontally (determined by radar) and was destroyed before it crossed
the border.

Bill Hawkins

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Loading...