Hi Mark,

You don't need to boil everything into one single number before
decomposing it into another form.

If you start with the years, well, the different sums at most offset you
by 1 as you branch to the next year at somewhat misaligned dates.
Similar with GPS weeks etc.

If you think it through, you can make a first rough estimate, and
correct it step-wise, making sure the ripple rules is properly applied.

Operating in de-composed form isn't all that hard. It is however
important to make test-benches that can check the dates over a wide
range of years. I typically do many centuries, to make sure I got the
Julian ripple rules right.

I made one function which was a bit handy, giving the amount of leap
days since epoch. In this case you would not only need the Julian but
also the Gregorian, and the difference between them would be... your
leap day adjustment.

Cheers,
Magnus

On 05/14/2017 03:58 AM, Mark Sims wrote:

On 5/14/2017 5:24 AM, Magnus Danielson wrote:

Good morning all,

I tried it by hand last night on two sheets of paper with a calculator
and a frosty adult beverage...because I'm crazy like that.  I'll kill
the suspense by saying I didn't get the right answer...so the rest of
what I'm going to say has an error somewhere...but I think I can make
the process work if the time library doesn't hold the answer.  (and I
think it does)

I asked https://www.andrews.edu/~tzs/timeconv/timeconvert.php to give
me current GPS time in seconds at known time, and then went to work.
That same converter has a "tell me GPS seconds now" which agreed with
the time in seconds coming from the TruePosition.

So...I figured out how many whole years (37...so its 2017), then used
the remainder to figure out whole months (4...so its May 2017), the used
the remainder to figure out days (13...so its 14 May 2017 because any
remainder puts us into 14 May), then used the remainder to figure out
hours (2...so its 14 May 2017 02:00), then used the remainder to figure
out minutes (31...so its 14 May 2017 02:31), then used the remainder to
figure out seconds (35...so its 14 May 2017 02:31:35), then subtracted
18 leap seconds to get 14 May 2017 02:31:17.

Only problem was that it was 14 May 2017 00:31:17 UTC.  I'm not sure why
the extra two hours...so I clearly got something wrong.

But, I think I should be able to do all this with, at most, single
precision floating point math.  Maybe integers...but I've got to think
about that as I'm not sure how integer math on the Arduino treats a
decimal remainder.

Of course...all this is moot if I can get what I want out of the time
library.  :)

thanks much,
ben

I went through much the same thing withe the wwvb cheatn d-psk-r. The date
and time format is integer minutes since 1980 as I recall. Long longs are
my friend.
Think I used even bigger. But I ended up with leap second tables and leap
days.
It really is complicated. But you learn a lot in the effort. By the way
that was my first serious C program on arduino and it worked. Beyond make
the light blink.
Good luck.
Paul
WB8TSL

On Sun, May 14, 2017 at 9:25 AM, Ben Hall kd5byb@gmail.com wrote:

On Sun, May 14, 2017 at 9:25 AM, Ben Hall kd5byb@gmail.com wrote:

The Arduino Time library can convert back and forth between numeric
year/month/day/hour/minute/second and a uint32 representing the number of
seconds since 1/1/1970. It does not take leap seconds into account however
so you would have to make an adjustment for them. It is reasonably well
documented and includes some handy conversion macros and examples.

As with other Arduino libraries, the source code is provided so you can see
how they did it.

--

--Jim Harman

On 5/13/17 6:58 PM, Mark Sims wrote:

I don't know that this conversion is that hard on an Arduino, except
perhaps the daylight time (just because that's such a complex irregular
thing)

There's only 604,800 seconds in a week. that fits in a long quite
nicely. If you don't need to work too far into the past, you need a
table of weeks with appropriate metadata->what calendar date it
corresponds to, and whether there's a feb 29 or leap second.
(or do it with arithmetic for the leap years)

Mark, Ben, Paul,

32-bit integers is sufficient. Use days instead of seconds. Use MJD instead of JD. Here's an example:

Step 1, convert calendar date to MJD, and then to GPS day:

// Convert year, month (1-12), and day (1-31) to Modified Julian Day (MJD).
// Adapted from sci.astro FAQ (valid for Gregorian dates from 17-Nov-1858).
int32 ymd_to_mjd (int32 yyyy, int32 mm, int32 dd)
{
return
367 * yyyy - 7 * (yyyy + (mm + 9) / 12) / 4
- 3 * ((yyyy + (mm - 9) / 7) / 100 + 1) / 4
+ 275 * mm / 9 + dd + 1721028 - 2400000;
}

#define MJD_TO_GPS_DAY(mjd) ((mjd) + 44244)

Step 2, apply leap seconds since 1980 using table look-up.

/tvb

----- Original Message -----
From: "Mark Sims" holrum@hotmail.com
To: time-nuts@febo.com
Sent: Saturday, May 13, 2017 6:58 PM
Subject: [time-nuts] GPS seconds conversion on an Arduino

I wouldn’t expect floating point to enter into it.

Add the leap second correction in, then take seconds modulo 86400 and you get the second-within-the-day. Divide seconds by 86400 and you get the day number.

With the day number, it’s quite straightforward to figure out gregorian date given a 0 date in modern times (GPS’ epoch is in 1980). You do have to figure out externally what 1024 week GPS cycle you’re in. You can start with a firmware default and increment an EEPROM value every zero-crossing. As long as the user gets a fix at least once every 1024 weeks, you’ll be good.

You figure out the year by subtracting 365 or 366 and incrementing the year number until the day is less than either 366 or 365. Picking which of those is tricky, but it’s not particularly onerous. You figure out the month by comparing the remaining days to a list of day-of-year-for-month values (again, being careful to increment by 1 during leap years if the month is > 2). Subtract that out, add 1, and the remainder is the day-of-month.

Turning a second-within-the-day value into H:M:S is child’s play. The only nuance left is 23:59:60 when a leap second occurs.

All of that is enough to go from GPS second number to the NMEA UTC output.

Going from NMEA UTC output to DST corrected local time is actually an exercise I’ve done for my GPS clock. You can take a look at my C code for that on GitHub: https://github.com/nsayer/GPS_clock

Now, going to Sidereal time, that’s a floating-point bitch.

The goal I had was to convert GPS to UTC to minutes from 1980 to create the
wwvb time message.
Much of it was reasonable but then the funnies came in. The WWVB contains a
part of the message that says DST is coming and dst is here.. Tables took
care of that nicely.
I used 64 bit words because that nicely line up with seconds in a minute.
Good comments by everyone.
Regards
Paul
WB8TSL

On Sun, May 14, 2017 at 12:15 PM, Nick Sayer via time-nuts <
time-nuts@febo.com> wrote:

Unless this is an educational exercise I'd move to a different processor.
One of those $3 Arm M3 units has enough  memory AND a more standard
development environment that you could use a standard library function to
do what you need.  For more money ($13) you can get the Arm M4 on an
arduino-like PCB and this unit has floating point hardware and even more
memory.  Still about the size of an Arduino Uno but 1/2 the price and 10X
processing power.

Then use nothing like this
http://cosmos-project.org/docs/core/1.0.2-/group__timelib__functions.html

But what is your "big Picture" goal?  Do you just need a sidereal clock
display.  Then you only need precision up to the number of digits displayed
up up to human perception.    50ms more or less is about all we can detect
by eyeball or ear.

But are you looking to aim a telescope and need sub-arcsecond precision?
The last time I needed to write software to aim a 'scope we had a wide
angle camera so I only needed to car about milliseconds but some people
today even with backyard telescope want better than that.

On Sat, May 13, 2017 at 6:58 PM, Mark Sims holrum@hotmail.com wrote:

--

Chris Albertson
Redondo Beach, California