The local TV stations appeared to be doing a poor job of keeping accurate time which caused trouble with my DVR that relied on it. So this page is the result of my monitoring of those errors.
Each digital TV station transmits GPS time and the GPS offset. (Subtract the GPS offset from the GPS time to get UTC time.) I record the time as sent by each station along with the time on the computer logging the data. The computer is kept synchronized to net time using the program chrony. Chrony tracking information indicates it is keeping the local clock synchronized within less than a micro-second of net time. The data is processed and plots are produced for each station showing the difference between the two times.
The receiving equipment introduces offsets from unknown delays between receiving the data packet and processing by the computer. Because my program sleeps for 10ms if no data is available that is probably about the magnitude that can be expected.
While the time transmitted by the station has only one second resolution, I use high resolution (1us) local time. This reveals some problems that using a one second resolution local clock would not.
The plots are for the previous week and updated at the end of each day. Errors within the range of +/-1 are as accurate as can be expected using a one second resolution. Anything outside of that range does not meet the requirements of ATSC A/65 and FCC regulations. (47 CFR 73.682(d)) Note that low power stations are given a pass on many requirements but keeping time ought to be easy.
Plots are identified with the station call sign. Positive values indicate that the TV station time is ahead of the actual time. This includes the GPS to UTC correction as transmitted by each station.
KODF-LD (RF 3)
K07AAD (RF 7)
WFAA (RF 8)
KFWD (RF 9)
KHPK-LD (RF 10)
KHFD-LD (RF 13)
KERA (RF 14)
KTXA (RF 18)
KTVT (RF 19)
KBOP (RF 20)
KDTX (RF 21)
KNAV-LD (RF 22)
KTXD (RF 23)
KXAS (RF 24)
KPXD (RF 25)
KDFI (RF 27)
KDTN (RF 29)
KMPX (RF 30)
KAZD (RF 31)
KDAF (RF 32)
KUVN (RF 33)
KDFW (RF 35)
KXTX (RF 36)
This is not all of the stations in the DFW area, just the ones I receive that provide a system time table.
Not evident in the plots is that the stations do not agree on the GPS offset. While many use the correct (for a few more months anyway) value of 16, some use 15 or 14 and one uses 0. WFAA is transmitting UTC time instead of GPS time and a GPS offset of zero. Good work guys.
Here is a sample of the raw recorded data:
stt: 2801, 8vsb:8, 1421434331, -1, 1105469530, 0, 0, 0, 0 stt: 2843, 8vsb:9, 1421434332, -1, 1105469546, 15, 0, 0, 0 stt: 2803, 8vsb:14, 1421434342, -14, 1105469544, 16, 0, 0, 0 stt: -1, 8vsb:18, 1421434344, -47, 1105469512, 15, 0, 0, 0 stt: -1, 8vsb:19, 1421434345, -1, 1105469560, 16, 0, 0, 0 stt: -1, 8vsb:20, 1421434345, -11, 1105469549, 15, 0, 0, 0 stt: 2849, 8vsb:23, 1421434352, -2988, 1105466580, 16, 0, 0, 0 stt: -1, 8vsb:28, 1421434362, 21, 1105469598, 15, 0, 0, 0 stt: 2841, 8vsb:29, 1421434363, 0, 1105469579, 16, 0, 0, 0 stt: 2813, 8vsb:30, 1421434364, -1, 1105469578, 15, 1, 0, 0 stt: 2807, 8vsb:32, 1421434370, -4, 1105469582, 16, 0, 0, 0 stt: -1, 8vsb:34, 1421434371, 758, 1105470343, 14, 0, 0, 0 stt: 2799, 8vsb:35, 1421434372, 9, 1105469597, 16, 0, 0, 0 stt: -1, 8vsb:36, 1421434372, -1, 1105469587, 16, 0, 0, 0 stt: -1, 8vsb:39, 1421434379, -4, 1105469590, 15, 0, 0, 0 stt: 2809, 8vsb:40, 1421434379, -18, 1105469577, 16, 0, 0, 0 stt: -1, 8vsb:41, 1421434380, -18, 1105469578, 16, 0, 0, 0 stt: -1, 8vsb:42, 1421434380, 0, 1105469596, 16, 0, 0, 0 stt: 2817, 8vsb:43, 1421434382, -1, 1105469595, 14, 0, 0, 0 stt: -1, 8vsb:45, 1421434388, -118, 1105469486, 16, 0, 0, 0 stt: -1, 8vsb:46, 1421434388, -2, 1105469602, 16, 0, 0, 0 stt: 2877, 8vsb:48, 1421434390, -1, 1105469605, 16, 0, 0, 0
The columns of data are:
While waiting for a System Time Table packet to appear my code also looks for the Terrestrial Virtual Channel Table which has the TSID. But it doesn't wait around for a TSID so some stations that have them will still show a value of -1 here.
Notice that one station (TSID 2813) thinks that we are in daylight savings time in January!
Since no one is providing accurate time, perhaps a few words on the sources of the errors are in order. Although I suspect that this might be my entry into the world of the Time Nuts.
Several stations are making no effort at all to synchronize their local clock to any reference at all. This is easy to spot because the error drifts steadily with time. A subset of this are the ones that re-sync occasionally. The error is allowed to grow too large though.
A few stations have nice steady errors that are not drifting so they have synchronized their hardware to a stable reference. It just happens to differ from the correct value by some amount. For some it appears that they are transmitting UTC time instead of GPS time because the offset is about the same as the value for the GPS offset. aka leap seconds.
This is one that afflicts all but one station. If the transmission of the system time table packet with its one second resolution is not triggered by the local clock ticking over the new second, the transmitted time will always be wrong. Most stations are transmitting the time table slightly faster than once a second. This means that on average, the time transmitted will be a half a second slow. But the error will vary over the range of 0 to 1 second slow with the precise error depending on which packet you look at.
I collected some data from one station for about a minute. Measuring the difference in the arrival time of each STT packet and the time error. This first plot shows that the packets are being sent at about 0.99 second intervals:
In this next plot you can see the saw tooth shape of the errors in time:
ATSC A/65 actually suggests that the transmission of the STT packet be triggered by the incrementing of the seconds counter and be sent before that. It is written as a suggestion and not a requirement (should rather than shall) though.
The one station that has synced their time packets (KPXD) shows that instead of compensating their local clock for drift they instead reset it about once every three hours which is the time required for the local error to grow by 1 second.
The standard requires no more than a +/- 1 second error as measured at the receiver. In particular it is referenced to the receipt of the CRC in the time table packet. Measuring the arrival time that accurately would require some very specialized hardware so I have to live with some small delay. The problem is that after the system time table packet is formed there is some delay before it gets to the transmitter. There could be buffering of data and a delay before a slot is found to slip the packet into. Most of this error should be constant and in principal it could be compensated for simply by scheduling the packet to be generated a bit early.
The real problem is that the stations and the FCC appear to not care at all about these errors. The FCC has no ability to monitor these errors and little desire in any case. Contacting the stations rarely (so far never) results in any change at all. Maybe one day that will change and I can retire this web page.
I received a reply to my complaint to the FCC about these time errors:
Hi David Thank you for your submission. Your complaint provides the FCC with important information we can use to develop policies to protect consumers, remedy violations of the Communications Act, and encourage future compliance with the law. The FCC appreciates the information you’ve shared with us. It appears that the State Attorney General’s Office will be better able to assist you. We urge you to contact that agency about this matter. Below is a link to the National Association of Attorneys General: http://www.naag.org/current-attorneys-general.php As such, no further action is required by the FCC. Your complaint was closed on 2015-02-11T11:10:35-05:00.
Unexplained is why a state would be interested in or even capable of enforcing the regulations of a federal agency. A federal agency that is charged with writing and enforcing those regulations no less.
Idiots.
On 17 March KTVT did something and their error is now within the +/-1 second requirement. It is still variable because transmision of the time table packet is not synchronized with the time. But at least it is close to the correct time.
KTXA (their sister station) followed on the 21st.
It didn't last as they both started drifting.
A leap second was added at the start of the day on 1 July 2015 UTC. Or 7PM local time on 30 June. Alas, not one station did this correctly. While the time error for a few stations didn't jump by one second meaning that they adjusted their local clocks, the value for the GPS to UTC offset that they transmit didn't change. The same mixed bag of 16, 15, 14, and even zero. Nobody changed to the correct new value of 17. At 7PM on 1 July only two stations have switched to 17.
Home