(34S) - Sunrise/Sunset
|
01-28-2015, 08:08 PM
(This post was last modified: 06-15-2017 01:29 PM by Gene.)
Post: #1
|
|||
|
|||
(34S) - Sunrise/Sunset
**Update No. 2**
Yet another version, this time with local registers and DST correction built in. (Thanks and credit to Dieter for the DST code.) DST settings are for the US, DST beginning on the second Sunday in March and ending on the first Sunday in November. If you prefer manual DST, remove steps 4 through 22 and subroutine 01 which begins at step 224. You may then manually set flag A for DST. It will be cleared after each use - if you prefer to stay in DST mode for a series of calculations, change the "FS?C A" in step 34 to simply "FS? A." If you don't want to use local registers, just remove the LocR16 command and the "." in front of each register number Operation is essentially as described for the first versions. Here is a dat file for the emulator. wp34s.zip (Size: 674 bytes / Downloads: 13) (I removed the dat file below for the original version.) Sunrise/Sunset Program: Code:
Registers: Code:
**See below for an update** Below are three versions of a program for the wp34s to calculate sunrise and sunset times. The programs are based on programs that I got from Marwan Joury, versions of which he posted in this article. I give total credit to Marwan, all I did was port his work to the wp34s. Most of the comments in my program listings are from Marwan's original listings that he sent to me. (So if you have any questions regarding the meat of the program, you will have to ask Marwan...) Program operation is as follows: Replace steps 6 and 7 with your offset from UTC, West is negative. (You must manually account for Daylight Saving Time, or British Summer Time, or whatever your local flavor of seasonally shifting daylight hours to suit local custom is called if you have one.) Key in your latitude in steps 15 through 22 in decimal degrees, North is positive. Key in your longitude in steps 24 through 32 in decimal degrees, West is negative. (You may use as many digits as you want for longitude and latitude, there is no requirement for 5 digits past the decimal point.) Go to run mode, key in the date in which you are interested in yyyy.mmdd format for version 1, dd.mmyyyy format for version 2 or mm.ddyyyy format for version 3. Press XEQ 'RS'. The program will run, briefly display "Rise-Set", then stop with the sunrise time displayed in the dot-matrix display area, and the sunset time displayed in the numerical display, in 24 hour clock format. Press R/S if you want see the day length. The sunrise and sunset times will still be on the stack in Z and Y, respectively, if you want to look at them again. All returned values are in hh.mmss format. Since your location information is hard-coded into the program, after entering the data as a part of the program, you can just run the program for new dates until and unless you want to change the location. You may also replace the value stored in register 6 (steps 8 through 12, which is the angle from zenith being calculated) with other values, for example 96, 102 or 108 degrees to calculate civil, nautical and astronomical twilight times, respectively. If you enter a value less than 90 degrees, you may calculate the times at which the sun rises above and then later sets below 90 minus that value. (E.g., if you enter 50 degrees, the program will calculate the times at which the sun rises to and sets below 40 degrees elevation. This may be useful if you desire to limit your exposure to UV, for example.) One of the subroutines may be used as a stand-alone program to calculate the number of days between two dates. Key in a date, press enter, key in other date, then press XEQ 02. (Key in the later date first if you want a positive result.) Attached below is a wp34s emulator dat file that has the y.md version. The differences between the programs are fairly trivial, so you can easily edit to create the d.my or m.dy versions. (Changes are in step 2, and between steps 78 to 86.) If you have a crystal installed in your real wp34s (to facilitate reliable communication), and a communication cable, you can place the dat file in the appropriate folder, start the emulator, and upload to your real wp34s to save a lot of manual keying. Version 1 - Input date in yyyy.mmdd format Code:
Version 2 - Input date in dd.mmyyyy format Code:
Version 3 - Input date in mm.ddyyyy format Code:
Register Usage: Code:
**Update No. 1** Based on Paul's and Dieter's ideas below, here is a single new version that will work in any date mode. (You must of course know what date mode the calculator is set to and enter the date accordingly.) I eliminated the accessible subroutine to calculate days between dates, since the built in wp34s ΔDAYS function can be used for that. The single program is now only 206 steps. The steps where time zone, longitude and latitude are enter have changed from above, but those are easy to figure. Otherwise, data entry, operation, and register usage remain the same, except 24 is no longer stored in register 20. I will change the wp34s.dat file to this version when I get the chance. Code:
Dave - My mind is going - I can feel it. |
|||
02-09-2015, 10:06 AM
(This post was last modified: 02-09-2015 10:16 AM by Kiwi Geoff.)
Post: #2
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
Hello Jeff O,
Thank you for making the WP34s "RS" code available. I was interested to find out how accurate a few lines of trig on a calculator could be - and was *astonished* how well your program predicts the Sunrise / Sunset. Here is a graph that shows how well your program works compared to a JPL ephemeris (DE200). Using the default location and UTC offset in your code. The averaged "sunrise error" is just 1 second over 2015. This is more than enough accuracy for the purpose - because "optical effects" on the horizon can have a much greater effect on when we 'see' the sunrise. Here is a sample of the DE200 derived "RS" for April 2015 for those that would like to run your program Jeff, and have an accurate reference to show just how well the WP34s program performs. Using the default location and UTC offset in the code. Code:
Regards, Kiwi Geoff (Christchurch, New Zealand). |
|||
02-09-2015, 09:13 PM
Post: #3
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
No thought of incorporating the WP 34S date functions to avoid having three programs?
- Pauli |
|||
02-10-2015, 10:31 PM
Post: #4
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
(02-09-2015 09:13 PM)Paul Dale Wrote: No thought of incorporating the WP 34S date functions to avoid having three programs? Yes, this would make the three different versions obsolete and the program would become more compact. For instance →DATE can be used to generate 31 December according to the current date mode setting, and the subroutine at LBL 02 can be replaced by the ΔDAYS command: Code: ... I just added such a version of the program to my 34s and stored it in the library. I think it's really nice and useful. ;-) Dieter |
|||
02-11-2015, 03:22 AM
Post: #5
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
(02-09-2015 10:06 AM)Kiwi Geoff Wrote: Many thanks for the program Jeff. You are welcome, credit for the program goes to Marwan, I just ported to the wp34s. Thanks for checking the accuracy, I am pleased with the results. Dave - My mind is going - I can feel it. |
|||
02-11-2015, 07:48 AM
(This post was last modified: 02-11-2015 07:49 AM by Thomas_Sch.)
Post: #6
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
(02-10-2015 10:31 PM)Dieter Wrote:Hello Dieter, could you please post your modified version of the program? Many thanks! Thomas |
|||
02-11-2015, 03:06 PM
(This post was last modified: 02-11-2015 03:09 PM by Dieter.)
Post: #7
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
(02-11-2015 07:48 AM)Thomas_Sch Wrote: could you please post your modified version of the program? Im am still working on it. My curent version also takes care of daylight savings time. Since 1996 the European Union switches to DST on last Sunday in March and back to standard time on last Sunday in October (both at 1:00 UTC). The following subroutine sets flag A (so that the "=" announciator comes on) if a date falls in the DST period. Code: LBL"DST" I may post my version of Jeff's program, but not without his permission. So Jeff, is this OK for you? Dieter |
|||
02-11-2015, 05:49 PM
Post: #8
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
(02-11-2015 03:06 PM)Dieter Wrote: I may post my version of Jeff's program, but not without his permission. So Jeff, is this OK for you? Certainly. I suggest posting in a separate new thread in the software library so it is not buried in this one below mine. Maybe post a message in this thread with a link to your new version. Dave - My mind is going - I can feel it. |
|||
02-11-2015, 06:09 PM
Post: #9
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
Thanks to you all, supporting me learning how to write programs for the WP 34S !
|
|||
02-11-2015, 08:03 PM
Post: #10
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
(02-09-2015 09:13 PM)Paul Dale Wrote: No thought of incorporating the WP 34S date functions to avoid having three programs? Not until you prompted me, see above for that plus other slight code improvements. Dave - My mind is going - I can feel it. |
|||
02-11-2015, 09:06 PM
Post: #11
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset | |||
02-11-2015, 09:46 PM
Post: #12
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
(02-11-2015 05:49 PM)Jeff O. Wrote: Certainly. I suggest posting in a separate new thread in the software library so it is not buried in this one below mine. Maybe post a message in this thread with a link to your new version. Fine. I just posted my version in this thread. The output is different from your version as all three results are returned simultaneously. They appear in the two display lines as well as on the stack (X=day length, Y=sunset, Z=sunrise). As usual, comments and corrections are welcome. Dieter |
|||
02-13-2015, 12:19 AM
Post: #13
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
(02-11-2015 09:06 PM)Paul Dale Wrote: Nice, thanks. Can we include this in the WP 34S library examples? Yes, of course you may include. But I am working on a new improved version that implements Dieter's DST code, plus uses local registers, so wait for that one. Should be tonight or tomorrow. Dave - My mind is going - I can feel it. |
|||
02-13-2015, 06:52 AM
Post: #14
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
(02-13-2015 12:19 AM)Jeff O. Wrote: Yes, of course you may include. But I am working on a new improved version that implements Dieter's DST code, plus uses local registers, so wait for that one. Should be tonight or tomorrow. May I suggest a few more improvements? The program in its current version uses lots of registers. Some for constants that are better entered directly (e.g. 90, 15, 18, 360), cf. my version. Some more registers are used for intermediate results that are not recalled later. Without these, the register count could drop to ~10 (instead of >20 now). Regarding the DST code: my suggestion implements the rules within the EU since 1996 (in earlier years different rules applied, e.g. DST ending in September). This is fine for EU citizens, but users in different places of the world should implement their own DST routine. For "worldwide use" I'd suggest removing the DST part and simply have the user set Flag A if he wants to see DST results (+1 hour). Alternatively the program could always return UTC results. Which would please our UK members and annoy those in Australia/NZ. #-) Finally: like many other HPs, the 34s features direct h.ms arithmetics, so when computing the day length there is no need to convert to decimal hours, subtract and convert back to h.ms again: simply use H.MS– instead. ;-) Dieter |
|||
02-13-2015, 02:19 PM
Post: #15
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
(02-13-2015 06:52 AM)Dieter Wrote: May I suggest a few more improvements? Of course, I have already made a lot of improvements based on your methods. (02-13-2015 06:52 AM)Dieter Wrote: The program in its current version uses lots of registers. Some for constants that are better entered directly (e.g. 90, 15, 18, 360), cf. my version. Some more registers are used for intermediate results that are not recalled later. Without these, the register count could drop to ~10 (instead of >20 now). I went through and eliminated several stored constants by using inline integers. I now use 16 registers. 360 is outside the range of inline integers, but its entry could still be shortened by one step via #036 SDL 001. I still store it the first time it is entered because it is used two more times, so storage and later recall saves a step. 90 and 15 can of course be entered via inline integer, but I store it because when it is used later, RCL arithmetic is used to shave some steps. (In my usage, it saves one step in each case.) But it may be possible to eliminate others by re-use or using the stack, I will look into that. (02-13-2015 06:52 AM)Dieter Wrote: Regarding the DST code: my suggestion implements the rules within the EU since 1996 (in earlier years different rules applied, e.g. DST ending in September). This is fine for EU citizens, but users in different places of the world should implement their own DST routine. For "worldwide use" I'd suggest removing the DST part and simply have the user set Flag A if he wants to see DST results (+1 hour). Alternatively the program could always return UTC results. Which would please our UK members and annoy those in Australia/NZ. #-) Your DST routine was easy to modify (assuming I did it correctly) to implement the DST rules followed in the US (and Canada, I believe, that being that DST starts 2nd Sunday in March, ends 1st Sunday in November). I like having it automatically handled in the program, but a manual mode may be more appropriate for some users, in which case your suggestion to remove the DST code and simply set or not set Flag A is excellent. Flag A lights the big “=” annunciator in the display, so that provides a nice visual indication. (02-13-2015 06:52 AM)Dieter Wrote: Finally: like many other HPs, the 34s features direct h.ms arithmetics, so when computing the day length there is no need to convert to decimal hours, subtract and convert back to h.ms again: simply use H.MS– instead. ;-) Yet another example of my failing to utilize the full capabilities of the wp34s as I attempted to port over versions written for less capable calculators. Thanks for your review and comments. Jeff Dave - My mind is going - I can feel it. |
|||
02-13-2015, 08:01 PM
Post: #16
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
(02-13-2015 02:19 PM)Jeff O. Wrote: I went through and eliminated several stored constants by using inline integers. I now use 16 registers. There are some intermediate values that are stored, but I cannot see that they are used later. (02-13-2015 02:19 PM)Jeff O. Wrote: 360 is outside the range of inline integers, but its entry could still be shortened by one step via #036 SDL 001. I still store it the first time it is entered because it is used two more times, so storage and later recall saves a step. 90 and 15 can of course be entered via inline integer, but I store it because when it is used later, RCL arithmetic is used to shave some steps. (In my usage, it saves one step in each case.) That's saving steps by using more registers. ;-) If I get it right, in standard precision every register accounts for four (!) program steps. This means that the use of a separate register should save at least five steps to have a positive effect on memory usage. Otherwise using the same constant several times is the better solution. (02-13-2015 02:19 PM)Jeff O. Wrote: Your DST routine was easy to modify (assuming I did it correctly) to implement the DST rules followed in the US (and Canada, I believe, that being that DST starts 2nd Sunday in March, ends 1st Sunday in November). Is this really observed by all states? Generally, implementing a different DST routine would be fine for the US and Canada, but for a international use it's not better than the EU version I posted – or any other for any region of the world. (02-13-2015 02:19 PM)Jeff O. Wrote: I like having it automatically handled in the program, but a manual mode may be more appropriate for some users Maybe the best solution is a manual mode along with some examples for writing your own localized DST routine. Here your US/Canada version as well as mine for the EU could be included. The user has to adjust the code anyway with his local timezone and location, so the idea of an individual DST routine is not too far off. All it has to do is set flag A during the DST period. Dieter |
|||
02-15-2015, 07:57 PM
(This post was last modified: 02-15-2015 08:01 PM by Dieter.)
Post: #17
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
(02-13-2015 02:19 PM)Jeff O. Wrote: Your DST routine was easy to modify (assuming I did it correctly) to implement the DST rules followed in the US (and Canada The code looks OK. The two XEQ 01 calls return the last Sunday in October resp. in February, adding 7 resp. 14 days gives the first (second) Sunday in November (March). Only the comment in the code needs an update: Code: 228 #007 I would like to ask a final question: the accuracy for 2015 is astonishing. But what about other years? I assume the program uses constants that are optimized for a certain period. How well does the program perform for e.g. 2000, 2050 or 2100? What is the range of years the used constants were optimized for? Dieter |
|||
02-15-2015, 08:31 PM
Post: #18
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
(02-15-2015 07:57 PM)Dieter Wrote: Only the comment in the code needs an update:Thanks, I missed that. Fixed in my listing. (02-15-2015 07:57 PM)Dieter Wrote: I would like to ask a final question: the accuracy for 2015 is astonishing. But what about other years? I assume the program uses constants that are optimized for a certain period. How well does the program perform for e.g. 2000, 2050 or 2100? What is the range of years the used constants were optimized for?That's a good question. I simply copied Marwan's work, so he or someone else with knowledge of such calculations would have to answer. Dave - My mind is going - I can feel it. |
|||
02-21-2015, 02:17 AM
Post: #19
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
(01-28-2015 08:08 PM)Jeff O. Wrote: **Update No. 2**Hi Jeff, Those of us living below the equator are coming up to our Autumn (or Spring in Northern Hemisphere) - our seasons are the opposite. To make Dieter's DST code work correctly for both North & South Hemispheres, I ADDED 3 lines of code ( marked with **NEW** ) as per the following - to make the code work properly for us "Down Under". Code:
Regards, Kiwi Geoff. |
|||
02-21-2015, 07:05 AM
Post: #20
|
|||
|
|||
RE: WP 34S - Sunrise/Sunset
(02-21-2015 02:17 AM)Kiwi Geoff Wrote: Those of us living below the equator are coming up to our Autumn (or Spring in Northern Hemisphere) - our seasons are the opposite. To make Dieter's DST code work correctly for both North & South Hemispheres, I ADDED 3 lines of code ( marked with **NEW** ) as per the following - to make the code work properly for us "Down Under". This requires R.01 to hold the latitude – but this happens not until further down the code. So another modification is required: move the latitude entry (lines 043...051) upwards, for instance like this: Code: Step Instruction Comments I also changed FS?C A (line 59) to FS? A because I think having the "=" annunciator signal a DST result is a useful feature. Dieter |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 4 Guest(s)