The GPS-UTC delta is part of the set of data GPS sends down from the satellites. My GPS clocks will show the time two seconds fast for some amount of time ranging from 0 to 12 minutes after first-fix because the periodicity of that particular message is 12 minutes. My guess is that 2 seconds means that the firmware was written some time before the leap second before the most recent one, and that in the absence of that message, the firmware uses a compile-time default delta that gets overridden when the real value arrives. What kinda sucks is that there’s no indication in the NMEA sentences that this “infill” data is being used. You just get the wrong time and then suddenly it corrects to the right time. It’s conceivable that SkyTraq could update the firmware with a new “default” delta, but that would only last until the next leap second. It’d be nice if they updated some non-volatile memory whenever a leap second occurred. Then you’d only see the error once when a new chip is brought up for the first time. The data is stored in battery-backed storage, so as long as you don’t *cold* start, you’ll have the correct time. This observation prompted me to change my mind and add a super-cap Vbatt circuit going forward (so it can tolerate up to around 45 minutes of power loss without having to cold-start). The SkyTraq receiver correctly reports (positive) leap second as they occur as 23:59:60. > On May 16, 2017, at 3:29 AM, Tim Shoppa <tshoppa@gmail.com> wrote: > > Since future leap seconds aren't known very far in advance, how wise is it > to even claim to handle any possible leap second or time scale conversion, > in a firmware-controlled device that cannot download future leap second > information from the Internet? > > The GPS itself presumably knows how to handle leap seconds at the moment > with possibly minor glitches. > > If you can connect to the Internet, then I think you're good for maybe the > next few decades until the current concepts of "web" and "URL" and > "internet" become as hopelessly outdated as Telex addresses. I think the > URL concept probably has at least a decade left in it, and that's > considerably longer than the couple-times-a-year possibility of a leap > second, so leap second file downloads from IETF would seem to make sense if > you claim to handle such conversions. > > The "future-proofing" of your time conversion is not a new issue. When I > read century-old articles about gear ratios for converting solar to > sidereal time (*) , they note that you should not try to get too many > digits of precision because they knew that the length of the solar day had > real and unpredictable variances even back then. One author notes that if > you want your gear ratio to work well for the next 100 years, you should > use the ratio appropriate for 50 years into the future, not today. > > Now admittedly, microcontrollers generally don't last as long as a set of > gears :-) > > Tim > > On Sat, May 13, 2017 at 9:58 PM, Mark Sims <holrum@hotmail.com> wrote: > >> Converting GPS seconds to Gregorian date/time on the Arduino will be an >> arduous task. You take GPS seconds and add it to the GPS starring epoch to >> get a Julian date. Then add in the number of leap seconds as a fraction of >> a day to get UTC and possibly add in a time zone offset for local time. >> Don't forget to do daylight savings time conversion... Then convert the >> result to Gregorian date/time for display. >> >> The problem is the Arduino floating point library is single precision only >> and does not have the resolution needed to handle the numbers involved. >> Doing it with integer arithmetic (long longs) opens up a whole new can of >> worms. >> _______________________________________________ >> 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.

Hello, I know that breakout boards for Motorola M12 have been done to death But…. I am doing a one that fits my needs. Primary to add a 1PPS + TOD as defined by ITU G.8271 Since most of the equipment I am working with has this as a standard interface. My plan is to have a AVR to do the protocal conversion as well as provide a USB management interface. Is there any interest form the group? Thank you Lincoln