Brian I log the solar values in a custom log file. Yesterday WD started with the first non-zero value at 06:27 AM but today on 1st March it had its first non-zero value at 07:20 AM. Now my actual sunrise yesterday was 06:41 AM and today is 06:39 AM. Now neither day was correct but I simply do not understand the sudden jump of 53 minutes just because it is the 1st of March. The sun/moon/lat/long control panel shows the correct sunrise and sunset times. Yesterday the last nonzero value was 18:49 PM which is way way after sunset here!

if you have a look at that formula i sent you , there is a new x value for the new month that is set

so its not a bug,its how the formula works

Brian I am sorry if I am being dense here but I dont understand what you are saying. Yes I can see that part of the formula, it calculates the Julian day so that the correct declination can be calculated, so yesterday x = 59 and today (1st March here in the UK) x = 60. That does not explain why I get a first non-zero expected solar max at 06:27AM on day 59 and today day 60 I get the first non-zero expected solar max at 07:20AM. I have converted the formula you sent me to a script and I do not get this particular error with the script, nor can I see where the formula as sent to me would come up with this error.

ricky spotted a bug in my code, which only happend in february,a double up with the adding of the days to the julian x

so that will explain the shift now thats its march

and it will also explain why february was a moving target all the time

march should be better…i.e try setting the adjusements back to zero now

thanks ricky…i missed that bug…could not see the wood for the trees!

Brian I cannot see that bug in the listing I have unles I dont understand the way Delphi works. Must admit I did my own bit there with my script.

Anyway I have installed the latest 10.23 full and then 10.23a zip this morning having just downloaded them, it has not sorted the problem, my sunrise is 06:37AM and the first non-zero reading from WD was at 07:18AM. Have I got the right download to fix that bug?

the bug was in february, where the day as added twice (at the start of the setting the x and again at the end of setting the x value routine)

for march, now, try removing any offsets/adjusments

Brian yes sorry I see it so march will be fine. Now I had no offsets added this morning when I started up.

Now I understand February March is still wrong but I think I understand from your formula what may be wrong, I can replicate very similar readings in my script to those I get now for March. I am going to take a careful look at it again and I’ll update later today, but I think it is to do with the Solarnoon calculation.

Brian if I understand your solarnoon calculation correctly you are using only the minute part of the sunrise and sunset times, adding them together and dividing by 2 which for today with s.r at 07:37 and s/s at 17:37 gives me (37+37)/2 = 37 ie 37 minutes past the hour. Well the solarnoon at my location from several places on the internet is roughly +7 minutes (give or take a couple of seconds).

I suggest you should use sunrise minutes since midnight + sunset minutes since midnight divided by 2 the take 720 (noon minutes since midnight) from this, so for today we get ((6*60)+37)+((17*60)+37)/2 = 727 then 727 - 720 = +7 This calculation still works if solarnoon is before midday clock time which does happen!

Using this formula in my script gives me readings closer to what I expect.

I suspect it’s easier than this.

(37+37)/2 = 37

…but hours only have 60 minutes so it should probably be:

((37 + 37) MOD 60) / 2 = 7

Chris there are many ways to skin a cat! Not sure if MOD 60 will work in all languages, andy way whatever takes you fancy as long as it works out to the correct time always, including when it is negative (ie before midday) which can and does happen.

Stuart

I have also just noticed a problem with this part of the formula

if mainunit.checkmonth>11

then

x:=31+28+31+30+31+30+31+31+30+31+31; <---- this last 31 on this line should be 30 for November. A very small error I know but none the less for that.

Brian to summarise what I believe needs changing in your formula for solar max is as follows.

This is the code I have in my PHP script which I hope is understandable

//Calculate Solarnoon value as an offset

$sunrise = (substr($sunriset,0,2) * “60”) + substr($sunriset,3,2); // convert to minutes since midnight where $sunriset = 06:37

$sunset = (substr($sunsett,0,2) * “60”) + substr($sunsett,3,2); // convert to minutes since midnight where $sunsett= 17:37

$solarnoon = ($sunrise + $sunset) / “2”; // minutes since midnight

$solarnoon = ($solarnoon+$minoffset) - “720”; // minute offset from noon to adjust time to solar time

I am not sure why you need the minute offset you originally had but I have left it asis in the calculation above.

I also believe your declination calculation is not accurate enough, when I do it your way and compare with other sources on the internet I get a value too high for the current day. I found this calculation which seems to be more accurate.

// Calculate solar declination

$t = 2 * pi() * (($julian_day) / 365);

$decl = (0.322003-(22.971*cos($t))-(0.357898*cos(2*$t))-(0.14398*cos(3*$t))+(3.94638*sin($t))+(0.019334*sin(2*$t))+(0.05928*sin(3*$t)));

Plus this last bit needs to be chnaged just for total accuracy.

if mainunit.checkmonth>11

then

x:=31+28+31+30+31+30+31+31+30+31+31; <---- this last 31 on this line should be 30 for November. A very small error I know but none the less for that.

Brian I know you are a busy person but is there any chance you could take a look at this please? Those of us who use the sunshine hours are having to manually adjust every morning as WD is calculating the first non-zero value some 30 minutes late due to the problem with your solarnoon calculations. My sensor starts reading around actual sunrise at 06:41 but WD expects the first non-zero value about 07:11 by which time thesensor reads much more than WD expects for sometime before WD catches up (if it is actually not sunny).

ok, i have replaced the code I had with your code

in a new 10.23c zip, uploading now

Thanks very much Brian, I’ll download it and make sure what happens tomorrow morning…

your calculations do not seem to be working very well for me here…

ok, i think its becuase I am not allowing for daylight saving correctly with your better solar noon formular

trying that now

http://www.usc.edu/dept/architecture/mbs/tools/vrsolar/Help/solar_concepts.html

good info there, and my original solar declinations were ok

http://www.usc.edu/dept/architecture/mbs/tools/vrsolar/Help/solar_concepts.html

good info there, and my original solar declinations were ok

so i have put that back now

Brian I am assuming that the latest full download of 10.23c has the solar calculations as you have decribed here. If so there is still a problem here at my latitude in the northern hemisphere. The first non-zero value is being calculated some ten minutes after the actual sunrise time which can still lead to false percentages. The first non-zero value should happen at sunrise or at least ±1min of sunrise and it does not. Can you PM me the formula as you now have it so I can alter my simulation script ot be the same, I can then play with it to see what effect the adjustments have.