Frequently Asked Questions
Run as Admin: In some instances, TM-Flash requires elevated access to perform an update.
Firewall or Anti-Virus software: Some software will block TM-Flash from functioning normally. Please try disabling these applications and retrying the update.
Trying to update across subnets: A broadcast message must be receivable from TimeMachines product to the Windows computer for the process to work. This may require re-locating the network connection points.
TFTP server running on update computer: The update processes uses TFTP, if there is already a TFTP server running, it must be disabled for the update process to work
Multiple Network Adapters: TM-Flash will on occasion attempt to use an incorrect network adapter. Temporarily disabling unnecessary network adapters can ensure TM-Flash uses the correct one.
Other Software Using Ports 67, 68, 69: Open a Command Prompt and use the commands below to identify if another software is occupying these ports.
netstat -ano | find ":67"
netstat -ano | find ":68"
netstat -ano | find ":69"
If software is found occupying any of these ports, identify the software running using the Process ID. Temporarily closing, disabling or uninstalling this software would allow TM-Flash to use these ports.
Note: WiFi clocks must be updated through the wired interface. Updating through WiFi is not supported.
Using a GPS signal simulator, we have confirmed correct operation for our TM1000A, TM2000A/B, and TM2500B models through August 10th, 2030. This is based on current release firmware of 2.4+ for the TM1000A, 0.3.4+ for the TM2000A, and 0.4.0+ for the 2000B/2500.
TM1000A models with serial numbers that start with a digit, not A or B, were not tested. These were discontinued during 2014. All other models use the same GPS module with no expected issues.
Current shipping firmware of TimeMachines time servers next expected rollover is in 2049. There are no known rollover issues until that time.
The TimeMachines clocks all include an onboard relay that can be used to control external events. The linked document explains this in further detail beyond what the manuals discuss.
Short answer, you don't.
Longer answer. By design, and IETF-NTP/IEEE-PTP time server standards, the time server protocols MUST send their time in UTC and TAI time respectively. This is why you, as the administrator of your time server, cannot change the time zone in your time server.
So how do you get the correct time zone offset to display on your device after it requests time from a time server? It is up to the client device, your PC, camera, recorder, or other device to offset the time to the local time zone the device is in. This includes offsetting for daylight savings time (DST). This is why everytime you setup a new install of Linux or Windows, or a Mac, you tell it what time zone you are in, so that it knows how to offset the clock correctly for display.
If you are having issues viewing/modifying information on the web page for your TimeMachines device please try disabling any antivirus protection that may be running on your PC. Once you have successfully viewed and made the necessary changes from the web page you may re-enable your antivirus protection. This will not cause any issues with operation of the device, only the ability to view the webpage.
The TM1000A arrives from the factory with a default IP address of 192.168.1.15. Unless the network it is plugged into is the same subnet, entering 192.168.1.15 into the browser URL of the PC being used for setup will not access the TM1000A’s web page. If lost or fogotten, the default settings of the TM1000A can be restored using a jumper located behind the front panel of the TM1000A. See the documentation for more information on how to perform the reset procedure.
The first step in this process is determining where the TM1000A is going to reside on the network. A static IP address is typically preferred. It should be assigned a routable IP address on the same subnet it is connected to. For example, if the IP address of a computer on the same subnet as the TM1000A is 10.10.4.71 with a subnet mask of 255.255.255.0, then the TM1000A should be set to 10.10.4.X where X is a value that is not currently is use. Your IT department may be able to help with this.
The second step is to change the IPv4 setting of the PC being used for initial TM1000A setup. Both the PC and TM1000A can remain connected to the final network during this process. In the network settings, change the adapter setting’s IPv4 address of the PC to something like 192.168.1.10, 255.255.255.0, no gateway required. Once that is completed, put the default TM1000A IP address into the PC’s browser, 192.168.1.15. The login webpage should appear. The default password is “tmachine”. Update the IP address, mask, and gateway to match what was determined in the first step above and save the settings.
Return the setup PC’s IPv4 settings to their original value(s) and test that the PC can log into the TM1000A by typing in its new IP address. At this point, the TM1000A is available for use by other devices on the network.
The TM2000A arrives from the factory with a default IP address of 192.168.1.20. Unless the network it is plugged into is the same subnet, entering 192.168.1.20 into the browser URL of the PC being used for setup will not access the TM2000A's web page. If lost or fogotten, the default settings of the TM2000A can be restored using the reset button on the front panel of the TM2000A. See the documentation for more information on how to perform the reset procedure.
The first step in this process is determining where the TM2000A is going to reside on the network. A static IP address is typically preferred. It should be assigned a routable IP address on the same subnet it is connected to. For example, if the IP address of a computer on the same subnet as the TM2000A is 10.10.4.71 with a subnet mask of 255.255.255.0, then the TM2000A should be set to 10.10.4.X where X is a value that is not currently in use. Your IT department may be able to help with this.
The second step is to change the IPv4 setting of the PC being used for initial TM2000A setup. Both the PC and TM2000A can remain connected to the final network during this process. In the network settings, change the adapter setting's IPv4 address of the PC to something like 192.168.1.10, 255.255.255.0, no gateway required. Once that is completed, put the default TM2000A IP address into the PC's browser, 192.168.1.20. The login webpage should appear. The default username is "admin", default password is "tmachine". Update the IP address, mask, and gateway to match what was determined in the first step above and save the settings.
Return the setup PC's IPv4 settings to their original value(s) and test that the PC can log into the TM2000A by typing in its new IP address. At this point, the TM2000A is available for use by other devices on the network.
The TM1000A does not have an internal clock source and does not serve time without a GPS lock. It is therefore a requirement that a continuous view of the sky be available to maintain its time serving functions. See the TM2000A for this added feature.
Linux browsers cause issues with the internal web server of the clocks and TM1000A. The TM2000A is not affected by this operating system difference.
Some anti-virus software can block browsers from displaying the settings that populate the fields of the web pages. If you are seeing no data in the web page fields, check and see if disabling your anti-virus fixes the issue.
First of all, there is almost certainly nothing wrong with the clock. Blinking dashes, or blinking seconds and AM/PM indicators are simply a notification by the clock that it has been unable to get a response from the primary or secondary time servers that are setup in the webpage. Something network related is preventing it. Either the time source is in-accessible (internet based?) or maybe the DNS entries are not working.
1) Are there network link lights where the Network cable plugs into the clock?
2) Check that you can log into the web server at the IP address of the clock. This just further confirms the clock is functional, beyond just pinging it. You can determine the IP address by double clicking the button on the back side of the clock by the network connection.
3) Make sure your internet connection is working and available to the clock.
4) Replace the FQDN of the time sources with their associated IP addresses to remove a DNS problem and potentially fix something that has changed on the internet. For example, if using the default settings, replace TimeServer1 (maybe was time-a.timefreq.bldrdoc.gov) with 220.127.116.11 and TimeServer2 (maybe was utcnist.colorado.edu) with 18.104.22.168. Another good internet based time source is 22.214.171.124 (pool.ntp.org).
We have seen cases where the firewall will start blocking NTP traffic. This is UDP traffic to port 123. Putting a specific rule into place to prevent this from happening may be a good step to take. Frequently this can be tested by unplugging the offending clock for 10-20 minutes and then starting it up again. It will likely re-occur, but it may help with diagnosis.
Another option is to use a Windows based computer as an internal time source. The NetTime software, mentioned in the Time Server Utilities section on the Documents web page, is a good simple server than can be easily setup to serve NTP time and keep itself synced to multiple internet sources. Usually the Windows firewall will require an Inbound rule for UDP on port 123, to make this work seamlessly.
Generally signal strengths for the first few satellites in the middle 30's is required. Sometimes it can be less than this if numerous satellites are in view, but lock time will be longer. A window with a good view of the sky can yield signal strengths in the middle 40s. It is important to note that signal strengths vary through the day as the satellites move. Low-E glass coatings can also degrade or block GPS signals. It is best to try numerous locations when looking for final location to place an antenna. Outdoors with a clear sky view is always best.
This IP address is the default IP that many devices go to when DHCP lookup fails. The clock has assigned this as its static IP address and can be accessed at this address by using an IP address on the browser PC of 169.254.254.XXX-1. For example, if the clock scrolls 169.254.254.147, then set the PC to 169.254.254.146. Of course, if the DHCP server is down, maybe fix that first.
The short answer to this question is no. The time servers get their time from the GPS Satellites and maintain their accuracy with it. The TM2000A does have an onboard OCXO that will maintain time in the event of a GPS signal loss, however this isn't intended as "set it with GPS and then disconnect the antenna" kind of time source. The hold-over time is limited in the web page setup and accuracy drifts without the GPS signal. There is a white paper discussing the accuracy over time without GPS lock for the TM2000A in the documentation section. The TM1000A does not serve time without the GPS signal lock.
Only the TM2000 is able to have its time set by any means other than GPS signal.
Some of the PTP client software we have used/tested:
PTPD: The linux PTP Daemon
TimeKeeper: FSMLabs **Highly Recommended for Windows and Linux**.
Domain Time II: Greyware. https://www.greyware.com
Windows 10 as of release 1809 has a PTP client that we checked to see that it works. Documentation on setting it up is here:
The short answer is no, but we can convert our time servers with a POE splitter. We've tested and recommend the TP-Link Splitter TL-POE10R.
The splitter comes with a power cord with 2.1mm power socket and needs an adapter to convert it to a 2.5mm male plug such as the amazon link below.
TM1000A requires 5V of power
TM2000B/TM2500B requires 12V of power
In some cases, yes. The question will be the structure of the building. If the building is a wood frame building and is relatively RF transparent, then the GPS antenna may be located near the time server. Metal and concrete structures are usually not RF transparent for GPS signals.
The next best option is in a window. In the United States, a south facing window is best as the most satellites will be visible. The window must also be RF transparent for GPS signals. There are some "Low-E" energy efficiency coatings that will block GPS signals.
A good test is to download an actual GPS app for a smartphone, such as "GPS Status" and see if the smartphone can get a lock in a given location, if it can, then the placing the GPS antenna in that location will most likely work.
Occasionally we get a request to be able to sync the TM2000 outdoors with GPS, then take it back indoors without GPS to run off its internal OCXO. A really nice way to do that is to use a small lithium battery. We tested one that is available on Amazon and had good luck with the battery being able to run over 24 hours on a charge, but in addition the included power supply was able to both recharge the battery and run the TM2000B with the included 'Y' cable.
The battery was Amazon.com ASIN: B00ME3ZH7C
You will also need to adapt from the 2.1mm plug on the battery, to the 2.5mm plug of the TM2000. Amazon.com ASIN: B01N812NKL
Your results may vary, but short of using a full Uninterrupted power supply, this worked pretty good.
All of the WiFi clocks and time server products use a circular connector plug with a 5.5mm outer dimension and a 2.5mm inner dimension. The center of the plug is positive.
The TimeMachines splitters use a center positive, 2.1mm inner, 5.5mm outer plug.
These types of power supplies are readily available on the market and any suitably voltage/current rated supply will generally work.
In this example, Netcat (nc) is used to display static text on a DotMatrix display without having to code UDP/IP sockets in C, Java, or some other high level langauge.
The TimeMachines API for controlling timer modes on the displays is available on the Documents page of our website. It shows the UDP/IP command sequences required to start and stop up/down timers, as well as display text on a DotMatrix display. If the customer isn't familiar with coding UDP/IP in a high level language like C or Java, there are command line utilities that will implement this functionality.
There didn't appear to be a way to put both the hex command bytes and the display text onto the command line with the nc command (there may be), so as an intermediate step, echoing them to a file seems a good option:
echo -n -e '\xA9\x1B\x02\x00123456' > testfile
This puts the 4 bytes required to send static, non-scrolling, centered, text to a clock (0xA9 0x1B 0x02 0x00), followed by a six digit text string (123456) into a file called "testfile". The script could be changed to echo whatever data you wanted to display after the four command bytes.
Then use the nc command to send the UDP packet with the data stored in the text file.
nc -w 0 -u 192.168.1.75 7372 1234 < testfile
The data in testfile, "123456" is displayed on the clock.
A second file could be created to return the clock to time mode:
echo -n -e '\xA8\x01\x00' > timemode
nc -w 0 -u 192.168.1.75 7372 1234 < timemode
Sorry, we don't have a CAD model for the TM1000/2000/2500 available. However, the box we use is made by Hammond Manufacturing, PN: 1455L1202BK
They have CAD models for their enclosures available.
Currently, TimeMachines does not make a waterproof or stainless steel clock suitable for clean room or harsh environments. However, there are some covers and enclosures that are available. We have had some customers use our clocks and then put these plastic "exit sign" bubbles over them.
The lens for the 2.5" clocks, both 4 and 6 digit:
The lens for the 4" clocks, both 4 and 6 digits:
They also make some wire protective covers, this one covers up to the 4"x6 digit clocks:
If you have found something similar and wish, to share, we'd be happy to add it to this list.