search

micooke / WWVB

Arduino WWVB Transmitter for Attiny85, nano, micro etc.
MIT License
30 stars 5 forks source link

Nearly there but... #6

Closed mr-sneezy closed 8 years ago

mr-sneezy commented 8 years ago

Got to report after doing more testing that there is still two minor bugs in the gps_time_sync_nokia5110.ino.

The setting for time zone offset for the WWVB is out by 12 hour (ahead). So a setting of (-6, 0) results in my desk clock being 12 hours ahead of local time (i.e. says AM instead of PM, date is 1 day ahead too). I can get it to be correct by setting the WWVB parameter to (-18, 0 ) though....

Also I still have the LCD text wrap issue even after using different PC today with a fresh grab of all the libraries (yours, and Adafruits GFX and 5110). Seems your system results in a slightly different compilation of the display code somehow. Arduino IDE version issue maybe ?

micooke commented 8 years ago

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.

mr-sneezy commented 8 years ago

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

micooke commented 8 years ago

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

mr-sneezy commented 8 years ago

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).

micooke commented 8 years ago

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(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(hh, mm, ss, DD, MM, YY, -6, 0, 0);)

mr-sneezy commented 8 years ago

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 :)

micooke commented 8 years ago

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" notifications@github.com 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 https://github.com/micooke/WWVB/issues/6#issuecomment-185681314.

micooke commented 8 years ago

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

mr-sneezy commented 8 years ago

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 https://github.com/micooke/WWVB/issues/6#issuecomment-186023932.

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

micooke commented 8 years ago

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

mr-sneezy commented 8 years ago

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

mr-sneezy commented 8 years ago

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...

micooke commented 8 years ago

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" notifications@github.com 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 https://github.com/micooke/WWVB/issues/6#issuecomment-186718072.

mr-sneezy commented 8 years ago

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 ?

micooke commented 8 years ago

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" notifications@github.com 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 https://github.com/micooke/WWVB/issues/6#issuecomment-186728236.