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

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

Expand Messages
  • rdobosz@rogers.com
    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
    Message 1 of 22 , May 10, 2012
    View Source
    • 0 Attachment
      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 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
      Message 2 of 22 , May 11, 2012
      View Source
      • 0 Attachment
        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 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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.