Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

sgl_imaging_challenge_banner_dslr_mirrorlesss_winners.thumb.jpg.9deb4a8db27e7485a7bb99d98667c94e.jpg

Recommended Posts

For quite some time now I've been working on a small weather station. The idea is to add automation to an obsy I'm building. The weather station as is measures temperature, humidity, pressure and presence of cloud. I also have the components to build a rain detector, but haven't implemented that yet.

First the box:

Made from vent covers and pieces of aluminium

weatherstation1.jpg.a4654cd886c82147ff599daba0622d7e.jpg

All put together

weatherstation2.jpg.040acfdf0f59eeb11feda5322d18c2a7.jpg

With sensors. The IR sensor is in the far back (top of the housing) and the BME280 sensor is the free hanging red pcb. The other pcb holds a few pull-up resistors and a capacitor for the I2C wires. Insulation added to keep critters out.

IMG_20191204_194304.thumb.jpg.33accb1a755c727d40f7a61625029fc9.jpg

First I thought of using an Arduino to control and collect the data, but recently I started tinkering with ESP32 wifi boards. These are a lot faster and have more memory than Arduinos, and I wanted to use microPython.

IMG_20191204_194054.thumb.jpg.be3dce9b54899fd156c8114f22508b10.jpg

The ESP32 board is also smaller than an Arduino UNO (about the size of an Arduino nano) and has built in wifi, which means I just need power to the device.

I uploaded the code to GitHub

https://github.com/wberlo/indi_meteostation

Output is as a HTML file (index.html) which presents data in a simple way. The INDI driver 'Weather Watcher' can read this file.

For now, temperature is mapped to temperature (of course), and 'clouds' is mapped to 'forecast/Weather' in INDI. 'Clouds' is a parameter that varies from 0 to 1. I used the same criteria as the AAG Cloud Watcher device: if sky temperature is less than -8 degrees, the sky is assumed cloud free. For a sky temperature between -8 and 0 degrees, there is partial cloud, and for a sky temperature higher than 0 degrees, the sky is overcast. This seems very arbitrary, and I expect to have to adjust this piece of code later.

163118336_Screenshotat2019-12-0419-18-35.thumb.png.f30b241b4f95f98de3891df9eca50b20.png

Major update:

The weather station now also reads and reports the SQM values from my wifi-SQM. 😋 See further down this thread for details.

 

Edited by wimvb
  • Like 8

Share this post


Link to post
Share on other sites

Thanks, Firas. Not yet calibrated. But that won't be much of a problem.

Share this post


Link to post
Share on other sites

This is very interesting.  I was thinking of the possibility of something similar myself.

  • Like 1

Share this post


Link to post
Share on other sites

It shouldn't be too difficult for you, Gina. You should probably also check out the updated Indiduino/Induino meteostation. The code is updated to use the BME280, mlx90614 and tsl2591. The latter for sqm. I'm currently also working on a sky quality meter using the tsl2591. Also with the esp32 board and microPython. 

  • Thanks 1

Share this post


Link to post
Share on other sites

New feature added.

I changed the firmware of the meteostation so that it now can read the SQM values from my wifi SQM meter

 

The SQM value is written to the index.html file and reported together with other weather data. This means that the Weather Watcher in Ekos now will read this value also.

  • Like 1

Share this post


Link to post
Share on other sites

My own weather station housing is not dissimilar in construction, though I made a timber frame and roof.  Buying pre-fabricated vents makes construction so much simpler.  At the moment all my instruments are 1-wire as I already had  them, though some are in need of repair -- the plastic of my AAG weather station has decayed somewhat in the sunlight.  For the time being I have painted it all with white gloss paint to try to give it a bit more life whilst I 3d-print new parts, though I have no option but to replace the wind direction vane as that has completely broken up.

So far I have temperature, air pressure, relative humidity and light intensity sensors working though I haven't moved the last one outside the screen as I haven't worked out how I'm going to protect it from the rain yet.  I've been looking at using weewx to capture the data, though there seems to be a fair bit to get my head around.

James

Share this post


Link to post
Share on other sites
3 minutes ago, JamesF said:

So far I have temperature, air pressure, relative humidity and light intensity sensors working though I haven't moved the last one outside the screen as I haven't worked out how I'm going to protect it from the rain yet.  I've been looking at using weewx to capture the data, though there seems to be a fair bit to get my head around.

I have the same: temperature, humidity, air pressure (and derived: dew point) from the Bosch BME280 environmental sensor. I also have temperature and sky temperature from the mlx90614 ir sensor, which will act as a cloud sensor. I get light readings from my SQM meter (also ESP32, but in a different case). I plan to mount the weather station outdoors (of course), and the SQM meter inside, so that it's only operational when the roof of my observatory is open. I won't need sky readings when I'm not doing any imaging, and the cloud sensor is enough to determine if I should open the obsy roof.

I have the components for a rain sensor, but so far haven't put those together yet. I first have to figure out where best to place it and if I should put a NiCr wire underneath to combat dew.

I must have a look at weewx, thanks for pointing that out.

Share this post


Link to post
Share on other sites

I shall certainly be stealing ideas for the SQM when I get that far :)

James

Share this post


Link to post
Share on other sites
42 minutes ago, JamesF said:

I shall certainly be stealing ideas for the SQM when I get that far :)

James

You're welcome :)

Share this post


Link to post
Share on other sites
1 hour ago, JamesF said:

I've been looking at using weewx to capture the data

Weewx only seems to capture data from devices that are directly connected to it, not through wifi. 

Share this post


Link to post
Share on other sites

I think it will be a little while before I get round to advancing my weather station project.  I have a queue of jobs and that's not at the top (yet).  I already have a lot of it done but Arduino + 1-wire based and I want to use RPi for remote operation and to tie in with my KStars/Ekos/INDI setup.  The latter runs all my imaging kit including (shortly) all sky camera and motorised ROR control.  I have a working logger for weather data and a 3D printed Stevenson screen.  Wind instruments are practically done too.   ATM the logger only logs data to an SD card and I would like to run a live weather web site like I did some years ago.  All the various parts want linking together.

Share this post


Link to post
Share on other sites
47 minutes ago, Gina said:

I think it will be a little while before I get round to advancing my weather station project.  I have a queue of jobs and that's not at the top (yet).  I already have a lot of it done but Arduino + 1-wire based and I want to use RPi for remote operation and to tie in with my KStars/Ekos/INDI setup.  The latter runs all my imaging kit including (shortly) all sky camera and motorised ROR control.  I have a working logger for weather data and a 3D printed Stevenson screen.  Wind instruments are practically done too.   ATM the logger only logs data to an SD card and I would like to run a live weather web site like I did some years ago.  All the various parts want linking together.

can you send me a copy of all that 😁😍😊🤞😜

Share this post


Link to post
Share on other sites

I probably have copies of the various Arduino sketches and of my modified INDI drivers.  Should also have circuit diagrams etc.  Most of it can be found on here in various threads and blogs.  I post pretty much everything I do on here.  No doubt I can find anything specific.

Share this post


Link to post
Share on other sites

I guessed you were 😄  Glad you find some of it useful :thumbsup:

Share this post


Link to post
Share on other sites
9 minutes ago, Gina said:

I guessed you were 😄  Glad you find some of it useful :thumbsup:

i love the way this forum helps everyone its just so lovely

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, Gina said:

 I want to use RPi for remote operation and to tie in with my KStars/Ekos/INDI setup.  The latter runs all my imaging kit

....

All the various parts want linking together.

That's about where I am too. I use 2 Rock64s for the gear with INDI/Ekos. Now with having ASTAP for platesolving, this has become very powerful (blind solve in 6 secs on a Rock64), and I don't have to use Kstars on my laptop anymore. I just RDP directly into one of the Rocks. But having the weather station and SQM wireless, frees up usb and allows me to run them standalone. The next step for me is to get the weather station working with the Ekos observatory module the way I want it. In the mean time I also have a 64GB emmc module incoming that hopefully is faster and more reliable than the microSD card. 

  • Like 1

Share this post


Link to post
Share on other sites
12 hours ago, wimvb said:

blind solve in 6 secs on a Rock64)

Really? - I dont get anyway near that using ASTAP  when "Blind" solving even on an I5 8gb 64bit SSD.

What do you mean by blind solving - e.g. so start 180 degree's for ra/dec coordinates with what FOV etc ?

Please share your parameters so all can benefit if possible 🙂 

Share this post


Link to post
Share on other sites

I loaded a fits image, and 6 secs later it hade a solution. I used standard settings in the indi simulator which is configured with my asi camera and skywatcher scope parameters. In all fairness, the target image wasn't very far from the park position of the scope, so that helped. I haven't tested it with my real mount and camera yet, so I don't know how it will perform in the field. Normally the solver won't need to do a blind solve, because it will use the scope position as a start in solving. 

Anyway, I'm satisfied with this feature. 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

I find plate-solving to be very quick when done locally.  I'm using the local astrometry implementation and it rarely takes more than a few seconds.  Obviously the field of view and general direction are known in that case though.

James

  • Like 1

Share this post


Link to post
Share on other sites

I timed it just now again, from parked position. I used a previous capture of the Sunflower galaxy. It solved it in 7 seconds, but at the same time ASTAP failed to do the refinement solution with the ccd simulator. My local astrometry on the Rock64 took 13 seconds to solve the image from ccd simulator. I need more clear nights ...

Share this post


Link to post
Share on other sites

Sorry hijacked your thread  - but when you said "blind solve" in 6 secs I had to ask 😲 🙂  Mine take a lot longer (blind solving that is ) while "local" or Mount supplied platesolving takes 6secs or less using ASTAP - using real set up ,no simulations in sight - which I am satisfied with.

But real blind solving - load  image (without a RA/DEC - e.g. RAW CR2) ,mount at home position and solve takes a lot lot longer with ASTAP. Hence I thought you had a secret method.

Thanks for the info 🙂

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By wimvb
      Just finished work on a sky quality meter with built in wifi. The device is based on the ambient light sensor TSL2591 and the wifi board ESP32. Communication between the two boards is through I2C. The device has a 40 degrees lens.
      The light sensor is programmable, which means you can set integration time (from 100 to 600 ms) and gain (from 1 to almost 5000, in 4 steps). I implemented automatic adjustment of these parameters to allow for the highest dynamic range (600M:1 accoring to the spec sheet).
      The device shows Sky readings as a web page. It is connected to a local wifi network, although it could also create its own access point. So far I haven't been able to calibrate the sqm yet, partly due to eternal cloud cover. But it should only require one parameter to be adjusted.
      The code is available on GitHub. Sky-Quality-Meter
      Here are som pictures.
      The components:

      The parts connected:

      The finished device:

      This is how output is presented:

    • By Waynescave
      Hi guys
      Can anyone identify which control box this is? Is it focusmaster? And does it run off robofocus driver in Indi lib as I cannot get a successful connection (in indi within ekos) 
      I bought a robofocus motor with this control box second hand. 
      I have faith with seller that hardware works as should. 
      I've tried other cables and USB ports too. The software (k stars) I use does do port search when connecting equipment.. 
       
      Any help appreciated 
      Wayne

    • By angryowl
      This will be a thread detailing some of the changes and additions I will be doing to my ASC/Weather Station project. This is version 2.0 as I'll be making some very big changes from the initial project and I think continuing on in the existing thread would not have made much sense.
      So, I still want to use an APS size sensor as after seeing the quality and light capturing capabilities of the now defunct Opticstar DS-616C XL camera and Meike lens I simply cannot go back to using a smaller lens/sensor combination. One thing is certain, I won't be paying £400 or potentially more for another APS astro sized camera so with that in mind I plan on heavily modifying a Nikon D50 DLSR and use the same lens. I chose the D50 primarily due to it having a CCD sensor (ICX453AQ) very close in specs to the one in the Opticstar (ICX413AQ) and the fact that I got a hold of a fully working body for £25.
      Now there's a few issues with going down the DSLR route which I plan on addressing as follows:
      The oversized camera body can be stripped down to bare essentials and fitted in the existing case with some moving of parts around Uncooled, the sensor is quite noisy so to cool it I plan on using the existing Opticstar enclosure with the TEC and hopefully get it purged with Argon to avoid dew formation. Also, since the box will need to be completely sealed to achieve this, there's simply not enough room inside for the main board to which the sensor connects to. The only way around this is using an 39pin 150mm long FPC extension which I managed to find and will be arriving shortly. This means I can have the sensor completely sealed with enough slack in the connection to place the mainboard anywhere I want. The D50 uses the NEF file extension as a "RAW" file format but it's not truly RAW and a heavy median filter is applied to all long exposure images to smooth out the noise. It works great for day to day shots, but in an application such as mine it'll most probably eliminate or severely affect my stars as most of them at the FL I'll be using the camera at will be a few pixels across and the Nikon median filter is very aggressive with such small features. The way around this is what's commonly known as Mode 3 on Nikons. Nikons have a additional Noise Reduction mode which takes the long exposure light first then straight after an equal length dark with the shutter closed, then applies the dark on the light and you get a further noise reduced image which again works very well, but not so much for AP. With mode 3 you essentially have the NR feature on and take an exposure but then immediately shut down the camera after the light has finished exposing. What this does is it causes the camera to dump a REAL RAW image onto the SD card without applying the median filter OR the Noise Reduction process. This obviously results in a much noisier image as expected, but all the stars will still be there and the image in this way can then be dark-subtracted and processed to my liking. I'll post some test shots I've taken to illustrate this. The D50 uses a hybrid shutter, both the CCD electronic shutter and mechanical shutter are used depending I think on the exposure length. If a high enough exposure is used, from what I understand, one can use exclusively the electronic shutter, but for longer exposures the shutters work in conjunction. Now I know the ICX413AQ in the Opticstar is more than capable of taking long exposures solely with its electronic shutter despite the fact that in its datasheet they recommend a mechanical shutter for proper use. So, my thinking is since the D50's sensor is similar to the ICX413AQ the only thing preventing the camera from being able to take any exposure using exclusively the electronic shutter is that its mechanical shutter is in the way and I don't think that the camera would prevent the CCD electronic global shutter itself to still open and close when required. However, this is all a theory at the moment and the only way to confirm it is to test the camera with the sensor outside when the FPC cable arrives. More on this later... In terms of capture software available, the D50 is actually very poor and I could only get digiCamControl to see and control the camera via USB. But I won't be using this as when the camera is hooked up to the PC its SD card is identified as a storage drive and the camera can be used as it would normally with the images appearing on the drive after being written to the SD! Since I'm using my VB app to process the images I would just point the app to that folder and should work. That's all I can think of for now but if and when new ones come up I'll add them here.
      Next I'll be describing some of the other changes planned.
    • By artoleus
      Hi,
      So, I have a minor setup issue for my automation setup.   Here is a brief overview of my setup:
      Raspberrypi on the scope connected to a powered usb hub.  Connected to the hub are a external wifi card (raspberry pi3 wifi is weak), an astromodified Canon 550D, a QHY5L-II for guiding and an EQ6 pro mount. The camera and QHY are connected to an OAG.  The QHY5 is also connected to the mounts ST4 port. 
      On the Rasperry Pi 3 I am running xubuntu with INDI server and PHD2 installed.  Using realvnc to view phd2.  indi server + webserver starts on boot,  static ip on external wifi card starts on boot. 
      On my laptop I have EKOS to connect to indi server and phd2 for guiding.  I am running phd2 on the raspberrypi to hopefully this will let PHD2 have a more direct (faster) connection to the guide camera.  
      My issue:
      Their appears to be a disabled install of ufw which has some groups under iptables.  I enabled the ufw and enbled the ports 4400, 7642 (PHD2), 8624 (indiweb), 7624(indi) however the guiding suite of Ekos would not connect to PHD2.  I disabled ufw and flushed the iptables and tried again with the above ports however the same result.  In the end I have opened all the ports to allow the connection to proceed, which is ok for short term but ideally I would want some security.  
      Does anyone know which ports I should open to get indi, indiweb and phd2 to talk nicely to my laptop EKOS version?  
      Anyone else running a similar setup successfully?  Can you give me any indications of what pitfalls to avoid?
      Thanks
       
    • By wimvb
      Imaging season is still a few weeks away up here, but I've started dusting of my gear and upgrading some parts.
      One step closer to automation is a motor focuser, and I opted for a budget solution. I bought a SkyWatcher DC focuser and built a computer control for it. Since I use INDI for my automation, I had to find a way to connect the focuser to indiserver. A first thought was to use the INDIduino code, but after some coding and testing I found out that this code is very limited and not really supported by indi clients. The Ekos/Kstars focus module can't be used for focus control if you use INDIduino, apparently.
      But then I stumbled upon an Arduino solution that emulates the MoonLite focuser (http://www.indilib.org/forum/general/283-moonlite-focuser-protocol.html). Unfortunately, this protocol is for a focuser with a stepper motor, whereas the SkyWatcher has a geared DC motor.
      I had already rewritten some code from stepper to (geared) DC motor, so it was easy to adapt this to the MoonLite based code.
      My solution consists of the following:
      hardware:
      - SkyWatcher DC focuser (only the motor is used, the handbox is replaced by the Arduino)
      - Arduino UNO
      - Velleman motor controller shield for Arduino
      - 9 V power adapter to power the shield
      - Raspberry Pi
       
      software:
      - Arduino sketch with Geared Motor library (see below for link)
      - INDI server on RPi, and client (Ekos/Kstars) on Windows
       
      I've tested this setup on my SkyWatcher Explorer 150PDS and it runs fine. Unfortunately I haven't been able to test the autofocus, due to absence of astrodarkness and clear skies.
      Since a DC focuser has no knowledge about the position of the actual focuser, the software assumes that position '0' is all the way in. Maximum position is 25000 for my setup. By default, focus is increased by 100 steps, which is supposed to be 100 ms of motor drive.

      BTW, the code is in my GitHub repository:
      https://github.com/wberlo/Arduino_Moonlite_Focuser
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.