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

Re: [ASCOM] PulseGuiding & I- am I missing something?

Expand Messages
  • johansea
    One other thing to worry about is how the scope firmware itself works ;-) Ie in some versions of the Meades, in Polar, a 100ms pulseguide in DEC can really
    Message 1 of 19 , Feb 2, 2013
    • 0 Attachment
      One other thing to worry about
      is how the scope firmware itself works ;-)

      Ie in some versions of the Meades, in Polar, a 100ms pulseguide in DEC can really take 800ms to complete, esp if DEC reversals are triggered as part of the process.
      Sending new guide commands whilst the reversing is in progress can effectively kill the lash application and you get odd results.
      In RA, a 500ms guide might only take 50ms to apply if speeding up and 250ms to apply if slowing down, so in that scenario, you can actually up the rates if reqd .
      A correctly written driver may be able to account for this
      using a flag ( ie Is Pulseguiding ), thus giving better control.
      Not sure whoever wrote the Meade driver would be able to utilise this knowledge tho :-)

      Andrew Johansen Melbourne Australia

      PS Now the latest Audiostar firmwares allow pulseguiding in AltAz,
      the timings can go up to rather large numbers if the pulseguide requires the motor to slow down, and its going at a glacial rate.
      Its a ratsnest to purely rely on the "time" specified for a "pulse"guide



      --- In ASCOM-Talk@yahoogroups.com, "Ray Gralak" wrote:
      >
      > > But frankly I see no reasons to use IsPulseGuiding: the software knows the durations of the last corrections it has
      > > sent (for RA and Dec) and it can wait the maximum of these durations before taking a new guiding exposure without
      > > asking anything to the driver...
      > > With hardware not capable to make simultaneous correction I still see no need to use IsPulseGuiding.
      >
      > http://tech.groups.yahoo.com/group/ASCOM-Talk/message/5287
      >
      > -Ray Gralak
      > Author of Astro-Physics Command Center (APCC)
      > Author of PEMPro: http://www.ccdware.com
      > Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
      > Author of PulseGuide: http://www.pulseguide.com
      > Author of Sigma: http://www.gralak.com/sigma
      >
      >
      > > -----Original Message-----
      > > From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf Of armando_unina
      > > Sent: Thursday, January 31, 2013 6:47 PM
      > > To: ASCOM-Talk@yahoogroups.com
      > > Subject: [ASCOM] PulseGuiding & I- am I missing something?
      > >
      > >
      > >
      > > Hi,
      > >
      > > I gave a look at ASCOM documentation.
      > > IsPulseGuiding method should return true with pulseguiding in progress; PulseGuide method should return
      > > immediately if the hardware is capable of back-to-back moves, i.e. dual-axis moves.
      > > I assume guiding software, in case of hardware capable of simultaneous guiding correction, should make only one
      > > IsPulseGuiding call for each couple of PulseGuide calls (on RA and Dec axis).
      > >
      > > But frankly I see no reasons to use IsPulseGuiding: the software knows the durations of the last corrections it has
      > > sent (for RA and Dec) and it can wait the maximum of these durations before taking a new guiding exposure without
      > > asking anything to the driver...
      > > With hardware not capable to make simultaneous correction I still see no need to use IsPulseGuiding.
      > >
      > > Ok, there could be a delay in making a correction and maybe the need to check by an IsPulseGuiding call.
      > >
      > > But why doesn't ASCOM interface provide a method to command guiding in both directions (e.g. void
      > > CombPulseGuide(int RA_ms, int Dec_ms) )?? (RA_ms sign could be used for RA+ and RA-; the same for Dec)
      > > Another method could be added just to check it the controller is capable to guide simultaneously (e.g. a
      > > CanComboPulseGuide).
      > >
      > > Am I missing something?
      > >
      > >
      > >
      > >
      >
    • armando_unina
      According to Ray Gralak and Andrew Johansen answers to my message, I see a possible guiding improvement in using a variable guiding speed to speed up the
      Message 2 of 19 , Feb 4, 2013
      • 0 Attachment
        According to Ray Gralak and Andrew Johansen answers to my message, I see a possible guiding improvement in using a variable guiding speed to speed up the correction (i.e. a guide rate that increases with the error amount). This is obviously related to (and limited by) the mount controller capabilities.

        How do common guiding software (e.g. PHD, Maxim, CCDSoft, ...) work?
        Do they rely on polling the mount controller by IsPulseGuiding without using any timers?

        Clear Skies!
        Armando Beneduce
      • Chris Peterson
        With one mount (using a custom controller and custom guide software) I have incorporated a PID control system (standard for just about every control system in
        Message 3 of 19 , Feb 4, 2013
        • 0 Attachment
          With one mount (using a custom controller and custom guide software) I
          have incorporated a PID control system (standard for just about every
          control system in the last century, except for telescope guiding, which
          is mired in the 19th century for amateur setups).

          Amongst other things, the PID controller manages both the speed and
          duration of corrections, optimizing the two. The improvement in guiding
          performance is substantial. The system operated with proportional
          control using just timing (how all guiding currently works) produces P-P
          errors of 0.5 arcsec. With proportional control using just speed (which
          is what you are looking at), the P-P guiding error drops to 0.1 arcsec.
          With PID control using timing and speed the error is below 0.05 arcsec.

          There is room for a vast improvement in guiding performance and ease of
          use (the PID system is adaptive, and requires no operator fine tuning).
          Unfortunately, there's a chicken-and-egg problem, in that mount makers
          aren't producing more sophisticated controllers because of the absence
          of software to manage them, and software makers aren't writing more
          sophisticated guiding code because no mounts can support it.

          Chris

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

          On 2/4/2013 8:02 AM, armando_unina wrote:
          >
          >
          > According to Ray Gralak and Andrew Johansen answers to my message, I see a possible guiding improvement in using a variable guiding speed to speed up the correction (i.e. a guide rate that increases with the error amount). This is obviously related to (and limited by) the mount controller capabilities.
          >
          > How do common guiding software (e.g. PHD, Maxim, CCDSoft, ...) work?
          > Do they rely on polling the mount controller by IsPulseGuiding without using any timers?
          >
          > Clear Skies!
          > Armando Beneduce
        • Chris
          I would expect any rational application to send PulseGuide commands followed by at least one IsPulseGuiding command and I d expect there to be a short delay
          Message 4 of 19 , Feb 4, 2013
          • 0 Attachment
            I would expect any rational application to send PulseGuide commands followed by at least one IsPulseGuiding command and I'd expect there to be a short delay between each IsPulseGuiding command so that the underlying hardware isn't stressed too much, something like:

            scope.PulseGuide(EWDirection, raDuration);
            scope.PulseGuide(NSDirection, decDuration);
            // maybe wait here until the guides should have finished
            Thread.Sleep(Math.Max(raDuration, decDuration);
            While (scope.IsPulseGuiding)
            {
            Thread.Sleep(50);
            }
            When you get here the pulseguide round has finished.

            I'd be very cautions about trying something like varying the guide rate to speed up large corrections because it's not something that drivers expect and you could be letting yourself in for a load of support issues.

            One way to find out for sure would be to use something with a traffic monitor such as POTH to see what these applications really do.

            Chris

            --- In ASCOM-Talk@yahoogroups.com, "armando_unina" wrote:
            >
            >
            >
            > According to Ray Gralak and Andrew Johansen answers to my message, I see a possible guiding improvement in using a variable guiding speed to speed up the correction (i.e. a guide rate that increases with the error amount). This is obviously related to (and limited by) the mount controller capabilities.
            >
            > How do common guiding software (e.g. PHD, Maxim, CCDSoft, ...) work?
            > Do they rely on polling the mount controller by IsPulseGuiding without using any timers?
            >
            > Clear Skies!
            > Armando Beneduce
            >
          • johansea
            Gday Armando Just for info, i just wanted to point out that you need to understand ( in detail ) how the scope itself implements a pulseguide . There are now
            Message 5 of 19 , Feb 4, 2013
            • 0 Attachment
              Gday Armando

              Just for info, i just wanted to point out that you need to understand ( in detail ) how the scope itself implements a "pulseguide".
              There are now at least three different ways the Meades work, depending on type of handbox and firmware loaded. Its a ratsnest in what "really" happens.

              Andrew Johansen Melbourne Australia

              --- In ASCOM-Talk@yahoogroups.com, "armando_unina" wrote:
              >
              >
              >
              > According to Ray Gralak and Andrew Johansen answers to my message, I see a possible guiding improvement in using a variable guiding speed to speed up the correction (i.e. a guide rate that increases with the error amount). This is obviously related to (and limited by) the mount controller capabilities.
              >
              > How do common guiding software (e.g. PHD, Maxim, CCDSoft, ...) work?
              > Do they rely on polling the mount controller by IsPulseGuiding without using any timers?
              >
              > Clear Skies!
              > Armando Beneduce
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.