Loading ...
Sorry, an error occurred while loading the content.

Re: ASCOM with 64-bit Windows 7 - Meade LS-8

Expand Messages
  • rdobosz@rogers.com
    Hi the default key HKEY_CLASSES_ROOT ASCOM.Simulator.Telescope CLSID with a (Default) value of {86931eac-1f52-4918-b6aa-7e9b0ff361bd} Is there but that is the
    Message 1 of 22 , May 12, 2012
    View Source
    • 0 Attachment
      Hi
      the default key
      HKEY_CLASSES_ROOT\ASCOM.Simulator.Telescope CLSID with a (Default) value of {86931eac-1f52-4918-b6aa-7e9b0ff361bd}

      Is there but that is the only entry. there is no meade.telescope

      what is the proper way to use regsvr32 to add this entry?

      thanks for your help its appreciated

      --- In ASCOM-Talk@yahoogroups.com, "Peter Simpson" <peter@...> wrote:
      >
      > Hi,
      > The Platform code is looking for a registry entry that is created when
      > your driver is registered as a COM object. Specifically, this message is
      > given when the CLSID value is missing. CLSID is a pointer that
      > associates the ProgID Meade.Telescope with a definition that describes
      > the real code object that exposes the Meade.Telescope object.
      > After COM registration, you should have an entry Meade.Telescope under
      > HKEY_CLASSES_ROOT, use Regedit to check this. If its not there, you
      > have not successfully registered your driver for COM and it won't work
      > with any ASCOM applications.
      > To see what should be present, use Regedit to have a look at the entry
      > HKEY_CLASSES_ROOT\ASCOM.Simulator.Telescope and you will see a CLSID
      > entry underneath it with a (Default) value of
      > {86931eac-1f52-4918-b6aa-7e9b0ff361bd}. You should have something
      > similar for Meade.Telescope but with a diffferent (...} value.
      > You should not attempt to add these missing entries manually, RegAsm
      > (.NET drivers) or RegSvr32 (other languages) should do this for you.
      > Please let us know what you find.
      > Regards, Peter--- In ASCOM-Talk@yahoogroups.com, "rdobosz@"
      > <rdobosz@> wrote:
      > >
      > > I'm attempting to use it with Starry Night 6. I get the error when i
      > choose the meade.telescope driver. However I don't think the issue is
      > with the actual software but more with my driver. I get the exact same
      > error when I load ASCOM Diagnostics and in the ASCOM Telescope Chooser
      > when I select the Meade.Telescope
      > >
      > > it says
      > >
      > > "Incompatable Driver (Meade.Telescope)
      > > This driver is not registered for COM (can't find ProgID), please
      > re-install"
      > >
      > >
      > >
      > >
      > >
      > > --- In ASCOM-Talk@yahoogroups.com, "Chris" chris_group_mail@ wrote:
      > > >
      > > > Can you let us know what application you are using to try to
      > connect?
      > > >
      > > > And what is the exact error you are seeing? The error messages are
      > designed to let us know what the problem is.
      > > >
      > > > Without knowing that my guess is that it could be a 64 bit
      > application that is trying to connect to the 32 bit Meade driver dll.
      > If that's the case then connect through a hub such as POTH.
      > > >
      > > > Chris
      > > >
      > > > --- In ASCOM-Talk@yahoogroups.com, "rdobosz@" <rdobosz@> wrote:
      > > > >
      > > > > I just installed ASCOM 6 w/ SP1 and trying to connect it to my
      > Meade LS-8 Telescope on Windows 7
      > > > >
      > > > > ASCOM doesn't allow me to select the Meade.Telescope Driver it
      > complains the driver is not installed correctly as cannot located the
      > ProgId and to suggests a reinstall.
      > > > >
      > > > > I've reinstalled and it had no effect. After hours of searching
      > it appears the culprit could be the fact im using 64bit windows.
      > > > >
      > > > > Does anyone happen to know if there is a resolution to this
      > problem? or might be able to shed any light on this matter
      > > > >
      > > > > thanks in advance
      > > > >
      > > >
      > >
      >
    • Peter Simpson
      Hi, The installer for your driver should have registered it for COM,which driver installer did you use or have you written your own driver? It would help if
      Message 2 of 22 , May 12, 2012
      View Source
      • 0 Attachment
        Hi,

        The installer for your driver should have registered it for COM,which driver installer did you use or have you written your own driver? It would help if you can run the ASCOM Diagnostics program in Start / All Programs / ASCOM Platform 6 / Tools and post the resulting log to the files section here.

        I'd also appreciate it if you could  sign your messages, it makes the conversation a little more personal, thanks!

        Best wishes, Peter

        --- In ASCOM-Talk@yahoogroups.com, "rdobosz@..." <rdobosz@...> wrote:
        >
        > Hi
        > the default key
        > HKEY_CLASSES_ROOT\ASCOM.Simulator.Telescope CLSID with a (Default) value of {86931eac-1f52-4918-b6aa-7e9b0ff361bd}
        >
        > Is there but that is the only entry. there is no meade.telescope
        >
        > what is the proper way to use regsvr32 to add this entry?
        >
        > thanks for your help its appreciated
        >
        > --- In ASCOM-Talk@yahoogroups.com, "Peter Simpson" peter@ wrote:
        > >
        > > Hi,
        > > The Platform code is looking for a registry entry that is created when
        > > your driver is registered as a COM object. Specifically, this message is
        > > given when the CLSID value is missing. CLSID is a pointer that
        > > associates the ProgID Meade.Telescope with a definition that describes
        > > the real code object that exposes the Meade.Telescope object.
        > > After COM registration, you should have an entry Meade.Telescope under
        > > HKEY_CLASSES_ROOT, use Regedit to check this. If its not there, you
        > > have not successfully registered your driver for COM and it won't work
        > > with any ASCOM applications.
        > > To see what should be present, use Regedit to have a look at the entry
        > > HKEY_CLASSES_ROOT\ASCOM.Simulator.Telescope and you will see a CLSID
        > > entry underneath it with a (Default) value of
        > > {86931eac-1f52-4918-b6aa-7e9b0ff361bd}. You should have something
        > > similar for Meade.Telescope but with a diffferent (...} value.
        > > You should not attempt to add these missing entries manually, RegAsm
        > > (.NET drivers) or RegSvr32 (other languages) should do this for you.
        > > Please let us know what you find.
        > > Regards, Peter--- In ASCOM-Talk@yahoogroups.com, "rdobosz@"
        > > <rdobosz@> wrote:
        > > >
        > > > I'm attempting to use it with Starry Night 6. I get the error when i
        > > choose the meade.telescope driver. However I don't think the issue is
        > > with the actual software but more with my driver. I get the exact same
        > > error when I load ASCOM Diagnostics and in the ASCOM Telescope Chooser
        > > when I select the Meade.Telescope
        > > >
        > > > it says
        > > >
        > > > "Incompatable Driver (Meade.Telescope)
        > > > This driver is not registered for COM (can't find ProgID), please
        > > re-install"
        > > >
        > > >
        > > >
        > > >
        > > >
        > > > --- In ASCOM-Talk@yahoogroups.com, "Chris" chris_group_mail@ wrote:
        > > > >
        > > > > Can you let us know what application you are using to try to
        > > connect?
        > > > >
        > > > > And what is the exact error you are seeing? The error messages are
        > > designed to let us know what the problem is.
        > > > >
        > > > > Without knowing that my guess is that it could be a 64 bit
        > > application that is trying to connect to the 32 bit Meade driver dll.
        > > If that's the case then connect through a hub such as POTH.
        > > > >
        > > > > Chris
        > > > >
        > > > > --- In ASCOM-Talk@yahoogroups.com, "rdobosz@" <rdobosz@> wrote:
        > > > > >
        > > > > > I just installed ASCOM 6 w/ SP1 and trying to connect it to my
        > > Meade LS-8 Telescope on Windows 7
        > > > > >
        > > > > > ASCOM doesn't allow me to select the Meade.Telescope Driver it
        > > complains the driver is not installed correctly as cannot located the
        > > ProgId and to suggests a reinstall.
        > > > > >
        > > > > > I've reinstalled and it had no effect. After hours of searching
        > > it appears the culprit could be the fact im using 64bit windows.
        > > > > >
        > > > > > Does anyone happen to know if there is a resolution to this
        > > problem? or might be able to shed any light on this matter
        > > > > >
        > > > > > thanks in advance
        > > > > >
        > > > >
        > > >
        > >
        >
      • rdobosz@rogers.com
        Hi there sorry for the delay, i havent had time to play with this and get it working This morning i setup a new laptop with 32bit windows 7 i installed the
        Message 3 of 22 , Jun 2, 2012
        View Source
        • 0 Attachment
          Hi there

          sorry for the delay, i havent had time to play with this and get it working


          This morning i setup a new laptop with 32bit windows 7


          i installed the drivers from meade

          first i installed autostar 5.5
          then i ran the update 5.9.3
          then i connected the telescope to autostar updated the telescope

          using these instructions

          http://www.meade.com/support/Win7_ASU592_Installation.pdf

          In device manager under ports

          i see - ETX_LS USB Serial Port (COM4)

          Under driver tab i see

          Driver Provider: Meade Instruments
          Driver Date : 7/16/2010
          Driver Version: 0.1.0.0
          Digital Signer: Meade Instruments Corp




          then i installed ASCOM 6 sp1

          but when i select device type telescope
          then i see meade.telescope

          when i select it it says

          Incompataible Driver (Meade.Telescope)
          This Driver is not registered for COM (can't find ProgID), please re-install

          I checked regedit under

          HKEY_CLASSES_ROOT\
          and i see the ASCOM.simulator

          but there is nothing with ASCOM & Meade.Telescope.. aboslutely nothing


          I included the diagnostics from ascom

          its called
          ASCOM Diagnostics - Meade.Telescope




          I tried this on both 64 bit system and 32 bit windows 7 with the same result. I wanted to confirm that it wasnt my 64 bit system so i did an install on another laptop w/ 32 bit




          Thanks so much
          Richard

          --- In ASCOM-Talk@yahoogroups.com, "Peter Simpson" <peter@...> wrote:
          >
          > Hi,
          > The Platform code is looking for a registry entry that is created when
          > your driver is registered as a COM object. Specifically, this message is
          > given when the CLSID value is missing. CLSID is a pointer that
          > associates the ProgID Meade.Telescope with a definition that describes
          > the real code object that exposes the Meade.Telescope object.
          > After COM registration, you should have an entry Meade.Telescope under
          > HKEY_CLASSES_ROOT, use Regedit to check this. If its not there, you
          > have not successfully registered your driver for COM and it won't work
          > with any ASCOM applications.
          > To see what should be present, use Regedit to have a look at the entry
          > HKEY_CLASSES_ROOT\ASCOM.Simulator.Telescope and you will see a CLSID
          > entry underneath it with a (Default) value of
          > {86931eac-1f52-4918-b6aa-7e9b0ff361bd}. You should have something
          > similar for Meade.Telescope but with a diffferent (...} value.
          > You should not attempt to add these missing entries manually, RegAsm
          > (.NET drivers) or RegSvr32 (other languages) should do this for you.
          > Please let us know what you find.
          > Regards, Peter--- In ASCOM-Talk@yahoogroups.com, "rdobosz@"
          > <rdobosz@> wrote:
          > >
          > > I'm attempting to use it with Starry Night 6. I get the error when i
          > choose the meade.telescope driver. However I don't think the issue is
          > with the actual software but more with my driver. I get the exact same
          > error when I load ASCOM Diagnostics and in the ASCOM Telescope Chooser
          > when I select the Meade.Telescope
          > >
          > > it says
          > >
          > > "Incompatable Driver (Meade.Telescope)
          > > This driver is not registered for COM (can't find ProgID), please
          > re-install"
          > >
          > >
          > >
          > >
          > >
          > > --- In ASCOM-Talk@yahoogroups.com, "Chris" chris_group_mail@ wrote:
          > > >
          > > > Can you let us know what application you are using to try to
          > connect?
          > > >
          > > > And what is the exact error you are seeing? The error messages are
          > designed to let us know what the problem is.
          > > >
          > > > Without knowing that my guess is that it could be a 64 bit
          > application that is trying to connect to the 32 bit Meade driver dll.
          > If that's the case then connect through a hub such as POTH.
          > > >
          > > > Chris
          > > >
          > > > --- In ASCOM-Talk@yahoogroups.com, "rdobosz@" <rdobosz@> wrote:
          > > > >
          > > > > I just installed ASCOM 6 w/ SP1 and trying to connect it to my
          > Meade LS-8 Telescope on Windows 7
          > > > >
          > > > > ASCOM doesn't allow me to select the Meade.Telescope Driver it
          > complains the driver is not installed correctly as cannot located the
          > ProgId and to suggests a reinstall.
          > > > >
          > > > > I've reinstalled and it had no effect. After hours of searching
          > it appears the culprit could be the fact im using 64bit windows.
          > > > >
          > > > > Does anyone happen to know if there is a resolution to this
          > problem? or might be able to shed any light on this matter
          > > > >
          > > > > thanks in advance
          > > > >
          > > >
          > >
          >
        • autostaretx
          What you appear to be missing is the installation of an appropriate ASCOM driver to handle the scope. The Platform alone does not have any. You need to visit
          Message 4 of 22 , Jun 2, 2012
          View Source
          • 0 Attachment
            What you appear to be missing is the installation of an appropriate ASCOM driver to handle the scope. The Platform alone does not have any.

            You need to visit the ASCOM site's Download:Telescopes page
            http://ascom-standards.org/Downloads/ScopeDrivers.htm
            and install (for an LS family scope) the "Generic LX200" driver.

            (The other "Meade" drivers do not recognize the LS's response to "what are you?" ... the Generic driver doesn't probe for that).

            You will also need (due to a quirk in the LS firmware) to turn ON "DTS" and "RTS" on the "COM port" that represents the LS scope.
            This is done with the ASCOM Profile Explorer.
            After installing the driver and using the Chooser/Driver Setup to tell it which COM port number the LS appears on, you then shut down that session (well, you're welcome to try to connect, but it will time out).
            Fire up ASCOM's Profile Explorer and open the [+] Com Port Settings list.
            Add the two values:
            RTSEnable
            and
            DTSEnable
            and set them both to "True".

            Exit Profile Explorer and ASCOM may now be willing to control the LS scope.

            good luck
            --dick


            --- In ASCOM-Talk@yahoogroups.com, "rdobosz@..." <rdobosz@...> wrote:
            >
            > Hi there
            >
            > sorry for the delay, i havent had time to play with this and get it working
            >
            >
            > This morning i setup a new laptop with 32bit windows 7
            >
            >
            > i installed the drivers from meade
            >
            > first i installed autostar 5.5
            > then i ran the update 5.9.3
            > then i connected the telescope to autostar updated the telescope
            >
            > using these instructions
            >
            > http://www.meade.com/support/Win7_ASU592_Installation.pdf
            >
            > In device manager under ports
            >
            > i see - ETX_LS USB Serial Port (COM4)
            >
            > Under driver tab i see
            >
            > Driver Provider: Meade Instruments
            > Driver Date : 7/16/2010
            > Driver Version: 0.1.0.0
            > Digital Signer: Meade Instruments Corp
            >
            >
            >
            >
            > then i installed ASCOM 6 sp1
            >
            > but when i select device type telescope
            > then i see meade.telescope
            >
            > when i select it it says
            >
            > Incompataible Driver (Meade.Telescope)
            > This Driver is not registered for COM (can't find ProgID), please re-install
            >
            > I checked regedit under
            >
            > HKEY_CLASSES_ROOT\
            > and i see the ASCOM.simulator
            >
            > but there is nothing with ASCOM & Meade.Telescope.. aboslutely nothing
            >
            >
            > I included the diagnostics from ascom
            >
            > its called
            > ASCOM Diagnostics - Meade.Telescope
            >
            >
            >
            >
            > I tried this on both 64 bit system and 32 bit windows 7 with the same result. I wanted to confirm that it wasnt my 64 bit system so i did an install on another laptop w/ 32 bit
            >
            >
            >
            >
            > Thanks so much
            > Richard
            >
            > --- In ASCOM-Talk@yahoogroups.com, "Peter Simpson" <peter@> wrote:
            > >
            > > Hi,
            > > The Platform code is looking for a registry entry that is created when
            > > your driver is registered as a COM object. Specifically, this message is
            > > given when the CLSID value is missing. CLSID is a pointer that
            > > associates the ProgID Meade.Telescope with a definition that describes
            > > the real code object that exposes the Meade.Telescope object.
            > > After COM registration, you should have an entry Meade.Telescope under
            > > HKEY_CLASSES_ROOT, use Regedit to check this. If its not there, you
            > > have not successfully registered your driver for COM and it won't work
            > > with any ASCOM applications.
            > > To see what should be present, use Regedit to have a look at the entry
            > > HKEY_CLASSES_ROOT\ASCOM.Simulator.Telescope and you will see a CLSID
            > > entry underneath it with a (Default) value of
            > > {86931eac-1f52-4918-b6aa-7e9b0ff361bd}. You should have something
            > > similar for Meade.Telescope but with a diffferent (...} value.
            > > You should not attempt to add these missing entries manually, RegAsm
            > > (.NET drivers) or RegSvr32 (other languages) should do this for you.
            > > Please let us know what you find.
            > > Regards, Peter--- In ASCOM-Talk@yahoogroups.com, "rdobosz@"
            > > <rdobosz@> wrote:
            > > >
            > > > I'm attempting to use it with Starry Night 6. I get the error when i
            > > choose the meade.telescope driver. However I don't think the issue is
            > > with the actual software but more with my driver. I get the exact same
            > > error when I load ASCOM Diagnostics and in the ASCOM Telescope Chooser
            > > when I select the Meade.Telescope
            > > >
            > > > it says
            > > >
            > > > "Incompatable Driver (Meade.Telescope)
            > > > This driver is not registered for COM (can't find ProgID), please
            > > re-install"
            > > >
            > > >
            > > >
            > > >
            > > >
            > > > --- In ASCOM-Talk@yahoogroups.com, "Chris" chris_group_mail@ wrote:
            > > > >
            > > > > Can you let us know what application you are using to try to
            > > connect?
            > > > >
            > > > > And what is the exact error you are seeing? The error messages are
            > > designed to let us know what the problem is.
            > > > >
            > > > > Without knowing that my guess is that it could be a 64 bit
            > > application that is trying to connect to the 32 bit Meade driver dll.
            > > If that's the case then connect through a hub such as POTH.
            > > > >
            > > > > Chris
            > > > >
            > > > > --- In ASCOM-Talk@yahoogroups.com, "rdobosz@" <rdobosz@> wrote:
            > > > > >
            > > > > > I just installed ASCOM 6 w/ SP1 and trying to connect it to my
            > > Meade LS-8 Telescope on Windows 7
            > > > > >
            > > > > > ASCOM doesn't allow me to select the Meade.Telescope Driver it
            > > complains the driver is not installed correctly as cannot located the
            > > ProgId and to suggests a reinstall.
            > > > > >
            > > > > > I've reinstalled and it had no effect. After hours of searching
            > > it appears the culprit could be the fact im using 64bit windows.
            > > > > >
            > > > > > Does anyone happen to know if there is a resolution to this
            > > problem? or might be able to shed any light on this matter
            > > > > >
            > > > > > thanks in advance
            > > > > >
            > > > >
            > > >
            > >
            >
          • Hristo Pavlov
            Hi All,   I ve been working on the second version of the IVideoCamera interface and came upong a usecase for video that changed things a little. There are
            Message 5 of 22 , Jun 2, 2012
            View Source
            • 0 Attachment
              Hi All,
               
              I've been working on the second version of the IVideoCamera interface and came upong a usecase for video that changed things a little. There are meteor observers that have unattended video cameras and software that operates them called MetRec. The software analyses the video in realtime and if it detects a meteor it records a short video of the meteor. It also platesolves it and writes in a file the position of the appearance and disappearance along with the time. One of the issues with MetRec is that it supports only one frame grabber which is quite old now and very difficult to find (only old items on e-bay). If there was an ASCOM interface for video then MetRec could be extended and could work with many more devices without a need to change anything.
               
              However the current version of IVideoCamera is not ideal for this type of meteor observing. Propbably 5fps would be sufficient to do analysis and record video with some missing frames. After all the observers are only after the time, position and direction of the trail and this can be determined only by 3 frames. However for some very fast meteors this may be insufficient. Also I remember that a number of people were not very happy with the fact that my proposal couldn't handle all video frames for viewing or realtime processing. So I though about this and I would like to propose a simple buffering that will allow retreival of all video frames for viewing or realtime processing. Of course this can be only possible if the hardware can manage it and if the driver decides to implemen it. Here is what I propose.
               
              - Add two new properties, for example called VideoFrameBufferSize and MaximumVideoFrameBufferSize
               
              - The client to continue and use a pull mechanism to retrieve video frames as fast as it can
               
              - If the VideoFrameBufferSize is set to 1 then the driver only allows the latest frame at the time of the call to be reteived i.e. it will works exactly as the previous proposed version
               
              - If MaximumVideoFrameBufferSize is also 1 this means that the driver does not support buffering and can only work in the mode as previously proposed
               
              - If the MaximumVideoFrameBufferSize is more than 1 then the driver supports buffering and setting the VideoFrameBufferSize to a value different than one will enable buffering
               
              - When buffering is enabled the driver will keep the configured number of frames in a buffer for processing and to help the client continue to work in case of delays in the hardware or the client that may prevent the client to receive all video frames. Once the buffer is full the driver will begin dropping frames by overwriting the last frame in the buffer. Please note that is generally how video processing software works even with DirectShow and other such standards. With all this if the hardware allows it the client will be able to receive all frames in buffered mode. Because frames have frame numbers it will be trivial for the client to determine if and when there are dropped frames. Usually when recording a video if a frame is dropped the recording software either duplicates the last available frame (most often) or simply doesn't include it in the video.
               
              - In buffered mode if the client asks for a frame but a frame is not available the driver will return NULL i.e. the buffer works as a queue and in a case of empty queue NULL is returned. May be in non buffered mode the driver will never return NULL (not sure about this) and will simply return the latest frame which may be the same frame as the one returned in the previous client call
               
              Generally this is roughly what I propose. It will make it possible meteor observers to use ASCOM for their work. The name of the properties and the precise way this works may be different but the idea is generally to support buffering with frame dropping. Other possible property names could include things like "CanDoVideoFrameBuffering" instead of using a special value for MaximumVideoFrameBufferSize to determine if buffering is supported. I have to say thought that I kind of like the simplicity of having only 2 extra properties.
               
              I would like to know what you all think about the proposed buffering mechanism.
               
              Regards,
              Hristo Pavlov
              Sydney, Australia
            • autostaretx
              I should have mentioned that the method of adding the RTSEnable and DTREnable Key values with Profile Explorer is covered in the ASCOM Platform Help, which is
              Message 6 of 22 , Jun 2, 2012
              View Source
              • 0 Attachment
                I should have mentioned that the method of adding the RTSEnable and DTREnable Key values with Profile Explorer is covered in the ASCOM Platform Help, which is found as a sub-topic of the ASCOM Platform 6 entry in the All Programs list accessed by clicking the Win7 Logo.

                Scroll down through the first list of bullet-point items and click on the 'Serial Port Configuration' link in the sentence:
                "The serial component is now compatible with devices that require RTS and CTS line use to be enabled, see Serial Port Configuration."

                good luck
                --dick


                --- In ASCOM-Talk@yahoogroups.com, "autostaretx" <rseymour@...> wrote:
                >
                > What you appear to be missing is the installation of an appropriate ASCOM driver to handle the scope. The Platform alone does not have any.
                >
                > You need to visit the ASCOM site's Download:Telescopes page
                > http://ascom-standards.org/Downloads/ScopeDrivers.htm
                > and install (for an LS family scope) the "Generic LX200" driver.
                >
                > (The other "Meade" drivers do not recognize the LS's response to "what are you?" ... the Generic driver doesn't probe for that).
                >
                > You will also need (due to a quirk in the LS firmware) to turn ON "DTS" and "RTS" on the "COM port" that represents the LS scope.
                > This is done with the ASCOM Profile Explorer.
                > After installing the driver and using the Chooser/Driver Setup to tell it which COM port number the LS appears on, you then shut down that session (well, you're welcome to try to connect, but it will time out).
                > Fire up ASCOM's Profile Explorer and open the [+] Com Port Settings list.
                > Add the two values:
                > RTSEnable
                > and
                > DTSEnable
                > and set them both to "True".
                >
                > Exit Profile Explorer and ASCOM may now be willing to control the LS scope.
                >
                > good luck
                > --dick
                >
                >
                > --- In ASCOM-Talk@yahoogroups.com, "rdobosz@" <rdobosz@> wrote:
                > >
                > > Hi there
                > >
                > > sorry for the delay, i havent had time to play with this and get it working
                > >
                > >
                > > This morning i setup a new laptop with 32bit windows 7
                > >
                > >
                > > i installed the drivers from meade
                > >
                > > first i installed autostar 5.5
                > > then i ran the update 5.9.3
                > > then i connected the telescope to autostar updated the telescope
                > >
                > > using these instructions
                > >
                > > http://www.meade.com/support/Win7_ASU592_Installation.pdf
                > >
                > > In device manager under ports
                > >
                > > i see - ETX_LS USB Serial Port (COM4)
                > >
                > > Under driver tab i see
                > >
                > > Driver Provider: Meade Instruments
                > > Driver Date : 7/16/2010
                > > Driver Version: 0.1.0.0
                > > Digital Signer: Meade Instruments Corp
                > >
                > >
                > >
                > >
                > > then i installed ASCOM 6 sp1
                > >
                > > but when i select device type telescope
                > > then i see meade.telescope
                > >
                > > when i select it it says
                > >
                > > Incompataible Driver (Meade.Telescope)
                > > This Driver is not registered for COM (can't find ProgID), please re-install
                > >
                > > I checked regedit under
                > >
                > > HKEY_CLASSES_ROOT\
                > > and i see the ASCOM.simulator
                > >
                > > but there is nothing with ASCOM & Meade.Telescope.. aboslutely nothing
                > >
                > >
                > > I included the diagnostics from ascom
                > >
                > > its called
                > > ASCOM Diagnostics - Meade.Telescope
                > >
                > >
                > >
                > >
                > > I tried this on both 64 bit system and 32 bit windows 7 with the same result. I wanted to confirm that it wasnt my 64 bit system so i did an install on another laptop w/ 32 bit
                > >
                > >
                > >
                > >
                > > Thanks so much
                > > Richard
                > >
                > > --- In ASCOM-Talk@yahoogroups.com, "Peter Simpson" <peter@> wrote:
                > > >
                > > > Hi,
                > > > The Platform code is looking for a registry entry that is created when
                > > > your driver is registered as a COM object. Specifically, this message is
                > > > given when the CLSID value is missing. CLSID is a pointer that
                > > > associates the ProgID Meade.Telescope with a definition that describes
                > > > the real code object that exposes the Meade.Telescope object.
                > > > After COM registration, you should have an entry Meade.Telescope under
                > > > HKEY_CLASSES_ROOT, use Regedit to check this. If its not there, you
                > > > have not successfully registered your driver for COM and it won't work
                > > > with any ASCOM applications.
                > > > To see what should be present, use Regedit to have a look at the entry
                > > > HKEY_CLASSES_ROOT\ASCOM.Simulator.Telescope and you will see a CLSID
                > > > entry underneath it with a (Default) value of
                > > > {86931eac-1f52-4918-b6aa-7e9b0ff361bd}. You should have something
                > > > similar for Meade.Telescope but with a diffferent (...} value.
                > > > You should not attempt to add these missing entries manually, RegAsm
                > > > (.NET drivers) or RegSvr32 (other languages) should do this for you.
                > > > Please let us know what you find.
                > > > Regards, Peter--- In ASCOM-Talk@yahoogroups.com, "rdobosz@"
                > > > <rdobosz@> wrote:
                > > > >
                > > > > I'm attempting to use it with Starry Night 6. I get the error when i
                > > > choose the meade.telescope driver. However I don't think the issue is
                > > > with the actual software but more with my driver. I get the exact same
                > > > error when I load ASCOM Diagnostics and in the ASCOM Telescope Chooser
                > > > when I select the Meade.Telescope
                > > > >
                > > > > it says
                > > > >
                > > > > "Incompatable Driver (Meade.Telescope)
                > > > > This driver is not registered for COM (can't find ProgID), please
                > > > re-install"
                > > > >
                > > > >
                > > > >
                > > > >
                > > > >
                > > > > --- In ASCOM-Talk@yahoogroups.com, "Chris" chris_group_mail@ wrote:
                > > > > >
                > > > > > Can you let us know what application you are using to try to
                > > > connect?
                > > > > >
                > > > > > And what is the exact error you are seeing? The error messages are
                > > > designed to let us know what the problem is.
                > > > > >
                > > > > > Without knowing that my guess is that it could be a 64 bit
                > > > application that is trying to connect to the 32 bit Meade driver dll.
                > > > If that's the case then connect through a hub such as POTH.
                > > > > >
                > > > > > Chris
                > > > > >
                > > > > > --- In ASCOM-Talk@yahoogroups.com, "rdobosz@" <rdobosz@> wrote:
                > > > > > >
                > > > > > > I just installed ASCOM 6 w/ SP1 and trying to connect it to my
                > > > Meade LS-8 Telescope on Windows 7
                > > > > > >
                > > > > > > ASCOM doesn't allow me to select the Meade.Telescope Driver it
                > > > complains the driver is not installed correctly as cannot located the
                > > > ProgId and to suggests a reinstall.
                > > > > > >
                > > > > > > I've reinstalled and it had no effect. After hours of searching
                > > > it appears the culprit could be the fact im using 64bit windows.
                > > > > > >
                > > > > > > Does anyone happen to know if there is a resolution to this
                > > > problem? or might be able to shed any light on this matter
                > > > > > >
                > > > > > > thanks in advance
                > > > > > >
                > > > > >
                > > > >
                > > >
                > >
                >
              • Chris Peterson
                This could be useful. A few comments: Metrec is the only Windows/DOS meteor detection software in common use that doesn t use DirectShow to access the standard
                Message 7 of 22 , Jun 2, 2012
                View Source
                • 0 Attachment
                  This could be useful. A few comments:

                  Metrec is the only Windows/DOS meteor detection software in common use
                  that doesn't use DirectShow to access the standard drivers that ship
                  with all digital video cameras and analog video frame grabbers. I doubt
                  that Metrec will get converted to use an ASCOM driver.

                  All meteor detection software uses some sort of ring buffer. This is
                  because it is necessary to start the video clip before the event
                  actually starts. Typical buffer sizes are several hundred frames.

                  It is very important to collect the data at 30 fps (or 25 fps for PAL)
                  and not drop frames. The data is used for much more than just endpoints
                  and direction. Some systems are now starting to run at higher frame
                  rates than conventional video.

                  To be useful, I'm assuming somebody would produce an ASCOM driver that
                  wraps the DirectShow library. I don't see individual analog camera
                  makers or frame grabber makers producing ASCOM drivers specifically for
                  their devices in most cases. The situation is different for digitally
                  controlled cameras, but so far meteor detection depends largely on
                  analog cameras with conventional video output.

                  Chris

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

                  On 6/2/2012 5:47 PM, Hristo Pavlov wrote:
                  > Hi All,
                  >
                  > I've been working on the second version of the IVideoCamera interface and came upong a usecase for video that changed things a little. There are meteor observers that have unattended video cameras and software that operates them called MetRec. The software analyses the video in realtime and if it detects a meteor it records a short video of the meteor. It also platesolves it and writes in a file the position of the appearance and disappearance along with the time. One of the issues with MetRec is that it supports only one frame grabber which is quite old now and very difficult to find (only old items on e-bay). If there was an ASCOM interface for video then MetRec could be extended and could work with many more devices without a need to change anything.
                  >
                  > However the current version of IVideoCamera is not ideal for this type of meteor observing. Propbably 5fps would be sufficient to do analysis and record video with some missing frames. After all the observers are only after the time, position and direction of the trail and this can be determined only by 3 frames. However for some very fast meteors this may be insufficient. Also I remember that a number of people were not very happy with the fact that my proposal couldn't handle all video frames for viewing or realtime processing. So I though about this and I would like to propose a simple buffering that will allow retreival of all video frames for viewing or realtime processing. Of course this can be only possible if the hardware can manage it and if the driver decides to implemen it. Here is what I propose.
                  >
                  > - Add two new properties, for example called VideoFrameBufferSize and MaximumVideoFrameBufferSize
                  >
                  > - The client to continue and use a pull mechanism to retrieve video frames as fast as it can
                  >
                  > - If the VideoFrameBufferSize is set to 1 then the driver only allows the latest frame at the time of the call to be reteived i.e. it will works exactly as the previous proposed version
                  >
                  > - If MaximumVideoFrameBufferSize is also 1 this means that the driver does not support buffering and can only work in the mode as previously proposed
                  >
                  > - If the MaximumVideoFrameBufferSize is more than 1 then the driver supports buffering and setting the VideoFrameBufferSize to a value different than one will enable buffering
                  >
                  > - When buffering is enabled the driver will keep the configured number of frames in a buffer for processing and to help the client continue to work in case of delays in the hardware or the client that may prevent the client to receive all video frames. Once the buffer is full the driver will begin dropping frames by overwriting the last frame in the buffer. Please note that is generally how video processing software works even with DirectShow and other such standards. With all this if the hardware allows it the client will be able to receive all frames in buffered mode. Because frames have frame numbers it will be trivial for the client to determine if and when there are dropped frames. Usually when recording a video if a frame is dropped the recording software either duplicates the last available frame (most often) or simply doesn't include it in the video.
                  >
                  > - In buffered mode if the client asks for a frame but a frame is not available the driver will return NULL i.e. the buffer works as a queue and in a case of empty queue NULL is returned. May be in non buffered mode the driver will never return NULL (not sure about this) and will simply return the latest frame which may be the same frame as the one returned in the previous client call
                  >
                  > Generally this is roughly what I propose. It will make it possible meteor observers to use ASCOM for their work. The name of the properties and the precise way this works may be different but the idea is generally to support buffering with frame dropping. Other possible property names could include things like "CanDoVideoFrameBuffering" instead of using a special value for MaximumVideoFrameBufferSize to determine if buffering is supported. I have to say thought that I kind of like the simplicity of having only 2 extra properties.
                  >
                  > I would like to know what you all think about the proposed buffering mechanism.
                  >
                  > Regards,
                  > Hristo Pavlov
                  > Sydney, Australia
                • rdobosz@rogers.com
                  Thanks Dick it seemed to work, i did everything you said then had to goto the driver in the profiler and point it to the com that telescope was sitting on.
                  Message 8 of 22 , Jun 2, 2012
                  View Source
                  • 0 Attachment
                    Thanks Dick it seemed to work, i did everything you said then had to goto the driver in the profiler and point it to the com that telescope was sitting on.


                    Connected ok

                    and in starry night it works properly, only issue is when i tell it to slew to a star once it moves there an error pops up from

                    ASCOM.Utilities
                    Timed out waiting for recieved data


                    is that normal?


                    thanks for your help

                    Richard

                    --- In ASCOM-Talk@yahoogroups.com, "autostaretx" <rseymour@...> wrote:
                    >
                    > I should have mentioned that the method of adding the RTSEnable and DTREnable Key values with Profile Explorer is covered in the ASCOM Platform Help, which is found as a sub-topic of the ASCOM Platform 6 entry in the All Programs list accessed by clicking the Win7 Logo.
                    >
                    > Scroll down through the first list of bullet-point items and click on the 'Serial Port Configuration' link in the sentence:
                    > "The serial component is now compatible with devices that require RTS and CTS line use to be enabled, see Serial Port Configuration."
                    >
                    > good luck
                    > --dick
                    >
                    >
                    > --- In ASCOM-Talk@yahoogroups.com, "autostaretx" <rseymour@> wrote:
                    > >
                    > > What you appear to be missing is the installation of an appropriate ASCOM driver to handle the scope. The Platform alone does not have any.
                    > >
                    > > You need to visit the ASCOM site's Download:Telescopes page
                    > > http://ascom-standards.org/Downloads/ScopeDrivers.htm
                    > > and install (for an LS family scope) the "Generic LX200" driver.
                    > >
                    > > (The other "Meade" drivers do not recognize the LS's response to "what are you?" ... the Generic driver doesn't probe for that).
                    > >
                    > > You will also need (due to a quirk in the LS firmware) to turn ON "DTS" and "RTS" on the "COM port" that represents the LS scope.
                    > > This is done with the ASCOM Profile Explorer.
                    > > After installing the driver and using the Chooser/Driver Setup to tell it which COM port number the LS appears on, you then shut down that session (well, you're welcome to try to connect, but it will time out).
                    > > Fire up ASCOM's Profile Explorer and open the [+] Com Port Settings list.
                    > > Add the two values:
                    > > RTSEnable
                    > > and
                    > > DTSEnable
                    > > and set them both to "True".
                    > >
                    > > Exit Profile Explorer and ASCOM may now be willing to control the LS scope.
                    > >
                    > > good luck
                    > > --dick
                    > >
                    > >
                    > > --- In ASCOM-Talk@yahoogroups.com, "rdobosz@" <rdobosz@> wrote:
                    > > >
                    > > > Hi there
                    > > >
                    > > > sorry for the delay, i havent had time to play with this and get it working
                    > > >
                    > > >
                    > > > This morning i setup a new laptop with 32bit windows 7
                    > > >
                    > > >
                    > > > i installed the drivers from meade
                    > > >
                    > > > first i installed autostar 5.5
                    > > > then i ran the update 5.9.3
                    > > > then i connected the telescope to autostar updated the telescope
                    > > >
                    > > > using these instructions
                    > > >
                    > > > http://www.meade.com/support/Win7_ASU592_Installation.pdf
                    > > >
                    > > > In device manager under ports
                    > > >
                    > > > i see - ETX_LS USB Serial Port (COM4)
                    > > >
                    > > > Under driver tab i see
                    > > >
                    > > > Driver Provider: Meade Instruments
                    > > > Driver Date : 7/16/2010
                    > > > Driver Version: 0.1.0.0
                    > > > Digital Signer: Meade Instruments Corp
                    > > >
                    > > >
                    > > >
                    > > >
                    > > > then i installed ASCOM 6 sp1
                    > > >
                    > > > but when i select device type telescope
                    > > > then i see meade.telescope
                    > > >
                    > > > when i select it it says
                    > > >
                    > > > Incompataible Driver (Meade.Telescope)
                    > > > This Driver is not registered for COM (can't find ProgID), please re-install
                    > > >
                    > > > I checked regedit under
                    > > >
                    > > > HKEY_CLASSES_ROOT\
                    > > > and i see the ASCOM.simulator
                    > > >
                    > > > but there is nothing with ASCOM & Meade.Telescope.. aboslutely nothing
                    > > >
                    > > >
                    > > > I included the diagnostics from ascom
                    > > >
                    > > > its called
                    > > > ASCOM Diagnostics - Meade.Telescope
                    > > >
                    > > >
                    > > >
                    > > >
                    > > > I tried this on both 64 bit system and 32 bit windows 7 with the same result. I wanted to confirm that it wasnt my 64 bit system so i did an install on another laptop w/ 32 bit
                    > > >
                    > > >
                    > > >
                    > > >
                    > > > Thanks so much
                    > > > Richard
                    > > >
                    > > > --- In ASCOM-Talk@yahoogroups.com, "Peter Simpson" <peter@> wrote:
                    > > > >
                    > > > > Hi,
                    > > > > The Platform code is looking for a registry entry that is created when
                    > > > > your driver is registered as a COM object. Specifically, this message is
                    > > > > given when the CLSID value is missing. CLSID is a pointer that
                    > > > > associates the ProgID Meade.Telescope with a definition that describes
                    > > > > the real code object that exposes the Meade.Telescope object.
                    > > > > After COM registration, you should have an entry Meade.Telescope under
                    > > > > HKEY_CLASSES_ROOT, use Regedit to check this. If its not there, you
                    > > > > have not successfully registered your driver for COM and it won't work
                    > > > > with any ASCOM applications.
                    > > > > To see what should be present, use Regedit to have a look at the entry
                    > > > > HKEY_CLASSES_ROOT\ASCOM.Simulator.Telescope and you will see a CLSID
                    > > > > entry underneath it with a (Default) value of
                    > > > > {86931eac-1f52-4918-b6aa-7e9b0ff361bd}. You should have something
                    > > > > similar for Meade.Telescope but with a diffferent (...} value.
                    > > > > You should not attempt to add these missing entries manually, RegAsm
                    > > > > (.NET drivers) or RegSvr32 (other languages) should do this for you.
                    > > > > Please let us know what you find.
                    > > > > Regards, Peter--- In ASCOM-Talk@yahoogroups.com, "rdobosz@"
                    > > > > <rdobosz@> wrote:
                    > > > > >
                    > > > > > I'm attempting to use it with Starry Night 6. I get the error when i
                    > > > > choose the meade.telescope driver. However I don't think the issue is
                    > > > > with the actual software but more with my driver. I get the exact same
                    > > > > error when I load ASCOM Diagnostics and in the ASCOM Telescope Chooser
                    > > > > when I select the Meade.Telescope
                    > > > > >
                    > > > > > it says
                    > > > > >
                    > > > > > "Incompatable Driver (Meade.Telescope)
                    > > > > > This driver is not registered for COM (can't find ProgID), please
                    > > > > re-install"
                    > > > > >
                    > > > > >
                    > > > > >
                    > > > > >
                    > > > > >
                    > > > > > --- In ASCOM-Talk@yahoogroups.com, "Chris" chris_group_mail@ wrote:
                    > > > > > >
                    > > > > > > Can you let us know what application you are using to try to
                    > > > > connect?
                    > > > > > >
                    > > > > > > And what is the exact error you are seeing? The error messages are
                    > > > > designed to let us know what the problem is.
                    > > > > > >
                    > > > > > > Without knowing that my guess is that it could be a 64 bit
                    > > > > application that is trying to connect to the 32 bit Meade driver dll.
                    > > > > If that's the case then connect through a hub such as POTH.
                    > > > > > >
                    > > > > > > Chris
                    > > > > > >
                    > > > > > > --- In ASCOM-Talk@yahoogroups.com, "rdobosz@" <rdobosz@> wrote:
                    > > > > > > >
                    > > > > > > > I just installed ASCOM 6 w/ SP1 and trying to connect it to my
                    > > > > Meade LS-8 Telescope on Windows 7
                    > > > > > > >
                    > > > > > > > ASCOM doesn't allow me to select the Meade.Telescope Driver it
                    > > > > complains the driver is not installed correctly as cannot located the
                    > > > > ProgId and to suggests a reinstall.
                    > > > > > > >
                    > > > > > > > I've reinstalled and it had no effect. After hours of searching
                    > > > > it appears the culprit could be the fact im using 64bit windows.
                    > > > > > > >
                    > > > > > > > Does anyone happen to know if there is a resolution to this
                    > > > > problem? or might be able to shed any light on this matter
                    > > > > > > >
                    > > > > > > > thanks in advance
                    > > > > > > >
                    > > > > > >
                    > > > > >
                    > > > >
                    > > >
                    > >
                    >
                  • Hristo Pavlov
                    Hi Chris,   Thanks for your comments.   An ASCOM driver would be an advantage as digital video cameras support much higher frame rates and are becoming more
                    Message 9 of 22 , Jun 3, 2012
                    View Source
                    • 0 Attachment
                      Hi Chris,
                       
                      Thanks for your comments.
                       
                      An ASCOM driver would be an advantage as digital video cameras support much higher frame rates and are becoming more comon in observing. This is also why I want to define an interface that works with both analogue and digital world.
                       
                      MetRec may not be modified to use ASCOM drivers but new software could be written to do the same. And why not even do it better ...
                       
                      Obviously to avoid dropping frames the only thing you can do is write a very fast software and use very good hardware. Other than this buffers will always get filled regardless of their size. Few hundred frames for meteor detection sounds like a reasonable number and one that the IVideoCamera can support (as this is not dependent on the interface itself).
                       
                      Cheers,
                      Hristo Pavlov
                      Sydney, Australia

                      From: Chris Peterson <cpeterson@...>
                      To: ASCOM-Talk@yahoogroups.com
                      Sent: Sunday, June 3, 2012 11:51 AM
                      Subject: Re: [ASCOM] Please comment on IVideoCamera proposed buffering

                       
                      This could be useful. A few comments:

                      Metrec is the only Windows/DOS meteor detection software in common use
                      that doesn't use DirectShow to access the standard drivers that ship
                      with all digital video cameras and analog video frame grabbers. I doubt
                      that Metrec will get converted to use an ASCOM driver.

                      All meteor detection software uses some sort of ring buffer. This is
                      because it is necessary to start the video clip before the event
                      actually starts. Typical buffer sizes are several hundred frames.

                      It is very important to collect the data at 30 fps (or 25 fps for PAL)
                      and not drop frames. The data is used for much more than just endpoints
                      and direction. Some systems are now starting to run at higher frame
                      rates than conventional video.

                      To be useful, I'm assuming somebody would produce an ASCOM driver that
                      wraps the DirectShow library. I don't see individual analog camera
                      makers or frame grabber makers producing ASCOM drivers specifically for
                      their devices in most cases. The situation is different for digitally
                      controlled cameras, but so far meteor detection depends largely on
                      analog cameras with conventional video output.

                      Chris

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

                      On 6/2/2012 5:47 PM, Hristo Pavlov wrote:
                      > Hi All,
                      >
                      > I've been working on the second version of the IVideoCamera interface and came upong a usecase for video that changed things a little. There are meteor observers that have unattended video cameras and software that operates them called MetRec. The software analyses the video in realtime and if it detects a meteor it records a short video of the meteor. It also platesolves it and writes in a file the position of the appearance and disappearance along with the time. One of the issues with MetRec is that it supports only one frame grabber which is quite old now and very difficult to find (only old items on e-bay). If there was an ASCOM interface for video then MetRec could be extended and could work with many more devices without a need to change anything.
                      >
                      > However the current version of IVideoCamera is not ideal for this type of meteor observing. Propbably 5fps would be sufficient to do analysis and record video with some missing frames. After all the observers are only after the time, position and direction of the trail and this can be determined only by 3 frames. However for some very fast meteors this may be insufficient. Also I remember that a number of people were not very happy with the fact that my proposal couldn't handle all video frames for viewing or realtime processing. So I though about this and I would like to propose a simple buffering that will allow retreival of all video frames for viewing or realtime processing. Of course this can be only possible if the hardware can manage it and if the driver decides to implemen it. Here is what I propose.
                      >
                      > - Add two new properties, for example called VideoFrameBufferSize and MaximumVideoFrameBufferSize
                      >
                      > - The client to continue and use a pull mechanism to retrieve video frames as fast as it can
                      >
                      > - If the VideoFrameBufferSize is set to 1 then the driver only allows the latest frame at the time of the call to be reteived i.e. it will works exactly as the previous proposed version
                      >
                      > - If MaximumVideoFrameBufferSize is also 1 this means that the driver does not support buffering and can only work in the mode as previously proposed
                      >
                      > - If the MaximumVideoFrameBufferSize is more than 1 then the driver supports buffering and setting the VideoFrameBufferSize to a value different than one will enable buffering
                      >
                      > - When buffering is enabled the driver will keep the configured number of frames in a buffer for processing and to help the client continue to work in case of delays in the hardware or the client that may prevent the client to receive all video frames. Once the buffer is full the driver will begin dropping frames by overwriting the last frame in the buffer. Please note that is generally how video processing software works even with DirectShow and other such standards. With all this if the hardware allows it the client will be able to receive all frames in buffered mode. Because frames have frame numbers it will be trivial for the client to determine if and when there are dropped frames. Usually when recording a video if a frame is dropped the recording software either duplicates the last available frame (most often) or simply doesn't include it in the video.
                      >
                      > - In buffered mode if the client asks for a frame but a frame is not available the driver will return NULL i.e. the buffer works as a queue and in a case of empty queue NULL is returned. May be in non buffered mode the driver will never return NULL (not sure about this) and will simply return the latest frame which may be the same frame as the one returned in the previous client call
                      >
                      > Generally this is roughly what I propose. It will make it possible meteor observers to use ASCOM for their work. The name of the properties and the precise way this works may be different but the idea is generally to support buffering with frame dropping. Other possible property names could include things like "CanDoVideoFrameBuffering" instead of using a special value for MaximumVideoFrameBufferSize to determine if buffering is supported. I have to say thought that I kind of like the simplicity of having only 2 extra properties.
                      >
                      > I would like to know what you all think about the proposed buffering mechanism.
                      >
                      > Regards,
                      > Hristo Pavlov
                      > Sydney, Australia


                    • autostaretx
                      The time-out means that ASCOM sent a command to the scope, and is expecting a response. One did not arrive in the allotted time (5 seconds, i think). No,
                      Message 10 of 22 , Jun 3, 2012
                      View Source
                      • 0 Attachment
                        The time-out means that ASCOM sent a command to the scope,
                        and is expecting a response. One did not arrive in the allotted time
                        (5 seconds, i think).

                        No, that's not normal... but i've never managed to get StarryNightPro v4.5 to work with ASCOM v5 and higher (incompatibilities between plugins... SNP doesn't recognize the plugin from ASCOM).
                        I use simpler "applications" (Pipe, an ASCOM diagnostic) to test scope operations.

                        The time-out is what the RTS/DTR Enabling is supposed to correct.
                        The fact that the scope is willing to *start* moving means that communication is established (at least outbound, PC-to-scope).

                        To diagnose, please activate the ASCOM "serial trace" function.
                        You do that at the Chooser window (where you tell it which scope), click the word "Trace" at the upper left corner of the Chooser window)
                        Then try using Starry Night as you were before.
                        ASCOM will create a log file an "My Documents/ASCOM" folder
                        of the traffic between the PC and the scope.
                        Zip it and email it to me (or post the zipped file to a folder in the Files area here) and i'll see what's up (and try to duplicate it on my LS-6). I'm rseymour (at) wolfenet.com

                        good luck
                        --dick

                        --- In ASCOM-Talk@yahoogroups.com, "rdobosz@..." <rdobosz@...> wrote:
                        >
                        > Thanks Dick it seemed to work, i did everything you said then had to goto the driver in the profiler and point it to the com that telescope was sitting on.
                        >
                        >
                        > Connected ok
                        >
                        > and in starry night it works properly, only issue is when i tell it to slew to a star once it moves there an error pops up from
                        >
                        > ASCOM.Utilities
                        > Timed out waiting for recieved data
                        >
                        >
                        > is that normal?
                        >
                        >
                        > thanks for your help
                        >
                        > Richard
                        >
                        > --- In ASCOM-Talk@yahoogroups.com, "autostaretx" <rseymour@> wrote:
                        > >
                        > > I should have mentioned that the method of adding the RTSEnable and DTREnable Key values with Profile Explorer is covered in the ASCOM Platform Help, which is found as a sub-topic of the ASCOM Platform 6 entry in the All Programs list accessed by clicking the Win7 Logo.
                        > >
                        > > Scroll down through the first list of bullet-point items and click on the 'Serial Port Configuration' link in the sentence:
                        > > "The serial component is now compatible with devices that require RTS and CTS line use to be enabled, see Serial Port Configuration."
                        > >
                        > > good luck
                        > > --dick
                        > >
                        > >
                        > > --- In ASCOM-Talk@yahoogroups.com, "autostaretx" <rseymour@> wrote:
                        > > >
                        > > > What you appear to be missing is the installation of an appropriate ASCOM driver to handle the scope. The Platform alone does not have any.
                        > > >
                        > > > You need to visit the ASCOM site's Download:Telescopes page
                        > > > http://ascom-standards.org/Downloads/ScopeDrivers.htm
                        > > > and install (for an LS family scope) the "Generic LX200" driver.
                        > > >
                        > > > (The other "Meade" drivers do not recognize the LS's response to "what are you?" ... the Generic driver doesn't probe for that).
                        > > >
                        > > > You will also need (due to a quirk in the LS firmware) to turn ON "DTS" and "RTS" on the "COM port" that represents the LS scope.
                        > > > This is done with the ASCOM Profile Explorer.
                        > > > After installing the driver and using the Chooser/Driver Setup to tell it which COM port number the LS appears on, you then shut down that session (well, you're welcome to try to connect, but it will time out).
                        > > > Fire up ASCOM's Profile Explorer and open the [+] Com Port Settings list.
                        > > > Add the two values:
                        > > > RTSEnable
                        > > > and
                        > > > DTSEnable
                        > > > and set them both to "True".
                        > > >
                        > > > Exit Profile Explorer and ASCOM may now be willing to control the LS scope.
                        > > >
                        > > > good luck
                        > > > --dick
                        > > >
                        > > >
                        > > > --- In ASCOM-Talk@yahoogroups.com, "rdobosz@" <rdobosz@> wrote:
                        > > > >
                        > > > > Hi there
                        > > > >
                        > > > > sorry for the delay, i havent had time to play with this and get it working
                        > > > >
                        > > > >
                        > > > > This morning i setup a new laptop with 32bit windows 7
                        > > > >
                        > > > >
                        > > > > i installed the drivers from meade
                        > > > >
                        > > > > first i installed autostar 5.5
                        > > > > then i ran the update 5.9.3
                        > > > > then i connected the telescope to autostar updated the telescope
                        > > > >
                        > > > > using these instructions
                        > > > >
                        > > > > http://www.meade.com/support/Win7_ASU592_Installation.pdf
                        > > > >
                        > > > > In device manager under ports
                        > > > >
                        > > > > i see - ETX_LS USB Serial Port (COM4)
                        > > > >
                        > > > > Under driver tab i see
                        > > > >
                        > > > > Driver Provider: Meade Instruments
                        > > > > Driver Date : 7/16/2010
                        > > > > Driver Version: 0.1.0.0
                        > > > > Digital Signer: Meade Instruments Corp
                        > > > >
                        > > > >
                        > > > >
                        > > > >
                        > > > > then i installed ASCOM 6 sp1
                        > > > >
                        > > > > but when i select device type telescope
                        > > > > then i see meade.telescope
                        > > > >
                        > > > > when i select it it says
                        > > > >
                        > > > > Incompataible Driver (Meade.Telescope)
                        > > > > This Driver is not registered for COM (can't find ProgID), please re-install
                        > > > >
                        > > > > I checked regedit under
                        > > > >
                        > > > > HKEY_CLASSES_ROOT\
                        > > > > and i see the ASCOM.simulator
                        > > > >
                        > > > > but there is nothing with ASCOM & Meade.Telescope.. aboslutely nothing
                        > > > >
                        > > > >
                        > > > > I included the diagnostics from ascom
                        > > > >
                        > > > > its called
                        > > > > ASCOM Diagnostics - Meade.Telescope
                        > > > >
                        > > > >
                        > > > >
                        > > > >
                        > > > > I tried this on both 64 bit system and 32 bit windows 7 with the same result. I wanted to confirm that it wasnt my 64 bit system so i did an install on another laptop w/ 32 bit
                        > > > >
                        > > > >
                        > > > >
                        > > > >
                        > > > > Thanks so much
                        > > > > Richard
                        > > > >
                        > > > > --- In ASCOM-Talk@yahoogroups.com, "Peter Simpson" <peter@> wrote:
                        > > > > >
                        > > > > > Hi,
                        > > > > > The Platform code is looking for a registry entry that is created when
                        > > > > > your driver is registered as a COM object. Specifically, this message is
                        > > > > > given when the CLSID value is missing. CLSID is a pointer that
                        > > > > > associates the ProgID Meade.Telescope with a definition that describes
                        > > > > > the real code object that exposes the Meade.Telescope object.
                        > > > > > After COM registration, you should have an entry Meade.Telescope under
                        > > > > > HKEY_CLASSES_ROOT, use Regedit to check this. If its not there, you
                        > > > > > have not successfully registered your driver for COM and it won't work
                        > > > > > with any ASCOM applications.
                        > > > > > To see what should be present, use Regedit to have a look at the entry
                        > > > > > HKEY_CLASSES_ROOT\ASCOM.Simulator.Telescope and you will see a CLSID
                        > > > > > entry underneath it with a (Default) value of
                        > > > > > {86931eac-1f52-4918-b6aa-7e9b0ff361bd}. You should have something
                        > > > > > similar for Meade.Telescope but with a diffferent (...} value.
                        > > > > > You should not attempt to add these missing entries manually, RegAsm
                        > > > > > (.NET drivers) or RegSvr32 (other languages) should do this for you.
                        > > > > > Please let us know what you find.
                        > > > > > Regards, Peter--- In ASCOM-Talk@yahoogroups.com, "rdobosz@"
                        > > > > > <rdobosz@> wrote:
                        > > > > > >
                        > > > > > > I'm attempting to use it with Starry Night 6. I get the error when i
                        > > > > > choose the meade.telescope driver. However I don't think the issue is
                        > > > > > with the actual software but more with my driver. I get the exact same
                        > > > > > error when I load ASCOM Diagnostics and in the ASCOM Telescope Chooser
                        > > > > > when I select the Meade.Telescope
                        > > > > > >
                        > > > > > > it says
                        > > > > > >
                        > > > > > > "Incompatable Driver (Meade.Telescope)
                        > > > > > > This driver is not registered for COM (can't find ProgID), please
                        > > > > > re-install"
                        > > > > > >
                        > > > > > >
                        > > > > > >
                        > > > > > >
                        > > > > > >
                        > > > > > > --- In ASCOM-Talk@yahoogroups.com, "Chris" chris_group_mail@ wrote:
                        > > > > > > >
                        > > > > > > > Can you let us know what application you are using to try to
                        > > > > > connect?
                        > > > > > > >
                        > > > > > > > And what is the exact error you are seeing? The error messages are
                        > > > > > designed to let us know what the problem is.
                        > > > > > > >
                        > > > > > > > Without knowing that my guess is that it could be a 64 bit
                        > > > > > application that is trying to connect to the 32 bit Meade driver dll.
                        > > > > > If that's the case then connect through a hub such as POTH.
                        > > > > > > >
                        > > > > > > > Chris
                        > > > > > > >
                        > > > > > > > --- In ASCOM-Talk@yahoogroups.com, "rdobosz@" <rdobosz@> wrote:
                        > > > > > > > >
                        > > > > > > > > I just installed ASCOM 6 w/ SP1 and trying to connect it to my
                        > > > > > Meade LS-8 Telescope on Windows 7
                        > > > > > > > >
                        > > > > > > > > ASCOM doesn't allow me to select the Meade.Telescope Driver it
                        > > > > > complains the driver is not installed correctly as cannot located the
                        > > > > > ProgId and to suggests a reinstall.
                        > > > > > > > >
                        > > > > > > > > I've reinstalled and it had no effect. After hours of searching
                        > > > > > it appears the culprit could be the fact im using 64bit windows.
                        > > > > > > > >
                        > > > > > > > > Does anyone happen to know if there is a resolution to this
                        > > > > > problem? or might be able to shed any light on this matter
                        > > > > > > > >
                        > > > > > > > > thanks in advance
                        > > > > > > > >
                        > > > > > > >
                        > > > > > >
                        > > > > >
                        > > > >
                        > > >
                        > >
                        >
                      • Hristo Pavlov
                        I don t know what to take from the lack of comments. I am also a little surpriced as in the previous discussions there were a number of people that wanted
                        Message 11 of 22 , Jun 7, 2012
                        View Source
                        • 0 Attachment
                          I don't know what to take from the lack of comments. I am also a little surpriced as in the previous discussions there were a number of people that wanted 'every-frame-video' approach so I thought that they would be very willing to comment on the buffering that I am proporsing?
                           
                          If there are still no comments for a few more days I will have to continue to work on the second version of IVideoCamera interface and include the buffering exactly as outlined below.
                           
                           
                          Again, I will be very happy to hear your comments and constructive critiques. So please tell me what you think.
                           
                           
                          Cheers,
                          Hristo Pavlov
                          Sydney, Australia

                          From: Hristo Pavlov <hristo_dpavlov@...>
                          To: "ASCOM-Talk@yahoogroups.com" <ASCOM-Talk@yahoogroups.com>
                          Sent: Sunday, June 3, 2012 9:47 AM
                          Subject: [ASCOM] Please comment on IVideoCamera proposed buffering

                           
                          Hi All,
                           
                          I've been working on the second version of the IVideoCamera interface and came upong a usecase for video that changed things a little. There are meteor observers that have unattended video cameras and software that operates them called MetRec. The software analyses the video in realtime and if it detects a meteor it records a short video of the meteor. It also platesolves it and writes in a file the position of the appearance and disappearance along with the time. One of the issues with MetRec is that it supports only one frame grabber which is quite old now and very difficult to find (only old items on e-bay). If there was an ASCOM interface for video then MetRec could be extended and could work with many more devices without a need to change anything.
                           
                          However the current version of IVideoCamera is not ideal for this type of meteor observing. Propbably 5fps would be sufficient to do analysis and record video with some missing frames. After all the observers are only after the time, position and direction of the trail and this can be determined only by 3 frames. However for some very fast meteors this may be insufficient. Also I remember that a number of people were not very happy with the fact that my proposal couldn't handle all video frames for viewing or realtime processing. So I though about this and I would like to propose a simple buffering that will allow retreival of all video frames for viewing or realtime processing. Of course this can be only possible if the hardware can manage it and if the driver decides to implemen it. Here is what I propose.
                           
                          - Add two new properties, for example called VideoFrameBufferSize and MaximumVideoFrameBufferSize
                           
                          - The client to continue and use a pull mechanism to retrieve video frames as fast as it can
                           
                          - If the VideoFrameBufferSize is set to 1 then the driver only allows the latest frame at the time of the call to be reteived i.e. it will works exactly as the previous proposed version
                           
                          - If MaximumVideoFrameBufferSize is also 1 this means that the driver does not support buffering and can only work in the mode as previously proposed
                           
                          - If the MaximumVideoFrameBufferSize is more than 1 then the driver supports buffering and setting the VideoFrameBufferSize to a value different than one will enable buffering
                           
                          - When buffering is enabled the driver will keep the configured number of frames in a buffer for processing and to help the client continue to work in case of delays in the hardware or the client that may prevent the client to receive all video frames. Once the buffer is full the driver will begin dropping frames by overwriting the last frame in the buffer. Please note that is generally how video processing software works even with DirectShow and other such standards. With all this if the hardware allows it the client will be able to receive all frames in buffered mode. Because frames have frame numbers it will be trivial for the client to determine if and when there are dropped frames. Usually when recording a video if a frame is dropped the recording software either duplicates the last available frame (most often) or simply doesn't include it in the video.
                           
                          - In buffered mode if the client asks for a frame but a frame is not available the driver will return NULL i.e. the buffer works as a queue and in a case of empty queue NULL is returned. May be in non buffered mode the driver will never return NULL (not sure about this) and will simply return the latest frame which may be the same frame as the one returned in the previous client call
                           
                          Generally this is roughly what I propose. It will make it possible meteor observers to use ASCOM for their work. The name of the properties and the precise way this works may be different but the idea is generally to support buffering with frame dropping. Other possible property names could include things like "CanDoVideoFrameBuffering" instead of using a special value for MaximumVideoFrameBufferSize to determine if buffering is supported. I have to say thought that I kind of like the simplicity of having only 2 extra properties.
                           
                          I would like to know what you all think about the proposed buffering mechanism.
                           
                          Regards,
                          Hristo Pavlov
                          Sydney, Australia


                        • Mark
                          Hristo, My guess as to why you are not getting many comments is two fold ... 1) I don t think most folks really understand what impact the buffered vs. every
                          Message 12 of 22 , Jun 8, 2012
                          View Source
                          • 0 Attachment
                            Hristo,

                            My guess as to why you are not getting many comments is two fold ...

                            1) I don't think most folks really understand what impact the buffered vs. every frame capability has on a possible ASCOM based implementation for video observing/imaging.

                            I think most folks do not realize (or care) that buffering is already going on in most popular software and that video frames are dropped all the time. The idea that they would suddenly "might not get all the video frames" got some attention.

                            2) There just aren't that many folks who will need the ASCOM implementation (those who are using imaging and control apps that can't currently handle longer exposure video cameras). The primary reason that those imaging and control apps don't directly support video cameras is that there simply isn't a business case to do so. The majority of users seem to find that the current software options are fine for their needs. Sure there's interest since we always want more than we currently have.

                            For the record I think you should just go ahead with your second version and implement it with the buffered capabilities.


                            Mark

                            --- In ASCOM-Talk@yahoogroups.com, Hristo Pavlov <hristo_dpavlov@...> wrote:
                            >
                            > I don't know what to take from the lack of comments. I am also a little surpriced as in the previous discussions there were a number of people that wanted 'every-frame-video' approach so I thought that they would be very willing to comment on the buffering that I am proporsing?
                            >  
                            > If there are still no comments for a few more days I will have to continue to work on the second version of IVideoCamera interface and include the buffering exactly as outlined below.
                            >  
                            >  
                            > Again, I will be very happy to hear your comments and constructive critiques. So please tell me what you think.
                            >  
                            >  
                            > Cheers,
                            > Hristo Pavlov
                            > Sydney, Australia
                            >
                            >
                            > ________________________________
                            > From: Hristo Pavlov <hristo_dpavlov@...>
                            > To: "ASCOM-Talk@yahoogroups.com" <ASCOM-Talk@yahoogroups.com>
                            > Sent: Sunday, June 3, 2012 9:47 AM
                            > Subject: [ASCOM] Please comment on IVideoCamera proposed buffering
                            >
                            >
                            >
                            >  
                            >
                            > Hi All,
                            >
                            > I've been working on the second version of the IVideoCamera interface and came upong a usecase for video that changed things a little. There are meteor observers that have unattended video cameras and software that operates them called MetRec. The software analyses the video in realtime and if it detects a meteor it records a short video of the meteor. It also platesolves it and writes in a file the position of the appearance and disappearance along with the time. One of the issues with MetRec is that it supports only one frame grabber which is quite old now and very difficult to find (only old items on e-bay). If there was an ASCOM interface for video then MetRec could be extended and could work with many more devices without a need to change anything.
                            >
                            > However the current version of IVideoCamera is not ideal for this type of meteor observing. Propbably 5fps would be sufficient to do analysis and record video with some missing frames. After all the observers are only after the time, position and direction of the trail and this can be determined only by 3 frames. However for some very fast meteors this may be insufficient. Also I remember that a number of people were not very happy with the fact that my proposal couldn't handle all video frames for viewing or realtime processing. So I though about this and I would like to propose a simple buffering that will allow retreival of all video frames for viewing or realtime processing. Of course this can be only possible if the hardware can manage it and if the driver decides to implemen it. Here is what I propose.
                            >
                            > - Add two new properties, for example called VideoFrameBufferSize and MaximumVideoFrameBufferSize
                            >
                            > - The client to continue and use a pull mechanism to retrieve video frames as fast as it can
                            >
                            > - If the VideoFrameBufferSize is set to 1 then the driver only allows the latest frame at the time of the call to be reteived i.e. it will works exactly as the previous proposed version
                            >
                            > - If MaximumVideoFrameBufferSize is also 1 this means that the driver does not support buffering and can only work in the mode as previously proposed
                            >
                            > - If the MaximumVideoFrameBufferSize is more than 1 then the driver supports buffering and setting the VideoFrameBufferSize to a value different than one will enable buffering
                            >
                            > - When buffering is enabled the driver will keep the configured number of frames in a buffer for processing and to help the client continue to work in case of delays in the hardware or the client that may prevent the client to receive all video frames. Once the buffer is full the driver will begin dropping frames by overwriting the last frame in the buffer. Please note that is generally how video processing software works even with DirectShow and other such standards. With all this if the hardware allows it the client will be able to receive all frames in buffered mode. Because frames have frame numbers it will be trivial for the client to determine if and when there are dropped frames. Usually when recording a video if a frame is dropped the recording software either duplicates the last available frame (most often) or simply doesn't include it in the video.
                            >
                            > - In buffered mode if the client asks for a frame but a frame is not available the driver will return NULL i.e. the buffer works as a queue and in a case of empty queue NULL is returned. May be in non buffered mode the driver will never return NULL (not sure about this) and will simply return the latest frame which may be the same frame as the one returned in the previous client call
                            >
                            > Generally this is roughly what I propose. It will make it possible meteor observers to use ASCOM for their work. The name of the properties and the precise way this works may be different but the idea is generally to support buffering with frame dropping. Other possible property names could include things like "CanDoVideoFrameBuffering" instead of using a special value for MaximumVideoFrameBufferSize to determine if buffering is supported. I have to say thought that I kind of like the simplicity of having only 2 extra properties.
                            >
                            > I would like to know what you all think about the proposed buffering mechanism.
                            >
                            > Regards,
                            > Hristo Pavlov
                            > Sydney, Australia
                            >
                          • Hristo Pavlov
                            Hi All,   I thought more about this and I think that very rarely a client software may want to change the buffer size on the fly as it is controlling the
                            Message 13 of 22 , Jun 14, 2012
                            View Source
                            • 0 Attachment
                              Hi All,
                               
                              I thought more about this and I think that very rarely a client software may want to change the buffer size on the fly as it is controlling the camera. The buffer size is something that will be changed based on the hardware where the client application is running so I think it is best if it is configured from the set updialog of the driver.
                               
                              In regards to this I am going to change the two properties I proposed below to: CanBufferVideoFrames and BufferVideoFrames, where the first property tells us if the driver supports buffering (in case our software requires it) and the second property is used to switch on/off the buffering using the buffer size configured in the setup dialog.
                               
                              With this we achieve the same as before but leave less things for the client software developer to worry about and simplify the usage pattern a little.
                               
                              I am still working on the second version of the IVideoCamera interface.
                               
                              Cheers,
                              Hristo Pavlov
                              Sydney, Australia

                              From: Hristo Pavlov <hristo_dpavlov@...>
                              To: "ASCOM-Talk@yahoogroups.com" <ASCOM-Talk@yahoogroups.com>
                              Sent: Sunday, June 3, 2012 9:47 AM
                              Subject: [ASCOM] Please comment on IVideoCamera proposed buffering

                               
                              Hi All,
                               
                              I've been working on the second version of the IVideoCamera interface and came upong a usecase for video that changed things a little. There are meteor observers that have unattended video cameras and software that operates them called MetRec. The software analyses the video in realtime and if it detects a meteor it records a short video of the meteor. It also platesolves it and writes in a file the position of the appearance and disappearance along with the time. One of the issues with MetRec is that it supports only one frame grabber which is quite old now and very difficult to find (only old items on e-bay). If there was an ASCOM interface for video then MetRec could be extended and could work with many more devices without a need to change anything.
                               
                              However the current version of IVideoCamera is not ideal for this type of meteor observing. Propbably 5fps would be sufficient to do analysis and record video with some missing frames. After all the observers are only after the time, position and direction of the trail and this can be determined only by 3 frames. However for some very fast meteors this may be insufficient. Also I remember that a number of people were not very happy with the fact that my proposal couldn't handle all video frames for viewing or realtime processing. So I though about this and I would like to propose a simple buffering that will allow retreival of all video frames for viewing or realtime processing. Of course this can be only possible if the hardware can manage it and if the driver decides to implemen it. Here is what I propose.
                               
                              - Add two new properties, for example called VideoFrameBufferSize and MaximumVideoFrameBufferSize
                               
                              - The client to continue and use a pull mechanism to retrieve video frames as fast as it can
                               
                              - If the VideoFrameBufferSize is set to 1 then the driver only allows the latest frame at the time of the call to be reteived i.e. it will works exactly as the previous proposed version
                               
                              - If MaximumVideoFrameBufferSize is also 1 this means that the driver does not support buffering and can only work in the mode as previously proposed
                               
                              - If the MaximumVideoFrameBufferSize is more than 1 then the driver supports buffering and setting the VideoFrameBufferSize to a value different than one will enable buffering
                               
                              - When buffering is enabled the driver will keep the configured number of frames in a buffer for processing and to help the client continue to work in case of delays in the hardware or the client that may prevent the client to receive all video frames. Once the buffer is full the driver will begin dropping frames by overwriting the last frame in the buffer. Please note that is generally how video processing software works even with DirectShow and other such standards. With all this if the hardware allows it the client will be able to receive all frames in buffered mode. Because frames have frame numbers it will be trivial for the client to determine if and when there are dropped frames. Usually when recording a video if a frame is dropped the recording software either duplicates the last available frame (most often) or simply doesn't include it in the video.
                               
                              - In buffered mode if the client asks for a frame but a frame is not available the driver will return NULL i.e. the buffer works as a queue and in a case of empty queue NULL is returned. May be in non buffered mode the driver will never return NULL (not sure about this) and will simply return the latest frame which may be the same frame as the one returned in the previous client call
                               
                              Generally this is roughly what I propose. It will make it possible meteor observers to use ASCOM for their work. The name of the properties and the precise way this works may be different but the idea is generally to support buffering with frame dropping. Other possible property names could include things like "CanDoVideoFrameBuffering" instead of using a special value for MaximumVideoFrameBufferSize to determine if buffering is supported. I have to say thought that I kind of like the simplicity of having only 2 extra properties.
                               
                              I would like to know what you all think about the proposed buffering mechanism.
                               
                              Regards,
                              Hristo Pavlov
                              Sydney, Australia


                            • paulkccd
                              Hristo, as one of those that previously asked for a frame-by-frame access. In fact, object detection was exactly one of the applications that motivated my
                              Message 14 of 22 , Jun 15, 2012
                              View Source
                              • 0 Attachment
                                Hristo, as one of those that previously asked for a frame-by-frame access. In fact, object detection was exactly one of the applications that motivated my original request.

                                A buffer is what I thought drivers would have to implement to allow this functionality (fixed or dynamic), but this should be transparent to the ASCOM client. Buffer, buffer size, etc., should be left up to the internal driver implementation and not exposed through the ASCOM interface, IMO.

                                Regards,

                                -Paul

                                --- In ASCOM-Talk@yahoogroups.com, Hristo Pavlov <hristo_dpavlov@...> wrote:
                                >
                                > I don't know what to take from the lack of comments. I am also a little surpriced as in the previous discussions there were a number of people that wanted 'every-frame-video' approach so I thought that they would be very willing to comment on the buffering that I am proporsing?
                                >  
                                > If there are still no comments for a few more days I will have to continue to work on the second version of IVideoCamera interface and include the buffering exactly as outlined below.
                                >  
                                >  
                                > Again, I will be very happy to hear your comments and constructive critiques. So please tell me what you think.
                                >  
                                >  
                                > Cheers,
                                > Hristo Pavlov
                                > Sydney, Australia
                                >
                                >
                                > ________________________________
                                > From: Hristo Pavlov <hristo_dpavlov@...>
                                > To: "ASCOM-Talk@yahoogroups.com" <ASCOM-Talk@yahoogroups.com>
                                > Sent: Sunday, June 3, 2012 9:47 AM
                                > Subject: [ASCOM] Please comment on IVideoCamera proposed buffering
                                >
                                >
                                >
                                >  
                                >
                                > Hi All,
                                >
                                > I've been working on the second version of the IVideoCamera interface and came upong a usecase for video that changed things a little. There are meteor observers that have unattended video cameras and software that operates them called MetRec. The software analyses the video in realtime and if it detects a meteor it records a short video of the meteor. It also platesolves it and writes in a file the position of the appearance and disappearance along with the time. One of the issues with MetRec is that it supports only one frame grabber which is quite old now and very difficult to find (only old items on e-bay). If there was an ASCOM interface for video then MetRec could be extended and could work with many more devices without a need to change anything.
                                >
                                > However the current version of IVideoCamera is not ideal for this type of meteor observing. Propbably 5fps would be sufficient to do analysis and record video with some missing frames. After all the observers are only after the time, position and direction of the trail and this can be determined only by 3 frames. However for some very fast meteors this may be insufficient. Also I remember that a number of people were not very happy with the fact that my proposal couldn't handle all video frames for viewing or realtime processing. So I though about this and I would like to propose a simple buffering that will allow retreival of all video frames for viewing or realtime processing. Of course this can be only possible if the hardware can manage it and if the driver decides to implemen it. Here is what I propose.
                                >
                                > - Add two new properties, for example called VideoFrameBufferSize and MaximumVideoFrameBufferSize
                                >
                                > - The client to continue and use a pull mechanism to retrieve video frames as fast as it can
                                >
                                > - If the VideoFrameBufferSize is set to 1 then the driver only allows the latest frame at the time of the call to be reteived i.e. it will works exactly as the previous proposed version
                                >
                                > - If MaximumVideoFrameBufferSize is also 1 this means that the driver does not support buffering and can only work in the mode as previously proposed
                                >
                                > - If the MaximumVideoFrameBufferSize is more than 1 then the driver supports buffering and setting the VideoFrameBufferSize to a value different than one will enable buffering
                                >
                                > - When buffering is enabled the driver will keep the configured number of frames in a buffer for processing and to help the client continue to work in case of delays in the hardware or the client that may prevent the client to receive all video frames. Once the buffer is full the driver will begin dropping frames by overwriting the last frame in the buffer. Please note that is generally how video processing software works even with DirectShow and other such standards. With all this if the hardware allows it the client will be able to receive all frames in buffered mode. Because frames have frame numbers it will be trivial for the client to determine if and when there are dropped frames. Usually when recording a video if a frame is dropped the recording software either duplicates the last available frame (most often) or simply doesn't include it in the video.
                                >
                                > - In buffered mode if the client asks for a frame but a frame is not available the driver will return NULL i.e. the buffer works as a queue and in a case of empty queue NULL is returned. May be in non buffered mode the driver will never return NULL (not sure about this) and will simply return the latest frame which may be the same frame as the one returned in the previous client call
                                >
                                > Generally this is roughly what I propose. It will make it possible meteor observers to use ASCOM for their work. The name of the properties and the precise way this works may be different but the idea is generally to support buffering with frame dropping. Other possible property names could include things like "CanDoVideoFrameBuffering" instead of using a special value for MaximumVideoFrameBufferSize to determine if buffering is supported. I have to say thought that I kind of like the simplicity of having only 2 extra properties.
                                >
                                > I would like to know what you all think about the proposed buffering mechanism.
                                >
                                > Regards,
                                > Hristo Pavlov
                                > Sydney, Australia
                                >
                              • Hristo Pavlov
                                Hi Paul,   Yes I also got to the same conclusion. By default the client will not want to deal with buffer. Also even the buffer size is very important for
                                Message 15 of 22 , Jun 17, 2012
                                View Source
                                • 0 Attachment
                                  Hi Paul,
                                   
                                  Yes I also got to the same conclusion. By default the client will not want to deal with buffer. Also even the buffer size is very important for performance and to minimize droppped frames, it will rarely change once it has been setup for a particular hardware and software.
                                   
                                  So I decided to leave the buffer size for the setup dialog but keep a readonly property in the IVideoCamera that will tell the client whether a buffer is used and what is the size. This is going to be important for the small number of specialized software that will heavily rely on buffering. At the same time I still have my view that generally drivers will not have to worry about implementing buffering for the vast magority of the clients and decided to leave it to the driver developer whether to support buffering or not.
                                   
                                  Obviously if your client software relies on buffering it will require a driver that supports it.
                                   
                                  Cheers,
                                   
                                  Hristo Pavlov
                                  Sydney, Australia

                                  From: paulkccd <yh@...>
                                  To: ASCOM-Talk@yahoogroups.com
                                  Sent: Saturday, June 16, 2012 12:16 PM
                                  Subject: Re: [ASCOM] Please comment on IVideoCamera proposed buffering

                                   
                                  Hristo, as one of those that previously asked for a frame-by-frame access. In fact, object detection was exactly one of the applications that motivated my original request.

                                  A buffer is what I thought drivers would have to implement to allow this functionality (fixed or dynamic), but this should be transparent to the ASCOM client. Buffer, buffer size, etc., should be left up to the internal driver implementation and not exposed through the ASCOM interface, IMO.

                                  Regards,

                                  -Paul

                                  --- In mailto:ASCOM-Talk%40yahoogroups.com, Hristo Pavlov <hristo_dpavlov@...> wrote:
                                  >
                                  > I don't know what to take from the lack of comments. I am also a little surpriced as in the previous discussions there were a number of people that wanted 'every-frame-video' approach so I thought that they would be very willing to comment on the buffering that I am proporsing?
                                  >  
                                  > If there are still no comments for a few more days I will have to continue to work on the second version of IVideoCamera interface and include the buffering exactly as outlined below.
                                  >  
                                  >  
                                  > Again, I will be very happy to hear your comments and constructive critiques. So please tell me what you think.
                                  >  
                                  >  
                                  > Cheers,
                                  > Hristo Pavlov
                                  > Sydney, Australia
                                  >
                                  >
                                  > ________________________________
                                  > From: Hristo Pavlov <hristo_dpavlov@...>
                                  > To: "mailto:ASCOM-Talk%40yahoogroups.com" <mailto:ASCOM-Talk%40yahoogroups.com>
                                  > Sent: Sunday, June 3, 2012 9:47 AM
                                  > Subject: [ASCOM] Please comment on IVideoCamera proposed buffering
                                  >
                                  >
                                  >
                                  >  
                                  >
                                  > Hi All,
                                  >
                                  > I've been working on the second version of the IVideoCamera interface and came upong a usecase for video that changed things a little. There are meteor observers that have unattended video cameras and software that operates them called MetRec. The software analyses the video in realtime and if it detects a meteor it records a short video of the meteor. It also platesolves it and writes in a file the position of the appearance and disappearance along with the time. One of the issues with MetRec is that it supports only one frame grabber which is quite old now and very difficult to find (only old items on e-bay). If there was an ASCOM interface for video then MetRec could be extended and could work with many more devices without a need to change anything.
                                  >
                                  > However the current version of IVideoCamera is not ideal for this type of meteor observing. Propbably 5fps would be sufficient to do analysis and record video with some missing frames. After all the observers are only after the time, position and direction of the trail and this can be determined only by 3 frames. However for some very fast meteors this may be insufficient. Also I remember that a number of people were not very happy with the fact that my proposal couldn't handle all video frames for viewing or realtime processing. So I though about this and I would like to propose a simple buffering that will allow retreival of all video frames for viewing or realtime processing. Of course this can be only possible if the hardware can manage it and if the driver decides to implemen it. Here is what I propose.
                                  >
                                  > - Add two new properties, for example called VideoFrameBufferSize and MaximumVideoFrameBufferSize
                                  >
                                  > - The client to continue and use a pull mechanism to retrieve video frames as fast as it can
                                  >
                                  > - If the VideoFrameBufferSize is set to 1 then the driver only allows the latest frame at the time of the call to be reteived i.e. it will works exactly as the previous proposed version
                                  >
                                  > - If MaximumVideoFrameBufferSize is also 1 this means that the driver does not support buffering and can only work in the mode as previously proposed
                                  >
                                  > - If the MaximumVideoFrameBufferSize is more than 1 then the driver supports buffering and setting the VideoFrameBufferSize to a value different than one will enable buffering
                                  >
                                  > - When buffering is enabled the driver will keep the configured number of frames in a buffer for processing and to help the client continue to work in case of delays in the hardware or the client that may prevent the client to receive all video frames. Once the buffer is full the driver will begin dropping frames by overwriting the last frame in the buffer. Please note that is generally how video processing software works even with DirectShow and other such standards. With all this if the hardware allows it the client will be able to receive all frames in buffered mode. Because frames have frame numbers it will be trivial for the client to determine if and when there are dropped frames. Usually when recording a video if a frame is dropped the recording software either duplicates the last available frame (most often) or simply doesn't include it in the video.
                                  >
                                  > - In buffered mode if the client asks for a frame but a frame is not available the driver will return NULL i.e. the buffer works as a queue and in a case of empty queue NULL is returned. May be in non buffered mode the driver will never return NULL (not sure about this) and will simply return the latest frame which may be the same frame as the one returned in the previous client call
                                  >
                                  > Generally this is roughly what I propose. It will make it possible meteor observers to use ASCOM for their work. The name of the properties and the precise way this works may be different but the idea is generally to support buffering with frame dropping. Other possible property names could include things like "CanDoVideoFrameBuffering" instead of using a special value for MaximumVideoFrameBufferSize to determine if buffering is supported. I have to say thought that I kind of like the simplicity of having only 2 extra properties.
                                  >
                                  > I would like to know what you all think about the proposed buffering mechanism.
                                  >
                                  > Regards,
                                  > Hristo Pavlov
                                  > Sydney, Australia
                                  >



                                • Hristo Pavlov
                                  Hi All,   I have been thinking about how to implement getting and setting custom video camera properties such as temperature, white ballance etc. The obvious
                                  Message 16 of 22 , Jun 19, 2012
                                  View Source
                                  • 0 Attachment
                                    Hi All,
                                     
                                    I have been thinking about how to implement getting and setting custom video camera properties such as temperature, white ballance etc. The obvious way to doing this would be using the SupportedActions and Action members where I would have the following actions:
                                     
                                    VideoCamera:GetTemperature
                                    VideoCamera:GetWhiteBalance
                                    VideoCamera:SetWhiteBalance
                                     
                                    I was however thinking that it would be more natural if there was another generic set ot methods for example called: GetCustomProperty, SetCustomProperty, SupportedCustomProperties and I would pass the property names
                                     
                                    VideoCamera:Temperature
                                    VideoCamera:WhiteBalance
                                     
                                    The difference is small and I am not sure whether adding new members is the best thing to do but also it looks more natural to me.
                                     
                                    What do you guys think?
                                     
                                    Regards,
                                    Hristo Pavlov
                                    Sydney, Australia
                                  • Tim Long
                                    Probably not. Unless I m missing the point, the only net difference is a little syntactic sugar . I don t think the benefit justifies the additional
                                    Message 17 of 22 , Jun 19, 2012
                                    View Source
                                    • 0 Attachment

                                      Probably not. Unless I’m missing the point, the only net difference is a little ‘syntactic sugar’. I don’t think the benefit justifies the additional complexity.

                                                                                                                                                                                                                                                                            

                                      If the interface feels too awkward, it would be pretty trivial for an app to add those semantics by inheriting from the driver class and adding the *Property methods itself.

                                       

                                      Regards,

                                      Tim Long

                                       

                                      From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf Of Hristo Pavlov
                                      Sent: 20 June 2012 00:00
                                      To: ASCOM-Talk@yahoogroups.com
                                      Subject: [ASCOM] IVideoCamera - Generic Action vs Generic Property

                                       




                                      Hi All,

                                       

                                      I have been thinking about how to implement getting and setting custom video camera properties such as temperature, white ballance etc. The obvious way to doing this would be using the SupportedActions and Action members where I would have the following actions:

                                       

                                      VideoCamera:GetTemperature

                                      VideoCamera:GetWhiteBalance

                                      VideoCamera:SetWhiteBalance

                                       

                                      I was however thinking that it would be more natural if there was another generic set ot methods for example called: GetCustomProperty, SetCustomProperty, SupportedCustomProperties and I would pass the property names

                                       

                                      VideoCamera:Temperature

                                      VideoCamera:WhiteBalance

                                       

                                      The difference is small and I am not sure whether adding new members is the best thing to do but also it looks more natural to me.

                                       

                                      What do you guys think?

                                       

                                      Regards,

                                      Hristo Pavlov

                                      Sydney, Australia





                                      ExchangeDefender Message Security: Check Authenticity
                                      Complete email hygiene and business continuity solution available from TiGra Networks
                                      Before replying, please review our email policy



                                    • Peter Simpson
                                      Hi Hristo, I think it would be more straightforward to use the features that we added in the latest interface specifications for precisely this purpose.
                                      Message 18 of 22 , Jun 19, 2012
                                      View Source
                                      • 0 Attachment
                                        Hi Hristo,

                                        I think it would be more straightforward to use the features that we added in the latest interface specifications for precisely this purpose. Actions and SupportedActions  are part of the core interface command set that is common to all driver interfaces from Platform 6 onwards.

                                        I think it would be a better approach to use the existing capabilities rather than to re-invent them with the same capability and a slightly different presentation. We deliberately chose not to make the capability more specific in order to allow maximum freedom of use.

                                        Regards, Peter

                                        --- In ASCOM-Talk@yahoogroups.com, Hristo Pavlov <hristo_dpavlov@...> wrote:
                                        >
                                        > Hi All,
                                        >  
                                        > I have been thinking about how to implement getting and setting custom video camera properties such as temperature, white ballance etc. The obvious way to doing this would be using the SupportedActions and Action members where I would have the following actions:
                                        >  
                                        > VideoCamera:GetTemperature
                                        > VideoCamera:GetWhiteBalance
                                        > VideoCamera:SetWhiteBalance
                                        >  
                                        > I was however thinking that it would be more natural if there was another generic set ot methods for example called: GetCustomProperty, SetCustomProperty, SupportedCustomProperties and I would pass the property names
                                        >  
                                        > VideoCamera:Temperature
                                        > VideoCamera:WhiteBalance
                                        >  
                                        > The difference is small and I am not sure whether adding new members is the best thing to do but also it looks more natural to me.
                                        >  
                                        > What do you guys think?
                                        >  
                                        > Regards,
                                        > Hristo Pavlov
                                        > Sydney, Australia
                                        >
                                      Your message has been successfully submitted and would be delivered to recipients shortly.