ATSC Monitoring

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.

Daylight Savings Time

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.

DST data

UTC time

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.

Time data

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 altered this to add code to forward signal strength data to RabbitEars. I will email the entire code package on request.



I started recording data in 2015 and keep it around in an archive. Besides time data there is also signal strength data. Which gets forwarded to RabbitEars as well.