Symmetricom TrueTime XL-DC GPSDO

[Ulaker]

Reply to myself, the 16.368 adjustable oscillator is hard to reach and requires repetitive disassemble  of the stacked boards. If it is the way to achieve bit lock and/or phase lock I had no successful  iteration of adjustment and proof of concept in doing it.

The rs-232 is either broken or misconfiguration of sorts. The tx pin is functional the rx is stuck on mark level so no way to input the ctrl-c and obviously none of the further interactin instructions on this path.

So question: is the manual of this board available or at least reverse eng of the rs-232 port path, possibly jumpers or driver chips already figured out? The rs-232 port is probably talking to the 80c186, so need to find out how the uart functionality is implemented. If it was a static jolt that destroyed a protection diode or rx driver IC in the proximity of the 9pin connector maybe the component  could be replaced  and functionality  restored?

Thanks for help and season greetings from Germany,
Ulaker

[ZigmundRat]

If you've set it on frequency, that's all you can do. Adjusting it after that isn't going to help. But I think you may have a bigger problem: The down converter antenna could be the wrong one.

The manual references a 142-603 model - @pacAir (and others) have indicated that the 140-615 you have has a different IF frequency and is incompatible. That would explain alot. Besides the 142-603 referenced in the manuals, there is also the 142-401, 142-602, and 142-610 which may also be compatible. I also just read: "It will not work with receivers matched to the "bullet" style downconverters (eg. XL-AK, XL-DC etc)." in an eBay listing from a guy who has been doing this for a long time. So I think that's accurate, sorry 

Regarding the serial port: @pacAir in the 2nd reply at the top of this thread posted a PDF of the option jumpers. J26 and J27 determine RS232/RS422. You might start tracing there and see what you find. My one unit I have open now has an LTC491 driver chip (differential driver) and a Sipex SP310 (RS232 driver). I haven't traced them out to see what's connected where  (there's also a 75179 on the GPS board, that could be the reason for the LTC491).

[Ulaker]

Thank you for guidance, I lack knowledge of the inner cogwheel mechanism that is buried inside the receiver board. Is there any description i.e. theorie of operation that explains the approach that the cavemen of gps technology have chosen to implement a signal processing to recover frequency and phase over this convoluted extraterestrial path with the components available four decades ago? Why two cpu architectures, 80c186  and 68000, completely different designs of data processing engines engaged in the task? Appearantly different groups with different taste and decision making choice required to skin the cat? If I understand it right part of the coarse aquisiton demodulation seems to work despite the incorrect front end? The gps derived solutions to date, time, longitude, latitude and elevating computation produces correct results. The tracking of satelites never gets to classify good or bad satellites, (the lists are empty even fter manny hours) despite the 2d time enumeration of recognizer satelites in field of view of the antenna.

 Not sure how long it will take me to find time to trace the path of the rs-232, (maybe the faulty part can be bypassed)  I expect to get more insight into the inner workings of this gps engine if it can be explored via the responses and monitoring parameters. 

Merry Xmas,
Ulaker

[ZigmundRat]

I also lack knowledge of the inner workings of GPS navigation and timing. I found this: http://www.nbmg.unr.edu/staff/pdfs/blewitt%20basics%20of%20gps.pdf to be a very readable description of the system. 40 years ago or today, the system basically works the same way. The main differences are in time to first fix, simultaneous satellites tracked, etc.

The reason for different processor architectures is the GPS is made by Trimble, the clock generator/disciplined oscillator by Datum. It is not a surprise that they would be different.

I can’t explain why (if the down converter is the wrong one) it would ‘half work’. I agree, it appears that C/A signal can be initially recovered but after that, it goes to another state where it can’t proceed.

If you want to talk to the GPS engine directly, you should be able to do so by carefully connecting to the serial port. Keep in mind the electrical signal levels if you do this. I used this method to capture the traffic between GPS module and the system board. The GPS is setup is TSIP mode so you will need to decode it. You might also need/want to see if you can find the software to talk to these old Trimble receivers. I think it was called TSIPCHAT, I will have to look in my old stuff for it.

Frohe Weihnachten Ulaker!

[ZigmundRat]

Just a bit more info for you. Just to illustrate the variety of parts used in these, I've included a picture of another GPS receiver which they used, an ACE-II model, again by Trimble.

But it wasn't 100% compatible, so they built a FPGA converter board and placed it between the system board and the GPS. These boxes were widely varying in their options and builds. I don't think I've run into two units with exactly the same firmware either. It's almost like the firmware was custom burned for each box shipped, depending on the options.

With regard to the OCXO: I also include here two pictures of my OCXO unit. One showing the cable routing and where the OCXO is mounted (2nd pic).
The OCXO itself is a Oscilloquartz 8666-CS, which is mounted on a little carrier card. I provided a picture of that board alone for reference (3rd pic). There's no magic there, just a regulator and an op-amp buffer for the output. It wouldn't be that hard to lay out a new board to match. If you decide to do this, and can't read some component values let me know. Likewise for dimensions. Good luck with your unit!

Cheers!

[Ulaker]

thank you for bringing more light into the evolution history of the beginnings of GPS technology.
Looks more like prototype or development studies than series fabrication. A long way between these and ublox neo m8p.

Did you never replace the NVRAM lithium-thionylchloride cell? I checked it and it was around 1V, so I replaced mine with a 3032 button cell since the original is hard to get and mighty expensive without even considering shipping cost.

What is the switch on the receiver board supposed to do? Usability in the same class as the trimmer on the 16.368 oscillator.
This gadget is a textbook collection  of solutions on how not to design equipment.

Did not find time to further fiddle around but the few restarts seem to have a reproducible behavior, the date, time and location reliably decoded and the status changes initially between looking for satellites and note enough satellite in between the 2d solution for several sat numbers is briefly displayed finally it decides to stay solid on not enough satellites and nothing more seems to happen on the status. Maybe peeking into the messages exchange between the two boards reveals weather it still continues to demodulate satellite signals, and if yes which ones.

Cheers!

[gpsdo_nut]

Great to see the TrueTime XL-DC thread still ticking on!  My Racal Dana 1992 counter power supply apparently took a dumper the other day so posed a question in the Repair section....and noticed new posts here!

@Ulaker - If I remember correctly, TrueTime customizes the Trimble GPS receivers to accept a scaled-down LO frequency from the 10MHz reference to something like 16.384kHz, which replaces the native 16.384KHz crystal that usually accompanies these Trimble receivers.  When your unit eventually loses lock on the original satellites, what does your XL-DC DAC value read (FN+71, up/down arrow to DAC page)?  Make sure it isn't pegged onto either end of the 16-bit DAC range (I think -32768 to +32767).  Do you have a frequency counter with a good reference to determine how far off to true 10Mhz your XL-DC is giving out?

Also make sure your receiver isn't stuck in TIME mode when you power on your unit.  Stick it in AUTO for the time being.

[Ulaker]

Hello, thank you for suggestions.

The mode is Auto,  upon power up it seems to iterate a few steps of the state machine giving Mode Auto and 1sat values like 22 and 4 etc in between messages like No usable satellites yet and looking for satellites.
I would like to believe, but do not remember exactly, some 2d messages among the sturtup strings.
After a while it seems to get stuck in looking for satellites.
The fact that it stays in the looking for satellites  may be indicative that the demodulator does not recognize sync or idle pattern which should translate usable signal and that to satellite in field of view.
The FN71 values change during the initial aquisiton steps, and stop when the looking for satellites is reached.
Is there some way to check signal to noise ratio anywhere? Any test points on the board with known healthy patterns for analog scope or digital status like carrier detection or bit lock, frame lock, etc? In these early design they sure must have hardware for signal processing so some partial tell tale points reachable on the board.

The steady state values given by FN71 are:

Dac -15098,
Response Time 6.250e+00s
Osc Phase -3.462e-06s
Osc Offset -7.362e-07
Osc Drift -1.750e-06/day

No idea weather these values are indicative of something. I never checked them before nor do I know where to look for healthy range values for a nominal operating device.

Season greetings,
Ulaker

[gpsdo_nut]

Your DAC value looks to be in the proper range.

I would like to believe, but do not remember exactly, some 2d messages among the sturtup strings.
After a while it seems to get stuck in looking for satellites.
The fact that it stays in the looking for satellites  may be indicative that the demodulator does not recognize sync or idle pattern which should translate usable signal and that to satellite in field of view.
 

Yes, if the receiver thinks it has enough satellites to form a 2D solution it'll briefly enter that state while continuing to search the sky to eventually (hopefully) enter 3D positioning mode.  As ZigmundRat may have hinted, it's still very possible the demodulator for the downconverter section to not be 100% compatible with your unit.

Is there some way to check signal to noise ratio anywhere? Any test points on the board with known healthy patterns for analog scope or digital status like carrier detection or bit lock, frame lock, etc? In these early design they sure must have hardware for signal processing so some partial tell tale points reachable on the board.

You can check the C/NO values of each satellite in FN60 - I have a Trimble SVee 6 model (old) and reports in Trimble's own AMU units.  I think anything above like an '8' is pretty good.  Newer models may report differently.  As for test points, not certain; the RF and digital domain stuff is done inside the Trimble GPS board, which is a modified COTS product but I wouldn't expect any real TPs for things like that - someone else can correct me if I'm wrong.

As I type this, you can also issue a F79 and do a COLD reset of the GPS module and see if it starts up and holds on to satellites better.  You also did mention changing the 3V lithium NV memory battery which should have done the same thing...but do try F79 COLD Start a try for grins.

[Ulaker]

Set FN79 selected to yes, does not seem to provoke reaction,  or does it apply this selection on next power cycle?

FN60 is and stays unpopulated, neither tracking nor bad show any entry, in other word end of list when it should display the sat numbers and possibly characterization their signal condition.

Might be that the front end down converter implementation  or its current bandwidth is no perfect harmony for the processors in the unit, still it does some corse aquisiton steps. There possibly is a different demodulator for parts of the signalling stream. Intrigueing that partial functionality. I guess it is perfectly explainable with better understanding of the coreography and orchestrations in these boards. It must have worked once upon a time but something  changed since than. It might be a unmatched front end....

At this time I have little inclination to procure another front end section, maybe after the rs232 rx path is functional.
Possibly the event that fried the rs232 input also impacted the antenna associated circuitry in some way detrimental signal integrity.

[looney]

I also received a XL-DC (Symmetricom branded) in the mail today, pictures and more info will follow later.

But I can tell you right now that it's a very basic unit, just a PSU and GPS board, 12 Symmetricom antenna, no other I/O, no Rb and no OCXO.
This leads to my question, is it possible to fit an OCXO even when there is no wire harness for it?

On the pictures in this topic I see that the power and coax go somewhere under the ribbon cable connecting the backplane and the front panel but it's not clear where they connect.
I'm also not sure if the option would need to be enabled in software.

I guess it's always a possibility to replace the TCXO on the GPS board with an OCXO or Rb?


Again, I will post picture and info according to the template later this week but I thought it was wise to ask this question first in case there is something in particular I need to look for that might not be included in the template


PS: The unit, as bare as it is, does function perfectly, 3d time fix in a few minutes and so far it seems within spec compared to my Rb optioned Oscilloquartz OSA 5230 receiver.

[Ulaker]

Happy to hear that thre are more electronics archeologists digging into the evolution of the time keeping technology.
As far as I was able to gather info there is no repair manual or schematic circulating in the open. Everithing I have seen so
far is descriptors experience. Modifications of the tcxo to ocxo or rubidium is definitely possible since symmetricom did
it a long time ago already. They used two or more receiver modules and middleware to translate message sentences
derive time and location to adjust the different options of local time keeper. The core peace of the processing is achieved on two cpu, one 68000 and one 80c186.
Depends on your determination and skills to reverse engineering and weather economics do not play significant part of the ecuation. The slope and loop time  to  control the local oscillator varies for each technology approach. At this time it is not clear to me weather different firmware versions existed for tcxo ocxo and rubidium or jumper configuration determined the discipline of the slave oscillator present.

Happy  new Year and fun with your new aquisition,
Ulaker

[ZigmundRat]

In our collective experience so far, it almost seems that each unit was built to order. The specific firmware version appears to be very much tied to the exact build options. So far, I haven't found any software setting or hardware strapping which sets the oscillator type. It appears that TCXO, OCXO, and Rb all have their loop parameters in ROM. This means that you will not readily be able to change out the TCXO for an OCXO, or Rb option. The only other option would be if you had the 'external oscillator option', which is the only way you can set any of the control loop parameters.

I guess we could start collecting ROM images and info on specific version, model number, GPS, and installed options. I have two Rb units, an OCXO with added low phase noise option, and a TCXO version with added low phase noise option. They two Rb units identify with the same model number (182-6222v006) and the same version (1.043) but the SYS version (027) is SV6 on one and ACE on the other. I don't know if both GPS engines are supported in the same ROM and are identified at startup, or if it's another case of unique firmware.

[Johnny10]

 

[salvateur2012]

bnjr ma betterie typê keeepers 3.5 volt a exploser du coup court cicruit jaimerais savoir le role de cette pile et cause possible merci

[ZigmundRat]

The battery allows the saving of current location, almanac data, and clock to keep time when powered off. This makes future startup times faster, but is not required for operation.

There is no normal reason the battery should explode. I suppose given their age an original battery could leak, but none of my units did. Please note that this is a special non-rechargeable lithium thionyl chloride long life  battery, and must be replaced correctly and with the correct type! If the original were replaced with something different or the circuitry were altered, then there could have a problem.

(I’m sorry, I do not read French, so used a translation to understand the question.)

[gmilliorn]

I purchased an XL as not working, the seller artfully hid the following in the shadows.  This appears to be
the original battery type, so they do leak for some reason.

I suppose that is what the previous poster was referring to.  This is truly a parts unit now I guess.

[gmilliorn]

The GPSDO seems unsalvageable, but the OXCO is OK and chassis, despite some lithium corrosion is fine.  I had
thought to marry this with a Trimble GPSDO but schematics seem unavailable, at least as far as I can tell.

So I've reverse engineered the display/keyboard and some of the backplane, at least well enough to talk to the
front panel, using an Arduino.  That's probably not sufficient to manage the Trimble I assume, based on what
others are using (the M1DST code looks interesting).

I can post the schematics if that is of interest.  It is not the TrueTime GPSDO board, though.

[gmilliorn]

Here's the schematics if they're of interest.
I don't know anything about TrueTime's products, so
all the names are based on assumptions.  It's enough for
an Arduino to talk to, at least.

[ZigmundRat]

Definitely of interest, thanks for sharing your work. Repurposing the chassis is a great idea, and now that you’ve got the backplane connections figured out you’re well on your way. In the original product, the front panel is little more than a clock plus a keypad and smaller LCD for configuration and some status displays. I would think that you could turn this into a display/control pad for the Trimble/UCCM type GPSDOs (or Thunderbolt). You would need to parse the serial output and send serial commands, but this is not especially difficult, just annoying as the output is mostly meant to be human readable. There are a variety of projects which provide displays for these units which you could leverage. Some simple, some more complex. The M1DST project is interesting (C# and .NET on a micro) but there are many other platforms which could be used (Teensy, ESP32, etc).

If you wouldn’t mind posting some code examples that would really complete the package.

Thanks again for sharing.

[Kean]

Indeed.  I have a similar unit, the TrueTime GPS-DC (2RU version) and I've not had any luck getting it to do anything due to the lack of any docs.

The idea of repurposing the front panel and chassis is appealing, and maybe even some of the output cards.  The front panel is slightly different on my model, but probably implemented in a similar fashion.  I suspect just the keyboard layout changed slightly between models.

[gmilliorn]

Here's the arduino code for probing/controlling the system.  It has
details on the clock display, which is basically a 96-bit shift register,
one bit per LCD segment.

The keyboard debouncing is poor, I've not spent much time on
it as I think I probably need to switch to a raspberry pi if I want to run
an NTP service on it.

[NA5B]

Hello all, I would like to use the Lady Heather with my Truetime XL-DC but it is not listed in the supported devices. I tried all the commands listed for various devices. Anyone running the Lady Heather with Truetime XL-DC? I see that Texaspyro has a picture shared here using the same unit with the software. I also have a Fei-Zyfer Nanosync and have no problem running it with the Lady Heather with /rx3 command. Thank you.