| Page 2 of 2 | 1 | 2 |
|
|
|
Clock accuracy & auto setting : digital television does a crapjob of providing time services...
Max,
Have you seen the white paper "The NTP Era and Era Numbering" on the NTP project page at www.ntp.org http://www.eecis.udel.edu/~mills/y2k.html? It includes a 128-bit date format, which has enough seconds bits to measure the age of the Universe until the Sun grows dim and enough fraction bits to measure the time a photon crosses an atomic nucleus. The mapping to and from this format and NTP timestamps is transparent, even when the NTP era rolls in 2036, 2172, ... Dave Max Power wrote: In North America, the FM RDS time service is of very low quality. In Europe (I understand) this is not the case with RDS. Stations running RDS should be mandated by law to provide a quality service -- based on transmitter power and coverage area. Over time RDS's time service should be uniform. DRM (on MW and SW) time service is of a lower quality than RDS -- but could be upgraded with a specialized "80 bit" NTP-UNIX time packet. ATSC and DVB-T (& DVB-H/M) need a uniform ~"80 bit"...~"128 bit" time packet service that is well thought out. Futureproofing is important, so probably 128 bits or more is preferable. LF time services are OK, and are necessary over large transnational regions -- like Sub Saharan Africa, Australasia and South America ... but any new LF service needs to be more technologically advanced than WWVB, MSF or DCF77 and its Swiss twin. In these regions 10 LF frequencies need to be allocated, but the signal to be transmitted needs to be more modern than WWVB or DCF77 -- maybe using some form of low complexity PSK or low complexity QAM and 240 hz to 480 hz of bandwidth. The signal must be futureproofed -- as above. I wish I had all of the email addresses of the Canadian National Research Council -- so that I could email them my CHU upgrade proposal at * http://CBC.am/CHU.htm * This proposal probably, if implemented -- would require a signal upgrade to account for 2 transmitters on all of the frequencies used. * A properly designed signal upgrade could make CHU a more powerful [technological design] than WWV[H] -- but this would probably require 2 or 3 years of experimentation. I would love to see support for high speed ECC polytone and MD63 (MD?) with its Walsh coding. ATSC time is always late ? ======================== ATSC and DVB-T (DVB in general) are devoid of a 64 bit (or 80 bit) clock packet (based on NTP and 'Unix Time'). For people to be forced to rely upon GNSS (Glonass, GPS, Galileo) for a time signal is rather immoral when TV transmitters (and radio too, remember RDS) pump out many megawatts of signal each day (globally). ///////////////////////////////////////////////// Immoral? That's a bit strong, innit? You don't NEED to rely on satellites for time signals. There are many LF radio time signals, such as WWV, WWVB, WWVH, CHU, MSF, DCF77, and others. CDMA cell phone towers broadcast a time signal. |
Clock accuracy & auto setting : digital television does a crap job of providing time services...
On Mon, 01 May 2006 05:42:07 -0700, Max Power wrote:
LF time services are OK, and are necessary over large transnational regions -- like Sub Saharan Africa, Australasia and South America ... but any new LF service needs to be more technologically advanced than WWVB, MSF or DCF77 and its Swiss twin. In these regions 10 LF frequencies need to be allocated, but the signal to be transmitted needs to be more modern than WWVB or DCF77 -- maybe using some form of low complexity PSK or low complexity QAM and 240 hz to 480 hz of bandwidth. The signal must be futureproofed -- as above. ================================ OK? What other technology can provide such accurate signals at such a low cost? The simple amplitude modulated nature of the LW signals makes for such low cost implementations. A PSK or QAM modulation is going to put the cost of hardware to decode the signal up to much to be useful. For consumer purposes (save cellular telephony) GNSS technology is too costly. NTP is OK for computers, but has a learning curve. But the consumer does not need any better accuracy than LW, and if they do then GPS is dirt cheap these days. The point is that the SW signals have very few users. Consider the number of say CHU users to MSF or DCF77. I am unaware of WWVB doing this. If WWVB does this, its signalling must be very quaint. Typical 1983 signalling medthods (bitfields transmitted) would probably not pass modern muster. The point was that the LW signals can provide better accuracy than the normal AM pulses used. BCD is the universal flaw of LW time stations. NTP could fix the problem, but NTP is not perfect for this [without tweaking]. BCD could be said to use odd signalling in not using {seconds} within a day, albeit seconds are not suitable for LW signalling rates. All LW signals implicitly signal the second... I assume both NTP and BCD signalling medthods are aimiable to 'bit averaging' for LW time service's slow signal rate and error correction condtions. Not really a 64bit signal cannot be transmitted within one minute for starters. Secondly a NTP style time signal would be overly complicated for the simple wall clocks to cheaply decode. I just described a simple binary coded signal with the year/day/time as separate fields with loads of bits left over for error correction, which could be taken or left depending on the power of the decoding device. It is good for a 1000 years. What more do you need? DRM on MW and SW only sends the Julian date and time. There is some BCD coding similar to WWVB and DCF77 -- for time and date. However, there is no [univeral] NTP or UNIX time packet in DRM. Probably because it is not suitable for simple decoding. SW signals do cover areas LW cannot reach (like Antartica) -- and with adiquate frequency diversity provide a higher time resolution vs LW. If you need something better than LW then GPS is a better solution than SW and probably just as cheap, and has global reach. I imagine that a good view of the sky is not hard in Antartica. DRM can cope with ionspheric delay via indicating TX (and at the reciver RX) coords. LW time stations are trapped in late 1960s style signalling. But are simple enough to provide a millisecond accuracy at the receiver for 20USD. I personally cannot think of anything dafter than an additional SW transmitter signal for CHU. Another LW station somewhere in north America would be infinitely more useful. JAB. -- Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk Northumberland, United Kingdom. Tel: +44 1661-832195 |
Clock accuracy & auto setting : digital television does a crapjob of providing time services...
Alan,
The 128-bit NTP date spans 584 billion years with a resolution of .05 attosecond. The 64-bit NTP timestamp spans 136 years with a resolution of 232 picoseconds. Is there something that needs better than 232 picoseconds? A 4-GHz CPU comes close. As for broadcasters chiming good time, I do know that PBS/NPR distributes progams via digital satellite and IP network with NTP. However, I am told the gadgetry that actually brands the signal doesn't use NTP, is often banished to the bottom of the rack and nobody knows how to adjust it. As for the broadcast program start time, so far as I can tell it's withing 30 ms of UTC. That's the best I can do with eyeball and ear. When I worked for an NBC affiliate in Detroit we had two clocks, one synchronized to the power grid and the other a Western Union gadget that synchronized via wire. The WU clock was purposely set to run slow by a second or two per hour. Once per hour WU sent a pulse over the wire causing the clock to do a hands-up jerk. I quickly learned to use that clock only to calibrate the few seconds offset of the grid at the hands-up signal. Broadcast networks once sent an audible ping at hands-up to do the same tning, but that was (ahem) 50 yuears ago.. Dave Dave Alan Larson wrote: In article "Max Power" writes: In North America, the FM RDS time service is of very low quality. In Europe (I understand) this is not the case with RDS. Stations running RDS should be mandated by law to provide a quality service -- based on transmitter power and coverage area. Over time RDS's time service should be uniform. DRM (on MW and SW) time service is of a lower quality than RDS -- but could be upgraded with a specialized "80 bit" NTP-UNIX time packet. ATSC and DVB-T (& DVB-H/M) need a uniform ~"80 bit"...~"128 bit" time packet service that is well thought out. Futureproofing is important, so probably 128 bits or more is preferable. 128 bits? What do you want - to specify the time of the heat death of the universe (long after our sun dies) to nanosecond resolution, then be able to tell the time of the death of the next universe (if there is one)? 64 bit NTP is probably quite adequate, and definitely enough bits if one doesn't insist on the NTP nanosecond precision. However, the time information doesn't need to be NTP, or IP based. By the way, NTP is not a part of unix. Presently, the analog TV stations transmitting time don't even seem to consider it worth keeping the clocks set accurately -- some use a PC's clock, with no external source to deal with its drift. The time sent with ATSC seems to be random as well. Some stations seem to have gone ahead with DST, but the only way to get the program data to be correct is to manually force (and set) the receiver to use local standard time. Of course, not using UTC is astoundingly stupid -- folks who live next to a time zone boundary are out of luck if some stations are on each side. However, counting on broadcasters to get the time right is a fantasy. They cannot even get their program guide information correct in the data stream. Alan |
Clock accuracy & auto setting : digital television does a crap job of providing time services...
Hi Dave,
Since the application for ATSC broadcasting seems to be mostly setting the clocks in the receiver's equipment, the 232 picoseconds of NTP seems to rather far beyond what is needed. After all, 232 picoseconds is just under 7 centimeters at light speed. Thus, broadcasting the time of day (to set the clock in your TV recorder) to that resolution seems a bit excessive. 0.01 second seems adequate to me to not miss the program. The problem as I see it is that the sources are way bad (as you note). Clearly, NTP would be a useful and available way of keeping a machine transmitting time on a broadcast signal in good sync. With ATSC, there seems to be some difficulty with daylight saving time -- when the time advanced this spring, I noticed that the electronic program guides apparently did not advance. Attempts to set the clock on my ATSC receiver from over the air signals got various times which did not match local time. I eventually gave up and went back to the recommendation in the addendum to the manual to manually set it to local non-DST time, with the timezone set. That gets the program guide to match, but the clock of course reads an hour slow. It is unclear whether the Asians who programmed the thing didn't understand time, or whether the standard is that completely flawed that it doesn't account for properly dealing with transferred times in UTC and converting for display. (Though, transmitting daylight saving time info in the WWVB style seems a good idea, given the government's willingness to fiddle with it and almost certainly break lots of things with built in advance/fallback calculations.) Precision is not a solution for lack of accuracy. Neither precision nor accuracy will make up for implementation errors. Alan p.s. Doesn't CBS news still do the ping at the top of the hour? I think they are still coming out from KCBS here. (I don't know what they do about satellite delay of the feed (signal travel time, and any digital coding/decode times). I have no idea how they will deal with the variable time delays of IBOC digital processing. In article "David L. Mills" writes: Alan, The 128-bit NTP date spans 584 billion years with a resolution of .05 attosecond. The 64-bit NTP timestamp spans 136 years with a resolution of 232 picoseconds. Is there something that needs better than 232 picoseconds? A 4-GHz CPU comes close. As for broadcasters chiming good time, I do know that PBS/NPR distributes progams via digital satellite and IP network with NTP. However, I am told the gadgetry that actually brands the signal doesn't use NTP, is often banished to the bottom of the rack and nobody knows how to adjust it. As for the broadcast program start time, so far as I can tell it's withing 30 ms of UTC. That's the best I can do with eyeball and ear. When I worked for an NBC affiliate in Detroit we had two clocks, one synchronized to the power grid and the other a Western Union gadget that synchronized via wire. The WU clock was purposely set to run slow by a second or two per hour. Once per hour WU sent a pulse over the wire causing the clock to do a hands-up jerk. I quickly learned to use that clock only to calibrate the few seconds offset of the grid at the hands-up signal. Broadcast networks once sent an audible ping at hands-up to do the same tning, but that was (ahem) 50 yuears ago.. Dave Dave Alan Larson wrote: In article "Max Power" writes: In North America, the FM RDS time service is of very low quality. In Europe (I understand) this is not the case with RDS. Stations running RDS should be mandated by law to provide a quality service -- based on transmitter power and coverage area. Over time RDS's time service should be uniform. DRM (on MW and SW) time service is of a lower quality than RDS -- but could be upgraded with a specialized "80 bit" NTP-UNIX time packet. ATSC and DVB-T (& DVB-H/M) need a uniform ~"80 bit"...~"128 bit" time packet service that is well thought out. Futureproofing is important, so probably 128 bits or more is preferable. 128 bits? What do you want - to specify the time of the heat death of the universe (long after our sun dies) to nanosecond resolution, then be able to tell the time of the death of the next universe (if there is one)? 64 bit NTP is probably quite adequate, and definitely enough bits if one doesn't insist on the NTP nanosecond precision. However, the time information doesn't need to be NTP, or IP based. By the way, NTP is not a part of unix. Presently, the analog TV stations transmitting time don't even seem to consider it worth keeping the clocks set accurately -- some use a PC's clock, with no external source to deal with its drift. The time sent with ATSC seems to be random as well. Some stations seem to have gone ahead with DST, but the only way to get the program data to be correct is to manually force (and set) the receiver to use local standard time. Of course, not using UTC is astoundingly stupid -- folks who live next to a time zone boundary are out of luck if some stations are on each side. However, counting on broadcasters to get the time right is a fantasy. They cannot even get their program guide information correct in the data stream. Alan |
Clock accuracy & auto setting : digital television does a crap job of providing time services...
Alan Larson wrote:
Hi Dave, Since the application for ATSC broadcasting seems to be mostly setting the clocks in the receiver's equipment, the 232 picoseconds of NTP seems to rather far beyond what is needed. After all, 232 picoseconds is just under 7 centimeters at light speed. Thus, broadcasting the time of day (to set the clock in your TV recorder) to that resolution seems a bit excessive. 0.01 second seems adequate to me to not miss the program. The problem as I see it is that the sources are way bad (as you note). Clearly, NTP would be a useful and available way of keeping a machine transmitting time on a broadcast signal in good sync. With ATSC, there seems to be some difficulty with daylight saving time -- when the time advanced this spring, I noticed that the electronic program guides apparently did not advance. Attempts to set the clock on my ATSC receiver from over the air signals got various times which did not match local time. I eventually gave up and went back to the recommendation in the addendum to the manual to manually set it to local non-DST time, with the timezone set. That gets the program guide to match, but the clock of course reads an hour slow. It is unclear whether the Asians who programmed the thing didn't understand time, or whether the standard is that completely flawed that it doesn't account for properly dealing with transferred times in UTC and converting for display. (Though, transmitting daylight saving time info in the WWVB style seems a good idea, given the government's willingness to fiddle with it and almost certainly break lots of things with built in advance/fallback calculations.) Precision is not a solution for lack of accuracy. Neither precision nor accuracy will make up for implementation errors. Alan p.s. Doesn't CBS news still do the ping at the top of the hour? I think they are still coming out from KCBS here. (I don't know what they do about satellite delay of the feed (signal travel time, and any digital coding/decode times). I have no idea how they will deal with the variable time delays of IBOC digital processing. Alan Be aware that, at least in LA, some stations put the 'ping' ahead of an 8-10 second delay. Realistically, do you even need to be more accurate than a frame of video? I think 0.01 seconds is 10-100 times better than it needs to be. We're not trying to pinpoint the position of the news helicopter, just start your DVR without missing the head of the show. The phone company time is sufficient for that. I suspect the times are 'way bad' because it isn't automatically loaded yet and the stations aren't getting any complaints and those guys have plenty to do withouit setting a clock almost nobody checks. Personally, I set the times and record times manually with no problems. GG |
| All times are GMT +1. The time now is 06:32 AM. |
|
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
HomeCinemaBanter.com