I actually wound up having to shut down this page for a couple of months there due to the sheer amount of spam, and a lack of (personal) time to reconfigure the system to handle this. Fortunately this problem is now solved, so back online for all to see!
Having fixed my counter and let the Thunderbolt Trimble GPSDO work its way up in accuracy for a week (now 5.2805e-13) I’m able to correct for 35 years of aging on the HP 10544A oscillator in my HP 5335A, albeit I have no idea how long since it was last calibrated.
The HP 10544A has the following specifications:
<5 x 10e-10/day after 24-hour warm-up. (2)
<1.5 x 10e-7/year.
SHORT TERM STABILITY:
1 x 10e-11/1 s Avg. time.
1 x 10e-11/10 s Avg. time.
2 x 10e-11/100 s Avg. time.
Which makes this an excellent oscillator, regardless the oscillator had drifted by 40 microseconds @ 10MHz so needed a slight speed up due to aging. To say the adjustment was… fiddly… is an understatement.
This is of course measured using the longest gate time on the counter, approximately 10 seconds. I have ordered a GPIB adapter so I can run TimeLab to validate all the oscillators I have picked up, but that will be a different post. I’ll fire up the rubidium I picked up a couple of weeks ago this week and see how that one compares.
The really nice part of the oscillator in this counter is that I can happily use it as a basic transfer standard for lower resolution oscillators, providing I check the calibration periodically and keep track of what I’ve used it for just in case an adjustment is necessary.
Another one from the Department of Yak Shaving…
The HP 5335A I bought a month or so back failed on me today in the middle of testing the time difference between two 10MHz oscillators, the reason I bought the meter. For a piece of 80’s era kit these are a nice meter and can be found cheaply enough, but they are not without issues given the age.
My first thought when presented the ‘Fail 5.1’ message was literally ‘Oh <omitted>’. That can’t be good, and a quick google turned up a post talking about that error and ‘unobtainium’ components.
I assumed the worst.
A day later armed with a copy of the service guide I started to follow the diagnostics process. Not having read the ‘Entire’ process I found the 10MHz signal wasn’t available where it should be.
I then found that the OCXO (10544A) had been previously dismantled for whatever reason which then lead me to suspect an issue with the oscillator and I happily proceeded down that path, still assuming the worst.
I did try an external oscillator and found no difference in the error, that _should_ have jogged me to reconsider the problem.
Today I decided to go back to basics, especially since fault finding in old equipment is _not_ one of my strong points. So, step 1 – check the power supplies.
5v -- OK 10v -- OK 15v -- OK 3v -- OK -15v -- +0.7v -5v -- + 0.6v
Ah Ha – not so good on the -ve voltage rails.
A check of the schematic and the -5v rail is driven from the -15v rail so I may be on to something here.
Also checking the board its fairly obvious that several of the regulators have previously been replaced, although the -15v (HP 1826-0214 – aka MC7915CT) is original and is simply a 7915 regulator. Checking the board shows the supply voltage to be correct, so the regulator is probably stuffskies.
The chip used to automatically switch between the internal and external oscillators (HP 1820-0802 – MC10102 – Quad NOR 2 Input) uses the -5 volt line to do it’s thing. No power, no oscillator output, no Interpolator, or so the current theory goes.
Fortunately the 5915 is a common part available almost anywhere, there’s a jaycar less than 1km from home which should have them in stock which is handy.
While peering over the board I note a number of ‘changes’ that have been made
and the relay socket appears to have been swapped out. I have seen a reference to ‘fixing’ a known issue due to the current draw of the fan damaging the relay (which _is_ unobtainium) and the relay socket. It looks like this mod has been performed.
The plastic retaining clips for the base of the oscillator had been severely damaged resulting in the oscillator moving around when it shouldn’t. An inspection didn’t show any issues, so I’ve now secured this with suitable screws that fill the original ‘slot’.
There was a secondary fault, namely the 15uF tant across the -15v supply had shorted loading the rail down, and is possibly the cause of the failed regulator as well.
I’ve temporarily removed this capacitor and all voltages reset to where they should be. I reconnected all the boards, powered up, and the meter immediately passed all diagnostics and went into operational mode, no more ‘Fail 5.1’ error to be seen.
So meter Saved!
I’ve learned a few things on this job as fault finding has never been a strong point, its all too easy to get overwhelmed when staring at a foreign PCB.
Lesson 1: If you don’t have the service guide, your probably guessing.
Lesson 2: If your guessing, your probably not going to find the fault.
Lesson 3: If you do have the service guide… follow it…
As part of the GPSDO project I’ve been working on using a graphical display I picked up from Futurlec several years ago, a 128×64 Blue GLCD (CM12864-2) which uses the KS0108 chipset.
As I want to drive this from a Beaglebone Black I’ve opted to use a GLCD Backpack from Sparkfun to simplify the hookup and interfacing, sending serial commands should be far easier than sorting though GPIO… at least it _should_ have been.
The first issue is the backpack pinouts don’t match the pin layout on the LCD I have, so I’ll have to make up an adapter board. Some breadboard does the job while developing so not a huge issue there.
The standard firmware comes with a number of simple operations for displaying text and some basic geometry operations, functional but nothing flash.
Unfortunately I found the standard firmware to be a little slow on the refresh rate and came with two standard fonts, big and bigger.
A little research found an updated set of firmware listed at the bottom of the page.
I modified this to include a small 3*5 font reminiscent of 80’s era computer games in place of the standard ‘large’ font, and quickly put together a nice summary page for the state of the GPSDO.
There are some minor dislikes for the font, for example the ‘H’ and ‘N’ characters are identical, but it works well enough that I may live with it.
The software was written in perl and may be shared later, its all very straight forward decoding of the GPS messages and sending serial data to the display so nothing complex in there. I have included a ‘deltacache’ which detects data changes so only updates are posted to the LCD to conserve the limited serial bandwidth and avoid buffer overflows as I don’t have any flow control at this stage as the ‘TX’ pin isn’t connected to the BBB to avoid damaging the 3v IO pin.
All in all I’m happy with the results so far. I still have a lot of work to do but this is a promising result.
Now that I have confirmed the Thunderbolt Trimble is working nicely down to 3.5ppt (3.5E-10) and getting more accurate as time goes on its time to put it in a box so its more durable and generally more usable. My plan is to add a Beaglebone Black, LCD and Keypad for display and control of the system alongside network.
* LCD to display the lock status, accuracy and any alarm conditions.
* Keypad for local interaction with the system.
* NTP server based off the GPS and PPS feed.
* Network support for NMEA and TSIP data from the GPS module.
* Multiple filtered and amplified 10MHz outputs to feed test equipment and VFO’s.
The best part is most of it is based on kit I already have in the junk box.
On the software level a number of existing open source projects will be used to build system:
The main components being:
* GPSD will listen to the serial connection and receive the data from the GPS module, this daemon will be configured to start receiving the data immediately rather than waiting for a client connection so it can feed the NTP server.
This is a nice tool for working with the GPS with _almost_ no configuration required to get it working, it also nice to be able to feed the data from a single GPS to multiple targets without having to code around it.
* NTPD will listen to the GPS and PPS data via shared memory alongside several external ntp servers to establish the base time. This time will be available to external systems, when tuned it should be reasonably accurate. A minor modification to the Beaglebone will be required to significantly increase the accuracy of this service.
This is a fairly standard protocol. Chrony may be used instead given its more suitable for a low power system, time will tell.
* An embedded network client will most likely be built to feed the NMEA data into my IC-7100 transceiver for an accurate position fix. I have the data, so why not 😉
* A GPSD monitor will be developed to process the TSIP data for analysis (ADEV) and reporting on the attached LCD and via a web interface. The TSIP data has to be processed as the NMEA and JSON feeds produced by GPSD don’t include the additional metrics and alarms states sent from the GPS unit.
* All performance data will be stored in a Round Robin Data Base for reporting over time. This is important in understanding the long term performance of the GPSDO.
* LCDProc will be run to control the graphical LCD, displaying system, performance, and GPS status information. An attached keypad will be processed by LIRC and used to switch displays and perform configuration options without requiring an external PC. (i.e. Run Self Survey).
* GPSCTL is part of the GPSD package and will be used to send commands to the GPS unit for any configuration changes to the applied.
* And finally, a NODE.js interface will be coded to make the whole lot available via a web interface, simply because its time I learnt node…
There’s a lot in this little project, I’m really enjoying it so far.
The Thunderbolt Trimble arrived during the week, and after 48 hours for the self survey and to calibrate the internal PID loops its delivering a nice level of performance, the only disagreement with my HP 5335 Counter is down in the 10E-15 territory which is outside the resolution of this GPSDO.
The entire ensemble is, however, untidy. The GPS unit itself is in a small metal box, I have an external laptop power supply to provide the required voltage levels, serial connections, antenna connection, and then the outputs… untidy. It gets worse when I run a serial cable to monitor it via Lady Heather or similar.
I want to be able to leave this system running all the time, so it needs to go in a box and include its own monitoring. I also don’t want to spend a fortune here but I also wanted rack mount, and sometimes things just work out with a 2RU rackmount PLA project box at the local Jaycar for $20 😉
The internals for the box are mostly coming out of my ‘junk’ box, bits and peices I’ve collected over the years, including:
* Beaglebone Black
This board will be used to ‘monitor’ the GPS unit and provide network connectivity for ntp etc. This board will also run the display, keypad, etc so I can monitor the system without using an external PC.
* USB to Serial converter.
An old prolific (PL2303) USB<->Serial converter will be used, while strictly not necessary it removes the need for level conversions here and the BBB has a usb port readily available.
* CM12864-2 128×64 White on Blue Graphical LCD bought for a project several years ago and never used. This will make a nice display for this project.
* 16 character keypad picked up at a field day somewhere. I don’t _need_ 16 keys, but it looks ok and will support any additional functionlity I may add later. Its been sitting in a drawer for years so the price is right 😉
*Amphenol case mount BNC connectors, I picked up a box of ~20 of these for $2 at a field day recently.
* level converters should these be necessary, I suspect they won’t be needed.
I have ordered on additional item:
Sparkfun Graph LCD serial backpack for the display, simply because this will be more convenient wiring the display up to the BBB.
The next steps:
* Code up a parser for the messaging coming from the GPS.
* Wire up the keypad and code up a driver using GPIO pins.
* Wire up the display and see if I can find a driver somewhere, I suspect I can.
* Code away.
all up the boxing project will cost approximately $50 out of pocket given I already have all the key components, and $30 of that is the backpack for the LCD panel to save some time.
The Thunderbolt Trimble GPSDO I ordered finally arrived, after all you can’t possibly have _too_ many time sources. Of course the first thing I did was set it up, run the position survey and plug it into my HP 5335 Universal Counter which was recently calibrated to a rubidium standard.
Lo and behold after warming up the counter read:
9.999 999 71 +6 (i.e. 9.999 999 71 * 10E6)
Ok, the trimble will take a while to run the Allan Deviation, I’ll leave it go and come back later. 24 hours later I read:
9.999 999 71 +6
No change, so what’s going on here as I expected exactly (or close to) 10 MHz and I’m reasonably sure the HP Counter is accurate.
I switch to Period mode:
100.000 002 9 -9 (i.e. 100.0000029 *10E-9
Which matches the observed frequency, at 10MHz the period should be exactly 100 nanoseconds… what’s going on here, lots of fiddling and trying to work out why it wasn’t right, is my counter wrong or there a problem with the Trimble…
What I didn’t facter in is that the ‘002 9’ is in fact ‘2.9 Femtoseconds’ or 2.9*10E-15, the rated accuracy of the GPSDO is 1.16*10E-12.
Aka… timing resolution achieved, and I can forgive the 2.9 femto seconds in either the counter or gpsdo. In other words, its reasonably accurate as is my counter, and that’s probably as accurate as I’m likely to have… at least until I get my hands on a cesium standard 😉
I spent a little time on my GPSDO project today, going back to basics after the previous board failed with multiple errors on my part. Lets simply say it was a learning experience 😉
At this stage I’m trying to get a lock between my:
+Navman Jupiter Tu60
The navman is mounted on a quick custom PCB and for the purpose of this testing powered via a USB-TTL Serial cable. The GPS has run for several hours to establish a reliable position and is currently reporting 37ns (3*10-7) accuracy which is within spec of +-40ns of UTC.
This specific crystal was manufactured in 2007, so we’re potentially looking at +-300ppb aging (3*10-6) error on the output frequency.
The objective of this little project is to use the accurate 10Khz output from the GPS module to ‘lock’ the crystal as closely to the GPS reference as possible by setting the voltage on the OCXO’s VCO input which adjusts the oscillator frequency by up to 0.9ppm (9*10-6).
I’ve made a simple PLL to facilitate this lock, this includes:
* A divide by 10 network to produce a 10Khz output from the 10MHz crystal frequency.
* A simple phase detector using an ‘XOR’ gate, the 10Khz signal from the crystal/divider and the 10Khz reference from the GPS module.
The theory is the XOR will charge a capacitor when the two signals are out of phase, the voltage on this capacitor being sent to the ‘VCO’ adjustment pin on the OCXO.
When the two signals are the ‘right’ amount out of phase we should see a stable voltage on the VCO pin and a stable phase offset between the two reference signals. Ideally this should occur somewhere around 90 degrees phase offset, some experimentation will be needed to set the voltage range up correctly for this.
At this stage I do have a reference lock at:
Reference voltage: 3.87v (adjustment range 3.2v to 4.8v)
Phase offset: 115.2 degrees (32 microseconds)
Hopefully I’ll pick up a ‘working’ HP 5335 timer/counter so i can verify the accuracy of the lock. Eventually I’ll need to compare this to a rubidium standard or similar.
I just picked up a recently calibrated HP 5335 and ran some simple comparisons using the HP5335 as a known good reference clock.
The undisciplined oscillator clocks in at 9,999,998.66Hz (2.4Hz off).
The gps disciplined oscillator clocks in at 9,999,999.99Hz (+-0.03hz off).
So the GPS Disclipline has provided a significant improvement in the resolution of the oscillator, down to approximately 100 nanoseconds which is the limit of the simple measures I can do at this time.
The GPS is rated at 40 nanoseconds from UTC, and the oscillator is rated at 20ppb (20 nanoseconds) so I’m getting close to what can be achieved here.
This is without fine tuning the time function setting the vco adjustment on the oscillator.
My home lab just got a massive upgrade with the addition of two HP Classic’s. I’ve just stacked the lot to see how it all compares, now down to ~2Hz at 10Mhz and still warming up so I’m happy to say its all calibrated nicely. I’ll have a GPSDO up and running in a few days so I’ll be able to say for sure.
At this stage I’m starting to work with Microwave frequencies so accurate time sources are critical and become more so as you move up the band.
The stack now includes:
* Stanford Research DS345 30Mhz syntesized function generator, acquired from Grays Online. This features an OXCO and a current calibration certificate 😉
* HP 5384A Counter, nice, compact, convenient. Acquired from Ebay, uses a Crystal oscillator but recently calibrated against a rubidium source.
* HP 5335A Univeral counter acquired from a deceased estate which adds some nice timing functionality up to 200Mhz.
* HP 5350B microwave frequency counter which covers up to 20GHz acquired today in a private sale which should help me move up the bands.
On the down side the HP335A just went clunk and the display went out… Hopefuly it isn’t much as I really wanted the timing functionality of this unit
The new motor mount is partially done. I found the existing motor lacked the power necessary to work on Delrin, with the bit bogging down and doing a really crap job even with very light passes.
As a consequence I spent a little time at the Sydney Hackerspace today seeing how the 3040 CNC coped, and it coped and it did a nice job with a 1mm cut depth and 300mm/min feed rate.
Here’s the first part of the mount on the Roland MDX-20 with the bearing mount attached. the bracket is cut from 13mm black Delrin which should support the motor and spindle mount nicely.
It is nice when you design a part and it works out perfectly, first time… if we don’t count the wax prototype that is 😉
IMHO this is an improvement over the original spindle mount which only used 2 mounting screws asthis mount uses all the available threaded holes on the Z axis for better support and alignment of the spindle.
Unfortunately I ran out of time so didn’t finish the actual motor mount, I may have time during the week so I can progress this project closer to completion.