Ola Hugo.
O problema non é se facer o timestamp ou non. O problema é que cando se sincroniza o Windows con NTP, ese servicio non ten prioridade con respecto a outros do sistema operativo. Polo tanto non podes asegurar que a petición que fai o programa de lectura de NTP ó procesador se atenda no momento en que a fai. Windows pode decidir que outras tarefas son máis prioritarias e retrasar a atención a esa petición. Según comentan no foro de ocultacións, non é infrecuente ver frames etiquetados con ata décimas de segundo fora de hora, e téñense visto ata de 1 segundo.
Polo que teñen medido, Linux sí atende as interrupcións a tempo e responde nun tempo non superior a milisegundos. É un problema do sistema operativo, non do programa que usas para o timestamp. Para que vexas cal é o problema vou a volcar aquí a contestación que David Herald puxo nese foro explicando a situación.
Saúdos.
At the risk of repeating some issues, some further comments on this.
1.On setting a PC clock accurately. Linux machines are straight-forward; the OS gives good access to the system clock, and standard NTP software accurately sets the clock (generally better than 10msec providing you are using a NTP server within a few thousand km, and a goog internet connection). Windows machines – that standard time setting functionality in Windows has uncertainties of the order of 1 second (depending on a large range of issues). However by using NTP software especially written for Windows (such as Dimension4) you can set the PC clock to the same level of accuracy as a Linux machine. BUT be careful of the NTP software you use. For example, there is a package out there called ‘Chronos’, and this sets the system clock with a constant error of around 0.3 secs.
2. On reading the PC clock. Again, the operating system for Linux gives accurate access to the system clock (which I have confirmed with testing). That is, the standard Linux functions for returning the time from the system clock give accurate time (at least at the 10msec level). The same can be achieved with a Windows operating system – but ONLY if the software used to read the system clock has bee appropriately written (which Hristo Pavlov has done in his BeeperSync package). Otherwise the reading of the system clock is affected by system interrupts, with random variations in the reported time. The starting assumption is that user software is not generally written to ensure accurate time extraction for the system clock in a Windows PC – the effects on overall system performance are too adverse.
3. From this, I hope that it is apparent that the issue of using NTP software as a time base is essentially an issue related to Windows operating systems. Conclusions based on testing with Linux do not apply to Windows, and vice versa. Thus it is critical that anyone doing testing clearly identifies the operating system(s) they are testing – as conclusions do not automatically flow to other operating systems.
4. On my understanding (which may be erroneous), Firewire is a serial bus architecture for high-speed data transfer. In that sense it is useful for avoiding dropped frames when transferring a live video signal to a PC environment. But on my limited understanding Firewire has no relevance to the issue of how time is extracted from the system clock. That is, I would not expect the use of Firewire will avoid the problems of reading the time from the system clock in a Windows PC.
5. On Composite video cameras with time inserters, versus PC cameras. In a Linux environment, from the limited testing I have been involved with it would seem possible to accurately associate time with camera frames. In the Windows environment, that is not possible/practical with the current usual tools – because of the way the system clock is ‘buried’ within the Windows operating system. In this regard the Composite Video camera with a VTI is a very neat solution; the time stamp is created on the basis of the vertical sync pulse at the commencement of output of a frame from the camera, and that stamp is written on that frame – with all of this occurring before any computer processing. As a result there is high integrity in the association of the time to the video signal. On the other hand, when you allocate a time to a video frame within a computer there are a whole heap of ‘unknowns’ associated with that processing. By way of a related example – we know that astrometry of fast-moving near-Earth asteroids reported using typical CCD cameras and the usual reading of system clocks typically have consistent errors in the time of the observation of the order of two seconds – associated with issues such as whole-of-system latency, and inaccurate reading of the system clock. Basic message here – if you are using a Windows-based PC to time-stamp a video stream, you cannot assert an accuracy of better than about 1 second without independent testing.
5. On desired time accuracy. There are two aspects of this. Absolute and relative accuracy.
(a) Relative accuracy. If you were recording a high-speed light curve to measure the details of the Fresnel diffraction pattern (double stars, stellar diameter etc), relative timing is highly important, whereas absolute time accuracy is relatively unimportant. Generally speaking, the relative timing can be accurately established on the basis of the frame rate of the camera, and the system cock is largely irrelevant.
(b) Absolute accuracy. This is important for two separate issues. Firstly, when deriving relative positions of the occulting object to the occulted star (eg in reporting astrometry from an asteroidal occultation) you need to know the absolute time of the observation. In the astrometry report I send to the Minor Planet Center, the event time and uncertainty are specified to a precision of 0.0000001 days – or 0.009 seconds. Secondly, with asteroidal occultations we combine the observations from multiple observers at multiple locations to derive the shape of the asteroid. Successful combination of observations can only occur if everyone is using the same time base.
The practical situation as I am seeing it with our occultation observations (based on video at either 30 or 25 fps) is:
- for lunar occultations, the resolution associated at single frame rate is somewhat greater than the uncertainty in the shape of the lunar profile
- for asteroidal occultations, the resolution associated at single frame rate is generally greater than short-scale variations in the asteroid’s profile.
That is, current standard video rates are coincidently about right for extracting good data for both lunar and asteroidal occultations. Increasing the frame rate will not achieve much, as the benefits of any extra timing precision will be lost in the effects of other uncertainties. Decreasing the frame rate (as by integrating) is at the expense of resolution – but usually well justified when the alternative is no data at all.
In practical terms, inconsistencies in the time base become very apparent when combining multiple chords for an asteroidal occultation. My impression (& I put it no higher than that) is that the primary source of inconsistency arises when the time is based on NTP (ie computer-based time), followed by the DCF system.
Finally, to answer the question more specifically – I think we should be aiming at being able to time-stamp a video frame with a time that has an absolute accuracy of better than 10msec. VTI’s reliably achieve this. It is ‘possible’ for computer-based systems to achieve this, but independent testing is required (with mere assertion along the lines of ‘it should be achieving this’ being particularly dangerous.
Dave Herald
Murrumbateman, NSW
Australia
