Rb Module error?

[@rt]

Hi Guys,
I have a Ublox LEA-5T timing module sending a pulse per second signal into a scope (Yellow trace).
On the other channel (Red trace), is a pulse per second signal produced by a pic program,
where the pic is clocked by the 10 MHz output of one of the used rubidium modules from eBay.

At 50ns scale, as in this video, I have to skip a timer count every 250 seconds to keep the signal on the screen.
... according to what I think is a second anyway... that would be one instruction which is four clock of the pic’s clock cycles.
I think that if I made any error in the pic timing routine, an interrupt driven 100Hz count using timer1,
it would result in much greater error either way. The pic is running at 10MHz and instruction time every 4 clock cycles.

Is is common for the used Rb module to have this much error, or could there be an issue with my program I don’t see?
I just don’t think I could do this if I wanted to... which is make it slow down roughly 100s every minute.

[andy_silicon]

Does your GPS have a good clear view of the Sky ?
Have you done a full GPS position survey ?
Have you fixed that position into the GPS and set the GPS to fixed position mode ?

From my wet finger calculations something is wrong - but without some more details you can't say what that is :-)

[@rt]

Hi The answer is no, no and no!
Do you think the error is in the GPS? I would still think that rather high.
It does have position fix indoors, and generally reports it uses 6-12 satellites for the position fix.

Having said that, it’s the same every time. About 100ns is lost per minute.

[edpalmer42]

100 ns drift in a minute works out to a frequency difference of about 1.6e-9.  That's within the adjustment range of some Rb standards.  Which one do you have?  Are you sure that it's working right?  Does it have a lock indicator pin?  Can you measure the frequency while it's warming up to a resolution of 1 Hz?  Calibration of your meter doesn't matter, just the resolution.  You should see it sweep up and down in frequency over a range of 100 - 200 Hz for a few minutes and then just stop sweeping and sit at a constant frequency.  The lock pin should change state at that point.

I can think of two things to try.

First, get rid of the pic for now.  Trigger the scope off of the 1 PPS from the GPS and look at the 10 MHz from the Rb directly.  If there's a drift, you should see it directly.

Another thing that would take a bit more work is to build a divider out of logic gates, i.e. digital counters.  That way, there will be no question of whether something's getting lost in the pic.

Ed

[andy_silicon]

Reviewing the video more closely - could it be that your GPS is providing the 1 second pulse within a 100nS window ?
I.e. Because the GPS uses a microcontroller which operates from (presumably) an oscillator which is not locked , the second output can only be within a certain 'quanta' of time.
Look up sawtooth correction.

[andy_silicon]

Just checked the LEA-5T datasheet and it has a granularity of 21nS and RMS of 30nS on the 1-second timing output. ( best accuracy 15nS *IF* you performed sawtooth correction )

[andy_silicon]

Which Ruby is it? FE5680 ? Or PRS10 ? Or Other ?
As the posts above suggest - you should really check you have Rb lock first.
All the FE5680's I have (5!) were better than 1E-11 before adjustment ( Ebay purchases )

[@rt]

Hi again Guys,
I have FE-5680A, I have purchased some months ago, and it does give indication of frequency locked.
If I recall, the state of the pin is low when it’s locked, so it’s high when it boots, the signal does walk a bit at boot time,
and settles in a couple of minutes.

could it be that your GPS is providing the 1 second pulse within a 100nS window ?

That would be fine, the other clock wouldn’t walk away from it if the frequency was more correct.
Remember in the video, I am the one making the big jump of the red trace to the left in my pic program,
just so you can continue to see the smaller movement at the same scale.
Without that intervention, the red trace always slows down.. will run off the screen to the right.

First, get rid of the pic for now.  Trigger the scope off of the 1 PPS from the GPS and look at the 10 MHz from the Rb directly.  If there's a drift, you should see it directly.

Another thing that would take a bit more work is to build a divider out of logic gates, i.e. digital counters.  That way, there will be no question of whether something's getting lost in the pic.

I thought about it too long without disengaging my mind from the problem.
I figured out the first one by now, but not had time to try yet. The second suggestion I should have also thought of.
There’s already a 100 kHz signal from the pic’s hardware PWM module, already divided down to a 1Hz pulse with logic.
That wouldn’t test the timer routine, but I would see any problem with clock input to the pic.

But the first one definitely... When I first got the Rb module my scope only had one working channel.
The idea of comparing things is new to me, this is the first time.
Now I really like the look of the new cheaper four channel Rygol being talked about here.

Thanks for all the replies. I won’t ask questions again till I’ve tried all of that.