Category Archives: Testing

Testing unguided performance

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.

New RA gear: looking good

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.

Rerouting cables to reduce dangle-effect

In a continued effort to get the Periodic Error down lower (now just at spec, but can do better), I next decided to tackle the mass of dangling cables.  These are a snag risk and I imagine that, even if not snagged, the fact that they are dangling and swinging back and forth is probably affecting PE – especially during times when a dangling cable is rubbing against some stationary part.

I did not want to route the cables internally through the mount – I did that some time ago and believe that internal rubbing contributed to the worsened PE at that time.  Instead, I want to make maximum use of the mount’s instrument panel and existing internal wiring to eliminate cables or shorten them.

There were 3 classes of cable to deal with

  1. Power cables (to the QSI camera and the Pyxis rotator);
  2. USB cables (to the QSI camera, the guider camera, and the rotator); and
  3. The special telephone-wire cable that feeds both power and control signals to the focuser.

1. Power Cables

The mount instrument panel provides 3.5mm power jacks supplying 12V and 5V.  The 12V provides enough current for the Pyxis rotator, but not enough for the QSI camera.  So I made a short jumper cable to power the rotator off the instrument panel’s 12V jack.

To get power to the QSI camera, I decided to use the mount’s “Aux Power In” and “Aux Power Out” jacks on the control and instrument panels.  As described in the manual, these jacks do not have any power supplied – they are simply a 4-conductor cable route through the mount.  If you want power to come out at the instrument panel, you must send power in to the jack on the control panel.


You can buy pre-made cables from Bisque that have the appropriate jumper jacks and plugs to do this for a variety of devices.  However, it’s very expensive, especially for a Canadian.  $169 for the cable and $95 for UPS shipping, for a total of US $264, or about $375 Canadian.

Instead, I made an appropriate cable set.  This is not hard if you are comfortable doing fine soldering, and I certainly recommend it.  I already had wire, bought the appropriate mount connectors from Mouser Electronics, and bought male and female 3.5mm power jacks from a local electronics shop.  A couple of hours work and a cost of about $30.

2. USB Cables

I had 3 USB cables to deal with:

  • USB to the QSI camera (data only);
  • USB to the Pyxis rotator (data only); and
  • USB, data and power, to the LodeStar guide camera.

The mount’s Instrument Panel provides two USB ports that are hubbed, internally, to the same USB cable that controls the mount.  I needed a third, so I mounted a tiny USB hub on the side of the instrument panel with velcro.  I ran power to this hub from the unused 5V power jack on the instrument panel, so it would have the power available to handle USB-powered devices.

Then I ran short USB cables as follows:

  • USB jack on instrument panel to QSI camera (avoiding the hub, because this pathway is carrying imaging signals and needs to be clean and stable);
  • 2nd USB jack on instrument panel to the input of the mini USB hub;
  • USB hub to Pyxis rotator;
  • USB hub to Lodestar guide camera.  (This cable also powers the guide camera, which is why the powered USB hub.)

3. Focuser Cable

This specialty cable is very long, so I just routed it up the body of the mount, bending at the mount’s pivot points, and leaving some slack where needed.

Here is the result – no dangling cables.

I re-ran a Periodic Error test, thinking things might get very slightly better.

Nope.  They got worse.  I’m now at 7.7 arcseconds peak-to-peak, which is out of spec for this mount.

I’m running out of ideas.  Before I go to the online forum for advice (and might end up replacing the RA drive gear), I thought I’d try one more thing.  I noted in the recent tests a “grumbling” sound coming from the RA gear box that I am pretty sure was not there before.  Something in the drive not running smoothly.

When I cleaned and regreased the gears a month ago I used MolyKote 33 grease, because it’s rated for lower temperatures.  I’m now second-guessing that decision.  The MolyKote is really thin and light and my winter temperatures aren’t that low.  Meanwhile, I’m wondering if it is too thin for the very hot temperatures we’ve been having this summer.

So, I disassembled the gear boxes again, and replaced the grease with Lubriplate 105, which is the specific grease recommended by Bisque for the mount.

I also changed the adjustment on the mount’s spring plungers – which set the tension holding the belt-driven worms to the worm gear.  There are two Bisque documents that contain information on setting these plungers, and they are inconsistent on one matter;  so I tried setting them according to the other document, the one I hadn’t been following.

It’s due to be cloudy for a few days, but next clear night I’ll test again and see where we stand.

Meanwhile, I was a little discouraged by this, so I thought I’d see how well guided imaging would do at this point.  Not that I’m going to use guiding to make up for out-of-spec PE, but just for fun.

That’s pretty nice.  It’s a single 300-second exposure, guided.  No flats, but darks and bias frames used.  Looking closely, especially near the edges, the stars are not perfectly round, but I suspect that’s optical (collimation) not guiding error.  Nice to know I could image if I needed to; but I’m going to keep working on the raw mount performance first.

First round, new Periodic Error analysis and correction

Wednesday, July 3

Continuing from last night – now that polar alignment is close, I’ll do a first pass of Periodic Error analysis.

First, with all corrections off (no PEC, TPoint, Protrack, or guider relays), I collected 4 worm rotations’ worth of tracking data. Plotting this with TheSky’s PEC analysis, I get the following:Uncorrected PE graph

Peak-to-peak error, completely uncorrected, is 6.8 arc-seconds.  This is within spec (7 arc-seconds) for this mount, for the first time – so this is very good news, although I think the mount can do still better.

Using this data to program a Periodic Error Correction curve into the mount, I then did another 4-cycles worth of data collection, this time with PEC running.

Corrected Periodic Error is 2.9 arcseconds peak-to-peak.  That’s good, and I feel good about the improvements that the maintenance has generated.  But I’m left with a few questions:

  1. Most important, why the corrected PE isn’t even better than that.  A good, pure, periodic error should be almost completely eliminated by PEC.  This wasn’t.
  2. This makes me think that the error in the uncorrected data isn’t entirely composed of repeating periodic error, but rather that there are other factors still being injected.

On my next clear night, I’ll re-check the tightness of the pier mounting bolts, re-check equipment balance, re-check spring plunger settings,  then do a further refinement of TPoint/Protrack and polar alignment.  We’ll see what that does and, if the data are still puzzling I’ll look for other causes such as loose connections in optical chain.

Meanwhile, a few unguided test exposures with PEC and ProTrack running, just for fun.  These are all single 60-second exposures, binned 2×2, PEC running but no guiding, and corrected by dark and bias frames (no flats).

Since I was pointed right next to it for testing purposes, I started with M10:

Pretty nice, unguided.  That’s only a 60-second exposure, and the very slight star elongation I can see would no doubt get worse with a longer exposure.  It’s tempting to just throw guiding at it – but I want unguided performance to be as good as I can get it first.

Next, not far away in the sky, M12:

And, just to try something on the other side of the meridian, M27:

In all of these test photos, you can see the slight star elongation goes left-to-right, almost precisely along the horizontal axis.  Since the camera was rotated with polar North up, within a small fraction of a degree, this means the horizontal axis in the image corresponds almost exactly to Right Ascension.  So this elongation still corresponds to RA:  RA error, which is likely, but not necessarily, Periodic error.

There was also substantial Dec drift during my data gathering.  This doesn’t affect PE, but leaves me wondering why.  I’m guessing not-yet-perfect polar alignment is a factor.

A few days of clouds and thunderstorms are now forecast, so more testing later.

Tune-up journal 2: 1st worm adjustments

Evening of July 15, it’s moderately clear.

Before dark, I finished re-connecting all the cables to the mount and related gear without doing any through-mount cabling.  Ran the mount and the rotator through their full ranges of motion several times to ensure nothing snags on anything.

Adjust worm tension plungers

My plan said to start with a new, small, TPoint run to verify polar alignment.  However, I decided to change that and do an initial check if the worm tension plungers are in-spec.  I thought that, if they aren’t, I should discontinue running the mount around with out-of-spec gears as soon as possible.  So, I checked the cam stop and worm spring plunger settings of both gear boxes.

Declination gearbox

I adjusted the cam stop to spec (1/8 turn out from bottomed-out).  It was already in more-or-less that position, so I don’t think it was out of spec.

Then I adjusted the 2 spring plungers.  The spec for these is “3 to 3.5 turns out from bottomed-out”.  They were a bit loose so, wanting them tighter, I set them to 3 – the tight end of the spec range.

Both of these adjustments can be done without removing the gearbox cover, so I haven’t yet inspected other components for tightness and tension – that will come later.

Right Ascension gearbox

Again, cam stop seemed OK but I re-adjusted it to spec just to be sure.

Spring tension plungers were quite a bit too tight.  They were about 1.5 turns out from bottom, so I readjusted them to 3, per the spec.

Quick re-check of periodic error

Continuing to deviate from my carefully thought-out plan, I couldn’t resist doing a new Periodic Error data gathering run to see if those adjustments had any effect.

Guiding reference plate solveSo, I carefully checked all the various settings that I have got wrong so many times:

  • Camera rotation close to zero (used a plate-solved image to confirm this);
  • PEC, TPoint, and ProTrack all off;
  • Autoguider set to do no corrections;
  • Pointed to a star near zero Declination, and just West of the Meridian.

PE data capture in-progressI gathered 1/2 hour of tracking data, which is about 8 worm rotations.  I used the main camera, binned 1×1.  During this data gathering, I noted that the guide star was showing up as 100% saturated.  This might be a problem – if it is over-saturating it may be difficult to calculate the FWHM radius.  This goes into the list of things to check next time.

7.7 arc-seconds error peak-to-peak, uncorrectedA quick analysis of the results shows it has certainly improved things.  Uncorrected periodic error is now at 7.7 arc-seconds peak-to-peak, down from 12.  That’s almost within spec (which is 7-7).

After I get back on-plan by checking polar alignment, I’ll do another test with a couple of minor additional changes:

  • Shorten exposure or use a dimmer guide star to get saturation below 100%; and
  • Loosen those RA plungers another 1/2 turn, to the loose end of the specified range.  If “looser” improved things, maybe “more looser” will improve them more.

Starting Mount Forensics and Maintenance

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.


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.


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.


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.

Changed scopes for summer

It was clear and warm last night, but a full moon.  So no serious imaging but a good night to adjust things.  With winter skies basically done, I decided to take off my widefield refractor and go with a longer focal-length OTA for the summer season of galaxies and nebulae.  So, the SV80S is put away, and I mounted the AT8RC 8″ Ritchey-Chretién, and rebalanced the mount accordingly.

M67-3x3-10secs--15C-LuminanceThat creates new re-adjustments that are needed, of course.  I re-built a V-Curve model for FocusMax, and got nice round stars on a quick 10-second test image of M67.

I was going to do a new TPoint pointing model, and also use that to re-check the polar alignment, but I became distracted.  I tried a quick test of autoguiding, intending to confirm that my previous autoguiding problems were field curvature on the SV80S.  They were – the AT8 produces a nice flat field, and the guide starts weren’t too badly distorted to use.

The problem was that I tried doing a guider calibration, and it didn’t work.  That ended up distracting me for the rest of the night, as I experimented with the parameters that control the amount of movement the calibration routine injects before measuring direction and distance.  No matter what I specified, even absurdly long displacements, I got the same error:  “Error, insufficient motion in X-direction during calibration”.

Guider-calibration-motionWhich is clearly not the case.  As these two guider frames show (click for animated gif), there is good motion happening in both axes between calibration images.  I puzzled over this for an hour or so, then it clouded over so I shut down and went to bed.

This morning an idea hit me which I think is the solution.  The guide stars aren’t in focus. That, alone, shouldn’t be a problem, as the guiding software should calculate the centroid of each star.  However, there are bright hot pixels in the image.  I bet the guider software is selecting and guiding on a bright pixel, which doesn’t move, not on a star.

I’ll test this next clear night:

  • Adjust focus of guide camera to get nice bright pinpoint guide stars; and
  • Use a dark frame with the guide camera to calibrate out the hot pixels.

We’ll see.

Finished Polar Alignment, First PEC Training

We finally had two clear nights of excellent conditions this past weekend. The sky was clear, the temperature was above freezing for the first time in months, there was no moon, and, being very early spring, there were no bugs. I have been waiting several months for an opportunity like this to finish installation and calibration of the mount.

2015-04-12-Polar-ResultsFirst, I finished refining the polar alignment. This ended up taking four passes, when I thought only two or three would be needed. After the first polar alignment modeling session over a month ago, substantial polar error remained and a rather large correction was recommended by the TPoint software. Last night, I applied that large correction and ran a new modeling run. I didn’t expect the results to be perfect, just closer, and, sure enough, TPoint reported substantial improvement to the polar alignment but with a minor correction still needed. I must have misread the decimal point in the correction instructions because, on pass three, the polar alignment was still off by about the same amount and another minor correction was recommended. I made that correction, paying more attention to getting the decimal point in the right place, then ran a final TPoint model just to check the alignment.

The results were very good. TPoint is reporting my polar alignment to be off by 1/2 arcminute in azimuth and 3/4 arcminutes in altitude. That is certainly good enough for now.

2015-04-12-pec-captureNext, I wanted to do an initial, first cut, of the mount’s periodic error correction. I collected about four worm rotations’ worth of data using the autoguider camera. Even without PEC turned on, the Paramount’s impressive performance showed up. Uncorrected, I recorded a periodic error of ± 1.1 pixel, or about ± 3.8 arcseconds. That is better than the best I ever achieved, with PEC turned on, on my Losmandy G11 amount.

2015-04-12-pec-curveThis generated a periodic error correction curve to be uploaded to the mount which applies a correction of ± 0.4 arcseconds.

2015-04-12-corrected-computedI verified this by doing another PEC data capture, this time with PEC turned on. Sure enough, the corrected PEC is now showing at about ± 0.5 arc seconds. That is, frankly, incredible; especially since I’m not particularly impressed with my PE data capture yet. Seeing was quite poor tonight, probably in the range of 3-4 arcseconds, so my PE data capture was probably seeing the target star scintillating due to bad seeing more than it was seeing mount drift.

2015-04-12-LeoTriplet-2x2-600-singleJust for fun, and as a more practical test, I decided to end the evening with a 10-minute guided exposure of the Leo triplet. I used five-second guide camera exposure intervals, with a low guiding aggressiveness to avoid “chasing seeing”. Although I forgot to take a screenshot of the guiding graph, guiding during this 10-minute exposure showed that it was making very small corrections, oscillating around a 1.5 arc second error. The single resulting image is shown here, without dark or flat fields. Nice pinpoint stars.

 Update: PE worse than I thought

Updated added later:  I have realized I made an error in recording the PE data above – I didn’t have the camera aligned “top-north”, so some of the error was masked as Dec motion.  Error is worse than recorded – in fact, it seems out-of-spec at about +/- 9 arc-seconds uncorrected.  Other posts will record the story of tracking this down and correcting it.

One clear night, one pass of polar alignment

A few days ago it was clear for one night, so I spent a couple of hours outside. At -22°C, a couple of hours was enough.

2015-01-tpoint-dataAfter a rough polar alignment, I did a TPoint automated sampling run, gathering about 25 calibration points around the sky.  This allowed TPoint to calculate polar alignment error and provide me with correction recommendations.  Then it clouded over and I was near-frozen.

2015-01-TPoint-alignment-windowSo, I’ve applied the recommended polar alignment corrections, but have not yet had another clear night to do another pass of TPoint calibration.  Because I had to do quite a large correction the first time, I imagine another round of corrections – probably down to a few arc-minutes – will be necessary before the alignment is sufficiently dialled in.

Now we’re getting somewhere

Lum-Median-LRGBBacking up and re-focusing on some basics has paid off. I’m quite pleased with this first result on M27. This is 4 hours of data over about 2 weeks, 1 hour each of LRGB, with RGB binned 2×2. QSI 583 camera on an AT8RC, autoguided with a Lodestar, on a G11.

What I did differently to make this result better than previous ones:

  • Better autoguider and more attention to guider settings
  • One colour per session, taking time and not rushing
  • Focused for each filter
  • Flats for each filter, immediately after the data gathering, so filters are certain to be in exactly the same spot
  • Normalized & stacked with CCDStack, basic processing in Maxim, more processing in Photoshop.

The problem is, this is quite addictive.  Now I want more data – several more hours of each, and I can see never being satisfied.  More data to follow when the clouds leave.