Homepage

Skybadger Observatory

Homepage

Building an SQM meter

Introduction

A Sky quality Meter (SQM) is the sensor that tells the observatory the state of the sky. It provides two values - the sky temperature and the sky brightness. The Sky brightness tells us how dark the sky is - typically for me it varies from 17 mags/square arc-sec at full moon to 21.0 on the rare darkest nights. The device also tells me the ambient temperature of the sensor, which is useful at night but less so during the day when insolation - heating of the box fro the sun, raises it well above what you might consider the real temperature. The skybrightness meter helps to corroborate the all sky camera in terms of telling us whether its cloudy or night since hte brightness increases when there is more cloud due to light pollution. The sky temperature reading gives a more direct reading of when its clear, since the sky temperature drops below zero, as far as -35, when there are no clouds in the sky due to that being the ambient temperature of the bulk of the atmosphere above the cloud layer. The sky temperature reading is also subject to interpretation. When my prevailing conditions apply:

  • it will be crystal clear at any temperature reading below -12.5 degrees C.
  • Somewhere between zero and 5-8 typically indicates thin haze
  • anything above that full cloud.
However when the wind turns round to come from the East, it can still be thick cloud down to -12 degrees. What I think this means is that the weather from the East is inherently colder than from the SW due to coming off the continent in winter (when this was observed) and so I need to check the wind directions to modify these clear sky conclusions. I also need to check the all sky camera but until I have coded some way of measuring the sky 'clearness' from the visual approach , the SQM remains the best way.

Putting this information together with the cloud image and the observing conditions data allows the Observatory automation tools to make decisions on whether to automatically open up and continue or whether the cloud is here to stay and pack up..
this happens because I have an Alpaca "Observing Conditions" driver measuring components like the SQM and temperature readings and mixing them with other environmental parameters to make an IsSafe decision which is exposed via the ASCOM Alpaca Safety driver.

Boith of these drivers are created, run and accessible through the NodeRed dashboard that allows manuial distance control fo the scope and dome over the web.

Building

The SQM consists of the common TLP4122 sensitive light sensor paired with the Melexis 9142 Infrared thermometer. The latter provides the ambient and sky temperature readings, while the first is a multi-range device that you can set the gain and collection time on. This is the family of devices used in the Unihedron SQM commercial device. Both of these sensor chips use the I2C two-wire bus to present their readings as slave devices to a master device. I implemented my standard pattern ESP8266/MQTT/web firmware pattern with the chip i2c interface talking to the above devices. The readings are sampled, averaged and reported to the MQTT messaging service and theb visualised by the MQTT listener at the Node-Red dashboard for all sensors. The hardware pattern is a fairly straightforward assembly of voltage regulator, ESP8266-01, i2c bus pullup resistors and the devices themselves. The light sensor is illuminated using a plastic LED torch lens used as a collector, available in different viewing angles, from ebay and elsewhere. The code provides a routine for the light sensor to control the gain and collection time to keep the values in the centre of the range. The sensor is franed by a led torch lens focuser to collect asmuch light as pssible from the sky and covers an effective field of about 30 degrees.

The device code is on Github in a public repository

Use

In use I have two ways of calibrating this device- directly by comparison agsint the SQM and also by comparison against imaged data. The ASTAP tool provides a means of applying pghotmoetry of stars to provide a measure of the backgroun brightness recorded in an image. Interestingly, while my meter typically records 0.3 Mag above the handlheld SQL, it also typically records at least 2.5 Mag fainter than the ASTAP results. The sense check comes in teh dform of the observed sky brightness. from my location I can clearly see the Milky way but not to the extent that it 'pops' out from an inky sky background. This aligns with the experience of a Mag 19-20 sky rather than a mag 17 one. Other factors apply I think in teh case of the ASTAP measurement and need to be investigated further.

Node Red Driver - Observing Conditions

.

	   
	   

Node Red Driver - Safety Driver

.

Integrating 'IsSafe' into Voyager for pausing observing sessions

.