 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : (MM/DM) Precision Time Keeping Project
  Page 2 of 3   |
|||||
| Author | Message | ||||
| DuinoMiteMegaAn Senior Member  Joined: 17/11/2011 Location: AustraliaPosts: 231 |
I found I was off by 4 minutes (sunset) in a US location and you can see that it was off by 39 minutes (sunrise) for Sydney. MMBasic has floating point math but in some calculations a double is probably needed. 
BTW ... I did not do this complex calculation - Garry did. All I did was to change a few lines and cut and paste it! |
||||
djuqa Guru  Joined: 23/11/2011 Location: AustraliaPosts: 447 |
I agree, it is like the weather reports online. All good in theory, but sticking your head out the window is even better. No matter how accurate an algorithm, it is still dependent on too many variables. Direct measurement is still best for local conditions. VK4MU MicroController Units |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
No matter how accurate an algorithm, it is still dependent on too many variables.
If you were referring to the complex sunrise/sunset algorithm, it only needs the date and the location to compute. Your Latitude and Longitude will never change for your location and the time will always be in the MM/DM!
Software is cheap, when you have 16 GB of SD flash storage. |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6097 |
One problem with the code: You have entered the Sydney coordinates in decimal degrees and still called the subroutine which converts DD.MM into decimal degrees. I am using your code to find and correct a few parsing errors in my MMedit program. All my errors stop me from getting a good look at your code. It is the same algorithm I have used before but converting between BASIC's is a pain at times. (Especially when I am not sure about the maths) Jim Edit "Yanky Date Syndrome" Swap day and month but it still doesn't get thing right. You refer to IF SD$="ST" but nowhere do you assign a value to SD$ Gotta go to the tip before the BOSS gets cranky. VK7JH MMedit MMBasic Help |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
You have entered the Sydney coordinates in decimal degrees and still called the subroutine which converts DD.MM into decimal degrees.
I wonder how this could be? There is no MMBasic variable that takes Deg/min/sec's? Point to the sub that converts to dec. degress? Line numbers? Edited: <---- I see it at 960! I am using your code to find and correct a few parsing errors in my MMedit program.
Now that is really strange. I had no parsing errors using MMIDE v 1.0. Where and what are your parsing errors? Line numbers? As for the math, like I said before this code is "as is". I did not create it but this GW-Basic program seemed the most accurate of any on the Internet. |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
Location input entry error <--- Whew! Line 200 should be -33.53:-151.10 'For Sydney Results: DECLINATION OF SUN:-22.325 DEGREES EQUATION OF TIME:-2.93494 MINUTES AZIMUTH OF SUNRISE: 62.7698 DEGREES AZIMUTH OF SUNSET: 297.23 DEGREES Sydney, Austalia SUNRISE= 5:2 SUNSET= 20:0 Hit CR To Continue ? Date of "location test" for sunrise/sunset in Sydney = December 18,2011 Internet calculated sunrise/sunset for the date = Sunrise 5:39 AM Sunset 8:04 PM Sunrise only off by 19 minutes? Close "as in horseshoes and hand grenades"
I still don't think the numbers are right! Help ... Is there an Astronomer on this board? see attached file: 2011-12-12_150649_sunrise_sunset_Garry.pdf Again, here is the link for the master code: Link: http://codecraft.proboards.com/index.cgi?board=qbasic&action =print&thread=208 Credits: Post by garry on Dec 30, 2006, 5:49pm |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6097 |
Line 220 remove the # from the end of the numbers. Re my parsing errors_ I am using MMedit not MMide. and the errors are all my doing.... Jim VK7JH MMedit MMBasic Help |
||||
| centrex Guru Joined: 13/11/2011 Location: AustraliaPosts: 320 |
Hi DuinoMiteMegaAn Some very frightening maths above. My question is have you tried the high precision rtc mentioned on page 1 of the posts. I am most intrigued, what is this all to be used for if it has to last 8 years. Regards Centrex Cliff |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3800 |
In case you have power derived from the mains, you might use that. Here it used to be (probably still is) very accurate if you tracked its frequency - over the long term very accurately 50Hz. (They tweak it in both directions but make sure the average is accurately 50Hz. I say "is" etc but I don't know if it's still the case.) It was/is far more accurate than xtals. John |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
My question is have you tried the high precision rtc mentioned on page 1 of the posts.
Absolutely, in fact, I used three versions. Version 1 of 2 of the Macetech's ChronoDot and the UK DS3231 by Love Electronics. 
Note: The DS3231 is a drop-in TCXO replacement of the "watch crystal" version DS1307. I will be releasing all the doc's in the future for this precsion RTC.
I am most intrigued, what is this all to be used for if it has to last 8 years.
All I can say is "remote security"
|
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
In case you have power derived from the mains, you might use that. Here it used to be (probably still is) very accurate if you tracked its frequency - over the long term very accurately 50Hz. (They tweak it in both directions but make sure the average is accurately 50Hz. I say "is" etc but I don't know if it's still the case.)
Using a line frequency hertz counter is out of the question. First, I would be dedicating the PIC32 in counting pulses which I do not want to do. The easiest solution is to use a precision RTC with battery back-up on the MM/DM. BTW ... Have you ever tried using that counting method and account for DST? (daylight savings time)
|
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
@TassyJim There were three problems in the Sunrise/Sunset algorithm. #1. Line 200 input was wrong for Sydney. Should be degs.min #2. Line 220 had garbage "#" at the end of the numbers. #3. Line 300 and 310 had a reversed date format. Should be the European date format instead of American Yankee version date format. Now the calculation, for Sydney, is within about 10 minutes! Thanks TassyJim! |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
Hopefully, this is the corrected version. [10 '--------SRSS_R2.bas----------------------------
20 '--------Read PIC32 Date and Calculate SunRise and SunSet Times-------------- 30 'Author: Hacker - DuinoMiteMegaAndy 40 'Date: 27/11/2011 50 'Version: Rev. 1.0b 60 'MMBasic Firmware: 2.7 DuinoMite Mega 70 'Platform: Win XP/SP3 80 ' Credits: Garry ? 90 ' 100 ' --------------Code Begin-------------------- 110 '----SUNRISE / SUNSET --------------------------------------------------- 120 'Latitude and Longitude --> south and east ARE negative <------- 130 ' 140 ' 150 ' 160 'Sydney, Australia Lat: -33 deg 53' South Long: -151 deg 10 East 170 CLS 180 ' 190 DIM N(12) 200 D1=-33.53:D2=-151.10 ' <------- Sydney, Australia 210 ' 220 PL=3.141592654/26:J=57.29577951 230 GOSUB 960 240 LA = D1 250 IF LA < 0 THEN LA = LA + 180 260 IF D2 < 0 THEN D2 = D2 + 360 270 LO = FIX(D2/15)*15 :REM finds time zone beginning 280 TD=(D2-LO)/15 290 ' 300 M$=MID$(DATE$,4,2):M=VAL(M$) 310 DA$=MID$(DATE$,1,2):DA=VAL(DA$) 315 ' 320 ' 330 FOR I=1 TO 12: READ N(I):NEXT I 340 DATA 0,31,59,90,120,151 350 DATA 181,212,243,273,304,334 360 X=(N(M)+DA)/7 370 ' 380 D=.4560001-22.195*COS(PL*X)-.43*COS(2*PL*X)-.156*COS(3*PL*X) +3.83*SIN(PL*X)+.06*SIN(2*PL*X)-.082*SIN(3*PL*X) 390 ' 400 'LOCATE 3,2 410 PRINT"DECLINATION OF SUN:"; 420 'PRINT USING"###.#";D; 430 PRINT D; 440 PRINT" DEGREES" 450 E=8.000001E-03+.51*COS(PL*X)-3.197*COS(2*PL*X)-.106*COS(3*PL *X)-.15*COS(4*PL*X)-7.317001*SIN(PL*X)-9.471001*SIN(2*PL*X)- .391*SIN(3*PL*X)-.242*SIN(4*PL*X) 460 ' 470 PRINT"EQUATION OF TIME:"; 480 'PRINT USING"###.#";E; 490 PRINT E; 500 PRINT" MINUTES" 510 CL=COS(LA/J):SD=SIN(D/J):CD=COS(D/J):Y=SD/CL 520 IF ABS(Y)=>1 THEN PRINT"NO SUNRISE OR SUNSET":GOTO 1040 530 Z = 90 - J*ATN(Y/SQR(1-Y*Y)) 540 PRINT"AZIMUTH OF SUNRISE:"; 550 'PRINT USING"####.#";ABS(Z); 560 PRINT ABS(Z); 570 PRINT" DEGREES" 580 PRINT"AZIMUTH OF SUNSET: "; 590 'PRINT USING"####.#";360-ABS(Z); 600 PRINT 360-ABS(Z); 610 PRINT" DEGREES" 620 ST=SIN(Z/J)/CD 630 IF ABS(ST)>=1 THEN T=6:TT=6:GOTO 670 640 CT=SQR(1-ST*ST) 650 T=J/15*ATN(ST/CT) 660 TT=T 670 'x 680 IF D<0 AND LA<90 THEN T=12-T:TT=T 690 IF D>0 AND LA>90 THEN T=12-T:TT=T 700 T=T+TD-E/60-.04 710 GOSUB 820 720 'LOCATE 3,2 730 'PRINT "TIME OF SUNRISE BERN:";T1$;":";T2$;" ";T$;"L.T. ";GM$;":";T2$;" GM"; 740 PRINT "Sydney, Austalia SUNRISE= ";T1$;":";T2$;" "; 750 T=12-TT:T=T+TD-E/60+.04 760 CNT=1 770 T12=12 780 GOSUB 820 790 'PRINT "TIME OF SUNSET= ";T1$;":";T2$;" ";T$;"L.T. ";GM$;":";T2$;" GM";" ";SD$ 800 PRINT " SUNSET= ";T1$;":";T2$;" ";SD$ 810 GOTO 1040 820 'x 830 T1=INT(T):T2=T-T1 840 IF SD$="ST" THEN T1=T1+1 850 T1$=STR$(T1+T12):T2=INT((T2*600+5)/10):IF T2=60 THEN 860 ELSE 870 860 T2=0:T1=T1+1:T1$=STR$(T1+T12) 870 T2$=STR$(T2):T2$=RIGHT$(T2$,LEN(T2$)-1) 880 IF INT(T2)<10 THEN T2$="0"+T2$ 890 GM = FIX(D2/15) :REM calculate difference between GM and local time 900 IF CNT = 0 THEN GM = VAL(T1$)+GM :REM GMT for sunrise 910 IF CNT > 0 THEN GM = VAL(T1$)+12+GM :REM GMT for sunset 920 IF GM +(VAL(T2$)/60)> 24 THEN GM = GM - 24 930 GM$ = STR$(GM) :GM$ = RIGHT$("0"+GM$,2) 940 RETURN 950 ' 960 'x This subroutine converts DD.MM input to DD.DD 970 DEGTMP = (ABS(D1)-ABS(FIX(D1))) *100/60 980 D1 = (FIX(ABS(D1))+DEGTMP)*SGN(D1) 990 DEGTMP = (ABS(D2)-ABS(FIX(D2))) *100/60 1000 D2 = (FIX(ABS(D2))+DEGTMP)*SGN(D2) 1010 RETURN 1020 ' 1030 ' 1040 'END 1050 ' 1060 INPUT "Hit CR To Continue "; Query$ 1070 RUN "B:TD_R1.bas" 1080 '============================================= /CODE] |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
Now, I am searching for one more algroithm, for my MM/DM time keeping project... Unix Time. Date and time information can be represented in a variety of ways. On the MM/DM it is stored in two strings using the PIC32 RTC (Time$ and Date$). To compute the elapse time using the Hr:Min:Sec & Date-Mon-Year is too cumbersome. On the MM/DM there is, of course, an internal timer that counts up in milliseconds but its timebase is not part of the PIC32 RTC. The best choice is to use Unix Time. Unix Time is a method of storing time as a 32-bit value specifying the number of seconds that have elapsed since midnight UTC of January 1, 1970. Since this time is always counting up except for twice a year for the daylight savings time adjustment, you can easily compute elapse time with it. Try doing elapse time with PIC32 time/date strings would be just too hard. Note: The timebase for the Unix time would be coming from the precsion DS3231 RTC. |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
My question is have you tried the high precision rtc mentioned on page 1 of the posts.
Here is the sample of the DS3231 "treasure trove" of algorithms I will be releasing. 120 PRINT "******************************************"
130 PRINT "* PIC32 DS3231 Time / Date Utilities *" 140 PRINT "******************************************" 150 PRINT "* [A] <-- Print PIC32 Time/Date *" 160 PRINT "* <-- Print DS3231 Time/Date/DOW *" 170 PRINT "* [C] <-- PIC32 RTC <--<<< DS3231 RTC *" 180 PRINT "* [D] <-- DST Daylight Savings Test Only *" 190 PRINT "* [E] <-- Spring FWD +1 Hr. DS3231 RTC *" 200 PRINT "* [F] <-- Fall Back -1 Hr. DS3231 RTC *" 210 PRINT "* [G] <-- DS3231 RTC <--<<< PIC32 RTC *" 220 PRINT "* [H] <-- Manual Set/Config. DS3231 RTC *" 230 PRINT "* <-- Print/Compare PIC32/DS3231 RTC *" 240 PRINT "* [J] <-- Print PIC32 DOW - Day of Week *" 250 PRINT "* [K] <-- Print PIC32 DOY - Day of Year *" 260 PRINT "* [M] <-- GoTo Main Menu *" 270 PRINT "* [Q] <-- Quit Menu *" 280 PRINT "******************************************" |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6097 |
On more change. If you change line 530 from Z = 90 - J*ATN(Y/SQR(1-Y*Y)) to Z = 90 + J*ATN(Y/SQR(1-Y*Y)) the AZIMUTH will be more realistic. It might be a northern/southern hemisphere thing. I think the remaining time differences are probably due to using different definitions of Sunrise. Civil, Military, Astro etc and Sunrise versus 'light' Jim VK7JH MMedit MMBasic Help |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
For other board members that would like a precision sunrise / sunset algorithm DO NOT USE THE ONE IN THIS TOPIC!  
Being 15 minutes off in both the sunrise and sunset calculations will not cut it. This algorithm was posted on the Internet in 2006 by Garry but the one TassyJim has is spot on.! TassyJim has a better one at this link on this board: 
http://www.thebackshed.com/forum/forum_posts.asp?TID=4434&PN =1 |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
Project Complete! 2011-12-18_081516_Precision_Time_Keeping_Project_R1.zip Enjoy |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
Breaking news..The DS3231 was downsized from a 16 pin SOIC to a 8 pin SOIC DS3231M High temp range of -40C ~ 85C <------- No more extreme temp. drift. +- 5 PPM <----- ~ +- 2.62 minutes per year Cost Digikey $3.798 USD per 3000 <----- Not good Avnet $3.85 USD per 500 <----- Good for high volume vendors Olimex ... Now an industrial TCXO RTC to match your industrial DuinoMite PCB?
2011-12-19_094207_DS3231M.pdf BTW ... For the frugal hackers on this board ... You could get a 8 pin SOIC to DIP adapter and carefully solder this chip to it, then attach a coin cell Lithium battery holder and four wires to your MM/DM and you are done!
http://www.alpha-crucis.com/en/breakout-boards/1077-soic-to- dip-adapter-8-pin-3700386604942.html
http://www.futurlec.com/SMD_Adapters.shtml |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
Minor basic files corrections for the "Precision Time Keeping Project R1"
#1 20/12/2011
Changed DST array (DSTDate$) in main_r1 line 1450 and dst_r1 line 1360 and td_r1 line 980 from 15 to 16. #2 20/12/2011
Fixed DST_R1.bas last line garbage.- took out the prompt symbol from the last line number Long term beta testing on going ... |
||||
| Page 2 of 3 |
|||||
 Print this page |
