Nearly there but... about wwvb HOT 15 CLOSED

Hmm, thinking about it - the wwvb_tx should be +6,00. With the -18 I'm guessing the date is wrong (it would be yesterday).

Reason for +6 is that your clock sync expects utc, and takes 6hours off the time to display cst. We don't want that, we want it to display localtime when cst timezone is selected on the clock. To achieve this, we should be adding +6 to the local time.

from wwvb.

No -18 gives it the correct day local time.
I'll do a test at +6 and post the result...

from wwvb.

Well that makes no frigging sense! Ill check it out tomorrow

from wwvb.

OK, that didn't do what I thought it would. The date on the Nokia LCD changed to the 19th and the time to 8AM not PM (after GPS time was valid). I aborted the clock time sync at that point.
I thought that the time & date on the Nokia LCD was independent of the time setting for the WWVB protocol output ?
gps.setTimezone did the LCD time zone correction for local ?
and
wwvb_tx.setTimezone sets the WWVB time zone offset (to match the clocks intended use region) ?

    // set the timezone before you set your time
gps.setTimezone(10, 30); // set this to your local time e.g. (ACDT = UTC +10:30)

// if you are using CST (UTC -6:00), set the timezone to -6,0
wwvb_tx.setTimezone(-6, 0);

Yeah, all this time zone stuff seems to be a real brain teaser (for me at least).

from wwvb.

The nokia time is set based off the time transmitted by wwvb with a +6 hour offset.
// To convert CST (UTC - 6:00) to local time, add 6 hours
line 253: addTimezone<uint8_t>(hh, mm, ss, DD, MM, YY, 6, 0, 0);

I think that wwvb.setTimezone ( wwvb_tx.setTimezone(-6, 0); )should be +6 (wwvb_tx.setTimezone(6, 0);), which means the offset back to local time on line 253 should be -6 hours (addTimezone<uint8_t>(hh, mm, ss, DD, MM, YY, -6, 0, 0);)

from wwvb.

OK, understood.
I think the issue for me is that I thought the Nokia LCD time was going to always be the 'reference' or the local time, but if it's offset by the same as the WWVB 'spoofed UTC time' then it never will be.
We have three times being juggled here. Actual UTC from the GPS, offset UTC to get the WWVB clock to read our local time, and local time on the LCD with it's local offset from GPS UTC.

The WWVB clock is hard coded to think it's sitting in USA and set by user to CST, so it subtracts 6 hours from UTC to get to US CST, then we need it to shift it by +16.5 hours to get it back to Australian CDST...
The local reference clock (the Nokia LCD) only needs to shift from UTC to Australian CDST by adding 10.5 hours...
That's my logic right now, if the GPS outputs UTC at least :)

Going on with that, I thought we'd have two independent offsets in the LCD example.
One to get the Nokia LCD to take GPS UTC time and offset to show local time.
Another to take UTC again but offset the WWVB output to make the WWVB clock to show local also.
Depending on where the WWVB clock was designed to work they won't be the same offset I think.

Maybe some of that makes sense :)

from wwvb.

Correct! Hence why i reckon the wwvb timezone should be +6, as its being
synced with utc + 10.5 :)
On 18 Feb 2016 22:26, "Martin" [email protected] wrote:

OK, understood.
I think the issue for me is that I thought the Nokia LCD time was going to
always be the 'reference' or the local time, but if it's offset by the same
as the WWVB 'spoofed UTC time' then it never will be.
We have three times being juggled here. Actual UTC from the GPS, offset
UTC to get the WWVB clock to read our local time, and local time on the LCD
with it's own offset from GPS UTC.

The WWVB clock is hard coded to think it's sitting in USA and set by user
to CST, so it subtracts 6 hours from UTC to get to US CST, then we need it
to shift it by +16.5 hours to get it back to Australian CDST...
The local reference clock only needs to shift from UTC to Australian CDST
by adding 10.5 hours...
That's my logic right now, if the GPS outputs UTC at least :)

—
Reply to this email directly or view it on GitHub
#6 (comment).

from wwvb.

Ok, changing to the +6 offset worked... Kinda. The day was off by 1. Looking into it, this is caused by to_day_of_the_year() inside TimeDateTools.h. Probably a 1 base, verses 0 base issue or i just copied cumulative days of the year wrong.
Stay tuned

from wwvb.

Hi Mark,

I had time for a quick test tonight, pulling the code down and compiling
here at home to verify your result. I had the desk clock get set 12
hours out (behind AU CDST) by using value +6, I then changed to -6 like
before and it worked. It's almost like a sign has got inverted some place.
I ran a compile and clock set again to recheck, and got the same result,
-6 on the WWVB time zone gets a good result results in the correct desk
clock time (and date), +6 goes 12 hours behind.

Or, perhaps you did some changes today that are not yet on the Github
yet and my code download is from before that.
If so let me know.

Later.

MS

On 19/02/2016 1:26 PM, Mark Cooke wrote:

Ok, changing to the +6 offset worked... Kinda. The day was off by 1.
Looking into it, this is caused by to_day_of_the_year() inside
TimeDateTools.h. Probably a 1 base, verses 0 base issue or i just
copied cumulative days of the year wrong.
Stay tuned

—
Reply to this email directly or view it on GitHub
#6 (comment).

This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

from wwvb.

AttinyGPS was also changed, so make sure you have the most recent version of that.

from wwvb.

Downloaded and checked. Nope had the latest version. It's going well good enough to create a demo video and schematic though :)

from wwvb.

Made a video clip this morning of the system setting the time on a desk clock, uploading it to Youtube.
Of note is that when starting from dead cold start (GPS wise) the Nano starts sending WWVB while the LCD shows an invalid time (1980 date etc) and the Fix says invalid as well.
I feel that for the example it might be fine to have that occur but for my working model it would be better if it didn't send WWVB until the Fix was Valid or GPS. Otherwise the first clock sync is wrong if it happened to be receiving already...

from wwvb.

Its setup that way to allow it to send a cached time. Gps will send a valid
time sometimes, even though gps fix location is invalid i.e. when there ate
less than 4 satellites. The invalid time should be sent for long enough
that a wwvb clock will sync to it anyway, so i wouldnt bother changing it
On 21 Feb 2016 12:23, "Martin" [email protected] wrote:

Made a video clip this morning of the system setting the time on a desk
clock, uploading it to Youtube.
Of note is that when starting from dead cold start (GPS wise) the Nano
starts sending WWVB while the LCD shows an invalid time (1980 date etc) and
the Fix says invalid as well.
I feel that for the example it might be fine to have that occur but for my
working model it would be better if it didn't send WWVB until the Fix was
Valid or GPS. Otherwise the first clock sync is wrong if it happened to be
receiving already...

—
Reply to this email directly or view it on GitHub
#6 (comment).

from wwvb.

I managed to have my clock sync to the invalid time, but yes it corrects itself on the next run.
The demo video is up.
https://www.youtube.com/watch?v=lA-yf535rdY
Switch to HD and the LCD is quite clear...
I took some images too, can I send them to you and you could put one on this repo someplace ?

from wwvb.

Great video! I can add something so that it only syncs if the year is
greater thab 15 and less than 80 as depending on the module - some output
00 as the start year.

Great vid! Up to you with the images. You can fork it and upload if you
want - i guess then it shows more than one contributor ;)
On 21 Feb 2016 13:38, "Martin" [email protected] wrote:

I managed to have my clock sync to the invalid time, but yes it corrects
itself on the next run.
The demo video is up.
https://www.youtube.com/watch?v=lA-yf535rdY

I took some images too, can I send them to you and you could put one on
this repo someplace ?

—
Reply to this email directly or view it on GitHub
#6 (comment).

from wwvb.