前のトピックを表示 :: 次のトピックを表示 |
投稿者 |
メッセージ |
Lightningwizard
登録日: 2007.10.19 記事: 165
|
日時: Wed Feb 06, 2008 7:25 am 記事の件名: Time stamps |
|
|
Hi SonotaCo,
I noticed that if timestamps are added in UFOCapture, they fluctuate a lot around the PAL 40 msec interval in my case. Why is this not constant? You would think the capture card delivers a constant stream of images... Does it wait for the disk to finish writing separate frames in an AVI before the next one can be written? ...apparently not, because it is also seen in the preview stream. The millisecond last digit ends at random numbers.
I have the advantage of using a GPS time inserter that marks the frames before they are captured into the computer. Now if I use also the UFOCapture time stamp with my computer running NTP daemon, I find that in order to have the two time stamps match approximately (with variations described above), I must set "+msec" to about 90.
I suppose this means it inserts computer time + 90 msec. Then:
1) phenomenon is captured at t=0
2) image is captured into computer with a transfer time of t=0+x (x<1 interlaced frame duration)
3) the current computer time is stamped on it, t=0+x
We then only need to correct for the transfer time: set +msec = -x (-40 msec for PAL maximum). Now we take into account a computer clock just slightly delayed to time server clocks by 'd' ms (it shows a lower time value than the real time). If this would be the only factor to compensate for, we would do: +msec = d
So the combined total compensation is: +msec = d-x (please check if I'm right)
I guess this tells me that if I have to compensate by +90 msec, my NTP lag was 50 msec if the image saving time is 40 msec. The only puzzle then is that my logs say the 'offset' is usually only between -10 and +10 ms, and the 'delay' listed there is likely the web transfer delay (ping to the server) for which is likely already compensated by the protocol.
Anyway, a nice exercise
But I am still curious for the fluctuations, if this could be resolved the timestamps would be more accurate when used in combination with NTP, which would be a help if one wants to analyze a video that has no GPS stamp from an inserter. I think it would be great if you supplied the Network Time Protocol together with UFOCapture, to ease scientific analysis of amateur recordings (example: gigantic jets recorded last year with drifting clock were tricky to analyze).
Oscar _________________ Weather & Photography
http://www.lightningwizard.com
EuroSprite blog:
http://eurosprite.blogspot.com |
|
トップに戻る |
|
|
SonotaCo Site Admin
登録日: 2004.08.07 記事: 12671 所在地: 139.67E 35.65N
|
日時: Wed Feb 06, 2008 2:33 pm 記事の件名: Re: Time stamps |
|
|
Hi Oscar
Thank you for commenting.
I agree that the importance of time stamps.
But it is one of the most difficult problem.
Things that can be done from application layer are limited.
UFOCapture records the inputting time to UFOCapture's module (by 100nsec resolution multimedia timer time).
But it has already included time dispersions.
Windows task dispatching mechanism is not good at realtime processing at all.
They usually have order of a few 100msec dispersions.
And DirectShow processing stages cause frame delays depend on the type of capture devices.
Therefore, only the device driver has a chance to put the correct time stamps.
But there is no device driver which does it.
I am hoping someone to write the device driver that put time stamps. |
|
トップに戻る |
|
|
Robert J Cobain
登録日: 2006.04.25 記事: 79
|
日時: Thu Feb 07, 2008 4:56 am 記事の件名: |
|
|
Hi Oscar, In order to get the best timestamps possible, you could try the Kiwi OSD. http://www.pfdsystems.com/kiwiosd.html This device is accurate to 1 millisecond and is mainly used by Occultation observers. Problem is that it often (every few hours) needs to be resynchronized manually by way of a yellow button! This is impractical for the meteor camera unfortunately. I have one, but it only gets used on special occasions! |
|
トップに戻る |
|
|
Lightningwizard
登録日: 2007.10.19 記事: 165
|
日時: Thu Feb 07, 2008 5:19 am 記事の件名: |
|
|
Robert,
I have the KIWI-OSD and indeed prefer it to the computer clock. We have also one installed for a remote sprite camera and it does have problems sometimes. What I found is even when it lost synchronization by satellite for a while and letters blink 'XXXXX', comparison with the NTP computer clock stamp shows that the milliseconds can be in sync (again) even if the hh:mm:ss are way off. Apparently the pulse per second of the GPS unit is received again, but the internal clock of the inserter drifted away during periods of no satellite reception.
So for continuous use I actually recommend to use both the KIWI and the NTP stamp for backup.
Oscar _________________ Weather & Photography
http://www.lightningwizard.com
EuroSprite blog:
http://eurosprite.blogspot.com |
|
トップに戻る |
|
|
SonotaCo Site Admin
登録日: 2004.08.07 記事: 12671 所在地: 139.67E 35.65N
|
日時: Thu Feb 07, 2008 9:04 am 記事の件名: |
|
|
Once I have tested the GPS time imposer.
http://sonotaco.jp/forum/viewtopic.php?t=945
By this experiment I introduced the +-msec offset to UFOCapture.
There I also found below.
1. GPS sometime loses satellites , it is equal to what Oscar said.
2. Low cost super imposers are not stable at sync timing.
Time correction algorithm is just a "replace". That makes big leap of time at a sync moment.
If you want short term stability, you should use an equipment that contains continuous clock and phase lock loop time adjustment function. I think it can be made with Linux computers. The time correction algorithm of unix systems is very wise. They guarantee both short term stability and long term accuracy. I am hoping those equipments become available at low cost. |
|
トップに戻る |
|
|
|