[EMAIL PROTECTED] (Nicola Berndt) writes:
>Unruh schrieb:
>> [EMAIL PROTECTED] (Nicola Berndt) writes:
>>
>>>>> Now using the following ntp.conf I can see that things are working,
>>> but not as expected. I would expect the pps clock to take over, no
>>> matter what happens, since I understand it is either there or not and it
>>> can't be wrong. Instead my system randomly marks either of these a false
>>> ticker every now and then..
>>>> Actually the pps CAN have noise on the line. I have found with my Garmin
>>>> 18LVM that sometimes the interrupt fires of 6 or 7 hits in a few
>>>> milliseconds,-- some sort of line noise coming in. Now, it is I admit
>>> a bit
>>>> of a kludge and I have not bothered to track down the problem-- bad
>>> solder
>>>> joint, TV interference,.....-- but it happens.
>>>> What is best if you can record say a days worth of interrupt timings
>>>> without haing the pps discipline your clock, and look at, or rather
>>> plot (
>>>> since looking at 86400 entries is liable to fry your brain) to see if you
>>>> are getting glitches-- noise tends to occur randomly so plotting
>>>> t_{i+1}-t_i over the day will show you if glitches have occured. If they
>>>> differ from 1 second according to your computer clock ( and you have left
>>>> your computer clock just rinning and not resetting it suddenly-- even ntp
>>>> running on the outside sources is fine since it shifts the time slowly)
>>>> then you have noise.
>>
>>> Ok, I will, I am just not sure, how to do so. Here are some assumptions,
>>> please correct me, where I'm wrong:
>>
>>> cat /proc/interrupt shows me /counts/ of different interrupts, so I
>>> assume,that is not what I am looking for. There is a IO-APIC-edge timer
>>> interrupt (0) and a IO-APIC edge serial interrupt (4). The timer
>>> interrupt grows constantly and the serial grows a couple of thousands
>>
>> Uh, you have serious problems withe your PPS. It looks to me like it needs
>> to be buffered. It should grow by 1 every second, not thousands. It sounds
>> like there is extreme noise on your pps line which when it gets near
>> transition causes loads of interrupts. Not good. Find out why the pps
>> output is so so so noisy.
>>
>>
>>> every start of a second (looks like) and If then stops until the next
>>> second. I assume that's the one and that the interrupts are fired, als
>>> long as the pps-signal is incoming.
>>
>> No, the interrupt is fired ONCE per edge transition. And there should only
>> be ONE edge transition.
>>
>But buffering would bring new troubles like a delay and / or jitter, no?
Buffering? What buffering? You have hardware problems not software
problems. the serial port interrupts are firing many times on an edge
transition. That is a hardware problem. Either your serial port hardware is
defective or the signal from the gps is really really noisy.
>Anyway, I will hook the pps output to a scope and check if I can find
>something strange at the actual transitions. Using a simple analog
>voltmeter just made it "tick" once a second.. Looked ok so far.. Now it
>looks like there are thousands of transitions every second. Any other
>idea how i could figure what is going wrong?
Nope. A scope is what I would use. Remember you want one that operates at
at least 10MHz. How is the pps line connected?
>>
>>> Now I find cat /proc/irq/4/serial to reportI "Is a directory" and I find
>>> nothing in there, so I am a bit stuck, since I simply don't know what to
>>> record..
>>
>> You need to write a little interrupt service routine to timestamp each
>> interrupt. But the info you gave already says something is seriously wrong.
>>
>>
>>
>>
>>>> Note that serial port nmea is liable to be out by up to 1/2 sec and
>>> to have
>>>> a lot ( 10s of msec) jitter on it, since the end of the string
>>> received by
>>>> a slow serial port ( eg at 4800Bd, it takes an nmea sentence of about 60
>>>> characters 1/8 of a second to be delivered and will have a jitter of few
>>>> characters in length-- or about 10ms jitter)
>>
>>> I don't understand why you are mentioning this, maybe you got me wrong.
>>> I run the nmea gps over usb and the pps goes to the serial port. So
>>> there is no data exept for the pps on my serial line..
>>
>> There is data on the usb line, which is a serial type line for which his
>> comments apply.
>Ah, I see. Still the offset should be more or les constant and the
>jitter is not too big. So I could take care of the offset in ntp.conf .
>Then all I'd need is the gps to set the time within 0.4 seconds
>precisely and pps to take over then. Do you see any problems with that?
Nope that is what you are supposed to do. I run mine off the serial port
and have the interrupt service routine timestamp the interrupt and put it
into a read buffer on /dev/gpsint.
>The issue is, that the final device will have to function outside, with
>no internet around and - even worse - will not have more then 5 minuites
>or so after startup to have settled. But let's adress these problems,
>when the pps-isue is solved...
That should not be too bad. If you choose the start up options for ntp
correctly it should settle down withing that time.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.org/mailman/listinfo/questions
