Hi, I love SGP. The climate here is wet and cloudy, and SGP lets me squeeze every minute from the few clear nights we get.
I have successfully got the “environment” window to display the sky quality and temperature from my device. However, there’s not a lot else that can be done with these values.
Would it be feasible to add support to add environment values to the FITS header of captured images, and/or maybe to the filenames?
Not an important feature, but I’d certainly find it handy!
Yes, it would be quite trivial to do so. That said, SGPro collects and displays up to 14 environmental parameters. I cannot imagine all of them would be useful as headers. Which ones, specifically, are you interested in? Specifically, when reviewing them later, they should have some bearing on either processing, archival or how you would capture data in the future (feedback).
That’s a good point. I would probably only use “Sky Quality”. It would be helpful in establishing later why a particular exposure was good or bad compared to another.
@animaal, are you getting sky quality from a Unihedron Sky Quality Meter? If so, would you mind telling me how you got that to display in the environment window? I haven’t been successful at getting my SQM to display.
…Keith
Right… so I have added:
If anyone has other environmental params that would be of use, drop them here. Thx.
There’s a case for all of the ones in ObservingConditions. They were put in because there was a use case in astronomy for each one, either affecting the data, for safety reasons, or both.
RainRate is probably not needed, except for diagnostic purposes.
Wow, @Ken , thanks for adding support for storing these values in SGP. That’s really quick, and I look forward to trying it in a future beta.
@MicroAstro , I’ve had a go at writing my own ASCOM driver for the Unihedron SQMs that appear as serial ports. E.g. the SQM–LU or SQM-LR. This driver tracks sky quality and environmental temperature. I have no idea if it works with the Ethernet versions, and I have no way to try. If you’d like to be a guinea pig, send me a message!
@Chris , that makes sense. It sounds like the environmental values are potentially useful both stored along with the images,and as triggers to take remedial action.
Hi,
I’ve written an ASCOM driver for the Unihedron SQL devices that present themselves as COM ports. I.e. the SQL-LU, and probably the SQM-LU-DL and SQM-LR. I have no idea whether or not it works with the SQM-LE, but I would doubt it.
Two gentlemen from this forum have kindly tested it, and confirm that it works, at least with their setups.
If anybody would like to try it, it is available from:
http://www.dizzy.eu/downloads.html
Please note, although it passes the ASCOM compliance test suite, it has not been formally tested; all the more so for the installer. You install it at your own risk.
Regards,
Martin,
Hi Martin,
I tested your ASCOm driver. Many thanks for your work ! I’ve seen one point: When looking to the unihedron App I see the string
11,22 mpsas
as value, if I look to the ascot driver I get
1122,00/"^.
as string.
Do your have any idea ?
Michel
Hi Michel,
I’ve sent you a message 
Thanks,
Martin.
As stated above, I can confirm that the SQM driver referenced here does not work with the 'LE version.
Tom
Thanks Tom.
The LE version uses a very different communication mechanism. I don’t have one to test with, so I’m afraid I probably won’t be able to add support for it.
I now have an experimental version of this driver with SQM-LE support, although I really don’t know if it works. I don’t have a SQM-LE.
If somebody would like to try it, send me a PM.
Following feedback from a number of the contributors above, The SQM ASCOM driver has been updated to V2.0. New features include:
V2.0 can be downloaded from here:
http://www.dizzy.eu/downloads.html
Please ensure to uninstall any previous versions before installing this.
Any feedback is welcome.
Working fine here.
Thanks!
Little bug in displaying average period:
I guess what I dont understand here is that this value, as received by the sensor is stored and communicated in “hours” (by ASCOM). This is fine… it’s no problem to convert and display as minutes if that is what should be done (seems like this is the case), BUT, SGPro does not manipulate this value in any way. It literally asks ASCOM for the value and displays it as is with the units in hours (which is correct). I would expect, that if you set this period to 5 min, that the value SGPro receives would be around 0.083 hrs, but it receives a value of 5 which we have no choice but to interpret as hours.
Maybe it’s an ASCOM problem 
Hi, SQM driver developer here…
Experience tells me that when there’s a code problem it’s generally a safe assumption that the problem is mine, so I’ve had a look.
I don’t have access to SGP any more, so the info below is from looking at the source code and my own recollection.
The ASCOM ObservingConditions spec says that the “Average Period” field is in hour units. It’s an odd decision, but as Ken says above, not a problem to work with.
The SQM driver GETs and SETs this value when requested by ASCOM, without any conversion.
When the driver is queried for a sky quality value, it reads the value from the device, and if the Average Period setting is >0, it replaces the value read with an average of the values read over the past (Average Period) x 60 x 60 secs.
I’m not seeing an issue but it’s possible I’m just missing something.
Just checking the simplest possible explanation - perhaps the label on the Observing Conditions Hub configuration (in the screenshot provided by @drvo above) should say “hours” instead of “minutes”? If that was the case, then I think maybe everything would work as expected. Although the user needs to specify the period in hour units, which seems a little awkward. E.g. the user enters “0.5” hours, which gets stored in the driver as “0.5”. The sky quality values returned by the driver are averaged over 0.5 x 60 x 60 secs. When SGP queries the Average Period value to display it, the value “0.5” is returned.
Perhaps?