Category Archives: Maintenance

Replaced observatory computer

Leave a reply

My old observatory PC has started becoming unstable, with sudden unexplained restarts and failures.  Not bad – it’s had a good 5-year run, living permanently outdoors in the cold.  It was also time to do something about the demise of Windows 7, and I found I couldn’t upgrade it to Windows 10 easily (nor was I sure that would fix the failures problem).

So, I’ve replaced it with a new machine.  As before, I configured the machine for no moving parts – especially no rotating hard drives – to reduce the effect of cold weather. I found, a couple of PCs ago, that hard drives seize up in the cold. (In fact the new machine has one moving part – a fan – but, being thermostatically controlled, a computer fan is rarely a problem in the cold since it doesn’t try to come on anyway.) The new one is installed in the observatory now and seems to be fine, and stable.

I forgot a number of configuration things though.  It took a couple of weeks to get all the necessary software and drivers installed and working.  Then, last night, I tried a “real” observing run and instead generated a big to-do list of things I forgot to set up.  Things such as transferring the PEC and TPoint models for the mount.

I think I’ve done all the necessary things now, but we’re back in cloudy weather for several days, so next test is some time away.

Zenith Table complete

Leave a reply

Except for a final coat or two of paint, the PZT (Pod Zenith Table) is complete. Now, in addition to the usual rotation, the dome can be pushed backward, entirely off of the observatory base. This opens up the whole sky, allowing the scope to look straight up, and eliminating the need to move the dome opening around as targets move.  I probably won’t use it all the time – no need for shorter sessions targeting just one part of the sky. But it will make more sky available, and will make things like automated TPoint data collection easier.

I’ve opened it for practice in daylight, but haven’t used it under dark skies yet.

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.

Two Big Changes underway

Leave a reply

Two things are in progress for the observatory:

  1. A new Right Ascension worm block. It has arrived from Bisque and I’ve installed it, but haven’t yet had a clear night to re-do PE measurements and see what effect it’s had.
  2. A PZT (Pod Zenith Table) – a DIY project, supported by hardware and plans sold by SkyShed, that allows the clamshell dome roof to be rolled off to the side.  Doing so will open up the whole sky above the dome – where, right now, I can’t point straight up or, indeed any higher than about 70° altitude.  Considering how high my horizons are (hedge, house), opening up the sky above will make a huge difference.  The PZT woodwork is assembled and I’m in the process of painting;  installation in the next few days.

Rerouting cables to reduce dangle-effect

1 Reply

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

Leave a reply

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.

Polar Alignment and TPoint model

Leave a reply

Clear tonight, but not dark until quite late.  (Duh. That’s what I get for re-starting the observatory only a few days after Solstice.)

I did new polar alignment tonight:

  • The “rough polar alignment” featur in TheSky, which slews to a computed star position which you then correct by adjusting the mount alt and az controls;
  • Then a TPoint model, about 40 observation points around the sky (semi-automated with camera and TheSky “Image Link” feature);
  • Then, with the TPoint model calculated, it makes an  “accurate polar alignment” feature available, which uses another star and continuous imaging to fine-tune the alt/az positions.

After that I did a few test slews.  Slewing to M27 from far away, it landed dead-on, precisely centred.

Just for fun I did a quick 60-second exposure while I was there.  It looks pretty good, so I’m hopeful I’ll see improvements.  This image is uncorrected (no darks or flats) and, more important, has no Periodic Error Correction running.  PEC training will be my next evening’s activity.  I won’t really know how the mount is performing until I see that Periodic Error graph.

Cleaned and re-greased RA worm block

Leave a reply

I used the same procedure again to remove, clean, and re-grease the Right Ascension worm block.  Some photos:

I then ran the mount through several iterations of exercise, and all seems well.  Even motion, no stalls, no weird noises.

Finally I did the manual mechanical check for hysteresis on both worm blocks, and no motion detected in either case.  I think I’m ready to start polar alignment – just need the couple of days of forecast thunderstorms to pass.

 

Cleaned and Re-Greased DEC worm block

Leave a reply

Following the instructions in Bisque’s video, I removed the Declination worm block, cleaned all the grease out of the drive gear and the worm gear, and re-greased.  Because of our winters, I used MolyKote 33, which is rated for much lower temperatures than the standard Lubriplate 103 that Bisque normally uses.

Some photos of the cleaning process, but I forgot to take photos of the re-greasing:

I then reassembled the Dec worm block into the mount and reset the cam stop and spring plungers to factor spec, and ran the Dec motor through 10 end-to-end exercise runs.  I ended up backing the spring plungers off 1/8-turn more than the lower end to eliminate a slight binding noise I could hear in the exercise.  (The manual specifies 2.5 to 3.5 turns back from bottom.  I ended up using 2-5/8 back from bottom.)

Next I’ll do the same procedure with the RA block.