Gina

The most important change will be in the dome sealing. This will be a 3D printed ring which will sit on the small flange on the dome and clamp it to the body of the ASC with a rubber sealing ring. This means a change to the part the dome sits down onto. This is the current arrangement of the sealed part of the ASC. The dome is outlined in red to make it show better. The conical shaped section will need to have a wide, flat top to take the clamping ring. I shall split the clear blue part into two to make in printable without support material.

Latest.

Actually, I've been very lucky with lack of droppings on the dome. Not had a bird dropping so far and I guess fly droppings have been washed off by the rain or are so small and out of focus that they don't show. I didn't notice anything when I washed the dome.

Looks like here we go again!! With a new design of ASC casing. Must say, I'm not really happy with the idea of setting the focus manually and relying on it not changing over many months of use. I don't want to have to keep taking it down and removing the dome to reset the focus so remote focussing seems to be on the agenda again!! Groan! The main imaging lenses needed a 6" quadrant gear (lever) with a stepper motor with small pinion engaging it. I would rather not have to enclose a 6" lever within the ASC casing! The problem is getting reduction gearing without too much backlash. I shall have to get thinking... Another thought is an external cover for the dome to use when not using the camera. Although it's quite capable of daytime imaging and can produce some rather nice pictures of the clouds scudding across the sky, I don't want much of this and mostly the ASC is not used in daytime. Nor is it used when it's raining. A cover would keep the sun off in the daytime and insect and bird droppings at any time. It should lengthen the life of the dome and reduce cleaning. ATM the electronics is in the observatory rather than within the ASC casing but if I add remote focussing and remote dome cover control that's a lot more wires between electronics and ASC and it would make sense to have the electronics in the ASC casing.

I'm looking again at the clamping and sealing of the dome. I would like a dome with a wide flange with holes for screwing the dome down but these are still still out of stock (as they were before). These are the two domes - I have the one with the narrow flange. I have tried many makes of dome in the past but these are the only ones that are distortion free that I have found. I could print a ring with fixing holes that would emulate a flange for clamping down the dome. It should be possible to get a seal using some EPDM sheet left over from my obsy roof.

Yes, I have but may try again.

After several months use and working well, the ASC finally succumbed to ingress of wet following many days of torrential rain and gales so it's come indoors for a service. There was mist in the lens which has now dried out and the camera is working and giving a reasonable image. Except that the focus has changed! The reason for the weatherproofing failure was the silicone sealant. We have had very large changes in temperature which could have been detrimental to the sealant. Then a very high wind with heavy rain must have forced wet up the 20mm dome overlap and into the insides. We are accustomed to horizontal rain but in this case the wet was forced upwards!! Whether there's any way of preventing wind blown rain going up into the dome if the sealant fails, I don't know but I guess more thought is required. Another problem is that over the months, the focus has changed slightly but enough to make me try refocussing. Been trying to refocus the ASC but had forgotten how extremely coarse the focussing was. Unlocked the focussing ring on the lens and moved it a "midgets whisker" and the focus was 10 times worse!! I was hoping that the focus would remain pretty good once set up but it does seem to have changed. Drat!! Looks like it may need remote focussing after all. I'll have to think about it. I wonder if I'll ever get an ASC that continues to work as I want!!

The anemometer is very sensitive and turns smoothly at well under 1 mph so the mean speed could be displayed in tenths but I guess there's really no point (no pun intended). The Beaufort scale for wind force is a good indicator but really I would like more points.

Now have the Wind sensors working.

The wind is very light and variable with anemometer rotating at around 1rps or less so not every 3s period getting a pulse. This could be the reason, I guess, though how the instantaneous direction could be over 15 when there's a modulo 16, I don't know! Sometimes the display seems right.

Having thoroughly tested the wind sensors indoors and found everything seemingly correct I've installed them outside on the observatory and powered up. BUT things are NOT right!!

Next I need to adjust the direction to suit the orientation of the wind instruments. This could be done when reading the encoder or when displaying the results. I guess the former is easiest. Think this should do it. dirn = (dirn - 1) %16; // correct encoder for North

Found the problem. Forgot to empty the bins after counting the hits ready for the next lot. Added this line and it seems to be working correctly. for (int i = 0; i < 16; i++) {bin[i] = 0;};

Seems as if the mean direction is bearing no relationship to the actual wind vane direction. The instantaneous direction is correct so the encoder is working fine - it's the Consensus Averaging calculations that are wrong. Somewhere in all that code!!

I'll just confirm that all compass points for the wind vane give sensible results then look to installing the wind sensors and mast. Later... Should have guessed it was too good to be true. OK yes the speed processing seems fine but the direction isn't! I had posted the sketch but now removed it as it isn't right. Switched the fan off and let the anemometer slow down and stop then moved the vane to the 0 position. I have given the Consensus Averaging time to work and for the wind speed to decay from the ring arrays. This is the result. Yes!! It's a long way off right!! So now I have more debugging to do! Though not tonight I don't think.

Seems to be working correctly now.

I think I need to see what's going into the ring array.

Corrected that error and the gust speed is reading correctly but the mean speed is still increasing. So still an error!! Somewhere in this section of code. void do1mJobs(){ // wind speed mean and gust ring arrays and report meanArray[ringIndex] = windSpeed; // put windSpeed into new array index gustArray[ringIndex] = windGust; // put windGust into new array index // windSpeed /=13; // /20 and *1.5 -- leave this for later meanSpeed = 0; gustSpeed = 0; for (int i = 0; i < 10; i++) { meanSpeed += meanArray[i]; // add all windSpeeds if (gustArray[i] > gustSpeed){gustSpeed = gustArray[i];}; // find maximum gust speed } meanSpeed /=133; // the first sum was over 20 values and then the second over 10 values gustSpeed *= 1.5; // Speed count over 3s rather than 4.5s sendSpeedMessages(); // HOLD temporarily for debugging windGust = 0; sendNumberMessage(ringIndex); // send ringIndex for debugging ringIndex = (ringIndex+1)%10; // move ringIndex on to next location in the ring array }

For debugging I have added a number display in the Wind tab. Currently showing the ringIndex and that is correct - starting at 0, increasing up to 9 and then back to 0. The mean and gust displays are increasing with every change in index though so I have another error (or two). Clearly not zeroing the values before forming sum and maximum.

I think the wind direction may be correct. The instantaneous direction is varying between WSW and W - 11 & 12 points or 247.5° and 270°. The mean direction is reading 261° which agrees (it is between 247.5 and 270). The wind mean speed is a different matter!! It isn't working! This is the averaging in the ring array. OTOH the Gust speed does seem to be working.

Looking at the direction. Might be right.

This looks better.

About to run this code void do3sJobs (){ // sendDirectionMessage(readDirection()); // send instantaneous direction windSpeed += PulseCount; // Accumulate mean speed if (PulseCount > windGust) {windGust = PulseCount;}; // Get max speed for gust PulseCount = 0; ++bin[readDirection()]; // increment appropriate bin } void do1mJobs(){ // debugging - send current mean and gust speeds meanSpeed = windSpeed/20; gustSpeed = windGust; windSpeed = 0; sendSpeedMessages();

Checking mean and gust speeds at the 1m point. void do3sJobs (){ windSpeed = ++PulseCount; // Accumulate mean speed if (PulseCount > windGust) {windGust = PulseCount;}; // Get max speed for gust PulseCount = 0; ++bin[readDirection()]; // increment appropriate bin } void do1mJobs(){ // debugging - send current mean and gust speeds meanSpeed = windSpeed; gustSpeed = windGust; sendSpeedMessages(); The results are wrong. All speeds are showing 1 rather than 0 with no fan running. Gust speed looks reasonable looking at the anemometer revs though 1 higher than it should be. The Mean speed should show around 20 times the real value as the value is the sum of 20 counts and hasn't been divided. It points to this line windSpeed = ++PulseCount; // Accumulate mean speed From Arduino reference Example Code x = 2; y = ++x; // x now contains 3, y contains 3 y = x++; // x contains 4, but y still contains 3 I can see what's wrong. Got the wrong operator, should be x += y; // equivalent to the expression x = x + y; Corrected windSpeed += PulseCount; // Accumulate mean speed

Actually, none of it is working correctly!! I've turned the fan off so the speed is zero. The direction is now something like 180° different and this hasn't shown up. I can see this is going to take a lot of debugging. And it's not as if I can put breakpoints in the code and debug it in the normal way. I shall have send messages to the MQTT network at strategic points in the calculations.