Hello,
I want to set my laptop time to the GPS time using a GPS receiver connected to the laptop. I am using windows OS. I am unable to find a software which can poll data from USB GPS receiver and set the laptop time. Can anybody suggest something?
Also most of the GPS receivers like Time Tools, Galleon etc come with a connection to the com port. But these days laptop doesn have the DB9 serial port. What is best solution for this??
I am breaking my head on this for many days now. Please help me out
I want to set my laptop time to the GPS time using a GPS receiver connected to the laptop. I am using windows OS. I am unable to find a software which can poll data from USB GPS receiver and set the laptop time. Can anybody suggest something?
Also most of the GPS receivers like Time Tools, Galleon etc come with a connection to the com port. But these days laptop doesn have the DB9 serial port. What is best solution for this??
I am breaking my head on this for many days now. Please help me out
Most USB GPS devices come with a device driver on an included CD to provide COM port serial output from the USB input. Exceptions are Delorme and Garmin GPS units.
Terry
Terry
You have apparently already found the software you need for setting the clock from a GPS receiver (Time Tools GPS Clock looks nice) so you just need to do what Terry said. Get the virtual COM port driver for your GPS receiver and you'll be in business.
...ken...
...ken...
Thanks Ken and Terry.
I also had one question. I want to set the laptop time with an accuracy of microseconds. Is this possible? I read the following in the GPS clock section of timetools
So I was thinking if microsecond accuracy or even millisecond accuracy is possible?
..jack
I also had one question. I want to set the laptop time with an accuracy of microseconds. Is this possible? I read the following in the GPS clock section of timetools
Quote:
The GPS clock utility can also update the system time of the host PC with GPS time. Note however, time synchronisation can only be achieved to the nearest second. Standard NMEA GPS devices do not have a pulse per second output that can be utilised by the serial port of a PC. Therefore, the microsecond accuracy that is available from TimeTools GPS T1000 and T2000 GPS timing receivers is not available with this software.
..jack
Hi Jack,
Simple answer: they are correct that consumer navigation GPS devices do not output the PPS signal so a program like GPS Clock cannot give you any better accuracy than can be extracted from the data output from the GPS receiver. It might actually be a bit better than 1 second. But there are so many factors they cannot control for that the best promise they can make is 1 second accuracy. But it's a free utility.
Millisecond and microsecond accuracy are possible on a PC.
But the crystal in the internal clock on a PC is about as accurate and stable as a cheap wristwatch (e.g. not very). So in order to maintain stable timing at that level of accuracy in a PC you would need connection to an accurate time server like the T2000 that you can use to monitor the PC timing fairly frequently. Or close proximity (~zero latency) connection to an NTP server that is connected to a T2000.
Do you understand time synchronization and how it really works, e.g. using the PPS signal from a time server device like the T2000 and why a pulse only once per second can give you millisecond or microsecond accuracy? Do you understand Accuracy? Stability? The difference?
What kind of application are you using that you want millisecond or microsecond accuracy?
...ken...
Simple answer: they are correct that consumer navigation GPS devices do not output the PPS signal so a program like GPS Clock cannot give you any better accuracy than can be extracted from the data output from the GPS receiver. It might actually be a bit better than 1 second. But there are so many factors they cannot control for that the best promise they can make is 1 second accuracy. But it's a free utility.
Millisecond and microsecond accuracy are possible on a PC.
But the crystal in the internal clock on a PC is about as accurate and stable as a cheap wristwatch (e.g. not very). So in order to maintain stable timing at that level of accuracy in a PC you would need connection to an accurate time server like the T2000 that you can use to monitor the PC timing fairly frequently. Or close proximity (~zero latency) connection to an NTP server that is connected to a T2000.
Do you understand time synchronization and how it really works, e.g. using the PPS signal from a time server device like the T2000 and why a pulse only once per second can give you millisecond or microsecond accuracy? Do you understand Accuracy? Stability? The difference?
What kind of application are you using that you want millisecond or microsecond accuracy?
...ken...
Hi ken,
I do understand the difference between accuracy and stability but I am not sure about the PPS signal.
I am trying to synchronize two laptops to a same time so that they provide exactly the same timestamps for the images. Images are taken at 30fps( frames per second) and can even go up to 115fps. I will be in a place where there is no internet access. The 2 laptops will be placed far apart. The only way I can synchronize time on two laptops is by using the GPS signal right?
-jack
I do understand the difference between accuracy and stability but I am not sure about the PPS signal.
I am trying to synchronize two laptops to a same time so that they provide exactly the same timestamps for the images. Images are taken at 30fps( frames per second) and can even go up to 115fps. I will be in a place where there is no internet access. The 2 laptops will be placed far apart. The only way I can synchronize time on two laptops is by using the GPS signal right?
-jack
[Warning for the casual reader, this is way long and a little bit technical.]
Jack,
Apologies in advance if some of this is redundant for you but I need to do the whole thing in order to make sure I do it right.
Accuracy -- Two pieces to this and they are both answers to the question: Accurate relative to what?
Relative to some "absolute" time. We typically treat Universal Coordinated Time (UTC), or what was originally called Greenwich Mean Time (GMT) as sort of the "absolute" time. Or more specifically, an atomic clock in the Greenwich Observatory, is considered to be "Zero" time, or as the military refers to it "Zulu".
If you need to sync to UTC, you need a signal that is traceable directly back to that atomic clock and without too many hops (latency) between. We typically do that by using less expensive atomic clocks that are placed nearer our location but which are constantly synchronized back to the master clock for UTC.
So, we can sync our PCs over the network to, say, Boulder, CO, in the US by using a program that knows how to use the network time protocol (NTP) to connect to an NTP server and sync up with it. If the sync program is a really good one it will try to get a good guess at network latency and factor in an adjustment for it.
Relative to another computer but independent of UTC. This seems like it would apply to your situation. You need two computers to be synchronized with each other to a high degree of accuracy. But it's not really important that they have any significant accuray relative to UTC. A few seconds or even a minute or two away from UTC are huge in the data synchronization world but for most practical purposes aren't a big deal for other stuff.
Pulse Per Second (PPS) - If you have a high accuracy timing device, like a Stratum One atomic clock, it can output a pulse every second on, say, a serial connection to the computer. There are two ways the computer can deal with this. The simplest, but least accurate is to read the timestamp message that follows over the serial connection nearest after the pulse is detected. This can be used by software on the computer to determine whether, and by how much, the internal clock has to be adjusted. Or alternatively, the pulse detection itself can be used directly by kernel level software to drive the timebase synchronization.
Naturally the next question is, If the pulses are coming only one per second, how can you get subsecond accuracy? Easy, Grasshopper. The pulses themselves are the accuracy. That is, the pulses are generated with huge accuracy, so by using them as the timebase for synchronization you can keep the computer sync'ed very tightly with the source of the PPS signal.
Also, you don't need to worry about the stability (drift) of the computer's internal clock because you are getting a fresh pulse every second. Even the crappiest crystal in the PC's internal clock can't drift enough to be significant in one second.
Consumer GPS signals. Consumer GPS receivers that are used primarily for navigation or geolocation functions are not designed to provide time synchronization. However, they can be used as a crude substitute in the field if one has the necessary software and is aware of the limits.
The data that is sent from the GPS receiver is a series of standard "sentences" that contain defined data. The data in those sentences are defined by the NMEA 0183 (National Marine Electronics Association standard 0183) or NMEA 2000.
The NMEA 0183 standard sentences allow the GPS receiver to send information related to Time & Date, Geographic Position - Latitude/Longitude, and individual satellite information. It's the Time & Date information that matters here.
The GPS satellites each contain three Stratum One cesium atomic clocks in them. These are highly stable clocks that were originally calibrated with UTC, so the signals that originate from them can be considered a good sync link back to UTC, and therefore a good source of synchronization on their own.
However, there are a few minor hitches in this that need to be understood. Latency is always the killer when trying to sync two or more devices together. That is, essentially, the time it takes for the signal to travel from sender to receiver. In the case of the extremely weak GPS signals, there are many things that will affect this. These are mainly related to atmospheric conditions from high in the atmosphere to anything affecting only local conditions.
If two devices are close enough together to be connected to the same GPS receiver, say via Bluetooth, it really won't matter because they'll be getting the same signal and by using it will be sync'ed as accurately as that signal will allow.
If they are too far apart to use the same GPS receiver but close enough together that they are affected by the same local atmospheric conditions, say, within a few miles of each other, it still won't be an issue as long as they use the same make/model of receiver and the same software.
If they are so far apart that they are being affected by significantly different atmospheric conditions, all may not be lost. Most GPS receivers support a protocol called WAAS (Wide Area Augmentation System). This is, to keep it really simple, a system of satellites and ground stations that are used to provide GPS signal corrections. These corrections account for GPS satellite orbital drift and clock drift plus signal delays caused by conditions in the atmosphere and ionosphere.
So, if our two GPS receivers that are far apart both have WAAS enabled they will still be pretty close, accuracy-wise, after the corrections are done.
Finally, we get to the question of whether a couple of consumer-grade GPS receivers will work for your purposes.
I think so. Here's why...
Just like PPS, most consumer-grade GPS receivers are sending updated data to the computer as a group of NMEA sentences once per second (1Hz). Indeed, some GPS receivers will send them out even more frequently, as many as five per second (5Hz). So, like PPS, the computer gets a fresh bit of information to sync with every second. And if the GPS signals is good and corrected fairly well, it will be fairly accurate, relative to UTC, and fairly stable.
If you have two computers using the same make and model GPS receiver of good quality with WAAS enabled and using the same software for keeping their clocks in sync, I think you should be able to keep them close enough for 30 frames per second with little difficulty and even 115fps shouldn't be a real problem.
Indeed, if you trigger the shooting sequence manually on each computer, you will have more of a time delta (offset) caused by when you start the shooting sequence on each computer than from any differences between the clocks. That is, if you do not trigger the shooting sequences at precisely the same instant on both computers, there will immediately be a small offset that will need to be corrected for.
I expect you will need some way to correct for any slight offset caused by operating procedutes anyway. If you can do that, correcting for any tiny differences between the clocks in the two computers will be trivial.
If you can't correct for procedure-induced differences, the issue of how tightly the computer clocks are locked together isn't very relevant.
On the other hand, if you can trigger the shooting sequences from software so that they will start at identical times on each computer, it will be possible to determine how tightly the computers are tied together by simply examining the timestamps in the first few frames.
I hope that all makes sense. I've tried to keep it simple without being patronizing, in case others may be interested.
I hope it's helpful.
How far apart will the two computers be: feet, meters, miles, continents?
Will your editing software allow you to adjust for a minor offset as long as it's consistent?
Could you share what you're up to without getting into trouble? The possibilities are interesting.
...ken...
Jack,
Apologies in advance if some of this is redundant for you but I need to do the whole thing in order to make sure I do it right.
Accuracy -- Two pieces to this and they are both answers to the question: Accurate relative to what?
Relative to some "absolute" time. We typically treat Universal Coordinated Time (UTC), or what was originally called Greenwich Mean Time (GMT) as sort of the "absolute" time. Or more specifically, an atomic clock in the Greenwich Observatory, is considered to be "Zero" time, or as the military refers to it "Zulu".
If you need to sync to UTC, you need a signal that is traceable directly back to that atomic clock and without too many hops (latency) between. We typically do that by using less expensive atomic clocks that are placed nearer our location but which are constantly synchronized back to the master clock for UTC.
So, we can sync our PCs over the network to, say, Boulder, CO, in the US by using a program that knows how to use the network time protocol (NTP) to connect to an NTP server and sync up with it. If the sync program is a really good one it will try to get a good guess at network latency and factor in an adjustment for it.
Relative to another computer but independent of UTC. This seems like it would apply to your situation. You need two computers to be synchronized with each other to a high degree of accuracy. But it's not really important that they have any significant accuray relative to UTC. A few seconds or even a minute or two away from UTC are huge in the data synchronization world but for most practical purposes aren't a big deal for other stuff.
Pulse Per Second (PPS) - If you have a high accuracy timing device, like a Stratum One atomic clock, it can output a pulse every second on, say, a serial connection to the computer. There are two ways the computer can deal with this. The simplest, but least accurate is to read the timestamp message that follows over the serial connection nearest after the pulse is detected. This can be used by software on the computer to determine whether, and by how much, the internal clock has to be adjusted. Or alternatively, the pulse detection itself can be used directly by kernel level software to drive the timebase synchronization.
Naturally the next question is, If the pulses are coming only one per second, how can you get subsecond accuracy? Easy, Grasshopper. The pulses themselves are the accuracy. That is, the pulses are generated with huge accuracy, so by using them as the timebase for synchronization you can keep the computer sync'ed very tightly with the source of the PPS signal.
Also, you don't need to worry about the stability (drift) of the computer's internal clock because you are getting a fresh pulse every second. Even the crappiest crystal in the PC's internal clock can't drift enough to be significant in one second.
Consumer GPS signals. Consumer GPS receivers that are used primarily for navigation or geolocation functions are not designed to provide time synchronization. However, they can be used as a crude substitute in the field if one has the necessary software and is aware of the limits.
The data that is sent from the GPS receiver is a series of standard "sentences" that contain defined data. The data in those sentences are defined by the NMEA 0183 (National Marine Electronics Association standard 0183) or NMEA 2000.
The NMEA 0183 standard sentences allow the GPS receiver to send information related to Time & Date, Geographic Position - Latitude/Longitude, and individual satellite information. It's the Time & Date information that matters here.
The GPS satellites each contain three Stratum One cesium atomic clocks in them. These are highly stable clocks that were originally calibrated with UTC, so the signals that originate from them can be considered a good sync link back to UTC, and therefore a good source of synchronization on their own.
However, there are a few minor hitches in this that need to be understood. Latency is always the killer when trying to sync two or more devices together. That is, essentially, the time it takes for the signal to travel from sender to receiver. In the case of the extremely weak GPS signals, there are many things that will affect this. These are mainly related to atmospheric conditions from high in the atmosphere to anything affecting only local conditions.
If two devices are close enough together to be connected to the same GPS receiver, say via Bluetooth, it really won't matter because they'll be getting the same signal and by using it will be sync'ed as accurately as that signal will allow.
If they are too far apart to use the same GPS receiver but close enough together that they are affected by the same local atmospheric conditions, say, within a few miles of each other, it still won't be an issue as long as they use the same make/model of receiver and the same software.
If they are so far apart that they are being affected by significantly different atmospheric conditions, all may not be lost. Most GPS receivers support a protocol called WAAS (Wide Area Augmentation System). This is, to keep it really simple, a system of satellites and ground stations that are used to provide GPS signal corrections. These corrections account for GPS satellite orbital drift and clock drift plus signal delays caused by conditions in the atmosphere and ionosphere.
So, if our two GPS receivers that are far apart both have WAAS enabled they will still be pretty close, accuracy-wise, after the corrections are done.
Finally, we get to the question of whether a couple of consumer-grade GPS receivers will work for your purposes.
I think so. Here's why...
Just like PPS, most consumer-grade GPS receivers are sending updated data to the computer as a group of NMEA sentences once per second (1Hz). Indeed, some GPS receivers will send them out even more frequently, as many as five per second (5Hz). So, like PPS, the computer gets a fresh bit of information to sync with every second. And if the GPS signals is good and corrected fairly well, it will be fairly accurate, relative to UTC, and fairly stable.
If you have two computers using the same make and model GPS receiver of good quality with WAAS enabled and using the same software for keeping their clocks in sync, I think you should be able to keep them close enough for 30 frames per second with little difficulty and even 115fps shouldn't be a real problem.
Indeed, if you trigger the shooting sequence manually on each computer, you will have more of a time delta (offset) caused by when you start the shooting sequence on each computer than from any differences between the clocks. That is, if you do not trigger the shooting sequences at precisely the same instant on both computers, there will immediately be a small offset that will need to be corrected for.
I expect you will need some way to correct for any slight offset caused by operating procedutes anyway. If you can do that, correcting for any tiny differences between the clocks in the two computers will be trivial.
If you can't correct for procedure-induced differences, the issue of how tightly the computer clocks are locked together isn't very relevant.
On the other hand, if you can trigger the shooting sequences from software so that they will start at identical times on each computer, it will be possible to determine how tightly the computers are tied together by simply examining the timestamps in the first few frames.
I hope that all makes sense. I've tried to keep it simple without being patronizing, in case others may be interested.
I hope it's helpful.
How far apart will the two computers be: feet, meters, miles, continents?
Will your editing software allow you to adjust for a minor offset as long as it's consistent?
Could you share what you're up to without getting into trouble? The possibilities are interesting.
...ken...
Jack,
I tried to locate Time Tools. I did get to the manufacturer's site, but did not see what I thought was the right download icon. Please clue me in on the link and download procedure.
Very interesting thread... Way to go, Ken...
I tried to locate Time Tools. I did get to the manufacturer's site, but did not see what I thought was the right download icon. Please clue me in on the link and download procedure.
Very interesting thread... Way to go, Ken...
Here's the page.
GPS Clock
Scroll down and look just below the image of the example config dialogue and you will see the word "Download" in bold letters.
That's not the link.
Look carefully just below the bold paragraph for this line:
"Download version 1.0.001 (20 Dec 2006) Download (1929 KB)"
The second instance of the word "download" is the link. ... Or maybe the link in the line above will get you the download...
...ken...
GPS Clock
Scroll down and look just below the image of the example config dialogue and you will see the word "Download" in bold letters.
That's not the link.
Look carefully just below the bold paragraph for this line:
"Download version 1.0.001 (20 Dec 2006) Download (1929 KB)"
The second instance of the word "download" is the link. ... Or maybe the link in the line above will get you the download...
...ken...
Thanks, Ken, you are most gracious... I will give it a try...
Hi ken,
Thank you very much for your wonderful explanation.
My 2 laptops will be say few hundred meters apart. The trigger to start the capturing of images is done by the software. I am not aware of the flexibilities of that software. All I know is that software captures the images and time stamps it using system clock. The time stamp is accurate to microseconds. My task is to set the system time so that the time stamps provided by the 2 laptops interpret the same image take at 2 different angles at same point of time. So that we can do some analysis on the 2 images which represent the same data taken at 2 different angles.
I am yet to buy a GPS receiver and also yet to fix the software to set the system clock. I saw many GPS receivers and as I mentioned in my first post was fully confused with both software and GPS receivers.
I think the timetools software GPS clock will not be an option for me right??
I need to look out for some other softwares
-jack
Thank you very much for your wonderful explanation.
My 2 laptops will be say few hundred meters apart. The trigger to start the capturing of images is done by the software. I am not aware of the flexibilities of that software. All I know is that software captures the images and time stamps it using system clock. The time stamp is accurate to microseconds. My task is to set the system time so that the time stamps provided by the 2 laptops interpret the same image take at 2 different angles at same point of time. So that we can do some analysis on the 2 images which represent the same data taken at 2 different angles.
I am yet to buy a GPS receiver and also yet to fix the software to set the system clock. I saw many GPS receivers and as I mentioned in my first post was fully confused with both software and GPS receivers.
I think the timetools software GPS clock will not be an option for me right??
I need to look out for some other softwares
-jack
The Time Tools software could work.
How long a period will the shooting sessions be? Will they be for hours or minutes?
In your situation you don't need absolute stability of the time. What you need is reasonable stability in the time drift. That is, it would be good if you used identical computers. Computers that are only a few digits apart in their serial numbers (so you know they went through the assembly line at nearly the same time and they will likely have identical components in their system clock).
If both computers clocks drift (gain or lose time) at very nearly the same rate, that's okay. You need the system clocks to be very close to each other in the timestamps. So if they can be set very close to each other immediately before you start shooting, and if they drift (gain/lose time) at very close to the same rate, they will still be as close together in their timestamps as when the clocks were set.
With this specific application, you do not want to be re-syncing the system clocks partway through a shooting session unless you can ensure that the sync updates to the clocks occur simultaneously on both computers.
That's really really hard to do. Actually, nearly impossible.
I know it may sound counter-intuitive, but you are actually better off with letting the system clocks drift than trying to keep them "accurate".
If you recall my explanation of "accuracy" you might recall that you can keep the two computers in sync relative to some "absolute" time, e.g. UTC. Or you can just worry about keeping them in sync with each other.
In your application, the only thing that matters is that they stay in sync with each other.
If it were me, I would do some immediate "lab" testing. If the two computers can be connected to the internet, I would download a program called NISTime and install it on both computers. It will sync the computers' clocks with a time server of your selection from a list included with the program.
Try to run the NISTime program as close to simultaneously on both computers as you can. Then do a shooting session as you would in the field. Compare the timestamps on some frames from early in the shoot and near the end of the shoot.
If you synced the computers very nearly simultaneously and if the drift in the system clocks is very nearly identical throughout the shooting session, you should be in business because you should be able to use GPS Clock in the field to sync the times on the two computers the same way you used NISTime to sync them in the lab tests.
I hope that makes sense.
I'll talk a little about your GPS selection concerns in another post, to keep this one from turning into another book. Perhaps tomorrow.
...ken...
How long a period will the shooting sessions be? Will they be for hours or minutes?
In your situation you don't need absolute stability of the time. What you need is reasonable stability in the time drift. That is, it would be good if you used identical computers. Computers that are only a few digits apart in their serial numbers (so you know they went through the assembly line at nearly the same time and they will likely have identical components in their system clock).
If both computers clocks drift (gain or lose time) at very nearly the same rate, that's okay. You need the system clocks to be very close to each other in the timestamps. So if they can be set very close to each other immediately before you start shooting, and if they drift (gain/lose time) at very close to the same rate, they will still be as close together in their timestamps as when the clocks were set.
With this specific application, you do not want to be re-syncing the system clocks partway through a shooting session unless you can ensure that the sync updates to the clocks occur simultaneously on both computers.
That's really really hard to do. Actually, nearly impossible.
I know it may sound counter-intuitive, but you are actually better off with letting the system clocks drift than trying to keep them "accurate".
If you recall my explanation of "accuracy" you might recall that you can keep the two computers in sync relative to some "absolute" time, e.g. UTC. Or you can just worry about keeping them in sync with each other.
In your application, the only thing that matters is that they stay in sync with each other.
If it were me, I would do some immediate "lab" testing. If the two computers can be connected to the internet, I would download a program called NISTime and install it on both computers. It will sync the computers' clocks with a time server of your selection from a list included with the program.
Try to run the NISTime program as close to simultaneously on both computers as you can. Then do a shooting session as you would in the field. Compare the timestamps on some frames from early in the shoot and near the end of the shoot.
If you synced the computers very nearly simultaneously and if the drift in the system clocks is very nearly identical throughout the shooting session, you should be in business because you should be able to use GPS Clock in the field to sync the times on the two computers the same way you used NISTime to sync them in the lab tests.
I hope that makes sense.
I'll talk a little about your GPS selection concerns in another post, to keep this one from turning into another book. Perhaps tomorrow.
...ken...
Just a quick note on GPS selection. To ease your mind that there are still options in case a consumer-grade navigation GPS won't do the job, you can also buy GPS devices that are designed to do exactly what you want. They use GPS signals to acquire sync. They connect to the computer and deliver PPS signals for synchronization. So a couple of them would get you in business if you really need to go that route.
High precision NTP Time Server, precision timing and accuracy solutions synchronized by GNSS: ZTI
The z100 runs on 12V and the z200 runs on AC.
And/or you can connect a better quality clock to the parallel port, if you have one, using their High Precision Clock product.
Or the Exactime 300 which is basically a standard navigation GPS receiver that also does PPS.
Lots of options.
...ken...
High precision NTP Time Server, precision timing and accuracy solutions synchronized by GNSS: ZTI
The z100 runs on 12V and the z200 runs on AC.
And/or you can connect a better quality clock to the parallel port, if you have one, using their High Precision Clock product.
Or the Exactime 300 which is basically a standard navigation GPS receiver that also does PPS.
Lots of options.
...ken...
ken,
Our experiment usually runs for say around 45mins to 1 hr.
I understand accuracy in my case will be keeping the 2 laptops in sync with each other. But here the only reference clock will be the UTC through GPS receiver. One laptop has absolutely no idea about what is going on in the other one. I think even if we start capturing images at different instants it should not be a problem because the system time will be already synchronized to GPS signal in both the laptops and hence images will be time stamped accordingly.Is this assumption acceptable??
I saw the link given by you:
High precision NTP Time Server, precision timing and accuracy solutions synchronized by GNSS: ZTI
But most of them require RS 232 port which most of the laptops doesn have.
I know u have already mentioned about using virtual com port drivers, but is there any other work around for this ??..Do we get any good USB GPS receivers because most of the GPS receivers I have seen are RS232 compatible and not with USB??
-jack
Our experiment usually runs for say around 45mins to 1 hr.
I understand accuracy in my case will be keeping the 2 laptops in sync with each other. But here the only reference clock will be the UTC through GPS receiver. One laptop has absolutely no idea about what is going on in the other one. I think even if we start capturing images at different instants it should not be a problem because the system time will be already synchronized to GPS signal in both the laptops and hence images will be time stamped accordingly.Is this assumption acceptable??
I saw the link given by you:
High precision NTP Time Server, precision timing and accuracy solutions synchronized by GNSS: ZTI
But most of them require RS 232 port which most of the laptops doesn have.
I know u have already mentioned about using virtual com port drivers, but is there any other work around for this ??..Do we get any good USB GPS receivers because most of the GPS receivers I have seen are RS232 compatible and not with USB??
-jack
Ken,
Thanks for the link. I have installed Time Tools and have it reading from the GPS signal. The computer is configured as follows: Update for daylight savings = yes; Time zone = Central; Update from Net = no.
There seems to be a slight lag in the sync for the seconds. How do I test to see that the PC time is actually being feed by Time Tools? I changed the hours display on the PC clock and it did not correct back to the present hour.
Very interesting thread! Thanks for the help.
Thanks for the link. I have installed Time Tools and have it reading from the GPS signal. The computer is configured as follows: Update for daylight savings = yes; Time zone = Central; Update from Net = no.
There seems to be a slight lag in the sync for the seconds. How do I test to see that the PC time is actually being feed by Time Tools? I changed the hours display on the PC clock and it did not correct back to the present hour.
Very interesting thread! Thanks for the help.
I did some more research and it appears that Time Tools will not correct for an error of greater than 15 minutes. So, I induced an error of 10 minutes. The time did not update to correct the error. Accordingly, my question still stands: how do I check to comfirm that the PC is using Time Tools for the sync feed.
Thanks!
Thanks!
Jack,
Most consumer-grade GPS navigation receivers come with either USB or Bluetooth, not RS-232 DB-9 connectors.
All of the consumer-grade USB GPS navigation receivers come with a driver to create a virtual COM port because many of the laptop navigation programs do not know how to communicate directly with a USB-connected receiver. The Bluetooth stack with Bluetooth receivers also allow you to direct the data to a virtual COM port for software that cannot communicate directly with Bluetooth.
I do not consider those devices in the ZTI link I posted to be either consumer-grade or navigation receivers.
If you are interested in a device like those from ZTI you simply purchase a USB-to-serial adapter. They are a cable with a DB-9 connector on one end and a USB connector on the other. They will allow you to connect a serial device to a USB port on your computer and will include a driver to create a virtual COM port for the software.
The only thing I'm not sure of with USB-to-Serial adapters and virtual COM ports is how well they deal with some of the pin-specific signals. If you purchase a device that sends the PPS pulse on the DCD (Data Carrier Detect) pin, for instance, will the virtual COM driver assert it properly for the monitoring software? I don't know the answer.
If you decide to go with a device that does PPS and, therefore, must connect by a serial port, you must talk with the manufacturer to see exactly what they recommend you use to connect to a computer that does not have a real RS-232/RS-422 port.
...ken...
Most consumer-grade GPS navigation receivers come with either USB or Bluetooth, not RS-232 DB-9 connectors.
All of the consumer-grade USB GPS navigation receivers come with a driver to create a virtual COM port because many of the laptop navigation programs do not know how to communicate directly with a USB-connected receiver. The Bluetooth stack with Bluetooth receivers also allow you to direct the data to a virtual COM port for software that cannot communicate directly with Bluetooth.
I do not consider those devices in the ZTI link I posted to be either consumer-grade or navigation receivers.
If you are interested in a device like those from ZTI you simply purchase a USB-to-serial adapter. They are a cable with a DB-9 connector on one end and a USB connector on the other. They will allow you to connect a serial device to a USB port on your computer and will include a driver to create a virtual COM port for the software.
The only thing I'm not sure of with USB-to-Serial adapters and virtual COM ports is how well they deal with some of the pin-specific signals. If you purchase a device that sends the PPS pulse on the DCD (Data Carrier Detect) pin, for instance, will the virtual COM driver assert it properly for the monitoring software? I don't know the answer.
If you decide to go with a device that does PPS and, therefore, must connect by a serial port, you must talk with the manufacturer to see exactly what they recommend you use to connect to a computer that does not have a real RS-232/RS-422 port.
...ken...
Quote:
I understand accuracy in my case will be keeping the 2 laptops in sync with each other. But here the only reference clock will be the UTC through GPS receiver. One laptop has absolutely no idea about what is going on in the other one. I think even if we start capturing images at different instants it should not be a problem because the system time will be already synchronized to GPS signal in both the laptops and hence images will be time stamped accordingly.Is this assumption acceptable??
That is why I recommended that you do some testing immediately. You do not need a GPS receiver to do a useful test right now. You can use the internet to sync the computer clocks, use your expected procedure to shoot some videos for the expected amount of time and check the timestamps, as I described in one of my previous posts. You do not need to rely on my judgment. You can easily perform some testing that will tell you if a simple and cheap solution will work or not.
Here are some programs you can use to sync your PC clocks over the internet to start your testing.
I use NISTime because it works and because I've been using it for twenty years when it was the only thing available. Others may be prettier and easier to use.
http://www.nist.gov/physlab/div847/grp40/upload/NIST-Time-software.exe
Here is a page that lists more software for setting your time to an atomic clock. I have not tried these. I only offer them as alternatives so you will have a choice.
Publishers of Time and Frequency Software
At this point I would stop worrying about GPS stuff and perform a simple test to see what exact concerns you might have.
1. Set the computers up so you can shoot something in a way that you will in the field, except not so far apart.
2. Use one of the above programs to set the clocks on the computers. You will need to connect them to the internet for this, maybe with cables or wifi.
3. Shoot a test session for as long as you will in the field.
4. Use the videos the way you plan to, e.g. post-process them or view them or whatever you plan to do with them.
5. How did it work out? Was there a problem? What is the nature of the problem?
...ken...
Quote:
I did some more research and it appears that Time Tools will not correct for an error of greater than 15 minutes. So, I induced an error of 10 minutes. The time did not update to correct the error.
Accordingly, my question still stands: how do I check to comfirm that the PC is using Time Tools for the sync feed.
Accordingly, my question still stands: how do I check to comfirm that the PC is using Time Tools for the sync feed.
If so, you already have checked. If GPS Clock did not correct the error it is not useful.
For whatever it's worth, GPS Clock will not provide a sync feed. That is not its purpose. If someone wants a proper "sync feed" they will need buy a device like those listed on the ZTI web site for that specific purpose.
To use a consumer navigation GPS receiver we would need a program similar to GPS Clock but which will correct much smaller time deltas, similar to what NISTime will do from an atomic clock time server over the internet.
This is still not a "sync feed". It is simply a one-time correction that you can do manually any time you want to. Or you can do it on a timed basis, either through the program or using Windows Scheduler.
For the cheap consumer-grade solution to Jack's situation, I envision using something like GPS Clock to do a one-time sync of the two computers' clocks and then do a shooting session. For each shooting session, if necessary, run the clock sync program again just before shooting.
Now that I think about it, it will still be possible to use GPS Clock by simply setting the PC clocks to be "wrong" by more than fifteen minutes, thus forcing GPS Clock to correct the clocks. This should work as long as GPS Clock will correct the PC clock to exactly one second.
...ken...
I have discovered that the sync feed function is working. What I needed to do to test was induce the time error and close the Windows clock. After closing, Time Tools forces the Windows Clock to the correct "Atomic Time." The updates seem to be constant and continuous.
I don't know how the Windows clock is getting the feed, and I don't need to, as long as testing proves it is working.
This feature will be great for true plotting and piloting by paper chart and pencil. Kewl
I don't know how the Windows clock is getting the feed, and I don't need to, as long as testing proves it is working.
This feature will be great for true plotting and piloting by paper chart and pencil. Kewl
Additional testing revealed that the sync update seems to occur only once per minute. I don't know whether Windows Clock is only sampling once per minute or if Time Tools is only sending the feed once per minute. Without the answer to that question, I don't know if the update rate could be improved.
I also tested with the automatic net update function turned back on. Time tools continued to operate in this configuration. I am leaving that feature on so that my computer will update the time by the best available feed, whether that be Time Tools or the Net.
As an aside, COMPASS seems to run the time from the GPS receiver (and not from Windows Clock). However, it seems to present the time display subject to the Widows Clock settings regarding Time Zone, etc. More testing is needed to confirm these initial impressions about COMPASS.
I also tested with the automatic net update function turned back on. Time tools continued to operate in this configuration. I am leaving that feature on so that my computer will update the time by the best available feed, whether that be Time Tools or the Net.
As an aside, COMPASS seems to run the time from the GPS receiver (and not from Windows Clock). However, it seems to present the time display subject to the Widows Clock settings regarding Time Zone, etc. More testing is needed to confirm these initial impressions about COMPASS.
Okay, calm down. Glad to hear it is doing something useful for you.
Now we need to be reasonable about expectation.
1. How much accuracy do you really need? For the purposes you mentioned, not a heckuva lot. Probably correct to one second, updated once a minute is way overkill.
2. How often does it need to update to maintain the accuracy? Well, even the crappiest PC clock won't drift enough in sixty seconds to be an issue for your purposes. Probably not for Jack's purposes, either. For your pusposes, probably once a day would be sufficient. Depends on how flakey the clock is. One of the towers in my office gets about three seconds ahead in a week. The other loses about a second in a week.
3. Your GPS needs to have a good look at the satellites, have WAAS enabled, be running for long enough to download the latest ephemeris tables from the satellite (typically a minimum of half an hour) and also long enough to be sure things have stabilized (typically twenty minutes, longer is better).
For your navigation purposes you want a reasonable degree of accuracy relative to UTC. You'll do more to ensure your accuracy relative to UTC by ensuring a good and stable GPS signal with up to date WAAS correction before doing the clock correction than by sweating how often the PC clock gets corrected.
Actually, for your purposes you probably don't even need to worry about the PC clock if what you want is a time display to use for plotting and piloting with charts and pencil. Either GPS Clock or Compass will give you the time readout you are looking for. It doesn't even matter if they update the PC's clock. Any time you want an accurate time reading you just need to be sure you've got a stable GPS reading and have had long enough to acquire the latest WAAS data, then fire up one of the GPS clocks.
For Jack's purposes, time relative to UTC is not relevant. He just needs the clocks on the two computers to be really close when the shooting starts and the time drift during the shooting to be nearly identical.
For Jack, it's more important to test the time drift on the two computers to make sure they are really close and going in the same direction than it is to get really close to UTC. He doesn't even need a GPS to do that.
For his purposes, in the field he will still need to make sure he gives the GPS receivers time to stabilize, just as you will need to do, but for a different reason. He doesn't care about accuracy relative to UTC. But by ensuring both GPS receivers have stabilized and are giving the same readings he has the best chance of getting the PC clocks set really close to each other.
...ken...
Now we need to be reasonable about expectation.
1. How much accuracy do you really need? For the purposes you mentioned, not a heckuva lot. Probably correct to one second, updated once a minute is way overkill.
2. How often does it need to update to maintain the accuracy? Well, even the crappiest PC clock won't drift enough in sixty seconds to be an issue for your purposes. Probably not for Jack's purposes, either. For your pusposes, probably once a day would be sufficient. Depends on how flakey the clock is. One of the towers in my office gets about three seconds ahead in a week. The other loses about a second in a week.
3. Your GPS needs to have a good look at the satellites, have WAAS enabled, be running for long enough to download the latest ephemeris tables from the satellite (typically a minimum of half an hour) and also long enough to be sure things have stabilized (typically twenty minutes, longer is better).
For your navigation purposes you want a reasonable degree of accuracy relative to UTC. You'll do more to ensure your accuracy relative to UTC by ensuring a good and stable GPS signal with up to date WAAS correction before doing the clock correction than by sweating how often the PC clock gets corrected.
Actually, for your purposes you probably don't even need to worry about the PC clock if what you want is a time display to use for plotting and piloting with charts and pencil. Either GPS Clock or Compass will give you the time readout you are looking for. It doesn't even matter if they update the PC's clock. Any time you want an accurate time reading you just need to be sure you've got a stable GPS reading and have had long enough to acquire the latest WAAS data, then fire up one of the GPS clocks.
For Jack's purposes, time relative to UTC is not relevant. He just needs the clocks on the two computers to be really close when the shooting starts and the time drift during the shooting to be nearly identical.
For Jack, it's more important to test the time drift on the two computers to make sure they are really close and going in the same direction than it is to get really close to UTC. He doesn't even need a GPS to do that.
For his purposes, in the field he will still need to make sure he gives the GPS receivers time to stabilize, just as you will need to do, but for a different reason. He doesn't care about accuracy relative to UTC. But by ensuring both GPS receivers have stabilized and are giving the same readings he has the best chance of getting the PC clocks set really close to each other.
...ken...
I've tested Compass and it does not interact with the PC clock at all.
I fired up Compass with my Bluetooth GPS and waited until there was a lock and a time display in Compass.
I set the PC clock to be two minutes slow. No effect on the Compass display.
I waited for a couple of minutes and Compass did not update the PC clock. The two sat there running happily two minutes apart.
It appears that there is no interaction between them at all.
I can't test GPS Clock. It only allows selection of COM ports 1 or 2. When I fire up my Bluetooth GPS is appears on COM3 because my tower has two real serial ports on it. Yeah, I know I could mess around with Device Manager and change things around but that's too much like work. And I would have to change it all back when I'm done.
Perhaps later I'll fire up the laptop and see how it works.
...ken...
I fired up Compass with my Bluetooth GPS and waited until there was a lock and a time display in Compass.
I set the PC clock to be two minutes slow. No effect on the Compass display.
I waited for a couple of minutes and Compass did not update the PC clock. The two sat there running happily two minutes apart.
It appears that there is no interaction between them at all.
I can't test GPS Clock. It only allows selection of COM ports 1 or 2. When I fire up my Bluetooth GPS is appears on COM3 because my tower has two real serial ports on it. Yeah, I know I could mess around with Device Manager and change things around but that's too much like work. And I would have to change it all back when I'm done.
Perhaps later I'll fire up the laptop and see how it works.
...ken...
Okay, I forced the device change so I could use COM2 at 4800. That made GPS Clock happy.
1. It only displays UTC. Not a big deal. Just an observation.
2. It's easy to get it to set the PC clock. You just click the Config button and check the option to Set PC System Time.
3. Also on the Config screen you can set the frequency that it should update the PC clock. It's not entirely clear what all the ticks mean and which end of the scale is more often or less often.
4. I tested by manually setting the PC clock wrong and watching GPS Clock reset it. I was able to force a reset by changing the PC clock to only a few seconds off. Within a couple of seconds it was reset.
Now I have to go change the COM port back so I don't forget and screw myself up the next time I go to use it.
...ken...
1. It only displays UTC. Not a big deal. Just an observation.
2. It's easy to get it to set the PC clock. You just click the Config button and check the option to Set PC System Time.
3. Also on the Config screen you can set the frequency that it should update the PC clock. It's not entirely clear what all the ticks mean and which end of the scale is more often or less often.
4. I tested by manually setting the PC clock wrong and watching GPS Clock reset it. I was able to force a reset by changing the PC clock to only a few seconds off. Within a couple of seconds it was reset.
Now I have to go change the COM port back so I don't forget and screw myself up the next time I go to use it.
...ken...
Don't forget to change whichever GPS you used back to its old COM port too.
Terry
Terry
Since the PCs are relatively close would it be possible to run an Ethernet cable or WiFi signal between them?
Couldn't you then run an NTP server on PC1 and sync PC2 to PC1?
Andrew Watson
Perth, Western Australia
Couldn't you then run an NTP server on PC1 and sync PC2 to PC1?
Andrew Watson
Perth, Western Australia
Hi Andrew,
Good to hear from you again.
It might be possible but it's rather complicated. If they need that much accuracy AND stability the simplest method would be to buy a couple of the model 200 devices from ZTI and use them.
I'm not yet convinced they need that much accuracy or stability. I'm pretty sure if they use a pair of consumer GPSs to set the PC clocks before each shooting session the computer clocks should stay similar enough for that long. At most they would need to resync the clocks between sessions.
The key is to make sure they have two computers whose time drift is very similar and in the same direction (e.g. faster/slower).
Think of it this way: the time between any two timestamps in the video does not to be exact. It merely needs to be very similar between the two computers.
So, if you are able to start the shooting on both computers at very nearly the same time there will be a specific small difference between the timestamps on the very first frame of the two videos. That will be caused by two things: the small difference introduced by not being able to sync the computers exactly simultaneously and by not being able to start the shooting exactly simultaneously. This difference is, then, a control.
So you should then be able to look at any random frames on the two videos, lets say the 27,465th frames, and the timestamps should have the same difference between them as the first frames have.
I believe you can get there, within any tolerances Jack needs, with just a pair of consumer GPS receiver and a program like GPS Clock. Then, by syncing the two computers in the field with that setup before each shoot, they will have the timestamps on the two videos close enough to get the job done.
The testing I recommended will tell them if it will be close enough.
Plan B is to buy a pair of the model 200 devices from ZTI or something similar.
They can also control for all of this by doing the same thing filmmakers do at the start of each "take". Just hold a digital clock with a Seconds display on it in front of the subject for a few seconds at the start of the shooting session. Or something similar so there is a "marker" in the video itself to visually key on. This may not be possible in the field but it's certainly possible to do in the "lab" testing I recommended as an additional control.
...ken...
Good to hear from you again.
It might be possible but it's rather complicated. If they need that much accuracy AND stability the simplest method would be to buy a couple of the model 200 devices from ZTI and use them.
I'm not yet convinced they need that much accuracy or stability. I'm pretty sure if they use a pair of consumer GPSs to set the PC clocks before each shooting session the computer clocks should stay similar enough for that long. At most they would need to resync the clocks between sessions.
The key is to make sure they have two computers whose time drift is very similar and in the same direction (e.g. faster/slower).
Think of it this way: the time between any two timestamps in the video does not to be exact. It merely needs to be very similar between the two computers.
So, if you are able to start the shooting on both computers at very nearly the same time there will be a specific small difference between the timestamps on the very first frame of the two videos. That will be caused by two things: the small difference introduced by not being able to sync the computers exactly simultaneously and by not being able to start the shooting exactly simultaneously. This difference is, then, a control.
So you should then be able to look at any random frames on the two videos, lets say the 27,465th frames, and the timestamps should have the same difference between them as the first frames have.
I believe you can get there, within any tolerances Jack needs, with just a pair of consumer GPS receiver and a program like GPS Clock. Then, by syncing the two computers in the field with that setup before each shoot, they will have the timestamps on the two videos close enough to get the job done.
The testing I recommended will tell them if it will be close enough.
Plan B is to buy a pair of the model 200 devices from ZTI or something similar.
They can also control for all of this by doing the same thing filmmakers do at the start of each "take". Just hold a digital clock with a Seconds display on it in front of the subject for a few seconds at the start of the shooting session. Or something similar so there is a "marker" in the video itself to visually key on. This may not be possible in the field but it's certainly possible to do in the "lab" testing I recommended as an additional control.
...ken...