Gina

Print was fine this time Some photos. Top printed in natural ASA filament whereas bottom was white ASA. The natural was on special offer.

New design - see how that works...

Casing top has finished printing and after tidying up (removing brim) I tried it on the ASC. Unfortunately, I forgot about the focus motor and the top doesn't fit so it's "back to the drawing board"...

Why oh why did I go for a 800mm cube for the base of my pier???? Over engineering in the extreme - but that was what was recommended at the time!

That sounds a good idea ??

I have designed and printed the bottom part of the ASC casing and also designed the top part that takes the dome. Now printing that. All in natural ASA filament.

Shutter doesn't open very far.

Amazing ? Love it!

While working out the shape of the casing I've been thinking about the RPi and buck converter. With the heat produced by the Peltier TEC heating not only the cooler but also the inside of the case it strikes me that the rather warm environment might not be good for the electronics, particularly the RPi. Now since I'm mounting the ASC on the side of the observatory roof, the RPi (and buck converter) could be placed inside the observatory where it's cooler (and dry). This would also make for a smaller ASC casing. The heat leaking from the cooler into the case can help with dew heating but isn't so good for electronics. Connecting the RPi to the ASC would be the USB cable to the camera, multiway flat cable to the focus motor and single wires for the Peltier TEC and the dew heater (if required) plus their power line (13.8v). I can make a separate box to take the RPi and buck converter and fasten it to the inside of the roof.

I've printed one of those to go in my longcase clock when I make it ?

Now designing and printing case parts.

Of course the rain shielding will need changing to suit the new orientation but it needs a new bracket anyway so I have new designs and 3D prints to do.

The mast-top unit will be just the wind instruments, the light measuring unit can be elsewhere. The current arrangement has the anemometer on top and the vane underneath but the bracket could be shorter is it was the other way up. I need to do something about the anemometer anyway as the bearing has come loose and it could blow off in a storm. Three diagrams - Current orientation Inverted With new bracket on top of hollow mast (aluminium pipe)

Thanks Dave. That is what I'll do - the plan is coming together ?

Tilted the camera to show more of the outdoors through the window. Very coppery coloured sky - looks like we might get a storm.

WOW!!!

Testing the remote focus - all fine. Here is a test exposure 10ms, gain = 0, sensor temperature -1.5°C. Short exposures generate much less heat.

Having the main data logger unit indoors would make it easier to drive an analogue display panel.

Found a WiFi shield but the trouble is, I don't know if it's compatible with the Data Logger Shield. ESP8266 ESP-12E UART WIFI Wireless Shield TTL Converter for Arduino UNO R3 Mega I'm wondering though if I should have the data logger unit indoors, directly plugged into my main desktop machine say. It seems a bit odd data logging at a remote site. I have an underground CAT5e cable between house and observatory that I've used in the past for 1-wire. It's in a 15mm plastic water pipe but I haven't checked it in the last few years and may have been attacked by rats. I could always lay a new cable though as I have plenty of CAT5e cable.

Taken laptop out to observatory and there's plenty of WiFi signal Hopefully then I should be able to do away with the cable feed. So I shall want a WiFi adapter or shield for the Arduino.

Aluminium plate 200mm x 150mm x 4mm attached to cooler with M5 flat headed Allen screws. 5mm holes in plate and M5 threaded holes in cooler.

To get the average wind direction I propose sampling the direction each second and adding a count to one of 32 "boxes" then when the data is read, take the box with the most counts as the direction and clear all the boxes. I might change to 16 boxes depending on how well it all works. For the wind speed, a sample of the count each second, compute the maximum, read that at the data reading interval then reset. For average, take the count at the end of the period, ie. when data is read, then reset. To convert mph to Beaufort I plan to use a table with the maximum of 127 mph (anything over 127 will be limited to 127 - heavens forbid!!). Though the Beaufort scale maximum of 12 is anything above 72 mph it might be interesting to add a few extra levels and as we are using binary coding the scale could go up to 15. We have had winds of 80 or 90 mph in the past!

If I do pre-processing of the wind data in the Nano, the data would be as follows :- Wind direction - one of 32 directions - 5 bits Wind average speed - Beaufort scale - 4 bits Wind gust speed - Beaufort scale - 4 bits Total 13 bits. If I have 16 bits available I could double the wind speed resolution giving 15 bits. As the wind gust speed is always going to be more than the average I could send the difference rather than the absolute speed - I reckon that would save a data bit or maybe two. I doubt the wind would be gusting more than 4 points on the Beaufort scale above the average.

Been checking on which pins I'm using on the Nano and I find I'm using D2 as interrupt for the anemometer and D3 for one of the direction measuring chip lines. OneWireArduinoSlave needs an interrupt line and I've used both of them but the direction chip can use different pins for its connections so I just need to change the wiring a bit and the code to match. I haven't yet added any code to deal with the anemometer so I can move that to D3 and use D2 for the OW-Slave as set in the library. The anemometer interrupt code should be short as it only has to increment a counter. The counter would be reset after reading by the OW-Slave read data routine. I shall need to decide how often to read the wind data and also what to do about wind gust speed. If the data is read once per second, I think this would cater for gusts but would result in a lot of data. This is a question of which data to process where. I could process wind speed in the Nano and sample the data every 10 or 15 seconds. Also the wind direction could be smoothed in the Nano and the average over 10-15s used as the data sent to the logger. I don't think short-term wind direction changes are significant. I think on the whole, I prefer the idea of doing a fair amount of data pre-processing in the Nano - might as well share the load a bit ? There is little point in sending wind direction with a resolution of a degree over to the logger - 16 or 32 steps after averaging seems much more sensible. In fact the direction measuring chip returns the angle with a resolution of a tenth of a degree.

Focus gear printed and now looking into mounting and casing. I think I shall mount it by screwing an aluminium plate onto one side of the cooler, wider than the cooler so that I can screw it to the obsy roof with two wood screws either side of the cooler. I think the casing can fit onto the top of the cooler and stick out slightly on 3 sides. It could be attached to the back plate that I'm using for mounting too, to give extra strength.