Precision pendulum techniques

Select the correct port, and baudrate ( usually 90600) ( 2nd line from top. left of screen).

The select VIEW, then CONFIGURATION VIEW, the scroll down on the left to TP or TP2 to set up the Frequency on the pps pin. Then lower left of that screen, make sure the yellow lock is unlocked, and click on SEND...

u-center is the easiest way of I've found so far. There's also ubxtool on Linux which works with the gpsd daemon.

NMEA output is in ASCII and can be read with a terminal emulator. However, UBX, used to send and read configuration data, is binary. It needs a program like u-center to encode and decode it, not a terminal emulator.

I'm writing a program to simply send change frequency commands and have hit a problem. It's that I can't get the UBX-CFG-TP5 specification on page 272 of the "u-blox 8 / u-blox M8 Receiver description including protocol specification" to exactly match the hex dump from u-center. I think the spec says rfGroupDelay is a 2 byte integer when it's actually a 4 byte integer. Or I'm reading it wrong! Any experience of this Joe?

When I get it right, sending the magic hex incantation:

B5 62 06 31 20 00 00 01 00 00 32 00 00 00 80 96 98 00 80 96 98 00 00 00 00 80 00 00 00 80 00 00 00 00 6F 00 00 00 55 7A

to the chip should set the M8Q to 10MHz with a 50% duty cycle. 10000000 is the little-endian sequence 0x00, 0x80, 0x96, 0x98

Dave

Sorry Dave - I have never needed to program the PPS output on the fly - always set it to a single value as per application needs. I have also for this only used GPS types with FLASH, so it was easier to just use Ucenter and program the flash so it remained fixed on power on.

I've now got my M8 running and linked to u-centre. I'm going to try manually setting my OCXO using the picPET to start with.

Do you have a dual trace scope John? - A quicky is to set the GPS to 1MHz, trigger the scope on that, and feed the OCXO 10MHz into the other channel - adjust the OCXO so the trace stays put..

Well I got the unit connected to the picPET and a bit of Pi code written to acquire some numbers, "measuring" the 1pps period. Good news, to 7 places of decimals it's 0.9999999s +/1 a bit. Bad news 1: hardly any perceptible change with the pot setting! Bad news 2: the GPS is very flaky, regularly losing lock. I get a decent position using "GPS Monitor" on my phone inside just next to the equipment, but I have the GPS antenna on the end of a piece of 3m cable on the windowsill / on top of the green wheely-bin outside the window. The antenna nominally has 30 dB gain, I think it's going back to Amazon!

I've found the M8Q works better than my Adafruit Ultimate GPS, probably because the M8Q picks up GLONASS (Russian) satellites as well as GPS(USA).

Even with an active antenna the Adafruit is fussy about location. Inside the house and looking out a North facing window are both unsatisfactory. Looking out my south facing dining room it works with occasional drop-outs. West facing upstairs windowsill it seems to work 100%.

I also had trouble with the pot setting and wish I'd bought a multi-turn one rather than using a cheapo trimmer. The trimmer turns in jumps and starts, and is pressure sensitive. I can get the 10MHz waveform stable by carefully turning it with an oscilloscope compensation screwdriver, but frequency slides as soon as I let go.

My 40+ year old Racal 7-digit counter only measures in microseconds. It counts 1000000 OCXO pulses in 1 GPS second, but the last digit jitters a little.

Haven't tried PET yet. The plan is to set the M8Q PPS to 0.25Hz (by setting period to 4000000uS), and see what ardPET makes of a 5MHz input. (I've wired my OCXO to a 7490 divide by 2 chip). I'll also try modifying ardPET to count more input pulses by extending the timing period to 'n' GPS pulses.

Meanwhile I've nearly cracked how to change ublox TP frequency with a Python program. The bUblox TP5 spec isn't wrong as I suspected, I misread it! The mismatch was because message length is sent as a 16 bit integer, not 8 bit as I'd assumed.

Code not quite working yet because I assumed duty cycle was sent as an integer, and it's not. 50.0% encodes to 0x80 (128), and 60% to 0x9a999999. I suspect the duty ratio is sent as a single precision float.

Dave

I've completed a Python Program that sets the Ublox M8Q GPS time pulse to any frequency between 1 and 24000000. (24MHz is the upper limit of my GPS)

Needs python3 and the struct and serial modules

By default the program runs on Linux and expects the serial device to be on /dev/ttyUSB0 which is where the M8Q usually appears on my system. This may vary depending on the distribution and what else is plugged in to USB. Not tested, but the code should run on Windows where the serial device will appear in the COM1, 2, 3 series. The device can be edited at the top of the program.

Code available on dropbox here.

Dave

Apologies if this has been linked already: **LINK**

https://hgss.copernicus.org/articles/11/215/2020/hgss-11-215-2020.pdf

Time and tide: pendulum clocks and gravity tides __ Duncan C. Agnew

It’s interesting, recent, and includes a goodly list of references.

MichaelG.

Thanks for the code Dave, I'll give it a try when I get my antenna!

Thanks to a posting on the Time Nuts list I found this u-blox application note:

**LINK**

Though written around the Lea 6 devices it is probably applicable to the M8 as well.

I came across William Scolnik's website, describing his impressive clock. Briefly:

Quartz Bob and Rod, Hall Effect detection, Hall Sensor position temperature compensated, Knife Edge suspension, electromagnetic impulse with precision power supply, electromechanical logic, and a vacuum tank:

Always fun to see the problems other run into! The vacuum tank is purpose made Pyrex with all the right seals, and it couldn't maintain a vacuum. Not because the tank or the seals were leaking: it was suffering from what the expert called a 'virtual leak', caused by the Pyrex and the rest of the clock degassing into a hard vacuum. To degas the whole, it was necessary to pump the vacuum for two days whilst heating the entire assemby to 120 degrees.

Doesn't bode well for my vacuum tank, which is a length of PVC drainpipe...

Dave

But I guess you are not aiming for anything like a high vacuum which would require something a lot better than general mechanical roughing pumps. I don’t suppose you are planning to buy a turbo pump. Do you have any details of the vacuum system and their target pressure. I can’t actually see any connections to a pump in the picture and I’m assuming the system is not intended for continuous pumping. I suspect their initial problem was getting rid of the water. I’m not a vacuum engineer but we have built a number of high and ultra high vacuum systems in the Lab for me to have picked up a little. We certainly from the electronics end of things have to be very careful of any materials we choose to introduce including cable  insulation.

Regards Martin

Edited By Martin Kyte on 22/02/2023 09:47:04

Edited By Martin Kyte on 22/02/2023 09:48:11

That is certainly an impressive clock. However I'm surprised he's operating it at such a hard vacuum although this may have only been during degassing. Water vapour and other organic materials are a major issue hence the need to bake.

To get really hard vacuum you would need several pumping devices starting with a dry claw pump, backing a turbo pump with a cold trap using liquid nitrogen and an ion pump to get rid of the last few molecules. I don't know what the vacuum requirements are for the latest 3nm semi-conductors but I'm sure they will be expensive.

Many plastics are a no no in high vacuum because of outgassing and that includes PVC covered wiring.

You may be able to buy stock Pyrex tube from a scientific glassware manufacturer. There is one near me in Hastings that I visited where they had a lathe for making large bell jars and other vessels. An impressive manufacturing process to see.

CS

That would look nice on the mantlepiece!

I think it fair to say that Mr Scolink’s collection is exceptional

**LINK** http://www.precisionclocks.com

MichaelG.

.

Direct links here: 

https://clockdoc.org/gs/handler/getmedia.ashx?moid=57449&dt=3&g=1

http://www.jacquetboxers.com/collection/scolnik_collection_part2.pdf

Edited By Michael Gilligan on 22/02/2023 10:16:36

Apparently Pierre Boucheron found Shortt SH41 in the clock vault at NIST with its vacuum "intact" after some decades and was able to use it for his measurements that showed it was sensitive to earth tides. Shortts weren't pumped down very hard, only to a few mm I think.

Although my clock is intended to run in a vacuum the pendulum has always been too buggy to be worth trying. I don't know how hard the vacuum will be. I have an ancient Edwards EB3A which we discussed in 2020, where Robert, G8RPI said the 'Specification seems to be 26" Hg / 133mB'. Whether it gets anywhere near that low remains to be seen!

Dave

Related to precision pendulums is the need for an accurate way of measuring them, ideally in both the short and long term; nanoseconds to years. Nanosecond measurements call for a stable accurate electronic oscillator, and vibrating a quartz crystal inside a thermostatically controlled oven heated somewhere between 40 and 80°C does a good job. Quite expensive, but available second-hand thanks to the mobile phone base stations, each of which requires an accurate time source, and are regularly upgraded.

John Haine kindly pointed me at an example, not the best OCXO in the world but 20x better than anything else I own. So yes please. After a misadventure in which I destroyed a chip by wiring it mirror-image, I made one that worked.

The OCXO outputs a 10MHz signal, and for nefarious purposes I also need a 5MHz output. Easily done with a divider IC (if you wire it up the right way round). So far so good, but getting the best out of an OCXO requires it to be trimmed accurately to 10.000000 MHz. This is done by tweaking a pot, and turned out to be harder than expected, which I blamed on using an e-cheapo trimmer pot. Duncan Webster supplied a far better multi-turn pot, which is really too good to waste on this, and is a difficult tight fit in the box:

However, before fitting the new pot, I decided to measure the number of pulses output by the OCXO in 10 GPS seconds by counting them with an Arduino. 10MHz is too fast for an Arduino, but it happily counts at 5MHz. The result was unexpected: the highest count I got out of the OCXO divided down to 5MHz is 4999991211 (4.999991211MHz, which is apparently 8.78Hz below target.) The count is stable.

Now I'm in a quandary: is the OCXO really wrong, or is there a problem with the Arduino and GPS? I trust the GPS, but maybe the Arduino's hardware counter consistently misses a few pulses, or I've programmed it wrong. How to prove it one way or another! There are a few things to try:

• I can tell the GPS to output 4 second pulses,
• I have a second OCXO. If it's also low, it suggests an Arduino problem, and up until today I've believed in it.
• I can measure the OCXO with a picPET, to see if that makes a difference
• I can compare the OCXO with the WWV time signal on 10MHz. Wasted a lot of time trying yesterday, and I'm not sure my equipment (a kiwiSDR) is good enough to detect an 8Hz difference, without involving a separate FFT analysis

In other words, another simple problem has turned out to be a first class time-waster!

Dave

I suspect that Joe Noci might give us all a brief MasterClass sometime soon, Dave

Meanwhile, it seems to me that the most accurate thing you have available is the GPS … and the ability to divide its output by integer values.

MichaelG.