[time-nuts] TS2100 OCXO Conversion: Command exploration
kyrrin at bluefeathertech.com
Sun Apr 8 20:14:01 EDT 2018
And, as of today, I still can't get it to lock. :-P
I think I'm going to have to conclude, reluctantly, that the full-size
OCXO's are simply not compatible with this unit. It strikes me as
possible there may be other hardware changes needed to run such. It's
just impossible to tell for certain without some kind of schematic.
So -- Reverse conversion, here we go. Looks like I'll just have to
settle for a square wave until I can find a couple of MTI 240's....
Thanks to all who rendered assistance.
On 07-Apr-18 16:08, Esa Heikkinen wrote:
> I have TS2100 which I modified from TCXO to OCXO. I have the 'offical'
> MTI OCXO, which I bought from someone on this board. I have also
> replaced the GPS unit to the HEOL Design model, which was required to
> get correct time at all. It's also much more accurate than the original
>> Now, with all this said: I'm still waiting for a 'Lock' indicator on
>> the front. It's tracking, and the D/A value certainly has changed from
>> what I had it at last night, but I'm still not getting a lock. Here are
>> my current numbers:
> If I turn off the unit and the OCXO is totally cooled down then it might
> need even 2-3 hours before getting the LOCK indicator on again! So
> please be patient.
> According to my measurements the LOCK indicator will turn on when the
> PPS has gone within 1 microsecond of UTC. But it's not fully locked
> even at this point! With HEOL Design GPS unit it will end up within 50
> nanoseconds of UTC, but that requires even more time.
> If you have trouble with locking you should compare the PPS with
> oscilloscope with some other receiver (for example Thunderbolt) or maybe
> you could 'steal' the PPS from the internal GPS and compare it with
> output. You should see it trying to reach the correct PPS and if it
> passes it at startup, it should change the direction and finally settle
> near the PPS input. In case of trouble you could also try with different
> A/D values manually and see what they do.
>> root timing utils tfp 0 -- returned 0x00f2
> That cannot be correct: Value is too low, near zero volts perhaps and it
> might be clipped. Looks like it has drived itself to the lower limit
> without getting correct feedback. This is a clear sign that clock
> steering is not working at all.
> From my unit:
> 1 ? tim
> 2 ? utils
> 3 ? tfp 0
>> root timing utils tfp 6 -- returned KM = 0.9994965
> 4 ? tfp 6
> KM = 0.9994965
>> root timing utils tfp 7 -- returned KO = 0.9994965
> 5 ? tfp 7
> KO = 0.9994965
>> root timing utils gain -- returned gain now:20 (There seems to be a
> 6 ? gain
> gain now:-20
>> root eng eeprom info -- returned 00000024
> Same here. Please note that to enable any eeprom writes you must close
> JP4 temporary.
> By the way: you don't need to start every command with 'root'. It just
> resets the menu structure back start every time, which sounds
> impractical. You gan enter the menus, type '?' to see the available
> commands and go back to previous menu level with 'pop' command.
>> Any thoughts on why I don't have a lock as yet?
> According to A/D value it looks like clock steering is not working at
> all. You should use oscilloscope to find out if A/D values have any
> effect at all.
> If you have rubidium or other kind of 10 MHz source put it to one trace
> of oscilloscope and TS2100 10 MHz output to another. Then try with
> different A/D values manually and see if it's even possible to get waves
> syncronized. If it's not possible with any A/D value then it will never
> lock, perhaps your OCXO is not compatible.
Bruce Lane, ARS KC7GR
kyrrin (at) bluefeathertech dot com
"Quando Omni Flunkus Moritati" (Red Green)
More information about the time-nuts