After repeated attempts to convince local stations to get Daylight Savings Time changes correct (they always jump the gun by a day) along with failures to convince the FCC to do something about it, the time has come to collect and publish some data illustrating the problems. (I discovered that the local FCC office has no ability to monitor any PSIP data. They have to visit a station and use their facilities to look at it.)
After a little research it looked like the SiliconDust HDHR receivers might do the trick so I ordered one. A C library is available to make the use of it easier. A key feature of that library that I use is the ability to filter the receiver output based on PID. This lets me stream the data including the system time tables while leaving the high bandwidth audio and video data behind.
The plan was to do initial code development on my main Linux box and move it over to a Raspberry Pi. But the code would not work on my Linux (Fedora 20) machine. It cannot find the HDHR4 unless given the IP address and even then it will not stream any data. So plan B was to do all of the work on the Pi. Later I determined that the problem was due to the way that the HDHR4 worked. It wasn't simply a passive player. It created connections with the host machine which meant that the default firewall settings blocked it. After I changed that it worked a lot better.
The way that this is supposed to work is that one month before the scheduled change the values DS_day_of_month and DS_hour get set to the appointed values. Because no data is transmitted about the month of the change, it is vital that the DS_day_of_month match the current day of the month only on the day of the change. Alas almost everybody does it a day early so that they set these values on 2 October 2014 for a 2 November 2014 change. Naturally my receivers believed them which resulted in one hour time errors on 2 October. I can't seem to convince anyone that this is a problem based on the behaviour of my receivers (the typical response is to blame the receiver) so maybe some data will shame them into acting. This is not a new or unknown problem as this 2008 Society of Broadcast Engineers news item shows.
On the day of the transition the station is supposed to change DS_status once their entire broadcast area has completed the transition and also set DS_day_of_month and DS_hour back to zero. This allows for the few markets that include two time zones.
The time on my DTVPal DVR seems to drift a bit and because it relies on averaging the data from several stations together in an unknown way, it is hard to know what the source of the problem is. Full power stations are required to keep the time they transmit in the system time table accurate to within one second as measured at the receiver. Some do a better job than others but currently (Jan. 2015) no one meets the +/-1 second requirement.
Some of these problems are out of the stations control because they are dependent on hardware that they purchase. If that hardware fails to do a good job, there is nothing they can do. Except perhaps find a different hardware vendor.
This is my main program. I found the CRC32 code somewhere on the net and forget where so it isn't included here.
I have been recording time and signal strength data since 2015. This is a lot of data and might be of some use. If you would like a look, contact me. Be aware that the data files are large (>60MB, compressed).
Now that I have setup my web pages in a new home I will probably take down this version of my ATSC pages soon.
Home