bg7tbl gpsdo master reference

[Dwaine]

You have a 50 ohm input on the scope?  It could be just that the high impedance and the cable inductance is making it overshoot a bit.

Yep....   I throw my 50ohm on it and do another screenshot.  Thanks for jogging my memory.   The Star-4 with the ubox LEA-5T and OSCILLOQUARTZ 8663 double oven is a great unit. Winner Winner chicken dinner.

[DaJMasta]

Yep....   I throw my 50ohm on it and do another screenshot.  Thanks for jogging my memory.   The Star-4 with the ubox LEA-5T and OSCILLOQUARTZ 8663 double oven is a great unit. Winner Winner chicken dinner.

No problem, I think there's a post of mine in this thread when I first got it with the same issue 

[Dwaine]

I wonder if I can upgrade the inbox GPS from a ubox LEA-5T to the LEA-8MT.  The datasheet says it's backwards compatible.  It would be a nice upgrade.

[Fennec]

I wonder if I can upgrade the inbox GPS from a ubox LEA-5T to the LEA-8MT.  The datasheet says it's backwards compatible.  It would be a nice upgrade.

Yes you can, but you have to config the new Module and upgrade the Antenna.

[Dwaine]

I wonder if I can upgrade the inbox GPS from a ubox LEA-5T to the LEA-8MT.  The datasheet says it's backwards compatible.  It would be a nice upgrade.

Yes you can, but you have to config the new Module and upgrade the Antenna.

Ok..  It's not worth the trouble then.

[DaJMasta]

A raw M8T module is also like 1/2 of the price of the GPSDO - currently the cheaper M8T is $89 in single quantities...


To my knowledge, the M8T's timing specification is no better than the 6T, not sure how that compares to the 5T, but there was no 7T and the current generation BG7TBL gpsdos seem to use the M7 series modules, which are not specifically designed for timing.

[Dwaine]

I finally added a top BNC connector to the STAR-4 for the 10mhz square wave output.   I terminated into 50 ohms.  Here is the screenshot.  Better looking.

[DaJMasta]

A little update on mine:

I've upgraded time references to a custom job based on an SRS PRS10 rubidium module and a Trimble Resolution SMT GPS receiver, so I figured I would try to properly measure the BG7TBL GPSDO that I've got, and the preliminary results (only 1.5 days of warm up/stabilization on the rubidium) are quite a bit better than the ones I made with high stability internal oscillators in instruments before.  So without further ado...
Using the BG7TBL GPSDO 2016-05-31 which uses the Ublox Neo M7 GPS module and a Bliley OCXO, about 40k seconds worth of recording, 1 second gate time, 100ps resolution counter



The rubidium oscillator should be at least an order of magnitude better in terms of stability, and the timing rating on the Resolution SMT is roughly 4-5x better than the Neo M8's, so the reference primarily in the noise of the measurement, though I will repeat the test with a full week of stabilization to be sure.

You still see a little of the coarse adjustment step behavior, but they happen much less frequently - don't know if this is antenna position related or just that it's been on for a long time (the BG7TBL has been on for weeks), but it's not jumping around like I had measured earlier, just infrequent adjustments to stay where it should be.  Looks like performance is pretty solid, and the minimum adjustment steps running into the VCO are about 1.5mHz in width.  There have been some ambient temperature swings over the duration of the test, but I don't see a huge correlation - I think most of the smaller curves are the heating cycle of the oven or something, hard to say because while you get NEMA output, you don't get much info on what the CPLD is doing.

[texaspyro]

Try the Venus timing receiver (available from Navspark and (for quite a bit less) Nick Sayer on Tindie).  They are quite a bit better than the Res-T (about 1/3 the sawtooth error in the 1PPS).

Also, rubidiums are generally more stable than OCXOs,  they tend to be quite a bit more noisy.  In a GPSDO you are usually better off with an OCXO.  The GPS will keep it on freq so the low drift of a rubidium doesn't bring much to the table except for better holdover if you lose GPS (which for a modern GPS receiver takes a REALLY crappy antenna setup).

And remember Mark's Rule of Rubidiums... the smaller they are, the crappier they are.  The UCT-8663 DOCXO (at the time, 10 for $100) that I put in my HP-53132A counter is around twice as good as my Symmetricom X72's (both drift and particularly noise wise). 

[DaJMasta]

Well at least in the case of the PRS10, the module is a rubidium disciplined OCXO with a self contained pps disciplining circuit, so it was really easy to build into something and should do a good job of things (and the spec sheet confirms that).

Hadn't heard of the Venus, though, I'd be interested in getting my hands on one at some point.  I've got a few GPS receivers with a PPS output and once the Rb reference is fully stabilized, I want to try to measure their jitter - datasheets seem to be pretty inconsistent in methods of reporting it if they mention it at all.  I think the Neo M7 is something like +-80ns, but the Resolution SMT is 15ns RMS (no peak numbers), and the Neo 8T is +-20ns, same as the LEA 6T.  Got a few to play around with, but seeing if I can pick up a jupiter 31 or a LEA 5T to toss into the testing mix, since they seem to be fairly commonly available.

[texaspyro]

seeing if I can pick up a jupiter 31 or a LEA 5T to toss into the testing mix, since they seem to be fairly commonly available.

My Venus receivers report a sawtooth error of +/- 6.1 ns.

I'm currently using a LEA 5T (with an indoor antenna) to test some new code in Lady Heather that disciplines a Symmetricom X72/X99/SA22.c    I'm using an indoor antenna to help get a noisy 1PPS.  The LEA 5T board has two outputs programmed for 1PPS.   One is quite a bit noisier than the other.   I'm seeing typical 1PPS jitter of around +/- 16-67 ns (the Symmetricom time interval counter has a resolution of 16.667 ns).

[texaspyro]

I connected a Tbolt to the 1PPS input of a Symmetricom SA22.c rubidium oscillator and ran Heather's software discipling code on it.   For some strange reason, you do get  better performance using a clean 1PPS rather than the crappiest one you can find ;-)

Anyway some interesting results came out.  White traces are the DDS frequency offset Heather is using to steer the SA22.c output freq,  yellow are temperature, magenta is the difference between the 1PPS in and 1PPS out (16.666 ns res of the SA22.c TIC).   The TIC reading is used to steer the rubidium's DDS output frequency.

The straight white and yellow traces are linear regression trend lines of those parameters.   A little math shows a clear dependence of the SA22 output freq on temperature of around 2.664E-11 parts per degree C. 

[DaJMasta]

Still a day off of full stabilization of the Rb reference and a good measurement, but I found something interesting.  I had been letting the counter go during the day to try to get a sense of how the Rb stabilized over time, and I realized yesterday that I was getting a pretty good correlation with changes of temperature in the room, so after some consideration, I put the BG7TBL module in a fancy thermal isolation chamber (soft sided lunchbox) to isolate it somewhat from the thermal changes of the room.  It improves stability a lot!  You still get the digital adjustments of frequency, but it improves the variation in between those steps by quite a bit, easily 2-4x.  Since the chassis is just aluminum and it's only a single oven, a temperature change in the room or moving air near it does make the frequency drift - it will still be close, but extra insulation dramatically reduces that drift.

Also interesting, picking up the reference and putting it in a soft sided lunchbox (and changing its orientation somewhat) makes a pretty big shift in frequency because of physical orientation, like as much as one Hertz difference, and it takes some hours for the reference to settle down and reconfigure itself.  I started seeing a good flat response (like pictured) around 12 hours after it spent a few minutes at an angle and then was moved to be level again.

I've also noticed that at least relative to the rubidium source, the BG7TBL is consistently just a tiny bit fast.  Typically around 1.5-1.8 millihertz, but it's rare to see the long term average (looking at about 12-16h blocks of data) much lower than that and in 6 days of measuring, I haven't seen it low.

[edpalmer42]

Still a day off of full stabilization of the Rb reference and a good measurement, but I found something interesting.  I had been letting the counter go during the day to try to get a sense of how the Rb stabilized over time, and I realized yesterday that I was getting a pretty good correlation with changes of temperature in the room, so after some consideration, I put the BG7TBL module in a fancy thermal isolation chamber (soft sided lunchbox) to isolate it somewhat from the thermal changes of the room.  It improves stability a lot!  You still get the digital adjustments of frequency, but it improves the variation in between those steps by quite a bit, easily 2-4x.  Since the chassis is just aluminum and it's only a single oven, a temperature change in the room or moving air near it does make the frequency drift - it will still be close, but extra insulation dramatically reduces that drift.

I've heard people say that a cardboard box is useful to isolate a unit from drafts and other thermal effects.  Other than that, you're looking at something like active temperature control or using lots of mass to provide thermal 'inertia'.

Also interesting, picking up the reference and putting it in a soft sided lunchbox (and changing its orientation somewhat) makes a pretty big shift in frequency because of physical orientation, like as much as one Hertz difference, and it takes some hours for the reference to settle down and reconfigure itself.  I started seeing a good flat response (like pictured) around 12 hours after it spent a few minutes at an angle and then was moved to be level again.

Are you talking about tilting the GPSDO or turning it left or right?  If tilting, OCXOs are sensitive to gravity.  Dave did a video on it a while back.  Turning a GPSDO left or right shouldn't have an effect, but it might make a difference to a Rb standard since it uses magnetism to set the frequency.  The case is usually made of Mu metal to reduce the effect.

I've also noticed that at least relative to the rubidium source, the BG7TBL is consistently just a tiny bit fast.  Typically around 1.5-1.8 millihertz, but it's rare to see the long term average (looking at about 12-16h blocks of data) much lower than that and in 6 days of measuring, I haven't seen it low.

Not good.  That's always been the problem with the BG7TBL units that he built from scratch.  I thought he'd fixed that.  Can you test it against another GPSDO?  Ideally, measure the time interval between the two PPS signals and capture the data on a computer using something like Timelab.  If there's any consistent drift over a period of a day or two, your unit has the problem.  Keep in mind that 'problem' is a relative term.  The frequency difference is negligible for anyone other than a Time Nut!

Ed

[DaJMasta]

The Rb source being measured is my other GPSDO and it's almost to a week's worth of settling time, I expect to be doing a little analysis of PPS timings though, as the datasheets even for timing receivers don't seem to give a lot of detail in terms of what your actually going to see in terms of PPS timing jitter.  I've got this ublox M7, the Resolution SMT in the Rb GPSDO, then a ublox M8T, a ublox 6M, and I'm trying to get a hold of another one or two to test (maybe Motorola M12/M12+, Jupiter 31, or ublox 5T?) just to get a sort of apples-to-apples test of the PPS accuracy instead of trying to compare +-XXns to XXns RMS and whatnot.

Yes it was tilting it up to get it into the lunchbox while still powered up... I just hadn't realized what was going on until after a few minutes of gawking at the spike, neat to see the physical nature of the oscillation in action, though.

As for the measurement, I don't have a TimePod, so the most accurate timing info I can get is with my PM6690, and I don't know if that will interface with TimeLab.  The intention was to use the Rb GPSDO as the reference clock and then measure interval lengths, but with two inputs I can measure time difference between two PPS pulses against each other too.  When I get some fully stabilized data for this I'll post previous day's plots and statistics, I've been capturing data pretty much all this week using the Rb GPSDO as the frequency reference and the BG7TBL as the input and the 1.5ish microhertz has been consistent over long intervals (I'm getting 40-50k seconds per measurement, generally).

[edpalmer42]

Here are some measurements I've made on various GPS receivers and GPSDOs.

Code: [Select]

GPS Devices -- Measure & analyze the period of the 1 PPS Output

Device ............... Std Dev (ns).... Range (max-min)(ns) ... Device ...... Notes

Navsync CW12 ......... 4 - 5 .......... 20 - 25 ............... GPS Rcvr .... 1,7
Motorola UT+ ......... 40 - 55 ........ 95 - 110 .............. GPS Rcvr .... 2,7
Rockwell Jupiter ..... 10 ............  50 ...................  GPS Rcvr .... 3,7
Motorola M12M ........ 10 - 15 ........ 40 - 60 ............... GPS Rcvr .... 7

Trimble Thunderbolt .. 0.4 - 0.5 ...... 2 - 4 ................. GPSDO ....... 6,8
HP Z3801A ............ 0.1 - 0.2 ...... < 1 ................... GPSDO ....... 6
HP Z3817A / CW12 ..... < 0.1 .......... < 1 ................... GPSDO ....... 4,6
Jackson Labs GPSTCXO . 0.3 - 0.4 ...... 2 - 3 ................. GPSDO ....... 6
NEC NWM-034241-201 ... 0.1 - 0.2 ...... < 2 ................... GPSDO ....... 5
Trimble UCCM ......... 0.09 - 0.11 .... < 1 ................... GPSDO ....... 5

Results are based on multiple runs of ~ 1000 measurements each.
Sawtooth correction has not been used for any of the GPS receivers.  Where supported, it would reduce the numbers substantially.
All units were connected to the same antenna system.

Notes

1.  Sawtooth correction not supported.
2.  Most 'range' results were in this group, but there were a few at 20 - 30.
3.  Only one test.
4.  Requires external 1 PPS input.  Equipped with E1938 oscillator.
5.  Measurement made with Fluke PM6681.
6.  Measurement made with HP 5370B.
7.  Measurement made with HP 5372A.
8.  Standard parameters.
9.  Optimized parameters. (Not yet used in any tests)
Normally, Std. Dev. shouldn't be used with quartz oscillators because frequency drift messes up the calculations.  However, in a GPSDO there is no drift so, AFAIK, it's okay.

If Timelab supports your counter, you should be able to duplicate these results.

Ed

[DaJMasta]

I'll definitely look into it then. I've seen it around and it seems to be standard - this counter is a rebrand of a counter sold under several major manufacturers, so I suspect it is then.  Will be nice to get something automated to extract the data too, the display info is great, but it's a real pain to try and recover all the data points and look in detail from a lot of measurements.

Looks like some impressive numbers on the outputs of the GPSDOs too.

[texaspyro]

As for the measurement, I don't have a TimePod, so the most accurate timing info I can get is with my PM6690, and I don't know if that will interface with TimeLab. 

You might want to look into the TAPR TICC.  Two channels, 60 ps resolution.  It works with Timelab or Lady Heather.  Timelab can handle live ASCII data streams from a device or file.  Also data from a logged file.   If Timelab can't handle your counter's native data format log it to a file and convert it to a format it can handle.  You can do this either post-processed or in real time.  Heather can configure and control the TAPR TICC.

Lady Heather now supports counters as an input device. It can handle input data as frequency, interval, period, or timestamps.  Internally, it converts all readings to time interval errors (the difference between the nominal frequency and the measured frequency converted to seconds). 

Heather can calculate ADEV, HDEV, MDEV, TDEV,  MTIE, frequency, phase, etc on up to four channels of data with two TAPR TICCs or two channels with generic counters.  Heather always shows frequency as the difference between the nominal frequency and the measured frequency.

If your counter can shovel data out a serial port (or a USB port that looks like a serial port) it should work.  It wants ASCII data at, ideally, 1 Hz gate time (but should be able to handle at least 10 Hz).    The numeric parser is rather general purpose and can handle the HP531xx data format.

Attached is a screen dump of Heather monitoring a SA22.c rubidium oscillator using a TAPR TICC which is using an HP5071A cesium beam oscillator as its reference clock.   It shows the SA22's temperature dependence.  The SA22 baseplate temperature changed 1.25 degrees C during that run.  You can see the air conditioning cycling and where it shut off.

[edpalmer42]

It just occurred to me that you might not need Timelab to duplicate my results.  I have a PM6681 counter from Fluke/Philips/Pendulum.  I can set it up to take 1000 measurements of the 1 PPS period and give me Min, Max, and Std. Dev.  No computer required.  I would expect your counter to have those capabilities.

Ed

[cdev]

A while back I think I saw software to use a Venus GPS and a Raspberry Pi to timestamp events - Its on "dan.drown.org" I think.. Probably his githib.

Wonder if a way could be finagled to make the whole more accurate than the sum of the parts? Possibly with a GPSDO and the RPIs GPIOs??

[DaJMasta]

A little update on my testing:

I've taken 4 or 5 segments of 50k second samples in different conditions after more than a week of continuous operation.  In my tests I found conclusive evidence of thermal drift in the BG7TBL, but in trying to figure out what it's coming from (the ublox 7M does not use a TCXO, there is a regular crystal on the board as well, and then there's always the potential for drift in the VCO adjustment supply), I found that the GPS was unlocking, sometimes for quite some time, and not reporting errors... so I can't count those results as an accurate representation of the unit's actual performance.

Before I jump to any hasty conclusions.... I've moved to a higher gain antenna and will let the thing resettle and repeat the tests.  I can still see clear drift in the PPS output due to no temperature compensation in the GPS module oscillator, but I can also see the jumps vary in frequency to try and stay centered around the correct frequency.  I did not get enough data captured to see where it fully settled before an unlock in yesterday's tests, so I'll be looking into that too.

The tests I did before included putting the BG7TBL unit in a lunchbox, then also thermally isolating the rubidium source to make sure it wasn't the source of the variation (and in later tests I confirmed that at least within the temperatures I was looking at, it was quite stable).  I did see the average frequency elevated when it was keeping itself warm in the lunchbox and by cracking open the back lid just a tad (2mm vent on the short side), I was able to finally get a 50ks average frequency just under 10MHz.... but since there's the possibility that the GPS was unlocked at that time, I don't think they're results you can count on.

[texaspyro]

The GPS module oscillator has very little effect on the GPSDO freq.  The GPSDO slaves to the GPS 1PPS output which is derived from a combination of the GPS module oscillator and the GPS signal.   The difference is known as the sawtooth correction and is typically in the range of +/- 10-50 ns.   The GPSDO takes care of averaging out the sawtooth error and steering the OCXO to 10 MHz.

[DaJMasta]

Can basically confirm that today, first half of the capture is enclosed and 4-5C above ambient outside the case, second half is in open air.  While you can see the drift, you can also see the pwm-style adjustment happening, and it's been pretty right on the nose in terms of frequency - less than 1e-10 every time I checked, half that after almost 10k seconds recording.

Also looks like for the Neo 7M, the adjustment step for the PPS output is about 10ns.

So if there's still drift from temperature, it's not from the GPS module.  Hopefully the next two days will be an open air 12-14h test, then a similar test that's half covered (elevated temp) and half not to see if there's still some change in the 10MHz output.

[DaJMasta]

Well I've got good news.  The drift in my initial results seems to be entirely because of the unlocking GPS.  The unit is not without its quirks, but it's certainly disciplining to the right frequency, not a high one.  This was taken with about 3 days of continuous GPS lock/uptime:



You can see variation, but the unit always compensates for it properly and converges to 10MHz (I actually caught 10.000 000 000 000 several times when watching the samples accrue).  Just after 11ks in, I actually took off a bubble wrap bag that had been insulating the unit and keeping it about 5C above normal temperature since the night before, and the result is hardly notable in the noise and was fairly quickly compensated for.

As I mentioned though, it's not entirely without its faults.  I had missed the fact that the GPS was unlocked earlier because the normal on behavior, a PPS pulse, is not actually from the GPS, it's from the micro inside.  Even though there's a PPS light on the board internally that is only on when locked, the blinking light on the outside goes all the time, and the GPS lock is instead indicated by a second, solid green light.

Another, much more relevant, issue is the way it adjusts.  The adjustment step size is fairly large, while I said 1.5mHz before, it's probably closer to 1.6mHz after seeing some more, and another 2-3 bits worth of adjustment on the DAC could make it MUCH smoother.  The adjustment algorithm is also fairly quick to respond to changes in the PPS input, and the PPS output from the neo 7M is somewhat noisy, also with its large step adjustment size.  The algorithm also seems to have no minimum time between step transitions, and is happy enough to jump two steps at once.... which really seems too aggressive for a reference designed to take hours to settle and stabilize.  I took a picture of the graph at a much shorter sample length that demonstrates these fairly quick transitions, and I haven't seen the frequency of adjustments decrease with more uptime.  Even with the same DAC, I think limiting the adjustment to one step at a time and perhaps one minute or so in between steps should go a long way towards reducing the frantic variation of the current system.  Maybe not a huge improvement, but a free one.




Performance is still good, though, especially given the price.  This 2016-05-31 model seems to have fixed any long term frequency drift issues and is disciplining to the correct place.

[nctnico]

I've been using my BG7TGBL GPDSO (version 2017-03-29) as a reference for a project but one thing that throws a wrench in the works is that the 1PPS output wanders around a lot (20ns) compared to the 10MHz output.