Paul; I've not just written a PSIP generator (EtherGuide Emissary ATSC), I've also written a transport stream/metadata validator called EtherGuide Ferret ATSC that ALWAYS (at least, every time so far) finds errors in transport streams by comparing PSI to PSIP and to elementary streams and against A/65, 13818-1, 13818-2, A/69, A78 and outputs PMCP derived from the data. Extensive user interface, presentation of data in hex, binary, decimal, and as "EPG" data. More elegant than TS Reader, but much, much more expensive. It's one of the reasons I say that I have mathematical proof. I can do this closed loop: source data (pmcp or converted into PSIP) converted into PSIP -> received, demuxed, converted into PMCP. Validated against the source date. Tested against other implementations. Tested (at least tx) against HP packet analyzers. Also, aside from two or three low-level routines (and CRC-32 calculation), different code, written in different years, for encode and decode. Sorry if it seemed I spoke down to you. Until someone gives me their bonafides on such a subject, I have to assume minimal PSIP knowledge. Give me a list of the sets that include your PSIP, and I might be able to tell you a bit as to how well they conform to the spec. There are quite a few of PSIP implementations out there on the receive side that are substandard or worse. I spot errors in encoder implementations, and even other t&m gear, from time to time. So, you believe that the UTC time value is to display the time to viewers? Kindy kludgy to start (always) with UTC time, convert it to GPS, transmit it, then convert it back to UTC before use, is it not? Thankfully, my implementations aren't written into silicon. Come to think of it, I'll send you an invitation to my PSIP list. No PR, but more than a few PSIP experts. And, a much lower SNR than this list. I don't think there's been a posting in more than a month. John Willkie _____ De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En nombre de Paul Freeman Enviado el: Thursday, May 24, 2007 4:14 PM Para: opendtv@xxxxxxxxxxxxx Asunto: [opendtv] Re: A full explanation of the PSIP time issue. Hi John, I realize that local time zone is set in the receiver. Just as you have spent a number of years implementing the transmission side of PSIP, I have spent a number of years (seven) writing different implementations of the receiver side of PSIP. PSIP software that I have written has been licensed by a number of different silicon customers and TV OEMs and is used in several million TV sets. This level of experience does not mean that I am right - as we both seem to have significant experience with PSIP and yet only one of us is right. But I just wanted to point this out to you. But my point had nothing to do with where the adjustment for local time zone and daylight savings time is made. My point was to answer your question of why the PSIP spec would require the broadcaster to transmit the GPS_UTC_offset field if the system_time and EIT event start time were both in GPS seconds. And my argument for requiring this is so that the receiver can compute the correct local time for display purposes, for example in a channel banner. -Paul _____ From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On Behalf Of johnwillkie Sent: Thursday, May 24, 2007 5:51 PM To: opendtv@xxxxxxxxxxxxx Subject: [opendtv] Re: A full explanation of the PSIP time issue. Paul; I KNOW that all times expressed in STTs are UTC. Until I had worked with the spec for a few years, I believed that the times in STTs were GPS. I was able to mathematically prove that I was wrong and I confirmed my new information with several of the authors. I've talked about this with multiple vendors and they have the same knowledge as I. I'm reminded that at one time I thought it was unlikely that the length of the diagonal of a right triangle could be calculated accurately by getting the square root of the sub of the square of the length of the two other sides combined. But, I was able to prove it mathematically in eighth grade, so I haven't had much need to check the math in the meantime to see if something changed. I guess you've missed the rather (to me) clear point: if the time in STTs was GPS, there is NO USE of the GPS_UTC_offset value, because the terminal would just be able to tell the time by comparing the start_time (32 bits) with the system_time ()32 bits). It would be required, if the system time was UTC, since you would only be able to match the start time of an event by adding system_time plus GPS_UTC_offset and compare the result with the EIT event start time. Your comments below evidence an understanding, but you have made no argument for ANY need of UTC time in the receiver, if the STT and EITs are denoted in GPS. If UTC is transmitted in the STT and EITs are GPS, then the need is clear; you add GPS_UTC_offset to the UTC integer to get the GPS integer. I need to point something out: local time zone is set in the receiver, and the same correction for the local time zone (minutes and seconds) is applied to GPS or UTC to derive local time. How to handle this is left up to implementers, but it's a value that doesn't change during the time a set is turned on, unless the set happens to be in a moving vehicle that crosses a time zone boundary while being turned on. Adding or subtracting static values like this is quite simple; things get fun when you have to add or subtract dynamic variables on the fly. So, local time has nothing to do with this 'argument.' Daylight savings time data is transmitted in the STT only within 30 days of a change, other than to indicate that DST is being observed or not. Here's something else that is commonly misread in the spec. It says to derive UTC, you subtract GPS_UTC_offset from GPS time. It doesn't say that you need to do this, only that when you want to do that, you follow the procedure. But, Bert says that PSIP is simple. Everything one needs to know about PSIP is contained in A/65 and the normative and informative references. That doesn't mean that one can figure out everything on the first dozen reads. Heck, it takes more reads than that to spot some of the subtle ambiguities. However, that doesn't apply to this situation, as there is NO AMBIGUITY in the spec on this point, there are just people who haven't read it enough (and played with the math and code) to figure it out. Let me put it another way. After 'grokking' A/65, I found that other specs were very simple to understand, almost at a glance, because of all the subtle issues that I've figured out with A/65. (One exception: CEA-608 is still a bit funky to me.) But then, when I'm reading another spec for the first time, I tend to focus on step #3 - how do I use it? John Willkie _____ De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En nombre de Paul Freeman Enviado el: Thursday, May 24, 2007 3:05 PM Para: opendtv@xxxxxxxxxxxxx Asunto: [opendtv] Re: A full explanation of the PSIP time issue. Hi John, I think the reason for sending the GPS_UTC_offset is so that the receiver can correctly determine the time of day for purposes such as displaying a channel banner and for labeling the columns on an EPG grid display with the correct start times. (I believe) the STT times are expressed in GPS and (we both believe) EIT start times are also expressed in GPS within the PSIP data. But the user wants to see these in times displayed in their local time. So the receiver must first convert the transmitted GPS times to UTC time by subtracting the GPS_UTC_offset, and then adjust the UTC time for the local time zone and local daylight savings time status. Without transmitting the GPS_to_UTC offset, the receiver would be displaying the wrong values in the channel banner and grid guide. _____ From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On Behalf Of johnwillkie Sent: Thursday, May 24, 2007 4:55 PM To: opendtv@xxxxxxxxxxxxx Subject: [opendtv] Re: A full explanation of the PSIP time issue. Yes, I meant to correct that. EIT times are GPS time, and I erroneously stated otherwise in this thread. However, that just begs the point. PSIP provides time of day, EPG and time for EPG events. Since the time in EITs are GPS, and - a false notion - the STT is GPS, just why is the GPS_UTC_value transmitted in the system time table? And, IT'S REQUIRED TO BE ACCURATE! It isn't needed; TV sets and receivers have no need for UTC (in this argument). And, I can find no other circumstance in PSIP where 8 bits of unneeded data is required to be transmitted, let alone where unneeded data is required to have a value other than '1' in each bit position. Now, that GPS_UTC_offset value is required in the actual PSIP time scenario, to correct the transmitted UTC to GPS. Once again, all this becomes obvious once you do the coding of just a PSIP encoder. John Willkie _____ De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En nombre de Paul Freeman Enviado el: Thursday, May 24, 2007 1:46 PM Para: opendtv@xxxxxxxxxxxxx Asunto: [opendtv] Re: A full explanation of the PSIP time issue. I am having a hard time concluding from the A/65C spec how the system_time field in the STT is anything other than GPS time. I do not see how the conclusion has been reached that this field represents UTC time, and so far have been unable to understand the arguments that have been presented in favor of the syste_time field representing UTC time. But I have seen some of the posts claim that the EIT information is UTC time, and nobody has refuted that yet. However, from my reading of the spec, even though the EITs change at 12:00, 3:00, 6:00, and 9:00 UTC time (not GPS time), the actual start times listed in the EITs are themselves expressed in GPS time. That is, the "start_time" field in the EIT is described on page 44 of A/65C as "A 32-bit unsigned integer quantity representing the start time of this event as the number of GPS seconds since 00:00:00 UTC, January 6, 1980".