DTC100 owners

[Gregg Lengling]

I've got a strange problem here and haven't been able to correct it.  I have a 61" RCA with the STB built in.  Since daylight savings clicked in my time on the OFF AIR side is always 1 hour behind, on Directv it's fine.  I go into the setup and check that I'm set for Central time zone and daylight savings....but it's still on standard time (screws up the program guides ect).  So I try to change the time and it won't let me, said it has received the time from a valid on-air source and won't let me change.  I hope I don't have to do a reboot and go back in and reset all my preferences and rescan everything.


------------------
Gregg R. Lengling
RCA P61310 61" 16x9
gregg@camelcomm.com

[Matt Heebner]

Mine does that too. I wonder if it has to do with the information put out by the digital stations and the programming guide. I would think eventually the stations will get it right.

Matt

[oflaherty]

After talking about the problem with our engineers, looking at the PSIP data and experimenting with one of our DTC-100's you guys are right on the money.
The PSIP on one of the local stations says we are still on standard time, but they have set their "System Time" ahead one hour to compensate.

The problem shows up in the Program Guide, where one station's 10 o'clock news comes 1 hour before the other station's 10 o'clock news.

According to the standard, http://www.atsc.org/standards/A65-A.pdf  , the "System Time" does not charge when we go in or out of Daylight Savings Time. Instead there is a separate flag in the PSIP to indicate when the local clock needs to spring ahead or fall back.

From page 18:

>>System Time Table

system_time — A 32-bit unsigned integer quantity representing the current system time as the number of GPS seconds since 12 am, January 6th, 1980. The count of GPS seconds and leap second count shall be accurate and correct to within plus or minus four seconds, as timed at the arrival in the decoder of the Transport Stream packet carrying the last byte of the CRC.

GPS_UTC_offset — An 8-bit unsigned integer that defines the current offset in whole seconds between GPS and UTC time standards. To convert GPS time to UTC, the PS_UTC_offset is subtracted from GPS time. Whenever the International Bureau of Weights and Measures decides that the current offset is too far in error, an additional leap second may be added (or subtracted), and the GPS_UTC_offset will reflect the change.

daylight_savings — Daylight Savings Time Control bytes. Refer to Annex A for the use of these two bytes.


From Annex A:

>>DAYLIGHT SAVINGS TIME CONTROL
In order to convert GPS into local time, the receiver needs to store a time offset (from GPS to local time) in local memory and an indicator as to whether daylight savings is observed. These two quantities can be obtained from the user interface (indicating time zone and daylight savings observance) or from the conditional access system, if present, and stored in non-volatile receiver memory.
Since there is a common time (GPS) transmitted in the PSIP, there needs to be a mechanism to indicate when the receiver should switch into (or out of ) daylight savings time at the appropriate local time. Once all the receivers have transitioned at their local times, the entire system can be shifted into daylight savings time. This is accomplished by appropriate setting of the daylight_savings in the STT."


From page 52:

>>After all time zone daylight transitions (within the span of the network) have occurred, the DS_status bit takes the value 1, indicating that daylight savings time is on.

The standard explains the procedure for warning the receiver when Daylight Savings Time is going to start and when it is going to end. The warnings start 30 days before the start of daylight time and 30 days before the end of Daylight Savings Time.

The daylight_savings flag of WTMJ-DT is now "1" in accordance with the standard.

---
Sean at WTMJ (in the news dept. – not an engineer.)

[Gregg Lengling]

I forwarded this info to channel 10/8 and asked them to check their data.  I figure they could be the culprit as they are on the air more than anyone else.  Besides we know that 4/28 is right now and I'm sure Jim Hall has read my post and that they're double checking theirs.   Who knows maybe when I get home tonight it'll have the right time.  I started a thread on hometheaterspot and came up with the same thing all around the country.  Seems like not everyone reads the technical manuals complete.  Like they say "Real Men don't read the instructions".


------------------
Gregg R. Lengling
RCA P61310 61" 16x9
gregg@camelcomm.com

[Gregg Lengling]

Just got an email from Mike at channel 10 regarding the time info...here's his response...I'm at work this AM but when I get home this afternoon I'll check and see if it fixed my time problem.

Hello Greg;

Thanks for the info from the group. I have just checked and found that
we were
not transmitting PSIP. A re-boot of PC driving PSIP this has it back
with the
System Time Table running at the correct values. If you are still
having a problem
call me at the station at 414-271-1036 or e-mail me here. All of our
receivers and
stream analyzers indicate not problem (including the DTC-100)

[Gregg Lengling]

Okay just got home and turned on the TV and the time is now correct so the channels at WMVS-DT did it.  I did have to rescan as everything was back to channel 8, but after a rescan it's showing 10 thru 10-5 so thanks to Mike at WMVS for fixing that.


------------------
Gregg R. Lengling
RCA P61310 61" 16x9
gregg@camelcomm.com