CF 30 Time Sync Issues

We are using CF30's and have noticed time sync issues, We are using TB's in Fire engines that have our CAD's mobile application. The TB time seems to drift off by as much as 5 seconds within an hour from CAD time. What ends up occurring, is when an apparatus is placed on an incident, the company officer presses the enroute button and sometimes that time is prior to the time CAD actually assigns them to the call!


Has anyone else had this issue? If so, how did you correct it? We are trying to avoid sending them all back.

Thanks in advance.

Matt

 

This could be a low bios battery - I see this especially in desktops (They take CR2032's) - Rick do you know if these batteries in the 30's are replaceable? (ie not soldered on) if so what are the steps to replace it?

Thanks

 

Are your toughbooks equipped with GPS? If so you can use a background utility to automatically sync your clock to UTC time from the satellites atomic clock. Here is a good example of one that we use: http://www.visualgps.net/NMEATime/

 

the vast majority are not, but we have a few oddballs that do have integrated GPS.

The particular TB I am having this issue with does not have integrated GPS.

 

You should be able to remove the screws on the bottom cover/plate and see it under one of the pc boards. But I'd have a hard time believing that a BIOS attery in a CF-30 could be that drained. What would cause it? MOst BIOS batteries in CF-28s I have are still good... Even after sitting (or being used) for years.

But it is easy enough to check and rule out.

It almost seems to me that the CAD program uses its own internal clock instead of the laptops. Can you check in the "options" or "setups" of that program to see if it gives you an option?

 

You are correct, each device whether it is a CAD workstation or laptop uses it's own OS time to time stamp calls etc...but to answer your question there is no way in our CAD to configure the time sync function as it is a function of the OS.

 

You might want to consider a master clock in the server room? Unless there's Internet connectivity on the workstations and server (eep!) to sync to a source like time.windows.com, you should consider an in-house NTP server synced to GPS time?

As a broadcaster, we use a facility clock system from Torpey Time ( http://www.torpeytime.com/main.htm) But there are other solutions for NTP servers like http://www.symmetricom.com. That way the server is on your intranet without threat from the bad world of the Internet.

 

If you are using Windows XP or newer, you can set the option in the Internet Time tab of the Date & Time properties dialog box (Double click on the clock in your systray). It defaults to the MicroShank time server; though you CAN set it to ANY server, including one configured on your OWN network.

mnem <~~~Informa-DwaGON~*

 

Thank you for the replies....more than likely we will end up going to some sort of third party app that will sync everything to one clock!

Thanks again for all of your help!

Matt

 

AboutTime is a free timesync application that works very well.

http://www.arachnoid.com/abouttime/

If you don't have your own server, use some of the 'pool' NTP systems, eg.
0.pool.ntp.org
1.pool.ntp.org
2.pool etc

(For other than the USA, there are localised servers like 0.uk.pool.ntp.org)

If you have a Linux system, NTP should be built in.
If you want to set up a full NTP server on a Windows machine, a full NTP package is available here:
http://www.meinberg.de/english/sw/ntp.htm

Robert.

 

But keep in mind this is for public safety purposes, not hobbyist.

 

The problem is that the time is drifting badly while the machine is running;
one very significant question - Does it correct itself if you reboot?

In other words, does the hardware clock drift or is it only the software that's getting out of step.

Another test is leave one showing the CMOS Setup screen with the clock for a hour or two so you can see if this is staying in sync with 'real time'.

You could have a driver problem or an application that's causing the software RTC to miss interrupts and get out of step. In that case, exchanging the machines will have no effect, you need to find the root cause of the problem.

Robert.