I have been following the “Blueastro Stick Station, TEMPerHUM and stuff like this” thread and was wonder if a simple option could be added to the " Other Equipment Options " tab. An option that would let the TEMPerHUM Display Graphs page read and track the temp data from an ASCOM complaint focuser. It seem like nice option to keep things simple for us that want minimal equipment.
Or is minimal equipment and astrophotography a oxymoron?
Steve B
I think that they are adding just that capability to SGP via the new ASCOM Observing Conditions interface. I already have an ASCOM driver ready for that purpose, so the Stickstation would work right out of the box.
Any focuser with a driver for Observing Conditions could be displayed as well.
All the best,
Per
A focuser driver can expose a temperature that’s expected to be used for temperature compensation. This isn’t inherently an ObservingConditions (OC) temperature.
While there’s nothing that would fundamentally prevent someone implementing an OC driver using the same hardware as a focuser driver it isn’t the sort of thing I would expect to be done. It would make a simple focuser driver much more complex to implement and I’m not sure I can see what additional use the OC temperature would have. It’s unlikely to be representative of an environmental temperature.
Chris
Hello Chris and Per
I was thinking that since SGPro already is reading my focus temp data, displaying it in the Focus Tab, using it to set autofocus by temp change if slected, etc. and adding it to my FITs header, it could be used. I was thinking that a check box could be added in the “Other Equipment Option” that would let TEMPerHUM graph read the temp data and plot this data. I’m not a software guy. the last time I wrote a software routine it was in GW-Basic on a Vic-20. I was thinking that since the data is already being used by SGPro, a new drive would be needed.
It would be useful to some one like me that is looking for a simple way to plot the focus/temp time data of a f2.9, 12" Newt. Was not looking so much to use it a (OC) temperature.
Steve B
My thought was simply that if SGP will use the OC device and graph it, an OC driver for your focuser device (sharing the hardware with the focuser driver) will produce the graph you want. Simple as that 
/p
Pretty much true. This won’t make much sense to non-programmer types, but SGPro currently has an abstract class named “EnvironmentConditions”. The current TemperHum device implemented this class. The new ASCOM OC interface will do the same.
Ken & Per
I’m a “non-programmer type” that dose support, “$”, and use “programmer types” hard work, if it useful to me needs. Ken, you are right about not making much sense to me as know little about the black magic works behind the useful user interface that I interact with on my computer screen. Are you saying that the “abstract class named “EnvironmentConditions”” is a program or routine with in its self, and is embedded with in SGPro? If so, that make a bit of sense to me. So dose the “TEMPerHUM Display Graph” pole or pulls the data from the “EnvironmentConditions” routine? And this “EnvironmentConditions” routine needs a driver to interface with my SiTechFocuser program that I use if I want to have the “EnvironmentConditions” routine pole the temperature data from the SiTechFocuser temp sensor?
Trying to get a grasp in this…
Maybe I should just craw back under my rock and enjoy using SGPro with in my comfort zone…LOL
I will say that I have spent a quite a bit of “$” on astro software and SGPro, for me, is the cats meow and I’m in for the long haul.
So thanks for all the hard work that goes into SGPro and the quick responce/updates that are provided. Please keep up the hard work.
Steve B
Sorry for the reply here as I know this thread has gone beyond a “Feature Request”.
Well… without going into a lecture on polymorphic behavior of classes, we can probably just say that we have structure in place that makes it fairly easy to add new types of devices without the core logic inside SGPro caring much.
The comment above was more for @perfrej
Yep, Ken, I figured as much. The current driver from me is in-process DLL and contains no timers, but before Christmas there will be an equivalent local server based one along with a version of the Windows application that connects via ASCOM instead of directly to the stick. None of this makes any difference to your implementation.
/p