Gday Mark

--- In ASCOM-Talk@yahoogroups.com, "mark301066" <theashleys@...> wrote:
>
> Hi Andrew
>
> Well I'm stupid, blind or both.

Nup. I have been working on an extended peek patch and my app was set
to use that. You have the std peek loaded, hence for a 497 Hbx, the
tab wasnt appearing. My goof
I have put a new exe up on my site Beta3001.
I tested this for use with the old peek and it appears to work,
so grab that and try again. It shld work this time.

>I think I've looked everywhere to no avail.

As per above, sorry bout that
It actually appears at the "connect to scope" prompt
but disappears when the peek parameters get read.

> Not to waste the time I exported something called misc data.

Thats useful but doesn't help here.
Its the 512bytes of EEProm used to store "permanent" settings.
We need to grab the working memory data for this test.

> I did try to filter as per dick's instructions but
> couldn't even get that to work!!

That bits easy.
Looking at yr logs you could use
*IRP_MJ*  in the Include filter prompt
( include the wildcard chars at each end )
Tick both Log Reads and Log Writes checkboxes
After that, you shld get a cleaner log

> Let me know if I'm being stupid!! :-)

Nup, just the fun of debugging by email.
Sometimes what i see isnt what you see.

Andrew Johansen Melbourne Australia

>
> CHeers
> Mark
>
> --- In ASCOM-Talk@yahoogroups.com, "johansea" <johansea@> wrote:
> >
> > Oops, one correction ( too many Autostar versions in my head )
> >
> > > You have Quiet mode selected, but POTH has requested LST ( :GS# ) in
> > > two of yr three logs????
> > > POTH Connect requested the local day/time/LST/TZ hence almost had
> > > enough data to do a valid calc
> > > ( it needs to get DST as :GG lies in a 497 Autostar )
> >
> > :GG works as advertised for the current 497 firmware,
> > its the ASII that is wrong
> > Thus POTH shld have enough info to do a proper local then LST compare.
> >
> > Andrew Johansen Melbourne Australia
> >
>

Boolean IsSafe             // Required, read-only
Boolean CanIsClear         // Required, read-only
Boolean IsClear            // Optional, read-only
Boolean CanEmergencyClose  // Required, read-only
Boolean EmergencyClose     // Optional, read-only
Boolean Connected          // Required, read-write
void SetupDialog(void)     // Required


-Matt Thomas
http://www.astromatt.com/
CCD Commander: multi-target unattended imaging
http://www.ccdcommander.com/

Sounds pretty good. I'd clarify that the setup dialog ought to have the
ability to enable or disable the emergency close feature if it's available.
That is, if it isn't being used, CanEmergencyClose should return false.
Otherwise the app may get confused because the relay is closed but nothing
is happening behind the scenes.

Also, I think there might be some merit in IsClear returning an integer,
perhaps a 0-10 scale. Some simple devices, like cloud detectors, provide a
degree of analog response. An application might be able to make good use of
a trend in this value, but could still just treat it as a boolean-like value
if desired. Another possibility would be an optional property Clearness that
returns a scale, and the setup dialog would provide an opportunity to define
the Clearness threshold that toggles IsClear.

Chris

*****************************************
Chris L Peterson
Cloudbait Observatory
http://www.cloudbait.com


----- Original Message -----
From: "Matt Thomas" <matt_e_thomas@...>
To: <ASCOM-Talk@yahoogroups.com>
Sent: Monday, December 01, 2008 2:18 PM
Subject: [ASCOM] Safety Monitor ASCOM Proposal


> Boolean IsSafe             // Required, read-only
> Boolean CanIsClear         // Required, read-only
> Boolean IsClear            // Optional, read-only
> Boolean CanEmergencyClose  // Required, read-only
> Boolean EmergencyClose     // Optional, read-only
> Boolean Connected          // Required, read-write
> void SetupDialog(void)     // Required
>
>
> -Matt Thomas

I'm going to stay away from the "Sensor" definition. I think there
could be a "Sensor ASCOM Specification" that can handle the sensor
side of things if there is a need.

This separation allows a few things.

1. A device can implement both the "Safety Monitor" and the "Sensor"
interfaces - but the burden is not there to support the more
complicated "Sensor" interface.

2. A "Safety Monitor" driver could be written that connects to
multiple different "Sensor" drivers - combining the output into a
single "Safety Monitor" interface.

3. An application can take input from multiple "Safety Monitors".

-Matt Thomas
http://www.astromatt.com/
CCD Commander: multi-target unattended imaging
http://www.ccdcommander.com/

Monday, December 1, 2008, 1:33:01 PM, Chris wrote:
> Sounds pretty good. I'd clarify that the setup dialog ought to have the
> ability to enable or disable the emergency close feature if it's available.
> That is, if it isn't being used, CanEmergencyClose should return false.
> Otherwise the app may get confused because the relay is closed but nothing
> is happening behind the scenes.

Agreed.

> if desired. Another possibility would be an optional property Clearness that
> returns a scale, and the setup dialog would provide an opportunity to define
> the Clearness threshold that toggles IsClear.

I like this better. However, I was leaning toward using:

Boolean IsQuestionable

instead of IsClear. The thought here being that I'm trying to abstract
the spec away from just Weather Monitor devices. Something like a line
voltage monitor or battery indicator like Doug brought up. But I
didn't like "IsQuestionable" enough to use it.

-Matt Thomas
http://www.astromatt.com/
CCD Commander: multi-target unattended imaging
http://www.ccdcommander.com/

Where did EmergencyClose come from and how is that different to "Not
Safe"? How would the application respond any differently? And why do we
need a Can property for it (if a driver doesn't support that, then it
will never be true, right?).

--Tim

> -----Original Message-----
> From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com]
On
> Behalf Of Matt Thomas
> Sent: 01 December 2008 21:18
> To: ASCOM-Talk@yahoogroups.com
> Subject: [ASCOM] Safety Monitor ASCOM Proposal
>
> Boolean IsSafe             // Required, read-only
> Boolean CanIsClear         // Required, read-only
> Boolean IsClear            // Optional, read-only
> Boolean CanEmergencyClose  // Required, read-only
> Boolean EmergencyClose     // Optional, read-only
> Boolean Connected          // Required, read-write
> void SetupDialog(void)     // Required
>
>
> -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
USED
> TO SUBSCRIBE(!) to:
> ASCOM-Talk-unsubscribe@yahoogroups.com
>
> Yahoo! Groups Links
>
>
>

> Also, I think there might be some merit in IsClear returning an
> integer,
> perhaps a 0-10 scale.

I disagree with that. That is just sensor data by the back door. The
application really just needs to know whether it is OK to observe or
not.

--Tim

> I like this better. However, I was leaning toward using:
>
> Boolean IsQuestionable
>
> instead of IsClear. The thought here being that I'm trying to abstract
> the spec away from just Weather Monitor devices. Something like a line
> voltage monitor or battery indicator like Doug brought up. But I
> didn't like "IsQuestionable" enough to use it.


Echoing Tim's post - how would the app use this?

Either it's good to observe, or it isn't.

This doesn't give the app enough info to make an informed decision, so
presumably it's either always going to treat this as either
IsSafe==True or IsSafe==False.

I can see that the distinction between IsClear and IsSafe could be
useful - for the app seeing IsClear==False it may just stop taking
exposures (which is quick to recover from), but IsSafe==False shuts
the obs down (which takes a lot longer to recover from).

A few months back I wrote a simple cloud detector driver and app
(using a shared text file to communicate over the network) where the
app is a simple GUI and alarm and the driver talks to an IR thermometer.
I could certainly see the simplicity and benefit of putting an ASCOM
bottom end onto the alarm app, on top of an ASCOM driver which reads
the text file.

John

EmergencyClose lets the application know that a backdoor hardware mechanism
has happened that did something like closing the dome or shutting down part
of the system. An example would be the emergency relay on the Boltwood.
Without a mechanism for providing such notice, you get into the difficulty
Bob Denny referred to in his earlier post. In general, any ASCOM supported
device type that can potentially affect other devices without software
intervention ought to have a comparable property.

My suggestion of including a Clearness property was also partly in response
to Bob's comment about the desirability of a sky condition value. It isn't
so much a sensor signal as user programmable indicator that could be set by
any combination of sensor signals. For instance, I can easily imagine a
driver that interfaces to both a seeing monitor and an allsky camera, and
provides a Clearness signal that the imaging app can use to determine if a
particular target should be processed, or if a session should be suspended.

Chris

*****************************************
Chris L Peterson
Cloudbait Observatory
http://www.cloudbait.com


----- Original Message -----
From: "Tim Long" <Tim@...>
To: <ASCOM-Talk@yahoogroups.com>
Sent: Monday, December 01, 2008 7:25 PM
Subject: RE: [ASCOM] Safety Monitor ASCOM Proposal


> Where did EmergencyClose come from and how is that different to "Not
> Safe"? How would the application respond any differently? And why do we
> need a Can property for it (if a driver doesn't support that, then it
> will never be true, right?).
>
> --Tim

> Either it's good to observe, or it isn't.

Wow, that sure isn't the case with my observing program. My choice of what
to image, and where to image, depends heavily on sky conditions. Some
observations are seeing limited, some observations are Moon limited, some
observations are transparency limited.

In particular, a sophisticated session controller like ACP could make
extremely good use of a Clearness (IsQuestionable) property, as it would
provide a mechanism to automatically change to a more appropriate target
based on conditions (something ACP already can do based on position). The
property would be optional because only certain types of sensing devices
would be capable of generating it.

Chris

*****************************************
Chris L Peterson
Cloudbait Observatory
http://www.cloudbait.com


----- Original Message -----
From: "John Winfield" <winfij@...>
To: <ASCOM-Talk@yahoogroups.com>
Sent: Monday, December 01, 2008 8:14 PM
Subject: Re: [ASCOM] Safety Monitor ASCOM Proposal


>> I like this better. However, I was leaning toward using:
>>
>> Boolean IsQuestionable
>>
>> instead of IsClear. The thought here being that I'm trying to abstract
>> the spec away from just Weather Monitor devices. Something like a line
>> voltage monitor or battery indicator like Doug brought up. But I
>> didn't like "IsQuestionable" enough to use it.
>
>
> Echoing Tim's post - how would the app use this?
>
> Either it's good to observe, or it isn't.
>
> This doesn't give the app enough info to make an informed decision, so
> presumably it's either always going to treat this as either
> IsSafe==True or IsSafe==False.
>
> I can see that the distinction between IsClear and IsSafe could be
> useful - for the app seeing IsClear==False it may just stop taking
> exposures (which is quick to recover from), but IsSafe==False shuts
> the obs down (which takes a lot longer to recover from).
>
> A few months back I wrote a simple cloud detector driver and app
> (using a shared text file to communicate over the network) where the
> app is a simple GUI and alarm and the driver talks to an IR thermometer.
> I could certainly see the simplicity and benefit of putting an ASCOM
> bottom end onto the alarm app, on top of an ASCOM driver which reads
> the text file.
>
> John

 I'm new here and I'm having a problem opening the platform. after I download it I can't run it. it says make sure you have access to that file. I don't know enough about computers to know what else to do. it has to be something with my computer because it opens and runs on the office computer. we are both running XP. Thanks for any Help
Andy

Tim,

I asked for it and then Bob asked for it (maybe you missed them) - so
I included it. I think Chris described it well enough not to repeat...

As for the CanXXX or not, I'm indifferent. Just trying to follow
convention.

-Matt Thomas
http://www.astromatt.com/
CCD Commander: multi-target unattended imaging
http://www.ccdcommander.com/

Monday, December 1, 2008, 6:25:12 PM, Tim wrote:

> Where did EmergencyClose come from and how is that different to "Not
> Safe"? How would the application respond any differently? And why do we
> need a Can property for it (if a driver doesn't support that, then it
> will never be true, right?).

> --Tim

>> -----Original Message-----
>> From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com]
> On
>> Behalf Of Matt Thomas
>> Sent: 01 December 2008 21:18
>> To: ASCOM-Talk@yahoogroups.com
>> Subject: [ASCOM] Safety Monitor ASCOM Proposal
>>
>> Boolean IsSafe             // Required, read-only
>> Boolean CanIsClear         // Required, read-only
>> Boolean IsClear            // Optional, read-only
>> Boolean CanEmergencyClose  // Required, read-only
>> Boolean EmergencyClose     // Optional, read-only
>> Boolean Connected          // Required, read-write
>> void SetupDialog(void)     // Required
>>
>>
>> -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
> USED
>> TO SUBSCRIBE(!) to:
>> ASCOM-Talk-unsubscribe@yahoogroups.com
>>
>> Yahoo! Groups Links
>>
>>
>>

John,

>> Boolean IsQuestionable
> Echoing Tim's post - how would the app use this?

You've described the exact reason for the IsQuestionable property. But
I think you've missed the reason for it.

IsClear is specific to a Cloud Monitor. I'm trying to abstract this
specification away from a Cloud Monitor to any kind of safety
monitoring device. IsClear does not abstract well - it is too
specific.

IsQuestionable for a Cloud Monitoring device will simply be the
inverse of what IsClear was.

-Matt Thomas
http://www.astromatt.com/
CCD Commander: multi-target unattended imaging
http://www.ccdcommander.com/

Monday, December 1, 2008, 7:14:34 PM, John wrote:

>> I like this better. However, I was leaning toward using:
>>
>>
>> instead of IsClear. The thought here being that I'm trying to abstract
>> the spec away from just Weather Monitor devices. Something like a line
>> voltage monitor or battery indicator like Doug brought up. But I
>> didn't like "IsQuestionable" enough to use it.



> Either it's good to observe, or it isn't.

> This doesn't give the app enough info to make an informed decision, so
> presumably it's either always going to treat this as either
> IsSafe==True or IsSafe==False.

> I can see that the distinction between IsClear and IsSafe could be
> useful - for the app seeing IsClear==False it may just stop taking
> exposures (which is quick to recover from), but IsSafe==False shuts
> the obs down (which takes a lot longer to recover from).

> A few months back I wrote a simple cloud detector driver and app
> (using a shared text file to communicate over the network) where the
> app is a simple GUI and alarm and the driver talks to an IR thermometer.
> I could certainly see the simplicity and benefit of putting an ASCOM
> bottom end onto the alarm app, on top of an ASCOM driver which reads
> the text file.

> John

Ok, v2 with descriptions:

Boolean IsSafe
   // Required, read-only
   // True when the Safety Monitor has determined that conditions are safe
   // to operate.  False when unsafe conditions exist.

Boolean CanIsGood
   // Required, read-only
   // True when the driver implements the IsGood property

Boolean IsGood
   // Optional, read-only
   // True when the Safety Monitor has determined that conditions are
   // "good" (driver/user defined).  Good conditions are always Safe.
   // Not Good conditions can be Safe.

Boolean CanEmergencyShutdown
   // Required, read-only
   // True when the driver implements the IsEmergencyShutdown property
   // This must be set false if the safety monitor cannot perform an
   // autonomous emergency shutdown either by lack of ability or lack
   // of proper connections.

Boolean EmergencyShutdown
   // Optional, read-only
   // True when the Safety Monitor has performed an Emergency Shutdown
   // autonomously from the PC due to an unsafe condition.  This value
   // must remain true until the emergency shutdown is no longer being
   // forced upon the observatory hardware.

I'm leaving out the ASCOM generic stuff this time...

I've changed IsClear to IsGood and abandoned IsQuestionable.

-Matt Thomas
http://www.astromatt.com/
CCD Commander: multi-target unattended imaging
http://www.ccdcommander.com/

Monday, December 1, 2008, 1:18:17 PM, Matt wrote:

> Boolean Connected          // Required, read-write
> void SetupDialog(void)     // Required


> -Matt Thomas
> http://www.astromatt.com/
> CCD Commander: multi-target unattended imaging
> http://www.ccdcommander.com/

--- In ASCOM-Talk@yahoogroups.com, "Chris Peterson" <cpeterson@...> wrote:
>
> > Either it's good to observe, or it isn't.
>
> Wow, that sure isn't the case with my observing program. My choice
of what
> to image, and where to image, depends heavily on sky conditions. Some
> observations are seeing limited, some observations are Moon limited,
some
> observations are transparency limited.
>
> In particular, a sophisticated session controller like ACP could make
> extremely good use of a Clearness (IsQuestionable) property, as it
would
> provide a mechanism to automatically change to a more appropriate
target
> based on conditions (something ACP already can do based on
position). The
> property would be optional because only certain types of sensing
devices
> would be capable of generating it.


How would you be able to do that if the mechanics behind the
IsQuestionalble property are opaque - possibly built up from things
like the state of an on-site backup battery?
You wouldn't know whether things were questionable solely due to sky
conditions.

Hence my suggestion (later in the same post) that IsClear would be a
more useful property, since it's somewhat less vague.

John

> Hence my suggestion (later in the same post) that IsClear would be a
> more useful property, since it's somewhat less vague.

Indeed. While I have no issue with IsQuestionable or IsGood, I do think the
more useful property is Clearness (an analog complement to IsClear),
specifically providing a scale of seeing conditions. Just what those
conditions are would depend on the available sensors the driver has access
to, and any possible configuration setting the driver provides.

Chris

*****************************************
Chris L Peterson
Cloudbait Observatory
http://www.cloudbait.com


----- Original Message -----
From: "John Winfield" <winfij@...>
To: <ASCOM-Talk@yahoogroups.com>
Sent: Monday, December 01, 2008 9:34 PM
Subject: Re: [ASCOM] Safety Monitor ASCOM Proposal


> How would you be able to do that if the mechanics behind the
> IsQuestionalble property are opaque - possibly built up from things
> like the state of an on-site backup battery?
> You wouldn't know whether things were questionable solely due to sky
> conditions.
>
> Hence my suggestion (later in the same post) that IsClear would be a
> more useful property, since it's somewhat less vague.
>
> John

> IsClear is specific to a Cloud Monitor. I'm trying to abstract this
> specification away from a Cloud Monitor to any kind of safety
> monitoring device. IsClear does not abstract well - it is too
> specific.
>
> IsQuestionable for a Cloud Monitoring device will simply be the
> inverse of what IsClear was.


Just to rephrase my other reply, I still don't get how an app writer
would know what to do with such an abstract term.

Although you cite the limited scope of IsClear as a negative, I see it
as a positive, in that the response of the app can be more meaningful
since it has more of an idea of the context of the property value.

It knows it pertains to the sky conditions, rather than any one of a
number of options the driver writer may factor in, non of which may be
relevant to the decision the app is trying to make.

If we're saying that IsQuestionable has a concrete meaning (within the
constraints of the sensors available to the driver author), then
it makes more sense to me.
e.g. If we were to define it as indicating questionable (suboptimal)
sky conditions, based on whatever metrics the sensor package provides.

You mention "any kind of safety monitoring device" which I guess
includes things like the aforementioned battery monitor, but wouldn't
that factor in to the IsSafe property - either it's at a level where
it's safe to continue and get a safe shutdown on losing power, or it
isn't.

Perhaps if you could give an example of what you're thinking of, it'd
be clearer to me?

John

Sorry to drone on, but it would make more sense to me if it read
something more concrete like:

Boolean IsGoodWeather
   // Optional, read-only
   // True when the Safety Monitor has determined that weather
   // conditions are "good" (driver/user defined).  Good
   // weather conditions are always Safe.
   // Not Good weather conditions can be Safe.


This allows the driver author to use whatever sensors are available to
determine whether the weather conditions are "good"

Maybe someone could give an app usage example of the more abstract
form? What would factor in to being "good" and what would an app do
with that knowledge?



--- In ASCOM-Talk@yahoogroups.com, Matt Thomas <matt_e_thomas@...> wrote:
>
> Ok, v2 with descriptions:
>
> Boolean IsSafe
>   // Required, read-only
>   // True when the Safety Monitor has determined that conditions are
safe
>   // to operate.  False when unsafe conditions exist.
>
> Boolean CanIsGood
>   // Required, read-only
>   // True when the driver implements the IsGood property
>
> Boolean IsGood
>   // Optional, read-only
>   // True when the Safety Monitor has determined that conditions are
>   // "good" (driver/user defined).  Good conditions are always Safe.
>   // Not Good conditions can be Safe.
>
> Boolean CanEmergencyShutdown
>   // Required, read-only
>   // True when the driver implements the IsEmergencyShutdown property
>   // This must be set false if the safety monitor cannot perform an
>   // autonomous emergency shutdown either by lack of ability or lack
>   // of proper connections.
>
> Boolean EmergencyShutdown
>   // Optional, read-only
>   // True when the Safety Monitor has performed an Emergency Shutdown
>   // autonomously from the PC due to an unsafe condition.  This value
>   // must remain true until the emergency shutdown is no longer being
>   // forced upon the observatory hardware.
>
> I'm leaving out the ASCOM generic stuff this time...
>
> I've changed IsClear to IsGood and abandoned IsQuestionable.
>
> -Matt Thomas
> http://www.astromatt.com/
> CCD Commander: multi-target unattended imaging
> http://www.ccdcommander.com/
>
> Monday, December 1, 2008, 1:18:17 PM, Matt wrote:
>
> > Boolean Connected          // Required, read-write
> > void SetupDialog(void)     // Required
>
>
> > -Matt Thomas
> > http://www.astromatt.com/
> > CCD Commander: multi-target unattended imaging
> > http://www.ccdcommander.com/
>

> Sorry to drone on, but it would make more sense to me if it read
> something more concrete like:
>
> Boolean IsGoodWeather

My reading is this is exactly what IsClear does, with a different property
name.

> Maybe someone could give an app usage example of the more abstract
> form? What would factor in to being "good" and what would an app do
> with that knowledge?

Do you mean the analog, rather than boolean form (what I called Clearness)?
I envision an app that accepts a command sequence (like ACP) to allow a
quality value to be assigned to each target in the list. If the Clearness
falls below the quality target, the app suspends or terminates imaging that
target and moves to the next target with a quality factor still less than
the Clearness value. If I understand Bob, this is exactly what ACP does
already. Clearness just provides an ASCOM defined mechanism to get this
information into the process flow.

An example would be a driver that uses an allsky camera or allsky bolometer
to determine transparency. The analog output would be mapped to the
Clearness value. This is probably the most common and easiest to generate
and for a typical imager to make use of.

Chris

*****************************************
Chris L Peterson
Cloudbait Observatory
http://www.cloudbait.com


----- Original Message -----
From: "John Winfield" <winfij@...>
To: <ASCOM-Talk@yahoogroups.com>
Sent: Monday, December 01, 2008 9:55 PM
Subject: [ASCOM] Re: Safety Monitor ASCOM Proposal v2


> Sorry to drone on, but it would make more sense to me if it read
> something more concrete like:
>
> Boolean IsGoodWeather
>  // Optional, read-only
>  // True when the Safety Monitor has determined that weather
>  // conditions are "good" (driver/user defined).  Good
>  // weather conditions are always Safe.
>  // Not Good weather conditions can be Safe.
>
>
> This allows the driver author to use whatever sensors are available to
> determine whether the weather conditions are "good"
>
> Maybe someone could give an app usage example of the more abstract
> form? What would factor in to being "good" and what would an app do
> with that knowledge?

> I'm going to stay away from the "Sensor" definition. I think there
> could be a "Sensor ASCOM Specification" that can handle the sensor
> side of things if there is a need.


That looks like a good summary Matt - it'd be great to be able to do
things like configure an imaging app to be able to take a number of
sensor readings from standard ASCOM sensor drivers after an exposure
and store them in configurable FITS header keywords, for later analysis.
No need for the app writer to have to worry about what sensors they
support.

John

> Do you mean the analog, rather than boolean form (what I called
Clearness)?

No, I meant the abstract "IsGood" (aka IsQuestionable).

I see the use of an analog Clarity rating, I guess it just comes down
to now complex we want to make the v1 interface.

Where does one draw the line - one could equally add an optional
Seeing rating, for example.

John

It isn't clear to me, either, how an app would use this information.

Chris

*****************************************
Chris L Peterson
Cloudbait Observatory
http://www.cloudbait.com


----- Original Message -----
From: "John Winfield" <winfij@...>
To: <ASCOM-Talk@yahoogroups.com>
Sent: Monday, December 01, 2008 10:15 PM
Subject: [ASCOM] Re: Safety Monitor ASCOM Proposal v2


>> Do you mean the analog, rather than boolean form (what I called
> Clearness)?
>
> No, I meant the abstract "IsGood" (aka IsQuestionable).
>
> I see the use of an analog Clarity rating, I guess it just comes down
> to now complex we want to make the v1 interface.
>
> Where does one draw the line - one could equally add an optional
> Seeing rating, for example.
>
> John

> You mention "any kind of safety monitoring device" which I guess
> includes things like the aforementioned battery monitor, but wouldn't
> that factor in to the IsSafe property - either it's at a level where
> it's safe to continue and get a safe shutdown on losing power, or it
> isn't.

No, a battery monitor wouldn't use the "Questionable" or "Good" value.
No meaning there.

But a line voltage monitor could. A low or high voltage that is still
safe, but that could cause unwanted effects may be not-good or
questionable.

Maybe an anemometer can be setup to issue a not-good condition when
the wind goes above 20 knots, but this is still safe.

Maybe a temperature monitor is setup to issue a not-good condition
when the temperature is above or below some value, but this is still
safe.

Clear/not-clear skies isn't the only event that will indicate
undesirable operating conditions. And certainly even a "Safety
Monitor" driver for the Boltwood II would be indicating a lot more
than Clear/not-Clear for the property in question (Cloud, Wind, Rain,
and Light status can all be included).

Thus "IsGood" is a much more generic description for this interface.

-Matt Thomas
http://www.astromatt.com/
CCD Commander: multi-target unattended imaging
http://www.ccdcommander.com/

Monday, December 1, 2008, 8:46:20 PM, John wrote:

>> IsClear is specific to a Cloud Monitor. I'm trying to abstract this
>> specification away from a Cloud Monitor to any kind of safety
>> monitoring device. IsClear does not abstract well - it is too
>> specific.
>>
>> IsQuestionable for a Cloud Monitoring device will simply be the
>> inverse of what IsClear was.


> Just to rephrase my other reply, I still don't get how an app writer
> would know what to do with such an abstract term.

> Although you cite the limited scope of IsClear as a negative, I see it
> as a positive, in that the response of the app can be more meaningful
> since it has more of an idea of the context of the property value.

> It knows it pertains to the sky conditions, rather than any one of a
> number of options the driver writer may factor in, non of which may be
> relevant to the decision the app is trying to make.

> If we're saying that IsQuestionable has a concrete meaning (within the
> constraints of the sensors available to the driver author), then
> it makes more sense to me.
> e.g. If we were to define it as indicating questionable (suboptimal)
> sky conditions, based on whatever metrics the sensor package provides.

> You mention "any kind of safety monitoring device" which I guess
> includes things like the aforementioned battery monitor, but wouldn't
> that factor in to the IsSafe property - either it's at a level where
> it's safe to continue and get a safe shutdown on losing power, or it
> isn't.

> Perhaps if you could give an example of what you're thinking of, it'd
> be clearer to me?

> John

Can you give an example of how an imaging app can blindly use these
significantly different meanings for the same property?

What does "Not Good" actually mean to the app - what behavior should
an imaging app instigate when it receives a NotGood signal?
Should it abort imaging, switch to a special type of target, or
something else?

Allowing an input from a line monitor seems to complicate matters, it
would seem to require different responses from an imaging app, but the
app has no way of differentiating between them from reading a single
boolean property.

This is why I was suggesting an IsGoodWeather property, it's maybe
possible for the app to infer something specific from the property,
without having to know the inputs driving it, in this case perhaps it
would temporarily cease imaging, without having to close up the obs.

IsGoodWeather allows for a little more sensor independence than the
more specific IsClear, since it may be using an anemometer, for example.

John



--- In ASCOM-Talk@yahoogroups.com, Matt Thomas <matt_e_thomas@...> wrote:
>
> > You mention "any kind of safety monitoring device" which I guess
> > includes things like the aforementioned battery monitor, but wouldn't
> > that factor in to the IsSafe property - either it's at a level where
> > it's safe to continue and get a safe shutdown on losing power, or it
> > isn't.
>
> No, a battery monitor wouldn't use the "Questionable" or "Good" value.
> No meaning there.
>
> But a line voltage monitor could. A low or high voltage that is still
> safe, but that could cause unwanted effects may be not-good or
> questionable.
>
> Maybe an anemometer can be setup to issue a not-good condition when
> the wind goes above 20 knots, but this is still safe.
>
> Maybe a temperature monitor is setup to issue a not-good condition
> when the temperature is above or below some value, but this is still
> safe.
>
> Clear/not-clear skies isn't the only event that will indicate
> undesirable operating conditions. And certainly even a "Safety
> Monitor" driver for the Boltwood II would be indicating a lot more
> than Clear/not-Clear for the property in question (Cloud, Wind, Rain,
> and Light status can all be included).
>
> Thus "IsGood" is a much more generic description for this interface.
>
> -Matt Thomas
> http://www.astromatt.com/
> CCD Commander: multi-target unattended imaging
> http://www.ccdcommander.com/
>
> Monday, December 1, 2008, 8:46:20 PM, John wrote:
>
> >> IsClear is specific to a Cloud Monitor. I'm trying to abstract this
> >> specification away from a Cloud Monitor to any kind of safety
> >> monitoring device. IsClear does not abstract well - it is too
> >> specific.
> >>
> >> IsQuestionable for a Cloud Monitoring device will simply be the
> >> inverse of what IsClear was.
>
>
> > Just to rephrase my other reply, I still don't get how an app writer
> > would know what to do with such an abstract term.
>
> > Although you cite the limited scope of IsClear as a negative, I see it
> > as a positive, in that the response of the app can be more meaningful
> > since it has more of an idea of the context of the property value.
>
> > It knows it pertains to the sky conditions, rather than any one of a
> > number of options the driver writer may factor in, non of which may be
> > relevant to the decision the app is trying to make.
>
> > If we're saying that IsQuestionable has a concrete meaning (within the
> > constraints of the sensors available to the driver author), then
> > it makes more sense to me.
> > e.g. If we were to define it as indicating questionable (suboptimal)
> > sky conditions, based on whatever metrics the sensor package provides.
>
> > You mention "any kind of safety monitoring device" which I guess
> > includes things like the aforementioned battery monitor, but wouldn't
> > that factor in to the IsSafe property - either it's at a level where
> > it's safe to continue and get a safe shutdown on losing power, or it
> > isn't.
>
> > Perhaps if you could give an example of what you're thinking of, it'd
> > be clearer to me?
>
> > John
>