Beeper Sync 3.3
| HOW TO USE IT | HOW IT WORKS | TROUBLESHOOTING | DOWNLOAD | HOME | FEEDBACK |
Here is some thechnical info (may be even too technical) about how BeeperSync works
The challenge of sending a pulse from the LPT port to an external device from a software running on a Windows machine with the precision of 5 ms from UTC is quite complex. There is a number of tasks that have to be performed with an accuracy better than 5 ms as in the end the errors add up. Those tasks, that have to be performed with a highest precision, include: Keeping the time internally, Synchronising and calibrating with an atomic clock NTP server over the internet, Calculating the error i.e. being able to self test and detect delays caused by the operating system.
Keeping the time internally
For the time keeping reference BeeperSync uses the internal CPU clock that operates in each processor. The method that is used to read the CPU clock ticks allows an accuracy of 800 ns. Additionally BeeperSync is a multi-threaded application and the time keeping thread runs with the highest priority possible in Windows. You will also notice that because of that BeeperSync is consuming considerable amount of CPU time. Even that this may slow down your other programs slightly it actualy allows us to get better precision. If you are experiensing more than just a small slow down please refer to the trobleshooting section.
Even with perfect reads of the CPU clock ticks over a period of 24 hours it is likely that the CPU time will drift slightly from UT. The drift value may vary but is usually below a few seconds and in many cases is much less than this. For some old computers though the drift may be considerably bigger than this. To correct the internally kept time for the CPU clock drift - BeeperSync adjusts the offset of the internal clock from UTC once a minute by quering the NTP server atomic clock each 53rd second of the minute. If you are using an old computer make sure you are using a broadband connection and have the optimization set for a broadband connection.
Calculating the error
Windows is a multi-tasking and multi-threading system. This means that there are many programs (pocesses) that are virtually running at the same time. It is virtually because your CPU can execute only one program at a time. To achieve the multi-tasking the operating system runs one process for a very short period of time and then switches to another process. Windows repeats this with all processes all the time and pretty much this is the only thing it is doing. As a reslt the user gets the impression that all of the programs are running simultaneously. You can also have independant small sub programs in your process which are called threads that also get execution time individually. This is how you can achieve separate tasks in your application to also appear to run simultaneously. The biggest issue related to time critical processes is that you never know exactly when the operating system will give some time to your application. You can however define a priority of your process and its threads telling Windows that your process has to be given execution time more often than the other processes. Still this is not a guarantee because some "system" processes (i.e. parts of the operating system program itself) have always higher priority.
The time keeping thread in BeeperSync is running with the highest priority possible for a program which is not part of the operating system. The only thing this thread is doing is to check the UTC time as frequently as it can. As you already know this is limited by the operating system and how many times the time keeping thread will have the ability to read the UTC time in a second depends on your processor speed and how many other programs are running at the same time. With an average computer the time keeping thread will be able to check the UTC a few ten thousand times in a second at least. As you can see this is a very good resolution but there is a possibility that the operating system switches the thread context at say 10:09:09.999999 UTC and gives execution time to another thread. Then when it switches back to our time keeping thread the UTC time may be for example 10:10:10.050000 already. Such a delay is unlikely to happen but is defenitely possible when some operating system process (usually related to communicating to a hardware device such as printer, modem or a floppy drive) requires some extra time and has to wait for the hardware to respond.
BeeperSync fortunately have no problems with identifying this delay caused by the operating system thread context switching and it constantly updates the label marked "Estimated time keeping precision" with the maximum delay detected. In all the tests which I have done on my computer BeeperSync was able to run for hours with a delay less than 1ms. The good thing is that while you are syncing your beeper you can monitor this error value and this will give you the confidence that everything is running perfectly well. If you see that the time keeping precision moves away from <1ms you can always restart BeeperSync and do another synchronisation.
Even if you don't pay attention to the error BeeperSync will not send a synchronising pulse to the LPT if the time delay after the sharp minute plus the UTC offset error is more than 45ms. If such a situation occurs BeeprSync will retry to sync the beeper box the next whole minute. The precision in determening the delay as I already mentioned is about 800ns (0.0000008 sec).
Only after the "pulse" has been sent to the LPT port, the time keeping thread will notify the GUI thread about the new UTC second and BeeperSync will update the UTC time label and will make a "beep". Please note that BeeperSync does not guarantee very high precision of displaying the time label and making the beep on time. The only operation which is guaranteed to happen with the highest accuracy is sending the "pulse" to the LPT port.
Synchronising and calibrating with an atomic clock NTP server over the internet
BeeperSync synchronises and calibrates with the NTP servers atomic clocks implementing RFC 2030. The error in determining the local clock offset from UTC is generally bigger than the time keeping error caused by the operating system. In the case of a dial-up internet connection it could be much bigger than the time keeping precision. BeeperSync will not allow you to start the syncing if the error is estimated to be more than 40ms. The bigest factor that affects the NTP syncing precision is your connection type and how many applications that the using internet are running in the same time you are running BeeperSync. If you stop all downloads you shouldn't have problem syncing with an error better than 40ms (40ms will allow another up to 5ms time keeping error for the 45ms threshold). With my broadband internet connection 95% of the time (i.e. when my wife is not watching online TV on the other comp) I can sync to the NTP time with an error of 3ms or less.
The synchronisation is done by calculating the UTC offset of the local clock. If we can get the local time with a high precision at the time we send the sync packet to the NTP server and then get the local time again when we receive the packet back we could calculate the offset of the local clock from UTC knowing when the packet has been received by the NTP server and when it was sent back and assuming that the travel time is exactly the same when sending and receiving. This is the method described in RFC 2030. The biggest error here comes from the assumption that the send and receive times will be the same. In reality your upload speed is usually lower than your download speed (unless you have a symertic connecton) and this causes an error. BeeperSync talks to the NTP server up to 50-60 times and gets five silimar in duration packets and then calculates the average UTC offset from them. After that the local clock to UTC offset is determined and updated again every 53-th second of the minute. If double the difference between the old and the new offset is bigger than the current estimated error, then the "Estimated max UTC offset" label is updated with this new error value. Basically what this means is that if BeeperSync shows you a small error during your syncing then you can rely that the error is really small.
Accuracy tests
In the first test I used the beeper timestamp function and Dave Gault's KIWI PC to measure how accurately the beeper was synced. I did 2 series of 10 measurements where I first synced BeeperSync with UTC before each of the series, then synced the beeper and then used its timestamp to test it with the KIWI time. The table below shows the result from those 20 measurements:
| Test performed with a dual-core Intel P4 650+ on 3.4 GHz and "Highest" BeeperSync priority | |||||||||||||||||||
| ±3ms (<1ms) | ±4ms (<1ms) | ||||||||||||||||||
| .997 | .999 | .999 | .999 | .997 | .997 | .999 | .998 | .999 | .999 | .001 | .999 | .999 | .999 | .999 | .998 | .998 | .999 | .998 | .999 |
The result clearly shows that the timestamps sent from the beeper box to the KIWI software were no more than 3ms away from UTC and most of the time just 1ms away. For the second test I did 4 series of 5 measurements on another computer:
| Test performed with a AMD Sempron 2600+ and "High" BeeperSync priority | |||||||||||||||||||
| ±6ms (<1ms) | ±12ms (±26ms) | ±9ms (<1ms) | ±6ms (±1ms) | ||||||||||||||||
| .998 | .997 | .997 | .998 | .999 | .998 | .998 | .999 | .997 | .998 | .999 | .999 | .997 | .998 | .997 | .998 | .999 | .999 | .998 | .998 |
From the second test we can see that because of the "High" BeeperSync priority (rather than "Highest" in the first test) there was an added time keeping error of 26ms in the second series and 1ms in the 4th series. The results are however no more than 3ms away from UTC. So even that the reported maximal error was bigger the syncing wasn't affected (i.e. the delay hasn't occured at the LTP beeper sync pulse second).
The next test I did was to check the errors estimated by BeeperSync. For this test I was syncing with NTP server while in the same time watching videos on YouTube. This way I was introducing a bigger synchronisation error and was then testing the real error with a synced beeper box using the KIWI PC.
The table below shows the results:
The results show that in all of the cases the actual error was well within the estimated error value by BeeperSync and most of the time was <=5ms. |
KIWI PC doing the timestamp measurements: |
Those 3 tests were performed with a broadband internet connection and with no other programs using internet during the time of the tests. There is one very interesting observation from those test results and that is the synced beeper box was almost all of the time before UTC. This shows that the time needed to send a packet to the NTP server was actually taking slightly more than receiving the packet back. As a result the calculated offset from UTC was putting the local clock 1ms before UTC. BeeperSync ver 1.03 includes correction for this 1ms.
The next tests show the time keeping accuracy of BeeperSync. The first graph shows the very first measurements done by Geoff. At this time BeeperSync did not have the time drift compensation implemented yet. On the graph you can see the UTC time measured using GPS when a pulse was sent by the BeeperSync every 10 seconds. The drift effect is clearly seen and the CPU clock has moved by about 2.5ms for 37 min.
The next graph shows the difference from UTC measured every 10 sec for a duration of 65 minutes. This time BeeperSync compensates for the CPU clock drift by re-syncing with the NTP server every minute. The test was done using a broadband internet connection with no browsing or downloading during the test. You can see how the UTC difference didn't move more than ±4ms. Again it is seen than the time was most of the time 1ms fast than UTC. The test was carried out with ver 1.02 that doesn't have this extra 1ms correction.
 |
And here is my inquisitive friend Charlie helping with the KIWI PC experiments. |
The last graph shows the 10 sec measurements done by Geoff for a duration of almost 20 minutes this time done on a dial-up connection. The internet connection was used for browsing during the experiement. You can see the error every minute when BeeperSync was re-syncing its clock to UTC. Also during each minute the 10 sec pulses were consistent to less than 0.1ms (Geoff can measure timestamps with the precision of 0.001ms). Still the total error was no more than 40ms away from UTC.
Accuracy test using KIWI OSD and NTSC Video (by Dave Gault)
On the left is the Beeper LED and on the right is KIWI OSD LED. At synchronisation of the BeeperSync reported UTC offset = 3ms; Precision <1ms. Each exposure has a duration of 17ms. I used the NTSC video because it's frame rate in not a whole integer. The start and stop times appear to walk a little bit for each exposure. We can use this to bracket the LED pulse start or leading edge. Alas PAL is no good for this because the frame rate is exactly 25fps.
 |
(a) Looking at the top field of the first frame we see that it ENDS at 2:40:57.992 and the Beeper LED is not lit. So the error is better than 0.008sec and is the LH bracket, so to speak. |
| (b) Looking at the second field of the first frame, the beeper LED is lit but all we can say is the LED lit SOMETIME during 2:40:57.992 and 2:40:58.009 the second frame is two seconds after the first. | |
 |
(c) Looking at the first field, then you can see that the exposure ended at 2:40:59.994 and the LED on but it appears to be not fully lit. Actually the LEDs switch on very fast, much shorter than 1ms IIRC. But in this case it appears to be not fully lit because it only received an exposure of 0.002seconds or less. This field is to RH bracket, so to speak. |
Put the (a) and (c) together, the earliest the LED could have come on is 2:40:57.992 and the latest is 2:40:59.994. So the LED switched on at 2:40:59.993 +/-0.001. Therefore the error of BeeperSync syncing the Beeper is 0.007 sec fast +/-0.001
Thanks to Geoff Hitchcox for the inspiration he gave me to write this program and for the continuing help with the testing, to Dave Gault for the support, for doing beta testing and for lending me his KIWI PC so I could do some testing myself, to Pauline Loader for helping me with instructions on how to synchronise her brain-child - the beeper boxes and to Dave Herald for pointing out the importance of creating such a tool for occultation timing observers.
Hristo Pavlov
30 September 2007