26 replies to this topic

[Mert]

Hi all,

 

Since I am always setting up my equipment either on my balcony or
when I go out to some dark site, I don't have a fixed setup.
When imaging the whole night, I wanted to have the ability to
switch off the equipment when ending the imaging session to

save battery.
For this I use a USB-switch board, and an Ascom driver I found
on internet that works with it.
So that gives me the option under advanced sequencer of NINA
to switch on/off some power outputs on my powerbox ( LifePo4
12V 100Ah  ).
When finished to wire that in and setup the sequences I would
like to be able to switch on/off some dewheaters when necesary.
So that led me to think about how to obtain the necesary
values for that into NINA.
The idea for a Weather Observing Conditions box plus driver
was born.
After quite some time working on the software side to write
an Ascom driver for it, right now I have the pleasure to be
able to automate my equipment almost completely and also

to have the option to obtain a logfile with all the measured

values from the whole session.
I have learned many things along this project and have had help
from very helpful people on the Ascom Developer group!
I am in the process of making a writeup for those who would
like to build something similar and will upload the Arduino
code and the Ascom driver to Github in case there is interest.

Not all of the functions of a Weather Observing Conditions
driver have been implemented because I use a mobile setup.
Therefore I left Wind, Rain, Cloudcover, Skybrightness and
Skytemperature out of it. ( I don't have a ROR observatory ).
Right now, it measures Temperature, Humidity, Dewpoint,
Atmosferic pressure, SQM and FWHM.

For the SQM value I still have to receive an UVIR filter to put

in front of the sensor but that will be very little effort.

Also still some problem when lower light levels then SQM19

are measured, busy with that.
The FWHM is under analisis and I will try to refine parameters
but for the moment it works nice using my Polemaster.
Here is a screenshot of what it measures for the moment.

 

Clear skies,
Mert

Attached Thumbnails

• 
• 

Edited by Mert, 03 April 2024 - 10:28 AM.

[PeteM]

Mert, this looks fantastic. Looking forward to seeing the writeup on it.

[Mert]

Thanks Pete, will certainly do that but first things first.
Right now it measures SQM values down to aprox 24 so that's more then enough.
Still have to calibrate the values, likely against ASTAP calculated SQM values.
Right now still a little flaw in the logging function of the driver that I have to address.

 

At the moment I use this setup when I image ( schematic ):

You can see the sensors wiring to the arduino nano and the

way I connect to my equipment.

 

 

 

Attached Thumbnails

• 

Edited by Mert, 04 April 2024 - 11:19 AM.

[Mert]

Here is my first "real" trial run, box mounted on a photo tripod looking at

the totally clouded sky through a window.

When the curve dips down to SQM 10 or alike is when I switched on the

lights.

 

Regards,

Mert

 

 

Attached Thumbnails

• 

[Arjan]

What's the SQM reading when you put the device in pitch darkness, like a box or so?

I have used a calibration factor to get it down to min detectable level at absolute dark. My sensor is not Taos, but AMS (now Osram), and has very high dynamic range: TSL2591.

I see AMS used to be Taos, hard to keep track of companies these days...

Edited by Arjan, 07 April 2024 - 09:51 AM.

[Mert]

What's the SQM reading when you put the device in pitch darkness, like a box or so?

I have used a calibration factor to get it down to min detectable level at absolute dark. My sensor is not Taos, but AMS (now Osram), and has very high dynamic range: TSL2591.

I see AMS used to be Taos, hard to keep track of companies these days...

Hi Arjan,

 

When I put the meter in a box in a dark room with tape over the lens, it

gives me a value of 22.37

It is still without calibration so at the moment it is just a relative value 

The sensor I use is a TSL237

I'm not sure which sensor would be more sensitive.

 

Regards,

Mert

[Mert]

For completeness here is a log of a complete night.

I still have to go out to some dark site and do calibration to

get more exact values.

This log is also with clouds in the sky looking through a window

towards the city. ( quite bright greyish sky, almost like my

flatpanel at low brightness ).

 

CS,

Mert

 

 

Attached Thumbnails

• 

[Mert]

Finally I had some relative clear night, now and then clouds rolling through.

So I setup themeter again and logged for the whole night from dusk to dawn.

Here you see the way I put the meter looking at the sky through a double glass

window.

Not optimal to do so but anyway, it is still not calibrated so precision right now

is not so important for me.

I configured to take a sample every 60 seconds.

 

Regards,

Mert

 

 

Attached Thumbnails

• 
• 

Edited by Mert, 10 April 2024 - 07:21 AM.

[Mert]

Last night I left the equipment setup on the balcony and tried to do

some imaging meanwhile logging data.

On the minipc that controls the scope I had some weird USB item

that made me reboot it to get started again.

Moon was 83% lit so quit a bright sky.

I still have to calibrate the FWHM values a bit better. ( will

use Meteoblue predictions etc. )

There were a few clouds passing by during the night.

 

 

Attached Thumbnails

• 

[Mert]

Yesterday I did some calibration on the FWHM measurements and got a

reasonable result compared with Meteoblue.

Of course the seeing from my balcony is not the same as when I

setup in the field ( in the same village ).

 

Here is a graph from the logfile over some 163 samples.

Values are in arcseconds.

 

 

 

Attached Thumbnails

• 

[Mert]

After some days recovering from surgery I setup inside to monitor

the totally clouded sky.

At some moment there was a gap in the clouds as you can see in

the zoomed graph.

Hope to finish-up the software and upload to github in order to

share with anyone willing to build this as well.

( Anyone willing to improve the software also welcome, since this

is open software, will upload the source code as well. )

 

CS,

Mert

Attached Thumbnails

• 

Edited by Mert, 06 May 2024 - 07:25 AM.

[lambermo]

Hi Mert,

It is still without calibration so at the moment it is just a relative value 
The sensor I use is a TSL237

I have one in operation since 2015 and it started without needing an offset at all when using this formula: 22 - 2.5*log10(freq)
Which I verified with the standard Unihedron SQM-L which I use for mobile applications.
I verified correctness thoughout the years but around 2022 I needed to add an offset.
Maybe it is time to simply replace the sensor ;-)

-- Hans

[lambermo]

Also: I see you're not using the 'standard' Melexis MLX90614-BAA infrared thermometer to determine cloud coverage. Any special reason for that ?

[Mert]

Hi Mert,


I have one in operation since 2015 and it started without needing an offset at all when using this formula: 22 - 2.5*log10(freq)
Which I verified with the standard Unihedron SQM-L which I use for mobile applications.
I verified correctness thoughout the years but around 2022 I needed to add an offset.
Maybe it is time to simply replace the sensor ;-)

-- Hans

Hi Hans,

 

Thanks for your feedback!

I used the same formula to start with but then wanted to correct against ASTAP

since I don't have an Unihedron meter to calibrate against.

When it get's under really dark skies the time of measurement gets very long

so I modified the routine a bit to keep the readout time limited!

 

Regards,

Mert

Edited by Mert, 08 May 2024 - 05:17 AM.

[Mert]

Also: I see you're not using the 'standard' Melexis MLX90614-BAA infrared thermometer to determine cloud coverage. Any special reason for that ?

No special reason at all but since I only use a mobile setup, typically

when clouded ( or partially ) I don't setup.

In my particular use case I don't find it very useful for me.

Evenso, it is very simple to implement, the ASCOM driver is prepared for it so you only

have to add a couple of lines to the code and done with that if needed.

 

--Mert

Edited by Mert, 08 May 2024 - 05:18 AM.

[Mert]

For those of you who might have interest to setup something similar

here is a link to my Github of this project : https://github.com/M...757/NANO-ObsCon

Any improvements or optimizations are more then welcome.

The source code and Arduino code are available for download as well as a 

Windows installer for the Ascom driver.

 

Regards,

Mert

Edited by Mert, 08 May 2024 - 06:51 AM.

[Jim in PA]

Thank you Mert!  This is a great project for me as I've been thinking about setting up the AT60 for some automated DSO this season.

 

I would imagine that your modelling of the TSL237 might be good enough as is.  Did you have to change anything?  My SQM-L has the Hoya 500CM filter on it, so I would think that the TSL237 set up with a similar filter to your astrocam will be closer to ASTAP than the SQM-L.  Thinking with just an IR/UV filter it would be closer since the Hoya filter on the SQM-L is less sensitive to red, but I doubt there would be more than ~0.3mpsas difference regardless.

Edited by Jim in PA, 08 May 2024 - 07:24 AM.

[Mert]

You're welcome Jim, happy to share!
I hope to read how it works for you.
(I finally put a UVIR filter in front of the TSL237.)

Regards,
Mert

[Mert]

If you need or like to add some sensor, have a look at the arduino code, easy to implement.
Then of course you need to edit the Ascom driver and recompile, fun to do.
IMHO the Ascom code is easy to follow and modify to your needs.
For me this was the most interesting part of the project.
If you need some help with it, please feel free to ask!

CS,
Mert

Edited by Mert, 10 May 2024 - 05:27 AM.

[Mert]

Just a little update, I added the Skybrightness in lx to the driver.

It uses a cuadratic aproximation of the SQM value measured.

When the Skybrightness is queried it calculates it's value

based on the last SQM value.

Will upload the modified source code and the installer to Github.

 

CS,

Mert

[Mert]

Almost a straight line, logging SQM against Skybrightness values.

Still some math to do.

 

 

Attached Thumbnails

• 

[Mert]

Ok, right now I finished polishing some firmware ( Arduino ) and tested

down to SQM 22 value ( device in dark box ).

I also changed the formula to derive an estimated Brightness value from

the measured SQM to a polinomial of the third degree.

All set to test in the field ( whenever that will be ).

For those of you who would like to build this device I uploaded the latest

Arduino sketch and source code plus an Ascom-installer

to my github. ( https://github.com/M...757/NANO-ObsCon )

In the image below you can see there are no FWHM values since I was inside

testing.

 

CS,

Mert

Attached Thumbnails

• 

Edited by Mert, 20 June 2024 - 11:19 AM.

[Mert]

And finally a full night's log, from late afternoon to early in the morning, just with the

device looking outside.

The night was very cloudy and full moon, so that was not optimal but anyways.

Here you see side by side a plot of SQM versus Skybrightness ( Lx ) and a simple

SQM value plot.

Data obtained from the logfile.

 

CS,

Mert

 

 

Attached Thumbnails

• 

[Mert]

As per feedback from sharkmelley I made a correction for the calculation
of Skybrightness by measured SQM values.
Herewith a new log run with the corrected formula for the calculation:

CS,
Mert

Attached Thumbnails

• 

Edited by Mert, 23 June 2024 - 10:06 AM.

[GlennLeDrew]

I would have thought the focal length of a Polemaster objective to be far too short to derive a FWHM value, the image being much too undersampled.