Re: [time-nuts] TV Signals as a frequency reference
I wrote a program that would scan the PSIP data from my local stations and the STT was always quite poor. Usually several stations had the GPS-UTC offset that was stale, even a year after a leap second. It would be trivial to make an automatic correct STT generator some online data (NTP, etc.), why this was not part of the software that generated the PSIP data is a mystery to me. DST was a mess. I think this bit from A/65 was confusing: When the transition into daylight saving time is between one day less than one month away and the actual transition the DS_day_of_month field takes the value day_in, and the DS_hour field takes the value hour_in. The DS_status bit is 0 indicating it is not yet daylight saving time. What exactly does "less than one month away" mean? Does it mean less than 31*24 hours away? Does it mean in the current calendar month? What happens is you get a STT that says "DST begins on the 11th at 2:00 AM". They couldn't figure out how to pack the month in 16 bits so you just get "the 11th", no month. It's now Feb 12th. Has DST started? Some devices would decide the answer is yes and others no. On Mon, Apr 2, 2018 at 10:08 AM, Mark Sims wrote: > I read that there is a requirement that the time data in the PSIP data stream > has to be within one second. > > I have an over-the-air DVR that would mess up the time and recordings because > it was originally not filtering the times the stations broadcast. They > finally modified the DVR firmware to do something like a median filter to > throw out the outliers. A local TV guru beat up on all the local stations > with a copy of the FCC rules to get the stations to broadcast the correct > time. And don't me started on the ways the stations still mess up the > daylight savings time transitions. Many are a month, week, or day off. > > --- > >> There is no requirement for us to inject time of any prescribed accuracy > into the digital stream. > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Holdover, RTC for Pi as NTP GPS source
Some of the DS chips have a square wave input that can be fed from a GPS PPS and the RTC will discipline itself. It can also produce a PPS when the GPS stops. The question is, is NTP's holdover on the system clock better than NTP disciplining the system clock with an RTC PPS. I'd guess not. Forget about accurate time from the RTC's registers. The slowness and variably in I2C is quite poor and most of them don't even have sub-second resolution when read or written. On Nov 1, 2017 4:22 PM, "MLewis" wrote: Is this a workable or worthwhile strategy?: - RTC providing date & time to second to system on boot - RTC frequency output driving a counter/divider to produce PPS - GPS module providing UTC PPS - GPS module's secondary PPS disciplining the RTC-counter-divider PPS by resetting the RTC's counter/divider (I'm assuming there's one that will rest fast enough to sync; I've never looked into these...) If GPS PPS is lost, then the RTC counter/divider is producing a recently disciplined PPS. Valid or invalid? And the DS3231 has: - a 32K output, and - an Active-Low-Interrupt/SQW output that can be set to PPS. It's unclear to me how to sync the DS3231 PPS to the GPS PPS, or if that can be done. Thanks, Michael ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/m ailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] A look inside the DS3231
Looks like it still says "DALLAS SEMICONDUCTOR" to the left of Maxim. Maybe Maxim only wanted to change the mask enough to find some empty space to sign it? On Thu, Jul 27, 2017 at 12:31 PM, Pete Stephenson wrote: > Hi all, > > A few days ago I reported the results from letting a DS3231 RTC run for > a year, and how the chip kept time well within the published specs. > > Since I had acquired several DS3231s from dubious sources (Asian vendors > on a major auction site) as part of an RTC module that fits on the > Raspberry Pi's header pins, I was doubtful of the authenticity of the > chips. I decided to sacrifice one in the name of science and decapped it > at home using alternating heat (a lighter) and cold (a glass of cold > water) to embrittle the epoxy casing, then sanded down the back of the > chip on fine-grain sandpaper to expose what I hoped was the back of the > internals (so as not to damage the die itself). > > Other than inadvertently sanding through half of the crystal's housing, > thus breaking one of the forks of the crystal, this was a success. (I > was prepared to decap one in acid had my attempt at physically removing > the epoxy package failed.) I slightly scratched the die itself while > separating it from the epoxy, but the die itself is clearly visible. > Based on a sample size of one and the markings on the die itself, it > appears the chip is authentic. The markings on the outside of the epoxy > package look a bit dubious and not like typical Maxim laser-markings, so > it's possible the chip was re-labeled at some point. I'll contact Maxim > to see if they can look up the lot information. > > I used my 2 megapixel USB microscope to take some images throughout the > process that you might find interesting. The microscope has limited > resolution, particularly at high magnification, so some of the photos > may not be perfectly clear. I have access to a Zeiss petrographic > microscope at my work and will see if I can get some better images > tomorrow. I'll try to get high-quality images of the whole chip and > stitch them together into a larger composite. > > Anyway, the photos are available at http://imgur.com/a/0zudj -- I will > add more photos from the petrographic microscope tomorrow. I focused > mainly on the markings on the die that indicated it was, in fact, a > Maxim chip but if there's any other region of the chip that you'd like > images of, please let me know and I'd be happy to take some more > pictures. > > I hope you find this as interesting as I did. > > Cheers! > -Pete > > -- > Pete Stephenson > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Four hour cycle in GPS NMEA jitter
On Thu, 2017-03-23 at 08:28 +1300, Kiwi Geoff wrote: > On 3/22/17, Trent wrote: > > https://goo.gl/photos/JZhBbFKFzkBAykti6 > > Why would a GPS module produce jitter with a pattern like this? > > Trent, I decided to R.T.F.M.(read the fantastic manual ;-) > > It looks like that in your Telit module, there is a mode called > > --- > Client Generated Extended Ephemeris (CGEE) That sounds very promising! Your FM is better than my FM, the "JN3 Hardware User Guide" revision 2, which has nothing in it about extended ephemeris mode. > CGEE data is always generated for a prediction interval of three days: > - Consists of 18 blocks of 4-hour EE data blocks > - Updated when a newly visible satellite is acquired I'm indoors with a poor view of the sky, so I'm be surprised if new satellites don't come into view throughout the day. > - Updated when new broadcast ephemeris is received from a tracked > satellite and the current EE data block is nearing expiration That explains the peak every four hours, assuming the EE data blocks are synced to start at UTC (n*4):00 and not device power on. > - On average, it takes 1.2 seconds per satellite for the receiver to > calculate CGEE That would easily explain the few outliers at the 4 hour mark. But std.dev. sure appears to increase for about 2 hours up to the 4 hour mark, then rests back to a lower value for about 2 hours before increasing again. See attached graphs. It's even more apparent when I overlay each hour period on the same X axis. That doesn't seem to fit the description of CGEE mode, but then again we don't really know the algorithms used in the GPS receiver. It's possible that a calculation involving a 4 hour EE data table takes longer, and thus produces more jitter in competing threads like NMEA output, when the computation is using the end of the interval vs the beginning. E.g., a linear search for a line in the table to use. > >From a quick glance at the manual, it looks like this mode can be > turned off with: > > AT$GPSIFIX=0 Unfortunately, the GPS's design as part of the IRU means I can't write to it :(. I'd really like to try that and see what happens. Obviously the proper fix is to get PPS working and I've known that all along. I'm really more interested in the WHY of the four hour cycle. I think turning off CGEE will be the only way to know if that's the sole explanation, or if there is more at play. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Time Dilation tinkering
On Wed, Mar 22, 2017 at 9:39 AM, David C. Partridge wrote: > Aiguille du Midi is 3842m IIRC (cable car base station at about 1000m). > > Dave > > > Pikes Peak in the US is 14114 ft, 4304m and has a road to the top. Of course > the base is at about 5000 ft/1600 m > > In EU, there's probably a Seilbahn of some sort pretty high up in the Alps, > although probably not to 4000m. Mauna Kea in Hawaii lets one drive from sea level to 13,796 ft, 4204 m. Pretty big delta for a few hours of over land travel. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Four hour cycle in GPS NMEA jitter
Hello time nuts, I'm working on a custom embedded Linux device, with a custom inertial reference unit, which contains a GPS module. The module is a Telit JN3, which is based on the SiRFSTAR IV I believe. I'd like to use the GPS to sync the Linux system clock. Eventually I'd like to use the PPS signal, which is routed to a FPGA that's part of the CPU, to implement a custom PPS hardware module that I can write a kernel driver for and use the Linux hardpps system. And maybe make that feedback to the CPU's main clock source, since the FPGA also controls that and could create a PLL between the TCXO that serves as the master clock signal and the CPU's source clock. But first things first. I'm just grabbing the time from NMEA sentences. And there's quite a bit of jitter there! Clearly using the first sentence output by the GPS is critical. I've tried to account for any time delays in the software. I think it's the GPS module that is creating the largest source of jitter. It appears to go in four hour cycles, peaking at 0:00Z, 4:00Z, 8:00Z, etc. Does this sound like something that one would expect with the NMEA output of a non-timing GPS? Is it related to satellite orbits? Or perhaps is has something to do with the design of the SiRFStar IV? I'll attach a graph of what I'm seeing. If the attachment doesn't come though it's viewable at https://goo.gl/photos/JtYfJCpRSZb3hCnM8. Methodology for the graph: System clock is left free running and not disciplined, after an initial one time set based on the GPS time. On each NMEA GGA sentence, sent at 1 Hz, the system clock's offset from the NMEA timestamp is measured. Each minute, the mean, std.dev, min and max are found for the last 60 offset samples. This is plotted on the graph. Any outlier samples, defined as more than 3 sigma from the previous mean, are also plotted. Concurrently, the chrony NTP daemon is running and monitoring the IT dept's NTP server, but NOT being used to set the local system clock. Once a minute, the system clock's offset to chrony's idea of the NTP server's clock is also measured. Chrony is using an algorithm based on median filtering to get its idea of the NTP server's clock. The NTP server is just a windows domain controller synced to the internet NTP pool and far from a precision source. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
