Re: Weather/Cloud Watcher ASCOM standard
Its the first time I'm writing in ASCOM group, but I will give my
opinion of what I think the driver should look like as a 24 years old
programmer-analyst and amateur astronomer from Quebec, Canada ;)
The Weather Sensor Driver Variables should be something like ...
- isSafe (Boolean) = Is it safe to observe?
- isClear (Boolean) = Is it clear to observe?
- SensorType (String or Array?) = Sensor Type
- SensorDesc (String) = Sensor Description
- SensorValue (Double) = Sensor current Value
SensorType, i mean a string or an array to define what is sensor type,
- temperature == Temperature Sensor
- cloud == Cloud Sensor
- humidity == Humidity Sensor
- barometric == Barometric Sensor
- altitude == Altitude Sensor
... The value could be an array but I think that if in the future a
new sensor type need to be added its easier with a string than with a
fixed array :S
SensorDesc, this would be the sensor description, either defined by
driver maker of could be defined if allowed in driver setup to set a
description about driver, like 'External Temperature', 'Internal
Pressure Level', etc...
SensorValue (Double) could ...
- For temperature sensor, return current temperature in celcius (ex: 25.4)
- For humidity sensor, return current humidity level in percentage
- For cloud sensor, return current clouds level in percentage (ex: 3)
- For barometric sensor, return current pressure in kpa (ex: 33)
- For altitude sensor, return current altitude in meters (ex: 150)
According to me this is quite simple to implement and should works
with most sensors.
ScopServ International Inc.
--- In ASCOM-Talk@yahoogroups.com, "Tim Long" <Tim@...> wrote:
> I would personally be happy with enumerated states instead of Booleans,
> but there is some precedent already for the "Safe" Boolean and I think
> Booleans are more portable across different languages.
> > -----Original Message-----
> > From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com]
> > Behalf Of Robert
> > Sent: 01 December 2008 00:49
> > To: ASCOM-Talk@yahoogroups.com
> > Subject: Re: [ASCOM] Weather/Cloud Watcher ASCOM standard
> > This would be something to start with. I was reading the info and
> > thinking might need 3 states of operation. Safe, Pause, and Unsafe.
> > Safe being that sensors report all good conditions. Pause meaning some
> > state where we stop operations, and wait for conditions to improve.
> > Example passing clouds detected. The last is unsafe which would be wet
> > detection or overcast clouds where we stop and start alerting and
> > closing the dome.
> > Robert
> > --- In ASCOM-Talk@yahoogroups.com, Matt Thomas <matt_e_thomas@>
> > wrote:
> > >
> > > Tim,
> > >
> > > No chairs here.
> > >
> > > > However to my mind that doesn't quite cut the mustard. For
> > astronomy
> > > > use, I think there are two pieces of information required. First,
> > is it
> > > > safe to open to roof? Second, while the roof is open, can we see
> > the
> > > > target we're trying to acquire? In other words, I think we need
> > IsSafe
> > > > and IsClear (you can interpret "clear" in a flexible way, it could
> > mean
> > > > "the sky is clear", "the clarity is above some arbitrary
> > or
> > > > just "clear to observe"). Using these two properties alone I
> > suspect
> > > > would cover 80% to 90% of the use cases, we would be able to
> > determine
> > > > if it is safe to even open the roof and we'd have a way of pausing
> > an
> > > > observing session during transient events such as passing cloud
> > cover.
> > >
> > > I think this is perfect. Anything beyond this should be optional.
> > >
> > > IsClear and IsSafe conditions would be defined in the Setup dialog.
> > >
> > > One other optional parameter I think is necessary is one indicating
> > if
> > > any Emergency Contact is closed (the hardware connection between the
> > > weather monitor and the dome). While this is usually concurrent with
> > > IsSafe, it may not be in all conditions (IsSafe may be user defined
> > to
> > > be more restrictive than the Emergency Contact definition is). But,
> > > this would be optional.
> > >
> > > -Matt Thomas
> > > http://www.astromatt.com/
> > > CCD Commander: multi-target unattended imaging
> > > http://www.ccdcommander.com/
> > >
> > ------------------------------------
> > For more information see http://ASCOM-Standards.org/.
> > To unsubscribe from this group, send an email FROM THE ACCOUNT YOU
> > TO SUBSCRIBE(!) to:
> > ASCOM-Talkemail@example.com
> > Yahoo! Groups Links