Tag Archives: PEC

Testing unguided performance

Leave a reply

Sunday night I used the removable dome cover (via the PZT) to enable two automated TPoint data-collection runs.  (The PZT makes this practical because I can start the run and then go indoors while it operates.  Before the PZT I had to stay in the observatory and adjust the dome position for every “sweep” of data.  This was both inconvenient, and also probably affecting the results through the vibration of moving the dome.)

The first run was 56 data points, just used to refine polar alignment, which was reported as “Excellent” in azimuth and needing small adjustment in altitude.  After doing the polar adjustment, I did another, large, TPoint run of 360 data points. This confirmed polar alignment was now excellent in both axes, and I then used this to build a high-quality TPoint “supermodel”.

What’s all that mean?  It means that

  • The scope control system now has a detailed model of how theoretical and actual pointing of the telescope differed at 360 different locations around the sky.  The recorded differences indicate where alignment is off, where something is loose or sagging, where non-linearities in the optical system affect pointing, etc.
  • Using this model, the scope control system can compensate, resulting in extremely accurate go-to pointing anywhere in the sky.
  • A feature called ProTrack also uses this model to adjust the drive tracking of the scope while it is in operation, keeping tracking accurate without the use of Autoguiding.  (This doesn’t prevent autoguiding, or PEC;  all 3 can be used together, and each contributes something to the accuracy of tracking.)

With a good TPoint model and ProTrack, the mount is supposed to be capable of unguided imaging of fairly long exposures.  I decided to test that, by taking unguided images of M15 of various exposure lengths.  In the following images, PEC, TPoint, and Protrack are turned on, but not autoguiding.  These are unprocessed.

Before PEC, TPoint ,and Protrack, 20 seconds would be the longest I could go without noticing distortion in star shapes.

To my eye, the above are showing no star distortion up to and including the 300-second (5-minute) exposure, but the 600-second (10-minute) one is starting to show distortion.  So it would seem I can do unguided imaging for exposures up to, and slightly over, 300 seconds.  Wow.

Confirmed, the new RA worm is working well

Leave a reply

Finally another clear night presented itself last night, and I replicated my testing of PE with the new RA worm block in place.

I tried data gathering with longer exposures, but didn’t like what it was telling me, then realized I was on the wrong track anyway;  I should keep my data gathering to short exposures and let the fact that I am averaging the PE over multiple worm cycles handle smoothing out the seeing.  This is consistent with all the advice in the Bisque support forum too.  So I increased to gathering more worm cycles – 7 cycles.

Uncorrected, the worm is averaging out at 1.2 arcseconds peak-to-peak, and even looking at the raw data, the worst case swing is 2.9 arcseconds. That difference shows the seeing jitter.  This is really good performance – the guaranteed spec from Bisque is 7 arcseconds, so the worm is ‘way outperforming that, and is below seeing.

Then another 7 cycles with PEC turned on:0.4 arcseconds peak-to-peak residual error with correction running (averaged out over the 7 worm cycles), with max including big seeing spikes of 2 arcseconds.

Wow.

I tried a quick image with guiding turned on.  I’ve lost the guider log, but with 3-second guide exposures and light aggressiveness (40%) it was holding the image to under 1/2 pixel.  The resulting image in this 5-minute exposure has nice round stars:

This seems to be avoiding an obvious question: what does an unguided image of some substantial length look like? I didn’t see the point of doing that test yet, since unguided imaging is substantially enhanced by ProTack, which I haven’t configured yet.

Next clear night (several days away) i’ll do a small TPoint run to re-check polar alignment, then a large TPoint run to build a good model, then do some experiments with PEC, TPoint, and ProTrack all turned on, to see how long unguided exposures can be.

These TPoint runs will be much easier, and more accurate, now that I have installed the SkyShed’s PZT so I can roll the roof right out of the way.  Previous TPoint runs involved having to chase the scope around the sky with roof rotation – both inconvenient, and also likely introducing vibration.

New RA gear: looking good

1 Reply

The new RA worm block is installed, and I had time for a brief test.  Testing was cut short because of a sudden cloud-over, but looked pretty good.  Next clear night I have a bit more testing to do.

Recall that I was unable, with all previous adjustments, to get uncorrected Periodic Error consistently below about 7.5 arcseconds peak-peak.  For example:

With the new worm block in place, here is a first uncorrected PE data collection:

This is incredible – 1.5 arcseconds peak-peak, with no correction being applied.  More in a moment on why the curve is so jagged, but this is certainly great performance.

Then I loaded the above as a correction curve, and did another data collection with PEC turned on:

1 arcsecond, peak-to-peak.  The wild fluctuation that is just visible on the right edge of the graph is when the guide star was lost when the clouds suddenly moved in.  I deleted those data points to get this graph – but I guess I missed one.

Both of these – uncorrected and corrected – are, in fact, error smaller than the seeing fluctuation I have on a typical night.  I think that’s why the curves are jagged – that’s seeing bouncing around.

I was going to test this theory, when it suddenly clouded over.  So next clear night, I’ll do another set of runs (uncorrected and corrected) but with guiding exposures of 3 or 4 seconds.  The long exposures should “smear” seeing jitters out and, if I’m right about the effect of seeing, should produce smoother curves.  I’m looking forward to testing this.

I’d also like to do another data run just to convince myself that this isn’t “too good to be true”.  Did I do something wrong that resulted in this excellent performance?   I don’t think so, but I’d like to replicate.  Adding guiding to a PE of 1 arcsecond should produce a very stable image.  In fact, I’m interested in seeing how long an exposure I can use unguided – that would certainly be convenient.

Standby for another clear night.  Looking out the window, that’s not tonight.

Starting Mount Forensics and Maintenance

1 Reply

It’s time to admit I have a mount performance problem

I am so impressed with the build quality of the MX mount that I’ve been reluctant to admit that there seems to be a performance issue showing up in my data. I think I’m ready to admit that now.

  • There is pretty good evidence of a problem;
  • I’m pretty sure it’s a rather basic problem, likely easily correctible (but only once I admit I have a problem and work on it);
  • The SB support forums show excellent responses from both manufacturer and other users, and every problem someone reports and works through seems to be solved.

Symptoms of one or more problems

There are a couple of things that I’m sure are indications of problems, although it remains to be seen if there is a single underlying problem or several. The symptoms are

Periodic Error (PE) is out of spec.

2015-06-19-Problem-16.8-Analysis.009

uncorrected periodic error 12 arc-seconds peak-to-peak

I gathered data incorrectly several times (mainly by forgetting to record the camera rotation angle, or to ensure it was 0 or 180), so it took me a while to see this. However, now I have reliable data showing I’m getting uncorrected Period Error of almost 12 arcseconds, peak to peak.

The spec for the mount is “maximum 7 arcseconds, peak to peak”. And this isn’t just marketing hype – most Paramounts do much better, and the SB support forums are full of examples of SB being horrified in the rare case when someone’s mount exceeds this spec, and of SB taking it seriously to correct it.

2015-06-19-Corrected-5.6-Analysis.012

Corrected periodic error, 3.9 arc-seconds peak-to-peak

Note that with Periodic Error Correction (PEC) active, the mount tracks at 3.9 arc seconds, which is quite good. However, I think I should work on getting the uncorrected performance into spec.

    • Surely if I get uncorrected performance as good as possible, then PEC should improve corrected performance even more; and
    • Surely being out-of-spec means something is wrong, and that problem could have other effects that show up in results, or that cause wear and tear on the mount’s drive mechanism.

So, I’ve resolved to work on this, with the minimum target of getting uncorrected PE into spec.

Strange Dec oscillation when guiding

Next, I’m getting very strange behaviour in the Declination axis when auto-guiding. At this point I don’t have a good theory for whether this is the same problem as the PE above, or a separate problem.

When autoguiding, there is no reason why there should be Dec motion or Dec corrections at all unless Polar Alignment is off, or unless ProTrack is enabled and making corrections that it thinks are needed.

Simulation of strange behaviour seen in guidingWhat I’m seeing in Declination is large-scale, slow-period oscillation in the Dec axis. Dec shows as being several arc-seconds off, but multiple successive autoguiding periods don’t seem to be able to correct it. Then it suddenly swings over to being several arc-seconds off on the other side of the axis. At no point does it converge to a “no or small error” state. (This image is a simulation since I forgot to take screen captures the last time I did this test.)

Aside from the obvious – that this indicates something is wrong – this also means that I can’t use dithering when collecting a series of images. After the first image, guider “settling” back within a specified error range never happens. RA settles quickly, but Dec just keeps oscillating from far-off on one side to far-off on the other side.

Things that look odd but I’m not sure are symptoms of problems

The above two issues are things that I’m sure are problems. There are also a couple of other strange things going on that I’m not sure are problems, but they look odd.

TPoint-Scatter-Graph-2First, my TPoint model isn’t very good. The point-spread graph is quite spread-out, and quite oblong. This is probably just another symptom of the same problem causing the above issues. It could also be giving ProTrack ammunition to make bad adjustment decisions, compounding the problem.

Second, I note, when gathering uncorrected data for doing a PE calibration, that I’m getting a large measured declination drift, in addition to the expected periodic error in Right Ascension. I haven’t thought through the mechanics enough to know if this is normal or an indicator of a problem.

Research in support group

I spent quite a bit of time searching through the SB support forums and documents (which are not well organized, and not easy to search, by the way). Here are some miscellaneous points I’ve noted – in no particular order.

  • Polar alignment is important, of course. If it’s off, drift will occur in both axes, compounding error. (I’m quite sure mine is quite good.)
  • Camera rotation is critical when gathering data to analyse PE. It must be close to 0 or 180 degrees. If it’s in-between, PE is masked by being distributed between the RA and Dec axes. (I made this mistake several times, gathering PE data with a poor camera angle.) I note that the software could be coded to correct for this (if given the rotation value), but it isn’t.
  • ProTrack affects tracking. That’s its job; but, when diagnosing problems, start by turning it off so we’re looking at “raw” performance, and to help determine whether ProTrack (or the TPoint model that drives it) are part of the problem.

The most common causes of problems seem to be:

  1. Flexure in system (mirror flop, loose physical mounting, etc.) Externally, I’m pretty sure I have this under control, but there could be something loose inside the mount.
  2. Problems with worm gears, any of:
    • Spring tension plungers needing adjustment;
    • Cam stop needing adjustment;
    • Pivot screws being loose;
    • Various other mounting screws being loose;
    • Rarely: gears or gear assemblies needing service or replacement.
  3. There are some reports of through-the-mount cabling contributing to problems, if the cables tangle, don’t have the necessary slack, bind against internal shafts or surfaces, or “wind and unwind”, contributing force to the expected movement of the shafts.
  4. Tension on the drive belts can also be checked and adjusted. It’s not clear how incorrect tension would cause the problems I’m seeing, but it’s easy to check and it would presumably contribute to longevity of the belts to ensure it’s correct.

Hypotheses

To be confirmed by experimental corrections and measurements, my hypotheses for my problems are:

Higher-than-spec PE

I think the spring plungers on my RA worm gear are too tight. If they were too loose, it wouldn’t affect normal RA tracking (but would show up as backlash in slews, and in TPoint). Too tight, however, might be causing gear friction, stiction, or over-sensitivity to minor machining imperfections.

Through-mount cabling could also be contributing to uneven PE performance if cables are binding.

How to test this hypothesis:

  • Check TPoint model for RA backlash, which would suggest “too loose” and disprove this hypothesis;
  • Make a new PE data-gathering run after making the following checks and adjustments.
    • Temporarily remove all in-mount cabling, routing cables on the outside;
    • Adjust the RA spring tension plungers to spec;
    • While I’m in the RA gear box, adjust cam stop and confirm other mounting screws are tight.

Erratic Dec during guiding:

I think the spring plungers on my Dec gear are too loose. Backlash could be causing the non-response to guiding adjustments, and is probably also polluting the TPoint model and causing ProTrack to make adjustments. Occasional ProTrack “adjustments” could be responsible for periodically throwing the Dec error to the other side of the zero axis.

Through-mount cabling could also be contributing to uneven performance if cables are binding.

How to test this hypothesis:

  • Check TPoint model for Dec backlash, which would confirm “too loose” and support this hypothesis;
  • After fixing PE as planned above, do a new guiding test after making the following adjustments:
    • o Temporarily remove all in-mount cabling, routing cables on the outside;
    • o Adjust the Dec spring tension plungers to spec;
    • o While I’m in the Dec gear box, adjust cam stop and confirm other mounting screws are tight.

Plan to deal with it

So, here is the plan to work through this problem. The plan will need adjustments as data come in.

  1. Change mount-to-pier fastening (see post of 2018-4-14)
  2. Remove through-mount cabling.
    (Temporarily – I like it, and hope to be able to restore it once I understand its role, if any, in the problem.)
  3. Check and adjust Cam-Stop on both axes
  4. Check tightness of worm-end pivot screws, both axes
  5. Check that RA and Dec worm plungers are adjusted to spec.
    It wasn’t easy to find out what the spec is: the SB documentation isn’t well organized. The specs are:

    • Cam Stop 1/8 turn back from bottomed out (measured with clutch in “run mode”);
    • Spring tension plungers: 3 to 3.5 turns back from bottomed out. (measured with clutch in “balance mode”)
  6. Check belt tightness, both axes
  7. Do a new 20-30 point TPoint run to verify polar alignment is good
  8. Carefully record uncorrected Periodic Error
    • double-check camera angle is 0 or 180
    • double-check PEC, TPoint, ProTrack, and Guiding Relays are off
    • keep a plate-solved image to verify camera angle and image scale
    • keep the gathered guiding log, and a screen shot of the data gathering graph
    • hoping, with above adjustments, PE will fall in spec; get help if not
  9. Upload PE Correction and record results
    • double-check “west side of mount” checkbox is correct
    • do a PE recording with PEC on but TPoint and ProTrack still off
    • keep the gathered guiding log, and a screen shot of the data gathering graph
    • residual error should be on order of 1 arcsecond
  10. Carefully record an autoguiding run
    • compute autoguider correction parameters with CCDWare calculator
    • hoping strange Dec issues gone; get help if not
  11. Reset TPoint
    • do a new large run (150+ stars) and supermodel
    • verify if it still thinks I have good polar alignment
    • test unguided tracking, with PEC and ProTrack on
    • test guided tracking with PEC and ProTrack
  12. Restore through-mount cabling
    Replace through-mount cabling, one cable at a time, verifying PE and guiding after each. This will be a slow and painful process, that I’ll work at as other reasons to take OTA off mount arise.

PEC, Autoguiding stars, and a test image of M81/82.

Leave a reply

It was clear last night, quite warm, although seeing and transparency were poor. More testing and calibration, and some real progress was achieved.

Better PEC

Now that I have focus perfect, and given my suspicion that I may be doing unguided imaging with this short refractor, I decided to re-do my PEC calibration. This time I used the main camera to get cooling and higher resolution. I captured about six worm cycles of data and recalculated the model.

Gathering data like this can be done before it is completely dark, so it was a good way to spend the hour of dusk while waiting for the sky to become completely dark. In the process, I noted two important things:

  1. Somehow, my TPoint model is off, even though it was near-perfect the other night. I needed to use a closed-loop slew to get to what should have been easy targets. I imagine I bumped something the other night while I was disconnecting and reconnecting the guide camera multiple times. Next testing evening, I will first try doing a re-synchronization and then, if necessary, a completely new TPoint model.
  2. SV80S-Field-CurvatureAlso, in the process of doing full-frame images with the large QSI camera, I can clearly see the field curvature. The extreme edges of the field are badly distorted, confirming this as the likely cause of the distorted stars I’m seeing in the guide camera, which is even farther from the center of the field.

So, I think I’m not going to worry about correcting those guide camera stars now, but, rather, see what I can do with unguided imaging. After all, this is a very stable mount, and I’m presently using a very short focal-length imaging scope.

Testing Unguided Imaging Limits

So, I slewed to a nice test image – a spot midway between M81 and M82 – and took test images at 10, 60, 100, 200, 300, 400, 500, and 600 seconds, with PEC on but no guiding. Those images, calibrated, are here:

Ignore the badly distorted stars at the upper left edge of the field, and look at the center. While I think I may have a minor collimation issue with the camera, I can see no difference between the stars in the 10-second image and those in the 10-minute image. With this mount and scope, I clearly don’t need Autoguiding for exposures in the 5-10 minute range. So, I’m going to shelf my calibration of the Autoguider until later in the season when I switch back to a longer focal-length imaging scope.

It also occurs to me that I have a field flattener for short scopes in a drawer somewhere.  If I come back to serious imaging with this scope later in the season (which I might want to do for a very wide field shot, such as M31) I’ll try that flattener.

Now, since I have a nice image framed anyway, I thought I would do some trial imaging of that M81 – M82 shot. I took 10 five-minute sub-exposures, unguided, and then a series of flat fields using the light panel mounted in the observatory. I already have a calibrated dark frame for use with this camera.

There sure are a lot of satellites in that part of the sky.  Lots of satellite trails to be removed.  Fortunately, the data rejection procedures in CCDStack make that fairly easy.

2015-04-17-M81-82-monoHere is the result, calibrated, combined, and cropped. (Still just a test – not a finished product, which would need better noise removal, scaling, etc.)

I would not have imagined I could get results like this unguided. This truly is a wonderful mount.

Static Electricity

A final note.  I’ve had several major static electricity shocks over the last couple of days, and I don’t remember this being a big issue in the past.  Twice tonight, a piece of equipment actually reset after a static spark.

What’s changed?  I think the answer is the new vinyl cover on the dome – I used to have a woven polyethylene cover, but switched to this vinyl one last year.  Maybe dragging the vinyl cover off the plastic dome is generating the charge.  Running a ground wire to the dome is now on the to-do list.