ASCOM Weather Interface

Sequence Generator Equipment Compatibility
1

There seems to be a number of requirements for reading weather data from a variety of devices and I wonder if defining a standard interface would be a good idea. This would delegate the pain of implementing connection to the hardware to the driver.

I’ve posted a discussion document in the ASCOM-talk files area here:

If you are interested in this please have a look and let me know what you think.

Chris

2

Hi Chris,
Would this be covered by ASCOM switches already?
I am looking to move my software Tektite Skies from a straight out safety monitor interface to occupying an ASCOM switch position. That way with another application a risk assessment can be conducted IAW their needs.

I think that generic switches would allow for future unexpected technologies rather than a standard that would need to change as each new device comes to the market.

Trent

1 Like
3

Hi Trent,

Yes the switch interface was designed to cover this. It was one of the reasons that I designed the switch interface the way it is.

I think that the switch interface would be a good way to do this, possibly using an agreed set of switch names for the weather parameters.

I’d be very interested to hear what you are thinking of, don’t hesitate to contact me directly if you think it will help.

Chris

2 Likes
4

I guess conceptually there are several ‘customers’ for weather information. Off the top of my head here are four:

  • Real time environmental information for enhanced tracking (ProTrack,
    10 Micron)
  • Safety monitor, triggered by rain /heavy cloud or
    excessive relative humidity - ie shut down for the night.
  • Dew heater
    control - triggered by dewpoint and humidity .
  • Go / No Go imaging -
    targeted cloud detection - where a program like SGP waits for the OK
    to image signal but also can abort / resume sequences based on cloud
    obscuration of the target. This might be ideal for programs like
    Tektite skies. - *This would be a feature request :wink: *

My point is that brainstorming the customer requirements is the first step in the process, whether or not there are currently sensors to do it. I’ll take a look at the ASCOM discussion thread.

2 Likes
5

What’ I’d like to see is a POTH of some type. For instance, I could use TekSkies cloud detector AND my rain detector. Both work well for different things and its possible to have more than one safety device. Specifically at the larger commercial facilities.

Or, after reading Trent’s message, exactly what he said since it’s based on our conversations :).

Chris

6

Subtle hint acknowledged

1 Like
7

The issue with the switch interface is that the calling application will have no idea how to access different properties without some sort of standard. For instance how do we know which switch to get wind data? How is this data represented? If the switch reads 252 is that 252mph or 25.2mph or 2.52mph? Or is is 25.2kmph? Or something completely different?

The awesomness of ASCOM is in standards and interfaces. Without some sort of contract we might as well “roll our own” implementation. I’m worried that things that use the switch for weather stations (and other stations) will be “one off” and thus negate the benefit that ASCOM provides.

I’m not saying this is a bad idea…quite the contrary actually. Just that from our perspective we need a contract to develop against. ASCOM generally provides these as device interfaces and the switch doesn’t provide an interface for how to operate a specific device like a weather station. But if we can figure out the contract piece then this could certainly be usable.

Thanks,
Jared

8

Thanks Jared,

Your comments about this is why I’m thinking that a more rigidly defined interface definition would be better.
So wind speed would be defined as a property with the name WindSpeed and would return a double that has the wind speed in metres per second.

From a look at the discussion on ASCOM-Talk this isn’t universally accepted. There’s an alternative proposal that the property names should be left undefined. This is what I think of as a Linux solution - dump the problems on the user.

If we do do something similar to what I’ve suggested in my discussion document - a defined set of properties - would you find this of use? Enough use that you would use it?

Chris

9

Chris,
If the property names are undefined I can tell you that it will be useless to us and we will likely not implement against it (unless I’m missing something). As you know, ASCOM is wonderful because it provides an abstraction layer and contract for devices and applications to adhere to. If we don’t have that then there is no reason to use it for these devices. They’d all just be one-off implementations at that point.

I’m not really sure how this could work with undefined properties? Maybe some additional clarification on how an application would access the device would help.

Thanks,
Jared

10

Also the document that you provided seems to be an excellent start on a contract and property names. As for units I’m all aboard for SI.

Thanks,
Jared