All Sky Camera/Weather Station build

[angryowl]

The 5V steppers I have all have terrible backlash so I'm not so sure how they would behave in a scope focuser. But for the Ascom Arduino focuser which I'm planning on putting together I'll be using a NEMA 17 motor with an MXL belt connected to the Feather Touch fine focus knob to keep backlash to a minimum.

[Gina]

1 hour ago, angryowl said:

Hmm, I am hoping the 12V version has more torque than the 5V one. According to this it does (170-190 pull in for 5V and 370-400 for 12V) but that remains to be seen.

That's a very interesting link   I thought the 12v motors just had different windings and provided the same torque - most informative

[angryowl]

Haven't looked on the datasheets for the 5V and 12V versions as I can't seem to find a reliable source, but that link seems to provide a fairly acurate indication of torque. The author performed the torque tests several times so can't be just a one off error in measurement. Though reading further down on the page reveals the author managed to break off some teeth on two of the plastic gears inside the gearbox during the test, and you also said one of your steppers stripped its gears Gina. This got me thinking whether the plastic gears inside can do the job without breaking anytime soon. 

[Gina]

They've been alright on my scopes and astro camera with SLR lenses.  Guess it depends on how easily your focus ring turns.  I wouldn't have thought your lens cover would put up much resistance.

[angryowl]

Well the lens cover is quite heavy and most of that weight is at the end of the arm which the stepper rotates, so I can see why it might be having problems with it. For focus and aperture it's a different story as it takes some force to twist both focus and aperture rings on the camera, and then there's the gear meshing which I don't think is perfect and so adds a bit of resistance itself.

[Gina]

Hmm... I see.

[angryowl]

The stepper motors arrived a few days ago but only today I had the time to mount them on the camera and they do indeed have more torque than the old ones and can easily spin both focus and aperture rings. Had some more issues appear on the PCB, but all are now resolved and it's ready to be mounted inside the enclosure.

Some tests which were carried out and found to be successful:

• Wireless antenna seems to work well through the thick aluminium enclosure even when the lid is on.
• The optocoupler can turn on the PC stick by using digitalWrite at the beginning of a sketch with a 30 second delay to account for the time it takes the PC to be ready to be switched on from when power is applied.
• Tested wind vane and working.
• Tested Stevenson screen and working.
• Tested enclosure and dome DHT22s and both working.
• HDD connected and mounted working.
• Both 12V power supplies working.
• PC and case fans both working.
• USB hub working.
• USB to Ethernet adapter working.
• Dew heater working.
• Tested Rain gauge connections with some Hall effect sensors and magnets and seem to be working.
• All limit switches on the camera body are working.
• Relays for the camera TEC and internal fan working.
• Camera working.
• PCB working.

Things that still need doing:

• Re-print one half of the anemometer body to allow the Hall effect sensor to be placed closer to the magnet. If that fails I will need to re-print the magnet holder and try to fit a more powerful magnet.
• Print the rain gauge
• Calibrate wind vane
• Calibrate anemometer 
• Calibrate rain gauge

I'm sure there's plenty more that needs doing but that's all I can think of now.

[angryowl]

Currently having some issues with the 3D printer, so until those are fixed I’ll make a start on the sketch for me Mega and the VB app.

I see this happening in two stages, well three but first one’s completed:

1.       STAGE 1: Test individual sensors and components for basic serial communication and correct functioning using individual and easily manageable Arduino sketches. Implement several fail-safe conditions at start up and during operation which should offer some protection in case things don’t really go as planned. (More on these later)  COMPLETED

2.       STAGE 2: Write Visual Basic app which will ultimately receive and send all data to the Mega. At this stage only basic functions and communication will be considered:

 

Data sent from app to Mega:

- Relay1 Camera TEC on-off button

- Case Fan on-off button

- PC Fan on-off button

- Dew Heater on-off button

- Aperture Stepper move buttons

- Focus stepper move buttons

- Cover stepper move buttons

 

Data sent from Mega to app:

- Stevenson Screen BMP280 and DHT21 values

- Wind Vane values

- Relay1 Camera TEC - current status

- Case Fan current status

- PC Fan current status

- Dew Heater current status

- Dome DHT22 values

- Case DHT22 values

- Aperture switches current status

- Focus switches current status

- Cover switches current status

- LDR values (Will need calibrating, not yet sure if will be done in Mega or VB code)

- Anemometer values (Hall Effect Interrupt)

- Rain Gauges 1 & 2 values (Hall Effect Interrupt)

 

No communication:

- Relay2 Camera Fan - HIGH at start up. (Stuck on HIGH on the relay board, not going to bother with it and leave as it is)

- PC ON switch - HIGH only at start up for a brief period of time to turn on PC stick

 

With these values then the following can be calculated in real time and displayed on the app main screen:

-          Outside dew point

-          Outside relative humidity

-          Outside temperature

-          Outside humidex

-          Wind chill

-          Pressure in mb

-          Inside (dome and enclosure) dew point

-          Inside (dome and enclosure) temperature

-          Inside (dome and enclosure) relative humidity

-          Light level in LUX

-          Wind speed in mph

-          Wind gusts in mph

-          Wind direction

-          Dew probability

-          Rain fall in mm

 

3.       STAGE 3: Some more advanced stuff like calculating the probability for certain conditions and also want to implement historical data recording  for days, weeks, months and years and the ability to retrieve this from within the VB app.

 

-          Min and max values for the day for certain stuff to be displayed on the main app window

-          According to this calculating the Wet Bulb temperature from the ambient relative humidity and air temperature is somewhat possible. This would open doors to calculating/estimating the probability of fog and snow sleet, or freezing rain in winter conditions.

-          Dusk and dawn times throughout the year graph would be fun to have

-          Cloudbase (not  sure how helpful knowing this will prove to be but it sounds nice)

-          And some other ideas I have but currently researching

The code for the Mega and VB app go hand in hand really so they need to be developed in parallel which is fine as depending at which stage I am, I should have a working solution allowing me to fully control the weather station. This means as soon as I am able to print, I’ll do the anemometer and rain gauge and calibrate them, and then it can go up the pole and start recording both images and data.

[angryowl]

Required at start-up:

What I mean by start-up, is these routines will run only once as soon as the Arduino Mega receives power from the PC stick and will never again run during normal operation. They are implemented to ensure several things. One of them is a power cut during normal operation.

- Lens cover start-up position will be covering the lens and aperture ring will be set to the highest aperture. These are both implemented to avoid damage to the sensor if the LDR routine has not had a chance to cover the camera lens and increase the aperture as it would automatically if the ASC is left running during the day. This is achieved using the limit switches for both steppers and code has been tested and running smoothly at start up.

- 30 seconds after being plugged in the mains, the Mega turns on the PC stick and this too only happens once at start-up. This routine is actually quite crucial to the operation of the entire station and every single sketch pushed to the Mega after mounting it on the pole needs to have this in as it’s the only way to remotely turn on the station. Implemented and running great so far.

There may be some other operations required to run at start-up but these are the two most important and have been already implemented.

[hughgilhespie]

Hi,

Slightly off-topic but I see that you intend to use VB for your weather station display. I wondered if you - or anyone else - has any experience of writing Windows GUI apps using Tcl/tk? The documentation seems to suggest that it's easier to program and that you can create GUIs very quickly. I would love to know more as I am about to start re-learning VB. I haven't used it since VB6 and - well, to put it mildly - it seems to have changed a bit! I want to write a GUI for my automated observatory. I am currently using MegUnoLink Pro to create the Windows GUI and link it to my Teensy based controller. It works fine but I really want to extend the interface beyond what the MegUnoLink software can do.

Regards, Hugh

[angryowl]

38 minutes ago, hughgilhespie said:

Hi,

Slightly off-topic but I see that you intend to use VB for your weather station display. I wondered if you - or anyone else - has any experience of writing Windows GUI apps using Tcl/tk? The documentation seems to suggest that it's easier to program and that you can create GUIs very quickly. I would love to know more as I am about to start re-learning VB. I haven't used it since VB6 and - well, to put it mildly - it seems to have changed a bit! I want to write a GUI for my automated observatory. I am currently using MegUnoLink Pro to create the Windows GUI and link it to my Teensy based controller. It works fine but I really want to extend the interface beyond what the MegUnoLink software can do.

Regards, Hugh

Hi Hugh,

Had a look at MegUnoLink and it seems like a nice quick solution for generating some graphs and controlling a sketch but looks somewhat limited in what you can do with the "dockable visualizers" as they call them. I've only ever used VB to design an app for someone to control a camera and heater via relays using timers and with a few other functionalities. Not sure about Tcl, but VB seems to more than enough for my particular application in terms of functionality and flexibility.

I do think you could implement a more advanced interface with VB than you could with the MegUnoLink from what I can see and the little experience I have with VB, not sure how more complicated and time consuming that would be though.

Maybe some of the more experienced programmers can weigh in on this...

[angryowl]

Some other things coming to mind:

The outside temperature from the Stevenson Screen reported will be a mean/average of the BMP280 temp and DHT21 temp. Just because I have two sensors and want to use them both 

The BMP280 sensor outputs pressure values in Pascals. These will be converted to millibars in the sketch.

The dome DHT22 will be used to calculate the probability that there will be dew inside the dome. Once temperature exceeds dew point in the dome the dew heater will turn on automatically. Dew on the dome should also be easy to spot by checking the images from the camera, and if somehow the heater is off, it could then be manually activated via a button.

During normal operation the limit switches will serve two purposes: using the aperture switches to ensure the aperture is either all the way up (daylight operation) or all the way down (nighttime operation) and the cover switches to ensure the cover is either on the lens or fully retracted. The other purpose is limiting stepper movement in the direction of the switch after the first switch detection to avoid stripping gears on the motors as they output quite a bit of torque.

[angryowl]

Stage 2 is more or less completed with basic functionality and communication between the app and the Mega.

The LDR and wind vane have not been calibrated so currently just the raw values are displayed on the app screen.

Still have some bugs I need to take care of before I move onto stage 3 but so far looks promising.

[angryowl]

Currently working on the app and adding functionality such as live charts and data recording. I'm thinking to record most values every minute at the moment but if this proves to be too frequent I can change it later to something like 5 minutes or longer. The app automatically creates folders for the current year and month which are then used to hold text files with the data for every day in the month. 

Then from the daily data recorded the app will build additional text files to be used for drawing charts and finding minimum and maximum values. These additional files will hold weekly and monthly values and the last week and month's charts and min/max values will be displayed on the main form. I'll also add combo boxes which can then be used to select previous text files for days, weeks and months.

Of course for the week/month files and charts I will not simply combine all the data captured every day, but will only grab values corresponding to certain times of the day. For the weekly chart I'll be using values for times 00:00, 06:00, 12:00 and 18:00 which for seven days produces a readable graph. For the month I'm thinking only times 00:00 and 12:00 as that should still show up nicely on the graphs.

I'll update with some images soon...

[angryowl]

Finished most of the core functions within the app and Arduino sketch and all that now remains is essentially designing the controls in such a way that they're easy and intuitive to use(something I was newer good at). This is where I would appreciate any input and suggestions from the good folk here.

Got the APP to do most of what I was after and works reliably. It's pretty much automated. You start the app and camera capture software, set the same exposure time in both programs and off you go. The camera recording software is somewhat limited in that it can only output files to one specific folder but the VB app deals with this by having a function that checks the specified folder every duration of the specified timer and looks at all of the files in there and picks the one with the latest creation date and crops it to a fairly squarish shape, adds a black overlay background and time and date stamp and cardinal points(these are to be determined once the camera is up the pole). It then creates a folder for the current year, month and day if there isn't one already in a permanent image location path and moves the modified file there. Immediately after this the latest file is displayed onto a picture box on the main app form for easy viewing(this also allows zooming of the image)

After this when the LDR determines it's light outside, a separate executable video creator file using ffmpg is invoked as a separate process and this does three things:

1. Looks at yesterday's permanent folder containing the images and inspects their creation dates and only picks the ones with creation dates starting from the time the LDR determined it's dark outside up until midnight. These images are then dropped in a list in chronological order.
2. Performs the same process as above with the only difference that it looks at creation dates starting from midnight up until the LDR determines it's light outside. These images are then added at the end of the list.
3. Effectively we now have a list with only the files from yesterday's dusk till today's dawn so no overexposed bright images. (The lens cover would have activated and covered the lens anyway)
4. The executable then stitches all of these images with configurable settings like frames per second, quality, effects , etc. This video file is then placed in a separate folder with today's name.

The original png files are still left in their original location but my decide in the future that they could be deleted, we'll see.

I added a Moon Phase and Age function just for the sake of it and I think it looks cool!

I designed some simple graphics to allow easy visualisation of the wind direction but we'll see how that works during real usage.

Daily, Weekly and Monthly min and max I decided to have drop down boxes for them allowing the use of a specific day/week/month then a  message pops up showing you the min and max temperatures and times and dates.

The current day's min/max will sit permanently on the app screen refreshing right after a new value is added (which at the current is a minute).

The charts are all zoom able which I find to be a fantastic feature. Data displayed in the weekly and monthly charts is selected from two drop down boxes which display all current text files for weekly and monthly charts.

At the moment I only have the temperature functions done, the rest humidity, pressure etc are not done but it's simply replication the temperature functions with a few tweaks here and there. 

The reasoning behind doing this is I could not have fitted charts components for all of the values I wanted on the form, so the way this is going to work is all the elements, drop down boxes, charts and text boxes will change depending on which of the radio buttons on the lower left hand corner of the screen is chosen. the default will be apparent temperature I'm thinking.

Ignore the data in the charts as it's all test values at the moment!

[angryowl]

Come to think of it, since there's no way to stop the camera recording at dawn(except issue a process stop from within the VB app dependant on the LDR value, but that would mean having to restart the camera manually at dusk, too much pain) I could leave the camera recording continuously and just add a bit of code in the external video .exe to simply delete all images with creation time higher than dawn and lower than dusk.

[angryowl]

Managed to calibrate the wind vane today and it's pretty accurate, consistent and responsive and I'm happy with it so far.

Also resolved the issue with the anemometer where I thought the magnet was too weak to trigger the hall effect sensor. Turns out I didn't push the sensor in all the way in the casing up to the level where the magnet was, a bit of tweaking and the anemometer now works! Will purchase a digital anemometer and perform a calibration with some server fans I have laying around. Hopefully this should give an accurate enough calibration for my needs.

Now that I have a brand new printer glass build plate with no chips in it and my printer issues are resolved, I can start work on the rain gauge. I have seen various 3D designs online but most of them either have not been tested or they don't perform reliably and consistently enough. The most  common issue on all designs seems to be the tipping mechanism of the bucket. From what I gather it's tough getting it to tip consistently.

Has anyone on here had a go at building one of these? Any tips or pointers would be most appreciated!

I have formulas for calculating volume of water collected by "funnels" which'll be used to collect water for the tipping mechanism, so on that front I'm fine. 

[angryowl]

Can't find your post Gina, in which you and another forum member were discussing various ways of properly displaying wind direction measurements from the same sensor I have. If my memory serves me right you were talking about recording a number of consecutive values, say 5, then doing some sort of calculation and outputting this as the main result. You mentioned this had the benefit of smoothing out the readings as wind direction can get erratic quickly.

Currently I'm just sampling the MLX sensor every second and that seems to produce good results. Not doing any computation, juts reading the current value at that particular point in time. Do you feel this would be an accurate enough way of measuring wind direction? Does anyone know how the professional ones out there do it? 

Just for the fun of it I tried a 10ms timer and the graphic displaying the arrow with the direction on the application was extremely responsive and barely any latency introduced. Of course using this in the finished app would do my head in as wind direction is quite erratic and the pointer would move far too fast. 

By the way the wind direction graphic on the app uses 64 dots each of about 5.6 degrees or so. I wanted a bit more granularity so went with this rather than just 16 or 32 points. In fact if I have enough time I could go for 360 points as the output from the sensor is 3600 so that would make each point 0 to 9 then 10 to 19 and so on! Only problem is being able to display and properly differentiate between 360 points on the circle! 

[angryowl]

All that's missing is the rain gauge!

[Gina]

9 hours ago, angryowl said:

Can't find your post Gina, in which you and another forum member were discussing various ways of properly displaying wind direction measurements from the same sensor I have. If my memory serves me right you were talking about recording a number of consecutive values, say 5, then doing some sort of calculation and outputting this as the main result. You mentioned this had the benefit of smoothing out the readings as wind direction can get erratic quickly.

Currently I'm just sampling the MLX sensor every second and that seems to produce good results. Not doing any computation, juts reading the current value at that particular point in time. Do you feel this would be an accurate enough way of measuring wind direction? Does anyone know how the professional ones out there do it? 

Just for the fun of it I tried a 10ms timer and the graphic displaying the arrow with the direction on the application was extremely responsive and barely any latency introduced. Of course using this in the finished app would do my head in as wind direction is quite erratic and the pointer would move far too fast. 

By the way the wind direction graphic on the app uses 64 dots each of about 5.6 degrees or so. I wanted a bit more granularity so went with this rather than just 16 or 32 points. In fact if I have enough time I could go for 360 points as the output from the sensor is 3600 so that would make each point 0 to 9 then 10 to 19 and so on! Only problem is being able to display and properly differentiate between 360 points on the circle! 

I'll see if I can find it.

[Gina]

This is the nearest I can find so far LINK

[angryowl]

2 minutes ago, Gina said:

This is the nearest I can find so far LINK

That's exactly what I was looking for... I'll have a read later on and see how it compares to what I'm using, thanks!

[angryowl]

I printed a tipping bucket style rain gauge without the collecting funnel or enclosure just to test if the concept would work and it does! A quick test with the sensor on an Arduino interrupt pin triggers consistently for every tip of the bucket. As always a picture is worth a thousand words:

Rather than printing the two pillars which stop the bucket, I used two M3 bolts which are adjustable via nylon lock nuts. This height adjustment is needed to ensure all the water in the bucket is discarded of when the bucket tips over.

Tomorrow I'll use a syringe to find the volume of water that each half of the bucket holds. The bucket is fairly small so depending on the funnel size, it should deal well with both light rain and a downpour with fair enough resolution. 

I have some liquid latex which I'll probably use to protect the sensor assembly and all other metal parts. I'll also try and spray the bucket inside walls and the funnel with a rain repellent solution I have in the hopes of measuring almost every drop and not have them stick to either the bucket walls or funnel thus hopefully increasing accuracy. Well at least in theory! 

(The bolt holding the sensor assembly and the nut for it are made of some sort of alloy which is not magnetic)

[angryowl]

Yesterday when I was waiting for the rain bucket to print I played around with some C# code with Visual Basic and tried to transform some circular fish eye images into panoramic rectilinear ones. I also tried to convert them to equirectangular and cylindrical but the results did not look as good. I quite like the result this produces and am contemplating whether or not to include this into my main app and have the outputted images displayed on the page somewhere in a small size.

Before and after images(not my images of course)

[Gina]

Very clever