 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 1 of 3   |
|||||
| Author | Message | ||||
| DuinoMiteMegaAn Senior Member  Joined: 17/11/2011 Location: AustraliaPosts: 231 |
Before I begin, I would like to credit "CrackerJack" for his software routines he did for his analog clock project for the MaxiMite. My project goal I wanted a MM/DM basic microcontroller that would run autonomously, at a remote site, with NO Internet, NO PC, NO GPS or NO other external clock source timebase for eight years without any user supervision EVEN for daylight saving times “hour” adjustments! In my quest to complete my project goal, I ran into the following problems: 1. The watch crystal on the MM/DM PIC32 is very inaccurate. In fact, ANY watch crystal used on any device eg DM/MM or RTC is very inaccurate. With a standard watch crystal of +- 20 PPM you could easily lose 10 minutes a year! 
BTW ... I would like to point out that it is not the board designers fault for this watch crystal on the DM/MM. The PIC32 was designed by Microchip for this watch crystal. 2. On loss of power or manual reset on the MM/DM you will lose your time and date every time.
3. The placement of the DM/MM microcontroller away from "ambinet room temperature" will greatly increase the PIC32 real time clock error by minutes. Remote logging usage would be not be very accurate.
4. I2C bus differences on the MaxiMite and DuinoMite created problems.
5. The PIC32 RTC does not have a DOW "Day Of Week" register or indication.
I am still in the beta testing phase and will release all software, docs and project information. Stay tune .... 
Any comments on the above problems welcome? |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
The question will come up "why not use the PCF8563 or the DS1307 low cost I2C real time clocks with battery backup? ” To these people, I would say "don't waste your time" <---<<< pun intended! First of all, both real time clocks have the same dreaded watch crystal (32768 Hz +-20 ppm min.) What you would be doing is using one inaccurate RTC to back-up, with a lithium battery, another inaccurate RTC (MM/DM PIC32 RTC). What you would be really buying is a battery backup solution not an accurate RTC. Don't waste your money! For a few extra Euro, $USD or $AUS you can have a precision time source of +-2 ppm with battery backup with a time loss of +- 1 minute per year and drifts very little in extreme temperatures! 
|
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
The Maxim-IC DS3231 TCX0 (temperature controlled oscilliator) I2C RTC is the solution.
The below pictures are breakout boards with the precision DS3231 chip. Only two vendors, I could find in the marketplace, makes a breakout board for the DS3231 SMD chip pins. One vendor is from the US and the other vendor is from the UK. 
|
||||
CircuitGizmos Guru  Joined: 08/09/2011 Location: United StatesPosts: 1425 |
I use an ST M41T93Z SPI device. Micromites and Maximites! - Beginning Maximite |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
Excerpt from the ST M41t93Z data sheet The accuracy of the Real Time Clock is dependent upon the accuracy of the
crystal, and the match between the capacitive load of the oscillator circuit and the capacitive load for which the crystal was trimmed. Temperature also affects the crystal frequency, causing additional error (see Figure 10 on page 23).
A TCXO (temperature controlled oscillator) is needed for precise time keeping.
Here is a description from Macetech on their ChronoDot DS3231 RTC breakout board.. The ChronoDot RTC is an extremely accurate real time clock module, based on the DS3231SN temperature compensated RTC (TCXO). It includes a CR1632 battery which should last at least 8 years if the I2C interface is only used while the device has 5V(3.3) power available. No external crystal or tuning capacitors are required. The DS3231 has an internal crystal and a switched bank of tuning capacitors. The temperature of the crystal is continuously monitored, and the capacitors are adjusted to maintain a stable frequency. Other RTC solutions may drift minutes per month, especially in extreme temperature ranges...the ChronoDot will drift less than a minute per year. This makes the ChronoDot very well suited for time critical applications that cannot be regularly synchronized to an external clock. Since the ChronoDot needs to read the temperature, it also contains a fairly accurate temperature sensor, accessible through I2C. Stated accuracy is +/- 3C, though the temperature register returns values with a resolution of 0.25C. Calibration may improve accuracy.
|
||||
| CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1425 |
M41T93Z: SOX18 package. Factory calibrated accuracy ±5 ppm guaranteed after 2 reflows (SOX18) – Much better accuracies achievable using built-in programmable analog and digital calibration circuits Glad you found a part that you prefer. Micromites and Maximites! - Beginning Maximite |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
So ... having found a precise temperature controlled RTC, its only a matter of refreshing the MM/DM PIC32 RTC every time when the boards are booted or power-on-reset or manually reset. I recommend also refreshing the PIC32 RTC every day using the MMBasic periodic interrupt timer. I chose, in my user MMBasic application, 02:00 (2 AM) every day to do this task. Now, the question is how to keep the MM/DM running for eight years (until the RTC lithium coin cell battery runs down), without human supervision? The time loss would be about 8 minutes after 8 years!
First of all, DST (daylight savings time) will need to be automatically adjusted for "spring forward +1 hr. and fall back -1hr" for eight years. The trick is to know the projected DST dates for your country location. (Your government controls this variable) On the Internet, you can find the projected dates of DST. In the US, it is the second Sunday in March and the first Sunday in November at 02:00 AM. Just use these dates in a dim array(16) and you would know exactly when to change the time due to DST. Its only a matter of unleashing the “explosive power” of the MaxiMite or DuinoMite using MMBasic to solve these time keeping algorithms.  |
||||
| CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1425 |
"I chose, in my user MMBasic application, 02:00 (2 AM) every day to do this task." And a suitable delay to keep it from happening again a couple seconds later at 02:00 (assuming the MM runs fast). Micromites and Maximites! - Beginning Maximite |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
And a suitable delay to keep it from happening again a couple seconds later at 02:00 (assuming the MM runs fast).
I don't understand. I am using the MmBasic periodic interrupt only once a day. It can only fire once a day. No deadband needed. I use this algorithm to get it to fire once from boot-up then I reset the settick for every 24 hours from that time. It doesn't have to be really accurate but I chose this time for the PIC32 RTC refresh and the DST time update by the government. Note: I did notice that the settick periodic interrupt drifts a lot (36 secs) Probably need a better solution. 160 'This time is close to the DST time update required by the US government.
170 tempdec = VAL(RIGHT$(DATE$, 4)) 180 IF hrdec = 2000 THEN ? "PIC32 Clock Is Reset To Default --> ABORT!": END 190 hrdec = VAL(LEFT$(TIME$, 2)) 'get hr val 200 mindec = VAL(MID$(TIME$, 4, 2)) 'get min val 210 SyncMin = 59 - mindec 220 SyncHr = 0 230 IF hrdec = 0 THEN Synchr = 1 240 IF hrdec = 1 THEN Synchr = 0 250 IF hrdec => 2 AND hrdec <= 23 THEN SyncHr = 25 - hrdec: GOTO 270 260 ? "UnKnown SyncHr --> ABORT!" 270 SyncMilliSecs = (SyncMin * 60 * 1000) + (SyncHr * 3600 * 1000) 280 SETTICK SyncMilliSecs, 550 ' 540 '---------------------Periodic Interrupt----------------------------------
550 oldtime$ = TIME$ 560 olddate$ = DATE$ 570 ? "Periodic Interrupt at ~ 2:00 AM Has Started ..." 580 ? "Checking DST For Today" 590 GOSUB 1410 'Check for DST and adjust DS3231 600 ? "Starting PIC32 RTC Refresh From DS3231 RTC ..." 610 GOSUB 760 'Update or refresh PIC32 RTC from DS3231 RTC 620 ? "PIC32 RTC Has Been Refreshed With The Precison DS3231 RTC" 630 ? "PIC32 OLD TIME = ",oldtime$ 640 ? "PIC32 OLD DATE = ",olddate$ 650 ? "PIC32 NEW TIME = ",TIME$ 660 ? "PIC32 NEW DATE = ",DATE$ 670 SETTICK 0,0 ' clear periodic interrupt 680 SETTICK (24 * 3600 * 1000), 550 'Set periodic interrupt to every 24 hrs at 01:59 (1:59 AM) 690 IRETURN ' return to system application code |
||||
| CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1425 |
Got it. I thought you were looking at the specific time of 02:00:00. So if that ran fast, you might see the time again. Micromites and Maximites! - Beginning Maximite |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
I could of used the precision DS3231 RTC for this but I am also checking for DST and if today was "spring forward or fall back" it could create problems. 
BTW ... In an event of DST, let us say today, the hour time adjustment will be made. To keep the hour adjustment from occurring only once, I used a DAT file. Since, there is no EEProm on the DM/MM, like on the Arduino, then using the code to change a SD or flash file "coded text" is really the only way to go. The DST would be set once and the dat file would be written to. Then, on the next day, the dat file string would be changed from "locked" to "unlocked" ready for the next DST change
|
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
For those who need to know the DOW (day of week) using their PIC32 RTC here is a MMBasic algorithm. It only takes the Date$ to find it.
10 '--------PIC32DOW.bas----------------------------
20 '--------Read PIC32 Date and Calculate/Print DOW - Day of Week------- 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 ' 90 ' 100 ' --------------Code Begin-------------------- 110 'Get date from PIC32 date$ 120 day = VAL(LEFT$(DATE$, 2)) 130 month = VAL(MID$(DATE$, 4, 2)) 140 year = (VAL(RIGHT$(DATE$, 4)) - 2000) 150 a = (14 - month) / 12 160 a = FIX(a) 170 y = year - a 180 y = FIX(y) 190 m = month + (12 * a) - 2 200 m = FIX(m) 210 d = ((day + y) + FIX(y / 4) - FIX(y / 100) + FIX(y / 400) + FIX((31 * m) / 12)) 220 DOW = d MOD 7 230 DOW = DOW + 1 ' offset for DS3231/DS1307 RTC --> Sun(1)Mon(2)Tue(3)Wed(4)Thu(5)Fri(6)Sat(7) 240 IF DOW = 1 THEN ? "PIC32 Calculated DOW = 1 = Sunday ":dow$ = "Sunday ": GOTO 320 250 IF DOW = 2 THEN ? "PIC32 Calculated DOW = 2 = Monday ":dow$ = "Monday ": GOTO 320 260 IF DOW = 3 THEN ? "PIC32 Calculated DOW = 3 = Tuesday ":dow$ = "Tuesday ": GOTO 320 270 IF DOW = 4 THEN ? "PIC32 Calculated DOW = 4 = Wednesday ":dow$ = "Wednesday ": GOTO 320 280 IF DOW = 5 THEN ? "PIC32 Calculated DOW = 5 = Thursday ":dow$ = "Thursday ": GOTO 320 290 IF DOW = 6 THEN ? "PIC32 Calculated DOW = 6 = Friday ":dow$ = "Friday ": GOTO 320 300 IF DOW = 7 THEN ? "PIC32 Calculated DOW = 7 = Saturday ":dow$ = "Saturday ": GOTO 320 310 ? "ABORT ---> DOW Not Found! ":END 320 INPUT "Hit CR To Continue "; Query$ 330 CLS 340 RUN "B:TD_R1.bas" 350 ' |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
For those who need to know the DOY (day of year) using their PIC32 RTC here is a MMBasic algorithm. It only takes the Date$ to find it.
10 '--------PIC32DOY.bas----------------------------
20 '--------Read PIC32 Date and Calculate/Print DOY - Day of Year------- 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 ' 90 ' 100 ' --------------Code Begin-------------------- 110 'Get date from PIC32 date$ 120 day = VAL(LEFT$(DATE$, 2)) 130 month = VAL(MID$(DATE$, 4, 2)) 140 year = (VAL(RIGHT$(DATE$, 4)) - 2000) 150 N1 = INT(275 * Month / 9) 160 N2 = INT((month + 9)/12) 170 N3 = (1 + INT((year -4 * INT(YEAR/4) +2) / 3)) 180 N = N1 - (N2 * N3) + day - 30 190 DOY = N 200 ? "Day Of Year ",DOY 210 INPUT "Hit CR To Continue "; Query$ 220 CLS 230 RUN "B:TD_R1.bas" 240 ' |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
Coming up is one of the hardest algorithms to solve using MMBasic. It's for the home automation and control geeks. (For dust to dawn lighting control) You need to supply your present location Latitude and Longitude in decimal format and this algorithm will calculate the sunrise and sunset times for your location. Stay tuned ... |
||||
crackerjack Senior Member Joined: 11/07/2011 Location: AustraliaPosts: 164 |
Or you could use an LDR.... but where would the fun be in that? |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
Your method of using a light dependant resistor has three flaws. #1. Its very slow to react to light changes - I would use a better, faster photo sensor type.
#2. It is not precise. It won't trigger control exactly under the same lighting conditions. Again, using a better photo sensor will fix this problem.
I prefer using the TEMT6000 OR AMBI Light sensor, which mimic's the human eye to light. (AMBI Light sensor is my preference)
#3. What's happens when the sky is storming or overcast or cloudy or snowing? Your LDR would be confused when to activate lighting control.
Since the MM/DM has at least 16 GB of SD storage flash, I think there is enough flash to run a sunrise and sunset algorithm using only a few KB!
In fact, using a photo sensor plus the sunrise/sunset algorithm would be the best solution. |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
Link: http://codecraft.proboards.com/index.cgi?board=qbasic&action =print&thread=208 Credits: Post by garry on Dec 30, 2006, 5:49pm The sunrise and sunset calculations are based on the algorithms and formulas published in the: Almanac for Computers, 1990 Nautical Almanac Office United States Naval Observatory Sunrise/Sunset Algorithm
Source: Almanac for Computers, 1990 published by Nautical Almanac Office United States Naval Observatory Washington, DC 20392 Inputs: day, month, year: date of sunrise/sunset latitude, longitude: location for sunrise/sunset zenith: Sun's zenith for sunrise/sunset offical = 90 degrees 50' civil = 96 degrees nautical = 102 degrees astronomical = 108 degrees NOTE: longitude is positive for East and negative for West NOTE: the algorithm assumes the use of a calculator with the trig functions in "degree" (rather than "radian") mode. Most programming languages assume radian arguments, requiring back and forth convertions. The factor is 180/pi. So, for instance, the equation RA = atan(0.91764 * tan(L)) would be coded as RA = (180/pi)*atan(0.91764 * tan((pi/180)*L)) to give a degree answer with a degree input for L. 1. first calculate the day of the year N1 = floor(275 * month / 9) N2 = floor((month + 9) / 12) N3 = (1 + floor((year - 4 * floor(year / 4) + 2) / 3)) N = N1 - (N2 * N3) + day - 30 2. convert the longitude to hour value and calculate an approximate time lngHour = longitude / 15 if rising time is desired: t = N + ((6 - lngHour) / 24) if setting time is desired: t = N + ((18 - lngHour) / 24) 3. calculate the Sun's mean anomaly M = (0.9856 * t) - 3.289 4. calculate the Sun's true longitude L = M + (1.916 * sin(M)) + (0.020 * sin(2 * M)) + 282.634 NOTE: L potentially needs to be adjusted into the range [0,360) by adding/subtracting 360 5a. calculate the Sun's right ascension RA = atan(0.91764 * tan(L)) NOTE: RA potentially needs to be adjusted into the range [0,360) by adding/subtracting 360 5b. right ascension value needs to be in the same quadrant as L Lquadrant = (floor( L/90)) * 90 RAquadrant = (floor(RA/90)) * 90 RA = RA + (Lquadrant - RAquadrant) 5c. right ascension value needs to be converted into hours RA = RA / 15 6. calculate the Sun's declination sinDec = 0.39782 * sin(L) cosDec = cos(asin(sinDec)) 7a. calculate the Sun's local hour angle cosH = (cos(zenith) - (sinDec * sin(latitude))) / (cosDec * cos(latitude)) if (cosH > 1) the sun never rises on this location (on the specified date) if (cosH < -1) the sun never sets on this location (on the specified date) 7b. finish calculating H and convert into hours if if rising time is desired: H = 360 - acos(cosH) if setting time is desired: H = acos(cosH) H = H / 15 8. calculate local mean time of rising/setting T = H + RA - (0.06571 * t) - 6.622 9. adjust back to UTC UT = T - lngHour NOTE: UT potentially needs to be adjusted into the range [0,24) by adding/subtracting 24 10. convert UT value to local time zone of latitude/longitude localT = UT + localOffset My MM/DM is getting hot in this MMBasic calculation |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
Sunrise / Sunset code snippet details I have tried many sunrise and sunsun calculations but the only one came as close is garry's. The others were off by 10's of minutes and even hours! I believe it has to do with the internet calculations for different locations.! I believe garry followed the NOAA sunrise and sunset algorithm but it is not apparent by his comments. Since I did not create this algorithm by scratch, the code is "as is" and please do not contact me if it does not work for your application.! The accuracy, I believe, is very good using MMBasic, but the sunset is off by 4 minutes and I believe it has to be to a precision or rounding error in the calculation. For the mathematical geniuses on this board, if you can find this small offset error - hats off to you! You need to provide several inputs to this algorithm. 1. date of sunrise/sunset - I used the Date$ from the PIC32 RTC for this input. (Its automatic) 2. latitude, longitude - location for sunrise/sunset in decimal format. I used Sydney, of course, Australia for my last code snippet test location. Latitude = 33 deg 53' South = -33.88333 Longitute = 151 deg 10 'East = 151.16667 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 Actual code snippet print of sunrise/sunset from the MMBasic algorithm = DECLINATION OF SUN:-22.325 DEGREES EQUATION OF TIME:-2.93494 MINUTES AZIMUTH OF SUNRISE: 62.5631 DEGREES AZIMUTH OF SUNSET: 297.437 DEGREES Sydney, Austalia SUNRISE= 5:0 SUNSET= 20:0 Hit CR To Continue ? Support Links: http://andrew.hedges.name/experiments/convert_lat_long/ http://www.timeanddate.com/worldclock/astronomy.html?n=240 Enjoy |
||||
| DuinoMiteMegaAn Senior Member Joined: 17/11/2011 Location: AustraliaPosts: 231 |
The code (algorithm) ... 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 'Decimal Degrees = Degrees + minutes/60 + seconds/3600 <------- 140 ' 150 ' 160 'Sydney, Australia Lat: 33 deg 53' South Long: 151 deg 10 East <---- convert to dec degrees! 170 CLS 180 ' 190 DIM N(12) 200 D1=-33.88333:D2=-151.16667 ' <------- 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$,1,2):M=VAL(M$) 310 DA$=MID$(DATE$,4,2):DA=VAL(DA$) 315 'DA = 18 <---<<< for test only 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 '============================================= |
||||
| crackerjack Senior Member Joined: 11/07/2011 Location: AustraliaPosts: 164 |
Hi Andy. Good work on that algorithm. I haven't tried it yet, but I hope to give it a run when I have some time. As for the LDR: I guess it really depends on the application and how much money you have to throw at it. In some scenarios, light dependent triggering would be preferential to time-based; for example a safety beacon or such would need to be active in the middle of the day if there is a storm approaching and ambient light-levels are low. Also, dusk and dawn are pretty slow when it comes to it. Only at the equator is it anything close to fast transition from light to dark and vice-versa. Lastly, an LDR costs a few cents, a normal LED even less (see the work done by Forrest Mims relating to LEDs as light sensors) compared with AMBI which is around $5. True not that dear, but in comparison... Anyway, once again - good work. |
||||
| Page 1 of 3 |
|||||
 Print this page |
