Author Topic: bg7tbl gpsdo master reference  (Read 186200 times)

0 Members and 2 Guests are viewing this topic.

Offline motocoder

  • Supporter
  • ****
  • Posts: 768
  • Country: us
  • Electrical Engineer
Re: bg7tbl gpsdo master reference
« Reply #50 on: August 22, 2015, 12:12:29 am »
Based on what what I can calculate in my clouded head right now. 5nS per 80S is 3.75nS per minute, 6.25-11 every second, or 1600 seconds per cycle at 10MHz, or 0.000625 Hz difference? 6.25-9% difference? If so, it would be hard for me to improve the adjustment of the rubidium standard!

I don't think that's valid. This assumes that it's going to continue, linearly, to drift 5ns every 80s. For the GPSDO, the GPS adjusts the value and they start to drift back in the other direction.

Oh, but I guess you're talking about a Rubidium standard here, which isn't GPS disciplined.
 

Offline TSL

  • Regular Contributor
  • *
  • Posts: 237
  • Country: au
Re: bg7tbl gpsdo master reference
« Reply #51 on: August 22, 2015, 12:31:07 am »
The FE5680 will slow drift off over time, but a very long time. The nice thing about them is that you can turn them off and when you turn them back on it only takes 5 minutes to achieve an accurate lock. GPSDO's will take much longer to settle and are best when not turned off at all.

The FE5680 is also adjustable in tiny increments, a quote from the manual for mine...

"The FE-5680A output frequency can be adjusted digitally over the RS-232 interface (pins
8 and 9). This feature is available as option 2, and is not available on units purchased
without this option. The frequency can be adjusted with a resolution of 1.7854E-7 Hz. For
an FE-5680A device with an output frequency of 10 MHz, this corresponds to a relative
frequency setting resolution of 1.7854E-14."


If you're lucky enough to have a unit with option 2 in it of course :)

VK2XAX :: QF56if :: BMARC :: WIA :: AMSATVK
 

Offline edpalmer42

  • Super Contributor
  • ***
  • Posts: 1619
  • Country: ca
Re: bg7tbl gpsdo master reference
« Reply #52 on: August 22, 2015, 12:48:02 am »
Well I have an unobstructed all sky view for my antenna, no problem there. I ave only one GPSDO. I thought that would be enough as I don't need another obsession. The FE5680B is the only other real standard I have. My biggest problem is big temperature swings where my equipment is. Anywhere from 0°C winter night to 40°C summer day. I am trying to get this under control. Daily variations tend to be in the 25°C range.

Like all Rb standards, the Fe5680B will change frequency slightly due to temperature changes.  You can minimize this with fairly trivial effort.  Just putting it in a cardboard box will reduce the changes significantly.  For a slightly more professional version, put the 5680B in an enclosure with a temperature-controlled fan that draws outside air through the enclosure.

Ed
 

Offline edpalmer42

  • Super Contributor
  • ***
  • Posts: 1619
  • Country: ca
Re: bg7tbl gpsdo master reference
« Reply #53 on: August 22, 2015, 12:53:38 am »
The FE5680 will slow drift off over time, but a very long time. The nice thing about them is that you can turn them off and when you turn them back on it only takes 5 minutes to achieve an accurate lock. GPSDO's will take much longer to settle and are best when not turned off at all.

The FE5680 is also adjustable in tiny increments, a quote from the manual for mine...

"The FE-5680A output frequency can be adjusted digitally over the RS-232 interface (pins
8 and 9). This feature is available as option 2, and is not available on units purchased
without this option. The frequency can be adjusted with a resolution of 1.7854E-7 Hz. For
an FE-5680A device with an output frequency of 10 MHz, this corresponds to a relative
frequency setting resolution of 1.7854E-14."


If you're lucky enough to have a unit with option 2 in it of course :)

I don't know about the 'B' version, but some versions of the 5680A also have a screwdriver adjust for really fine frequency adjustment.

Ed
 

Offline Lightages

  • Supporter
  • ****
  • Posts: 4295
  • Country: ca
  • Canadian po
Re: bg7tbl gpsdo master reference
« Reply #54 on: August 22, 2015, 03:13:47 am »
My point was that the error, based on the current state of affairs, was far below my ability to adjust it. The FE5680B is a bit of a different beast from the A series. If I need better accuracy, I should move to a climate controlled air tight laboratory.  >:D
 

Offline usagi

  • Frequent Contributor
  • **
  • Posts: 357
  • Country: us
Re: bg7tbl gpsdo master reference
« Reply #55 on: August 22, 2015, 03:56:13 am »
Hopefullly they will stay in stock until Christmas. Currently e-mailling oscilloquartz about the star 4 module.

I emailed them as well.  8)

Offline motocoder

  • Supporter
  • ****
  • Posts: 768
  • Country: us
  • Electrical Engineer
Re: bg7tbl gpsdo master reference
« Reply #56 on: August 22, 2015, 06:02:00 am »
I set the frequency counter up to calculate the ratio of the two frequency inputs. I set the gate time to the maximum value, which is 1000 seconds. Using the Lucent as input one, I hooked up the three BG7TBL units up successively to the frequency two input.

The ratio for the BG7TBL/TRIMBLE and BG7TBL/Huawei(Oscilloquartz Star4) was consistently 1.000.000.000.0. I ran each for a number of 1000 second cycles with stats turned on and tracking the max/min values, and I never saw any other value. The BG7TBL/2014-12-09, on the other hand, gave me some 1.0 readings, but there were a couple of 1.000.000.000.1 readings. I believe this is because the bug with the frequency being slightly off is still there. In any event, for most people I think it's a non issue. I can only barely see the problem at the limits of my counter.

Of all 4 units, I like both the Lucent and the Huawei/Oscilloquartz/Star4. I love that the Lucent has a serial interface where you can send commands and view stats. The Huawei/Oscilloquartz/Star4 has only a read-only, GPS-only interface, but it has a GPS chip with better sensitivity and more channels, a very good, cooler-running OCXO, is more compact, devoid of strange power connectors, and has a clean sine wave output. If we can get some sort of read/write interface working for the Huawei/Oscilloquartz/Star4, it would be a hands-down winner.
 

Offline edpalmer42

  • Super Contributor
  • ***
  • Posts: 1619
  • Country: ca
Re: bg7tbl gpsdo master reference
« Reply #57 on: August 22, 2015, 06:39:07 am »
I set the frequency counter up to calculate the ratio of the two frequency inputs. I set the gate time to the maximum value, which is 1000 seconds. Using the Lucent as input one, I hooked up the three BG7TBL units up successively to the frequency two input.

The ratio for the BG7TBL/TRIMBLE and BG7TBL/Huawei(Oscilloquartz Star4) was consistently 1.000.000.000.0. I ran each for a number of 1000 second cycles with stats turned on and tracking the max/min values, and I never saw any other value. The BG7TBL/2014-12-09, on the other hand, gave me some 1.0 readings, but there were a couple of 1.000.000.000.1 readings. I believe this is because the bug with the frequency being slightly off is still there. In any event, for most people I think it's a non issue. I can only barely see the problem at the limits of my counter.

Of all 4 units, I like both the Lucent and the Huawei/Oscilloquartz/Star4. I love that the Lucent has a serial interface where you can send commands and view stats. The Huawei/Oscilloquartz/Star4 has only a read-only, GPS-only interface, but it has a GPS chip with better sensitivity and more channels, a very good, cooler-running OCXO, is more compact, devoid of strange power connectors, and has a clean sine wave output. If we can get some sort of read/write interface working for the Huawei/Oscilloquartz/Star4, it would be a hands-down winner.

Since you have a 53131A counter, why not measure the time interval from the rising edge on the Lucent to the rising edge on one of the others.  This is the highest resolution method of directly comparing two oscillators.  Collect the data via RS-232 with Timelab.  Frequency offsets like the bug in the BG7TBL unit will be easy to see rather than digging around in the last digit.  Some of your results won't be as good as John Miles' when he discovered the bug because his equipment is so much better than ours, but some of it will be comparable.

Ed
 

Offline usagi

  • Frequent Contributor
  • **
  • Posts: 357
  • Country: us
Re: bg7tbl gpsdo master reference
« Reply #58 on: August 22, 2015, 08:18:25 am »
With multiple GPSDO's you will need to check their specs sheets to see which is the best.

i.e. the uBLox based units are/where using the NEO-6 GPS unit. This has a PPS accuracy specified at 30ns RMS, its timing brother the T version can achieve 15ns.

the bg7tbl star4 gpsdo uses the ublox LEA-5T unit.

Offline motocoder

  • Supporter
  • ****
  • Posts: 768
  • Country: us
  • Electrical Engineer
Re: bg7tbl gpsdo master reference
« Reply #59 on: August 22, 2015, 04:33:02 pm »
I set the frequency counter up to calculate the ratio of the two frequency inputs. I set the gate time to the maximum value, which is 1000 seconds. Using the Lucent as input one, I hooked up the three BG7TBL units up successively to the frequency two input.

The ratio for the BG7TBL/TRIMBLE and BG7TBL/Huawei(Oscilloquartz Star4) was consistently 1.000.000.000.0. I ran each for a number of 1000 second cycles with stats turned on and tracking the max/min values, and I never saw any other value. The BG7TBL/2014-12-09, on the other hand, gave me some 1.0 readings, but there were a couple of 1.000.000.000.1 readings. I believe this is because the bug with the frequency being slightly off is still there. In any event, for most people I think it's a non issue. I can only barely see the problem at the limits of my counter.

Of all 4 units, I like both the Lucent and the Huawei/Oscilloquartz/Star4. I love that the Lucent has a serial interface where you can send commands and view stats. The Huawei/Oscilloquartz/Star4 has only a read-only, GPS-only interface, but it has a GPS chip with better sensitivity and more channels, a very good, cooler-running OCXO, is more compact, devoid of strange power connectors, and has a clean sine wave output. If we can get some sort of read/write interface working for the Huawei/Oscilloquartz/Star4, it would be a hands-down winner.

Since you have a 53131A counter, why not measure the time interval from the rising edge on the Lucent to the rising edge on one of the others.  This is the highest resolution method of directly comparing two oscillators.  Collect the data via RS-232 with Timelab.  Frequency offsets like the bug in the BG7TBL unit will be easy to see rather than digging around in the last digit.  Some of your results won't be as good as John Miles' when he discovered the bug because his equipment is so much better than ours, but some of it will be comparable.

Ed

I don't have the data logging set up yet, but I can combine the TI measurement with the built-in stats calculation on the 53131A.

Not sure I have this right - 53131A is not known for its intuitive UI. I set it up for "TI 1 to 2" measurement, then enabled Statistics with 1000 samples and ran a single stats cycle. Both channels have 50 ohm termination, AC coupling, auto trigger levels.

(All values in microseconds unless otherwise noted)
Lucent to Huawei - StdDev 0.000590; Mean 0.091113; Max 0.0923; Min 0.0898 -> (max - min) = 2.5 ns
Lucent to Trimble - StdDev 0.000355; Mean 0.047302; Max 0.0488; Min 0.0463 -> (max-min) = 2.5 ns
Lucent to BG7TBL - StdDev 0.000356; Mean 0.095016; Max 0.0958; Min 0.0943 -> (max-min) = 1.5 ns

Trimble to Huawei - StdDev 0.000685; Mean 0.050237; Max 0.0523; Min 0.0488 -> (max-min) = 3.5 ns
Trimble to BG7TBL - StdDev 0.000615; Mean 0.050347; Max 0.0523; Min 0.0493 -> (max-min) = 3.0 ns

Huwaei to BG7TBL - StdDev 0.000952; Mean 0.018382; Max 0.0213; Min 0.0163 -> (max-min) = 5.0 ns

I might have upset things a bit by jostling the GPSDO enclosures. It's hard to plug/unplug BNCs on these things. I will let them sit for awhile and repeat one of the measurements to see how much it changes. Might also make sense to do a longer sample run - maybe 10,000 samples.

(edit) More samples on Huawei to BG7TGBL - StdDev 0.010116; Mean 0.0355101; Max 0.0523; Min 0.0203 -> (max-min) = 32 ns
« Last Edit: August 22, 2015, 07:14:22 pm by motocoder »
 

Offline edpalmer42

  • Super Contributor
  • ***
  • Posts: 1619
  • Country: ca
Re: bg7tbl gpsdo master reference
« Reply #60 on: August 22, 2015, 09:47:50 pm »
I don't have the data logging set up yet, but I can combine the TI measurement with the built-in stats calculation on the 53131A.

Not sure I have this right - 53131A is not known for its intuitive UI. I set it up for "TI 1 to 2" measurement, then enabled Statistics with 1000 samples and ran a single stats cycle. Both channels have 50 ohm termination, AC coupling, auto trigger levels.

(All values in microseconds unless otherwise noted)
Lucent to Huawei - StdDev 0.000590; Mean 0.091113; Max 0.0923; Min 0.0898 -> (max - min) = 2.5 ns
Lucent to Trimble - StdDev 0.000355; Mean 0.047302; Max 0.0488; Min 0.0463 -> (max-min) = 2.5 ns
Lucent to BG7TBL - StdDev 0.000356; Mean 0.095016; Max 0.0958; Min 0.0943 -> (max-min) = 1.5 ns

Trimble to Huawei - StdDev 0.000685; Mean 0.050237; Max 0.0523; Min 0.0488 -> (max-min) = 3.5 ns
Trimble to BG7TBL - StdDev 0.000615; Mean 0.050347; Max 0.0523; Min 0.0493 -> (max-min) = 3.0 ns

Huwaei to BG7TBL - StdDev 0.000952; Mean 0.018382; Max 0.0213; Min 0.0163 -> (max-min) = 5.0 ns

I might have upset things a bit by jostling the GPSDO enclosures. It's hard to plug/unplug BNCs on these things. I will let them sit for awhile and repeat one of the measurements to see how much it changes. Might also make sense to do a longer sample run - maybe 10,000 samples.

(edit) More samples on Huawei to BG7TGBL - StdDev 0.010116; Mean 0.0355101; Max 0.0523; Min 0.0203 -> (max-min) = 32 ns

This is useful information.  It shows that all the units appear to be working properly.  For most users, any of them would provide excellent service.

Now, can we answer the question:  Which one of these units is the best?  Moto, in the unlikely case that you haven't figured it out yet, I'm playing to the audience here!  ;)

The mean, max, and min values are arbitrary so they aren't useful.  Every test will give different values.

The Std. Dev. and Max-Min values are very useful.  You would expect those values to be similar (but not equal) from one test to another.  The two lowest Std. Dev. values both include the Lucent which suggests that it's the best one.  The Max-Min values are also at the low end of the scale.  The Trimble measurements are in the middle.  Huawei comes next.  But the BG7TBL measurements are both the best and worst of the pack!  :o

No, nothing's wrong.  These results aren't surprising.  GPS signals have jitter, so anytime you take a snapshot you could get a really good result or a not-so-good result.  Your edit clearly shows the affect of a not-so-good snapshot.  That one justifies the term 'outlier'.  We pretend that those measurements never happened.  Seriously, that's allowed!  Something hiccupped and the data is trash so you discard it.

To get some useful results out of these measurements, you have to take multiple data runs and compare the results to determine what typical results are.

Regarding the data logging, I urge you to get that going.  Timelab handles both the data collection and analysis.  All you have to do is plug in the cable!  Well, okay, you have to configure the serial port.  And I guess you have to figure out which cable wiring you need.  But you can handle that!  :D  Logging the data will move you out of the 'snapshot' business.  You'll be able to see how the units perform over time and your comparisons will be more consistent.  You should be able to confirm the frequency error of the BG7TBL unit - unless he's come out with a new firmware version that fixes the problem.  That would be interesting news!

If you look back at this message, it shows some of the things that Timelab can tell you about these units.  Yeah yeah, I know tl;dr, and even when you try and read it your eyes glaze over.  What can I say?  If you were trying to measure the diameter of a metal shaft, would you use a plastic ruler or learn how to use a micrometer?

Ed

P.S.  Do I dare mention that the best way to evaluate a GPSDO is to compare it to a local standard like a Rubidium oscillator?   ;)

 

Offline Lightages

  • Supporter
  • ****
  • Posts: 4295
  • Country: ca
  • Canadian po
Re: bg7tbl gpsdo master reference
« Reply #61 on: August 22, 2015, 11:03:36 pm »
P.S.  Do I dare mention that the best way to evaluate a GPSDO is to compare it to a local standard like a Rubidium oscillator?   ;)

And on that note!

Day three with my bg7tbl and I did some more time checking the frequency difference. Yesterday the drift was 3.75nS per second between my bg7tbl and my FE5680B. This indicated the FE5680B was lower by around 0.000625Hz. Today the drift was around 3nS per second. This would imply 0.0005Hz.

Which is correct? I don't know. Maybe they will get closer as time as goes on.

What else can I characterize with a oscilloscope, a used FE5680B, and a computer?
 

Offline TSL

  • Regular Contributor
  • *
  • Posts: 237
  • Country: au
Re: bg7tbl gpsdo master reference
« Reply #62 on: August 23, 2015, 12:33:01 am »


I don't have the data logging set up yet, but I can combine the TI measurement with the built-in stats calculation on the 53131A.

Not sure I have this right - 53131A is not known for its intuitive UI. I set it up for "TI 1 to 2" measurement, then enabled Statistics with 1000 samples and ran a single stats cycle. Both channels have 50 ohm termination, AC coupling, auto trigger levels.

(All values in microseconds unless otherwise noted)


Good to see some data, and given you're now measuring into the nS other thing need to be taken into account.

Are the leads from each GPS to the counter, the same length ?

Are they sharing a common antenna and, if you're using a splitter to share that antenna, are those leads also the same length ?

Are those patch leads made of the same material since velocity factor of the cable will also contribute.

When measuring such short time intervals it is important to remember that 1nS =11.8" or 29.98cm dependent on your unit of measure.

Disparate lead length will contribute nS or fractional nS offsets as will operating the GPS's at different heights since we're also now into the realm of relativistic effects. ( Dave demonstrated that in one of his videos )

A common antenna is critical to ensure multi path effects and other external influences are common too.

Other factors can contribute to GPS error, the Thunderbolt Manual is a wealth of information and contains a table that has these effects to consider...

Error Source                    --- 1 Standard Deviation
Atmospheric Models (Ionosphere) --- 5 - 50 ns
Receiver noise (Multipath)      --- 1 - 20 ns
Satellite Clock Model           --- 10 ns
Satellite Orbit Model           --- 5 ns
Antenna Survey                  --- 1 ns


+1 to edpalmer for mentioning TimeLab - this software is specifically designed for such measurements.

Comparison of these devices can lead to frustration when you are unsure of which source is the "truth" and nearly everything you set up to get data contributes to the error of the result.


VK2XAX :: QF56if :: BMARC :: WIA :: AMSATVK
 

Offline edpalmer42

  • Super Contributor
  • ***
  • Posts: 1619
  • Country: ca
Re: bg7tbl gpsdo master reference
« Reply #63 on: August 23, 2015, 05:27:09 pm »
P.S.  Do I dare mention that the best way to evaluate a GPSDO is to compare it to a local standard like a Rubidium oscillator?   ;)

And on that note!

Day three with my bg7tbl and I did some more time checking the frequency difference. Yesterday the drift was 3.75nS per second between my bg7tbl and my FE5680B. This indicated the FE5680B was lower by around 0.000625Hz. Today the drift was around 3nS per second. This would imply 0.0005Hz.

Which is correct? I don't know. Maybe they will get closer as time as goes on.

What else can I characterize with a oscilloscope, a used FE5680B, and a computer?

Both values are correct.  They are 'snapshots' as I described in my previous message to motocoder.  Don't think in terms of 'ns per second'.  Measure the offset and note the time.  From there, keep recording the offset and time over a period of hours.  When you graph it, you'll see the short-term wiggles as well as the long-term trend (if any).  If the trend is a straight line, everything is good.  The slope of the straight line shows the frequency offset.  If you want, you can tweak the frequency of your FE5680B to reduce the offset.  If it's curving around, you'll have to look deeper to see what's happening.

Exactly what are you measuring - offset between two 1 PPS signals or 1 PPS vs. 10 MHz?  If you're using the 10 MHz, you should probably divide it down to a lower frequency so that the phase doesn't wrap while you're taking measurments.  That creates headaches when it comes to analyzing the data.

Ed
« Last Edit: August 23, 2015, 05:29:06 pm by edpalmer42 »
 

Offline Lightages

  • Supporter
  • ****
  • Posts: 4295
  • Country: ca
  • Canadian po
Re: bg7tbl gpsdo master reference
« Reply #64 on: August 23, 2015, 05:32:20 pm »
I am measuring the phase change of the 10MHz signals. I don't have the time to do many measurements during the day right now. I am just checking it daily. But I will probably do as you suggest in a week or so. I was rather surprised at how close they are given that my FE5680B must be rather old and I thought it might have drifted a bit.
 

Offline edpalmer42

  • Super Contributor
  • ***
  • Posts: 1619
  • Country: ca
Re: bg7tbl gpsdo master reference
« Reply #65 on: August 23, 2015, 05:44:10 pm »


I don't have the data logging set up yet, but I can combine the TI measurement with the built-in stats calculation on the 53131A.

Not sure I have this right - 53131A is not known for its intuitive UI. I set it up for "TI 1 to 2" measurement, then enabled Statistics with 1000 samples and ran a single stats cycle. Both channels have 50 ohm termination, AC coupling, auto trigger levels.

(All values in microseconds unless otherwise noted)


Good to see some data, and given you're now measuring into the nS other thing need to be taken into account.

Are the leads from each GPS to the counter, the same length ?

Are they sharing a common antenna and, if you're using a splitter to share that antenna, are those leads also the same length ?

Are those patch leads made of the same material since velocity factor of the cable will also contribute.

When measuring such short time intervals it is important to remember that 1nS =11.8" or 29.98cm dependent on your unit of measure.

Disparate lead length will contribute nS or fractional nS offsets as will operating the GPS's at different heights since we're also now into the realm of relativistic effects. ( Dave demonstrated that in one of his videos )

A common antenna is critical to ensure multi path effects and other external influences are common too.

Other factors can contribute to GPS error, the Thunderbolt Manual is a wealth of information and contains a table that has these effects to consider...

Error Source                    --- 1 Standard Deviation
Atmospheric Models (Ionosphere) --- 5 - 50 ns
Receiver noise (Multipath)      --- 1 - 20 ns
Satellite Clock Model           --- 10 ns
Satellite Orbit Model           --- 5 ns
Antenna Survey                  --- 1 ns


+1 to edpalmer for mentioning TimeLab - this software is specifically designed for such measurements.

Comparison of these devices can lead to frustration when you are unsure of which source is the "truth" and nearly everything you set up to get data contributes to the error of the result.

Variations in lead length and velocity factor don't affect these kinds of measurements.  They create a constant offset which is tossed out with the mean, max, and min values.  They could be significant if you were trying to synchronize your 1 PPS signal to a real world time of day signal or some other existing standard.

Antenna issues however, are something to think about.  Differences in antenna gain and receiver sensitivity could change the results.  If there's any RF interference, different antennas will do a better or worse job of filtering that.  How will each receiver react to that?  It would be interesting to gather enough data to establish some level of confidence in the results and then swap the antennas and see if the results change.

Ed
 

Offline motocoder

  • Supporter
  • ****
  • Posts: 768
  • Country: us
  • Electrical Engineer
Re: bg7tbl gpsdo master reference
« Reply #66 on: August 23, 2015, 06:58:54 pm »


I don't have the data logging set up yet, but I can combine the TI measurement with the built-in stats calculation on the 53131A.

Not sure I have this right - 53131A is not known for its intuitive UI. I set it up for "TI 1 to 2" measurement, then enabled Statistics with 1000 samples and ran a single stats cycle. Both channels have 50 ohm termination, AC coupling, auto trigger levels.

(All values in microseconds unless otherwise noted)


Good to see some data, and given you're now measuring into the nS other thing need to be taken into account.

Are the leads from each GPS to the counter, the same length ?

Are they sharing a common antenna and, if you're using a splitter to share that antenna, are those leads also the same length ?

Are those patch leads made of the same material since velocity factor of the cable will also contribute.

When measuring such short time intervals it is important to remember that 1nS =11.8" or 29.98cm dependent on your unit of measure.

Disparate lead length will contribute nS or fractional nS offsets as will operating the GPS's at different heights since we're also now into the realm of relativistic effects. ( Dave demonstrated that in one of his videos )

A common antenna is critical to ensure multi path effects and other external influences are common too.

Other factors can contribute to GPS error, the Thunderbolt Manual is a wealth of information and contains a table that has these effects to consider...

Error Source                    --- 1 Standard Deviation
Atmospheric Models (Ionosphere) --- 5 - 50 ns
Receiver noise (Multipath)      --- 1 - 20 ns
Satellite Clock Model           --- 10 ns
Satellite Orbit Model           --- 5 ns
Antenna Survey                  --- 1 ns


+1 to edpalmer for mentioning TimeLab - this software is specifically designed for such measurements.

Comparison of these devices can lead to frustration when you are unsure of which source is the "truth" and nearly everything you set up to get data contributes to the error of the result.

I agree with Ed's reply to your post, but just want to clarify one thing. Those variables you point out impact only those values that represent absolutes, i.e. not deltas between samples. So coax cable length differences (and by the way, the lengths are identical) do impact the mean, max, and minimum value. I pointed this out when I mentioned that each unit has a potentially different value for the antenna delay constant (something you left out of your list). From what I have read, this value is used to adjust the time offset to compensate for propagation time between the antenna and the GPS.

However, as Ed points out, these variables do NOT impact the relative measurements that I provided, i.e. the standard deviation and the span (max - min) values. And that's really the only thing I'm interested in with these measurements - I just posted them because I had the data and thought people might want to see it.
 

Offline motocoder

  • Supporter
  • ****
  • Posts: 768
  • Country: us
  • Electrical Engineer
Re: bg7tbl gpsdo master reference
« Reply #67 on: August 23, 2015, 11:35:08 pm »
I bumped up the count on the 53131A statistics. The UI on this thing baffles me sometimes, but I think it ran for about 45 minutes or so before emitting a value. 

Lucent to BG7TBL/2014-12-09 - StdDev 3.4090ns, Max 48.8ns, Min 35.3ns, (Max-Min) 13.5ns.

This value correlates well with what I've seen by hooking my scope up to trigger on the Lucent, setting the BG7TBL up on the other channel with infinite persistence, and then measuring the horizontal deviation of the two waveforms. Is this an indication that this version of the BG7TBL does not have the slightly off frequency issue?

I will see if I can get TimeLab up and running next.
 

Offline edpalmer42

  • Super Contributor
  • ***
  • Posts: 1619
  • Country: ca
Re: bg7tbl gpsdo master reference
« Reply #68 on: August 24, 2015, 12:20:56 am »
I bumped up the count on the 53131A statistics. The UI on this thing baffles me sometimes, but I think it ran for about 45 minutes or so before emitting a value. 

Lucent to BG7TBL/2014-12-09 - StdDev 3.4090ns, Max 48.8ns, Min 35.3ns, (Max-Min) 13.5ns.

This value correlates well with what I've seen by hooking my scope up to trigger on the Lucent, setting the BG7TBL up on the other channel with infinite persistence, and then measuring the horizontal deviation of the two waveforms. Is this an indication that this version of the BG7TBL does not have the slightly off frequency issue?

I will see if I can get TimeLab up and running next.

Sorry, but you're still doing snapshots.  Your StdDev measurement averages things out so that any frequency drift is completely invisible.  Remember that the error was only about 2e-11 so nanoseconds are like mountains.  When John Miles made his measurements, he got a phase drift of approx. 2 us per day which is about 80 ns per hour.  You should be able to see that with a scope.  I don't know if the GPS jitter and wobble might be enough to hide that trend unless you measure it for hours as I suggested to Lightages.  You could try making a StdDev measurement for a few minutes every hour.  That would help average out the short term noise.  This time, the mean will be the important number.  See if it's changing in a consistent manner.

Ed
 

Offline motocoder

  • Supporter
  • ****
  • Posts: 768
  • Country: us
  • Electrical Engineer
Re: bg7tbl gpsdo master reference
« Reply #69 on: August 24, 2015, 01:16:00 am »
I bumped up the count on the 53131A statistics. The UI on this thing baffles me sometimes, but I think it ran for about 45 minutes or so before emitting a value. 

Lucent to BG7TBL/2014-12-09 - StdDev 3.4090ns, Max 48.8ns, Min 35.3ns, (Max-Min) 13.5ns.

This value correlates well with what I've seen by hooking my scope up to trigger on the Lucent, setting the BG7TBL up on the other channel with infinite persistence, and then measuring the horizontal deviation of the two waveforms. Is this an indication that this version of the BG7TBL does not have the slightly off frequency issue?

I will see if I can get TimeLab up and running next.

Sorry, but you're still doing snapshots.  Your StdDev measurement averages things out so that any frequency drift is completely invisible.  Remember that the error was only about 2e-11 so nanoseconds are like mountains.  When John Miles made his measurements, he got a phase drift of approx. 2 us per day which is about 80 ns per hour.  You should be able to see that with a scope.  I don't know if the GPS jitter and wobble might be enough to hide that trend unless you measure it for hours as I suggested to Lightages.  You could try making a StdDev measurement for a few minutes every hour.  That would help average out the short term noise.  This time, the mean will be the important number.  See if it's changing in a consistent manner.

Ed

I have Timelab up and running now. I think I may have destabilized things by diddling around with the antenna delay setting on the Lucent. It went out of locked mode and said it was adjusting the frequency for a few minutes. It's back in locked mode now, but I can see occasional spikes in the phase difference curve, so I think it's still not back to a steady state.  Anyway, I will let it run for awhile and report back when I have something interesting to share.
« Last Edit: August 24, 2015, 04:02:33 am by motocoder »
 

Offline motocoder

  • Supporter
  • ****
  • Posts: 768
  • Country: us
  • Electrical Engineer
Re: bg7tbl gpsdo master reference
« Reply #70 on: August 24, 2015, 05:17:39 am »
The BG7TBL/2014-12-09 is about to slip a whole cycle, so looks like the BG7TBL frequency bug is still there.
 

Offline Lightages

  • Supporter
  • ****
  • Posts: 4295
  • Country: ca
  • Canadian po
Re: bg7tbl gpsdo master reference
« Reply #71 on: August 24, 2015, 05:20:03 am »
I wish I had known about that bug before I purchased mine. It would have made much more sense to get the Trimble based unit, no?
 

Offline motocoder

  • Supporter
  • ****
  • Posts: 768
  • Country: us
  • Electrical Engineer
Re: bg7tbl gpsdo master reference
« Reply #72 on: August 24, 2015, 05:31:34 am »
I wish I had known about that bug before I purchased mine. It would have made much more sense to get the Trimble based unit, no?

It slipped a cycle in about 6840 seconds, which equates to 9,999,999.999,854 Hz. I guess for many purposes it doesn't matter. However, IMHO there's a bigger downside to this unit which is that there's no ability to control or monitor things other than the NMEA data via the serial port.

Have you cracked it open to see what's inside? I know it's a Morion OCXO, but what is the micro? It might make a decent GPSDO if an alternate firmware could be loaded. Probably some Wun Hung Lo microcontroller, but maybe it's something decent?
 

Offline TSL

  • Regular Contributor
  • *
  • Posts: 237
  • Country: au
Re: bg7tbl gpsdo master reference
« Reply #73 on: August 24, 2015, 05:55:43 am »

Have you cracked it open to see what's inside? I know it's a Morion OCXO, but what is the micro? It might make a decent GPSDO if an alternate firmware could be loaded. Probably some Wun Hung Lo microcontroller, but maybe it's something decent?

Its a Mega8 in mine, standard pin pad for programming too. see pic.
VK2XAX :: QF56if :: BMARC :: WIA :: AMSATVK
 

Offline motocoder

  • Supporter
  • ****
  • Posts: 768
  • Country: us
  • Electrical Engineer
Re: bg7tbl gpsdo master reference
« Reply #74 on: August 24, 2015, 06:08:32 am »

Have you cracked it open to see what's inside? I know it's a Morion OCXO, but what is the micro? It might make a decent GPSDO if an alternate firmware could be loaded. Probably some Wun Hung Lo microcontroller, but maybe it's something decent?

Its a Mega8 in mine, standard pin pad for programming too. see pic.

Ok, that's good news. He must be using that Altera CPLD for glue logic, that MAX232 to drive the serial port, and I assume there's a D/A in there somewhere to drive the ECF voltage. Should be open to reverse engineering. Is it worth the effort?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf