NTP Time Servers for VideoIQ Cameras

One of the more frustrating things I try to oversee is the video camera surveillance system for our gated community.  I was an advocate of such a system and provided a lot of support and politicking to get it; but, in the end, the HOA decided on VideoIQ instead of the Mobotix brand that I wanted (long story).
 
We have an entry way camera that views the front gates and a license plate camera that captures the license plates of vehicles as they enter.  I'm constantly perplexed why we never get a matching 'pair' of video captures so I can match the vehicle of the entry camera with the license plate capture.  It seems one of the culprits is the time of the two cameras is off.  I complained about this, and the vendor said both are set to auto correct their respective times. (The cameras seem so be well over a minute off of each other, which is a big deal when you get a lot of traffic going through at busy times).
 
Well, I looked at the VideoIQ settings and they have the NTP server pointing to pool.ntp.org for both cameras.
 
Is this the correct usage?  I thought you needed to specify a server number with this service, for instance server 1.pool.ntp.org or server 2.pool.ntp.org.  I admit, I'm not an expert at all in this area.
 
I'm thinking instead of using the following servers for our Las Vegas, NV area:
 
nist1-lv.ustiming.org     
tick.cs.unlv.edu
tock.cs.unlv.edu
 
Should I input the server name and assume the VideoIQ system has enough smarts to match that to a DNS server or should I input the IP of the servers directly?
 
What are other installers doing when using NTP to correct their camera surveillance systems?
 
Thanks in advance for any help and admittedly, I should search this further, but just don't have the time to put into this right now (I just want a quick fix to be done with this)!
 
I'm not even going to go into the frustration of missing vehicle captures at night for the entry cameras, that is for another day...

Should I input the server name and assume the VideoIQ system has enough smarts to match that to a DNS server or should I input the IP of the servers directly?

Click to expand...

 
If the VideoIQ system has a syslog function; turn it on and test the NTP; you should see it sync if it works.
 
Read something somewhere about a syslog function.  Didn't see it though in the VideoIQ user guide.
 
Never seen pool.ntp.org used for an NTP server address. I see that in the manual though. 
 

 
Yup tested it to work; apologies; never used it before.
 

root@ICS-JogXUbuntu1:~# ntpdate pool.ntp.org
 8 Mar 14:42:43 ntpdate[12328]: adjust time server 66.228.59.187 offset -0.013458 sec
root@ICS-JogXUbuntu1:~#

Click to expand...

 
 
 
Tested these from Chicago and couldn't get to any of them.
 

nist1-lv.ustiming.org     
tick.cs.unlv.edu
tock.cs.unlv.edu

Click to expand...

pool.ntp.org is a valid NTP source... and it round robins between servers so if one is down, others keep responding.  It really is the best way to do it.
 
If you wanted to get more specific you could choose just north american servers, but in theory that's what you get from pool.ntp.org anyway.

Thanks Pete, good idea about the syslogs, I know the Axis systems have that easily accessible.  I'll check for that with this system.

Thanks neillt.  I am wondering why they did not sync when set to that server then?  Must be something with the cameras themselves instead of the wrong NTP server name, good to know.

If the clock is too far off to begin with, most NTP implementations will assume something is wrong and not update the time.
 
I would start by setting the time manually, then enabling NTP to keep things on track.

Usually when I sync IP cams to something I use the NVR recording the video, most of the time, and let the NVR get the time from something else (NTP Pool, Domain Controller, etc).
Since your cameras are edge storage that won't work. I agree with the above, set the time then test a sync. See if that works.

Yes, pool.ntp.org works very well.  If your clocks are off, the most likely culprit is bad/wrong DNS info.  Other possibility would be that you don't have a default gateway set, but that is less likely.
 
Out of curiosity, what was it about the Mobotix cameras that you preferred?
 
There is no syslog function directly in the VideoIQ cameras, but in the View software if you do "Ctrl+Shift+~", you'll get a pop-up menu and you'll see an option there to pull logs from the camera.

Things can get squirrely in a hurry if time sync gets screwed up. I second the notion of having as many devices as possible use an on-site source for time as their primary. And make SURE the DNS record for it responds with valid time 24x7x365. Then there's the adventures of timezone settings on the devices, make sure they're all on the SAME TZ.

While it probably won't matter with the cameras, stuff like LDAP, ActiveDirectory and a more sophisticated crypto or login methods will absolutely get screwed up if time on the workstations is more than about 5 minutes out of sync.

One way to debug some of this is to run a DNS server on site, one that collects and logs DNS requests. Watching what gets requested can help point out when something's amiss. That and you then also have the chance to put in your own DNS records to return your own IP addresses instead.

If you've got anything on site that can run an NTP server I'd recommend using that instead of just leaving each device to make their own connections to an Internet server somewhere else.

Personally my preference is to have an internal NTP server. 
 
Here is an NTP server and three internet NTP sources.
 

 
Many years ago working on a unix vector tracking thing (related to Catia) and playing around with GPS's got really into the whole time sync thing.
 
That said I liked it so much installed an NTP server and GPS antenna on the roof of one of the buildings at work.
 
Initially it was only utilized for routers and switches; then afterwards DNS servers. 
 
I then put an NTP server at home to sync all my stuff....thinking it was in the early 2000's.
 
I just recently shut down the NTP server and moved it to the PFSense firewall.  Its been working great.  I am using PPS on one of the serial wires.   Very cheap to do.

Thanks for the replies, a lot of great information here!  Also, this thread is very timely (you see what I did there) due to clocks changing tonight.
 
Please correct me if I'm wrong on this assumption, but if this was a DNS problem, I could just put in a hard IP of an NTP server and that should provide a solution correct?
 
Pete:  Exactly how 'cheap' is cheap (regarding having your own server linked via GPS)?  I think you missed a link in your last post.
 
The cable modem and (cheap) router (another long story) are in a very small box on a lamp post so not a whole lot of room to add things.
 
To answer another question from this thread, I am not a Mobotix expert, but after viewing their products and driving their software for a bit at trade shows, I think they have a superior system over the VideoIQ.  The IQ view software is just awful, and it doesn't seem to have rules that can capture a vehicle during the night (fairly well light area with street lights) reliably.  Maybe the vendor just doesn't know how to set this up, but after complaining persistently, they supposedly brought out a factory rep to go over the settings.  Other than install a new version of firmware into the camera the performance is still the same.
 
Maybe I'm too picky, but it seemed my $70 (at the time) Vitamin D software had better rules to setup captures than this software.
I also liked the fact that their M12 line has dual image sensors for day night operations.
 
brk:  Do you know these VideoIQ systems well?  Have you done a lot regarding rules for capture setups?  I could use a good man right now (HOA might be willing to pay you to check these settings out).  FYI, we pay a maintenance contact (for way to much money) but own the cameras outright and I do have admin credentials.
 
I was thinking at one time to get another vendor to service these cameras, but after interviewing two other companies, I thought it was better to stick with what I got.  Also, unfortunately, after getting this brand
 
I will be at the ISC West show at the Sands, and ask again for some companies that are familiar with VideoIQ, but, recommendations made a couple of years ago (by them) didn't pan out to well.

Please correct me if I'm wrong on this assumption, but if this was a DNS problem, I could just put in a hard IP of an NTP server and that should provide a solution correct?
 
Pete:  Exactly how 'cheap' is cheap (regarding having your own server linked via GPS)?  I think you missed a link in your last post.
 
The cable modem and (cheap) router (another long story) are in a very small box on a lamp post so not a whole lot of room to add things.

Click to expand...

 
I have always used the IP of the NTP server (well internal one).  You can utilize anything these days to sync NTP with PPS (Linux or Windows).
 
I did a modification to this board for PPS.  Easy.

 

Meeting the PPS over RS-232 requirement

The purpose of the patches is to provide a true RS-232 level PPS signal on pin 1 (DCD line) of the connector.  Whilst the PPS signal on test point TP9 could be used, it is at CMOS level and not RS-232 level, and may not be recognised correctly by the RS-232 receiver chip in your PC.  You can try it if you like, of course.  I have provided a Serial Port LEDs program to show the status of the RS-232 control lines.  Fortunately, there is an unused CMOS-to-RS-232 level converter gate available in U6, with its input on pin 11 and its output on pin 14.  However, as this is an inverting gate, and we want a positive going PPS signal, it should be driven with a negative going PPS signal.  That available at TP9 is positive going, however it is also used to drive the ridiculously bright blue LED through a CMOS inverter gate in U5, so by taking the output from that inverter on pin 8 of U5 we have the required negative-going PPS signal to drive U6.

Click to expand...

 
 

The two red patch wires shown below were added by me to provide an RS-232 level, positive-going PPS output.  Note that with the Windows NTP port, the DCD line must be asserted (positive going) as provided by this patch, as that port cannot use an inverted DCD signal.

Click to expand...

 
 
You can purchase the board at Sure Electronics for $35.00 USD here:
 
http://www.sureelectronics.net/goods.php?id=99
 
The board comes with a GPS antenna and USB cable.
 
The board is tacked to a 2X4 in the attic with a cat5e to RS-232 connector on it running down to the basement. 
 

Do a search in the Wiring Closet for TM1000A. It's a consumer grade NTP GPS server with a built-in web interface that I've been using for over two years now. Except for the initial problem mentioned in the thread, it's worked flawlessly. I've probably got a dozen devices sync'ing with it now. Pretty much a PnP device. Looks like they sell for $300 now.

BraveSirRobbin said:

brk:  Do you know these VideoIQ systems well?  Have you done a lot regarding rules for capture setups?  I could use a good man right now (HOA might be willing to pay you to check these settings out).  FYI, we pay a maintenance contact (for way to much money) but own the cameras outright and I do have admin credentials.

Click to expand...

 
I was the VP of Global Sales and Support before we sold the company to Avigilon, so, yes, I know a few things about them.
 
FWIW, I wouldn't recommend running your own NTP server.  Not that there is anything *wrong* with that, but I don't think that is your problem.  If the cameras have proper network config, then they should be syncing just fine to pool.ntp.org.  We have 10's of thousands of cameras deployed with that setup working well.
 
It's funny (to me) that you prefer the Mobotix software, most people that have used our stuff give feedback that they really like the UI, but that can certainly be a personal preference thing.  And sometimes the first thing you see is what you get in your head as the "reference" and everything else just seems a bit odd.
 
Not sure if you've seen this video already, but it's a training walk-through of the View software from a user perspective: http://www.youtube.com/watch?v=x9zundsMFZ4
 
I *think* part of the problem you're having is just basic understanding of analytics/object classification vs. "rules", and how the system really works and makes decisions.  If you email a couple of video clips of scenes/events that you're having problems with to [email protected] I can have one of my techs take a look.  I'll also be at ISC West next month, if you want to come by our booth we can chat a bit there as well.  I assume you already signed up for one of the free exhibit hall passes, but if not let me know and I can get a free exhibit hall pass.

FWIW, I wouldn't recommend running your own NTP server.  Not that there is anything *wrong* with that, but I don't think that is your problem.  If the cameras have proper network config, then they should be syncing just fine to pool.ntp.org.  We have 10's of thousands of cameras deployed with that setup working well.

Click to expand...

 
Yup the chances are pretty nil that a "disconnect" to the WAN during a time change will mess with the time.  That said I have seen this only twice in the last 15 years with global enterprise companies.  The last time it was with a company of approximately 15k users in multiple offices that utilized Lotus for their email servers.  The sync time fix from the disconnect did take about 2 weeks to fix.  Concise time sync from internet NTP servers does vary and the more the internet traffic the less accurate it is. 
 
Today its worst than it was a few years ago.
 
Really though I guess whats a few milliseconds of variance anyways?  What does that really mean?
 

root@ICS-ZM-2:~# ping 1.pool.ntp.org
PING 1.pool.ntp.org (205.233.73.201) 56(84) bytes of data.

64 bytes from ns1.your-site.com (205.233.73.201): icmp_req=1 ttl=52 time=38.2 ms
64 bytes from ns1.your-site.com (205.233.73.201): icmp_req=2 ttl=52 time=38.3 ms
64 bytes from ns1.your-site.com (205.233.73.201): icmp_req=3 ttl=52 time=38.1 ms
64 bytes from ns1.your-site.com (205.233.73.201): icmp_req=4 ttl=52 time=36.9 ms
^C
--- 1.pool.ntp.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 36.970/37.928/38.304/0.554 ms

root@ICS-ZM-2:~# ping localNTPSTOURCE

PING localNTPSTOURCE (localNTPSTOURCE) 56(84) bytes of data.
64 bytes from localNTPSTOURCE: icmp_req=1 ttl=64 time=0.097 ms
64 bytes from localNTPSTOURCE: icmp_req=2 ttl=64 time=0.089 ms
64 bytes from localNTPSTOURCE: icmp_req=3 ttl=64 time=0.096 ms
64 bytes from localNTPSTOURCE: icmp_req=4 ttl=64 time=0.095 ms
^C
--- localNTPSTOURCE ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.089/0.094/0.097/0.007 ms
root@ICS-ZM-2:~#

Click to expand...

 
I was one though not to every utilize or share a WAN link for CCTV security and data; but that was me.
 
Over the years though "playing" I have seen hard coded stuff  (time syncing) in firmware that I cannot change even though the option was provided for an NTP time server.
 
Like the firmware is checking what is being put into the blank spaces; not fitting just right and failing over to what is configured in the firmware.