rtc test 2

rtc test 2

[Joshua Clayton]

> On Monday, November 16, 2015 09:46:33 AM Steve Eagan wrote:
> 
> I agree, setting to the opposite extreme is a good idea
> 
> On Friday, November 13, 2015 03:45:56 PM Joshua Clayton wrote:
> > rtc on 109 was set to the maximum adjustment value 273420 parts per
> > billion.
> > synchronized at 3:39:00 pm Today.
> > I'll check it again on Monday to see how far it has drifted.
> > Monday November 16 at 7:42:00 on my PC clock, the rtc on109 reads 07:40:36
> > 
> > My expectation was that the time would be ahead, instead it is 1 minute 24
> > seconds behind. Perhaps I misunderstand which way the adjustment pushes
> > the
> > clock?
> > 
> > On the bright side, the effect is pronounced. It seemws to support the
> > idea
> > that it is doing something.
> > 
> > Any thoughts on a value to try next? My first thought is to set to the
> > opposite extreme... Going ahead with that.
> > 
> > OK then. Setting adjust to
> > 
> > root at evi:~# cat /sys/class/rtc/rtc0/device/adjust
> > -277760
> > root at evi:~# cat /sys/class/rtc/rtc0/device/d
> > 0xc0
> > 
> > Monday November 16 at 7:51:00  Clock syncronized to my PC clock.

Tested rtc this morning
November 18 7:45:00 AM, instrument 109 shows November 18 7:45:03
So the adjusment has made the clock fast. The adjustment is in the opposite direction previously thought.

3 seconds * 1 billion / 172440 seconds = 17397 parts per billion

 
I am going to try another setting:

if the setting -277760 yields 17397....

I'm kind of in a boggle.
-277760 + 17397 would be -260363... the closest available value is -260400

synchronized November 18 09:33:00

root at evi:~# cat /sys/class/rtc/rtc0/device/d
0xc4
root at evi:~# cat /sys/class/rtc/rtc0/device/adjust 
-260400

Since my understanding of the math involved was upside down, I have little confidence in the above figures (except the empirical numbers),
but the testing will continue.

One thing to think about: The closer we get, the longer it will take to make a good measurement. Data is only available at one second
granularity 

-- 
Joshua Clayton
Software Engineer
UniWest
122 S. 4th Avenue
Pasco, WA 99301
(509) 544-0720

rtc test 2

[Joshua Clayton]

On Wednesday, November 18, 2015 10:40:53 AM Alan Miller wrote:

> With 2 points we can generate a time per setting slope (like shown).    
> This graph point is 3 seconds out of 172800 or .000174 sec/sec.   That?s
> get us to within 4 minutes in a year so a longer test may be needed and a
> better setting passed on with an upgrade. Not sure about the math you have
> Josh ? to get parts per billion, billion should be in the denominator.
Hah. You almost got me there. Made my head spin a little.
To convert from seconds per second to parts per billion, the numerator gets multiplied by a billion. 
(technically the denominator gets multiplied too, but the billion is folded into the unit),
i.e. the billion in the denominator is implicit.

> 
> Best accuracy to graph with would use the min & max settings for 2 points
> like below ? we now have 1. Maybe the slope is negative but would still
> work if our min/max adjustments can over/under compensate.

We actually do have a second and third data point:
	the first test with Adams calculated guess
	the test with the maximum adjustsment


I will dig out the emails with those results when I have time,
and when I have recovered some from the math fatigue :)

hopefully they are linear.

-- 
Joshua Clayton
Software Engineer
UniWest
122 S. 4th Avenue
Pasco, WA 99301
(509) 544-0720