Differential Flexure…my story

For years now I have been taking long exposure LIGHT frames. 500 second exposures at ISO200 was my goto setting for my Nikon D5300. With my QHY294C I have been using 600 seconds at GAIN=1600 for narrowband LIGHT frames and 200-300 seconds for broadband (LPR filter) LIGHT frames.  I have been resisting buying an off-axis guider while focusing my attention on better guiding and a software based differential flexure compensation scheme.

I hope to create a post detailing my work on improving my guiding.  This post is going to focus on differential flexure. I have two telescopes…an 80mm refractor and an 8” EdgeHD SCT. The refractor has very little differential flexure. The 8”EdgeHD SCT has dramatically more flexure. So…

What is Differential Flexure?

Differential flexure refers to a mechanical flexing of one or more components in your astrophotography set-up. If you have a high-end mount and choose not to auto-guide you can experience differential flexure if the mirror in your telescope moves or if the weigh of your telescope causes it’s mounting plate to flex. In these cases the RA or DEC axis may indicate they are on-target but the imaging camera might have shifted by one or more pixels. Most long exposure astrophotographers use auto-guiding because it can cater for most of these mechanical issues.

Auto-guiding implies that a separate auto-guiding camera is used. Differential flexure can still exist while auto-guiding but now the problem is how to ensure that both cameras do not shift position w.r.t each other. The easiest way to imagine this situation is with a SCT telescope that has a big mirror that is positioned for focusing and a guiding camera attached to a separate guide scope. The position of the guide star(s) will be determined by the separate guide scope and it’s guide camera. This position information will then be used to adjust the RA and DEC axis so that the guide star position is kept constant. If the SCT’s mirror shifts it’s position as the RA axis rotates over the course of the evening this will cause the image recorded by the imaging camera to shift by several pixels. The auto-guiding software will not be aware this is happening.

In my case, I use a guidescope for guiding. As my mount tracks the sky, I believe the primary mirror in my 8” EdgeHD SCT moves ever so slightly. This causes the image to shift in my QHY294C at rates as high as 40 arc-seconds per hour. When using the highest magnification of my EdgeHD scope the pixel scale of my images are 0.47 arc-seconds/pixel. This equates to 85 pixels/hour or 1.4 pixels/minute. A 600 second exposure could have stars stretched up to 14 pixels which would be horrible.

How to get rid of Differential Flexure?

The standard way to get rid of differential flexure is to use an off-axis guider. The two cameras share the same image delivered by the telescope. If a primary mirror moves then both cameras will see the same movement. The off-axis guider costs $200 – 300US. Using an off-axis guider is more complicated:

1)Your guiding program needs to have a differential camera configuration for each Telescope/Field Flattener/Barlow combination.

2)It is more difficult to find a guide star because the guide camera is looking at a much smaller section of the sky.

3)You have to have the space to install an off-axis guider between your telescope and imaging camera.

Many Astrophotographers have struggled with differential flexure. Some have been successful making mechanical modifications to their rig to stiffen how their guiderscope is mounted and improving the rigidity of their focuser. Others have chosen to use shorter exposures. Pros go with an off-axis guider.

My Software Solution FlexComp

During the 2018/2019 winter, I was still using my Nikon D5300. At that time I didn’t think using filters or an off-axis guider were possible. I was certainly seeing differential flexure so I decided to invent a program that could help me. I wrote a program that would read my Nikon NEF raw files using the LibRAW library. The program would then scan thru the image and find all the stars that exceed a target brightness.

Next I had my program build a database of star locations. When my program reads the next NEF raw file it would compare the new database to the old database and identify if the stars has shifted position.

I found that all the stars were moving the same amount in each photo but, over the course of an evening, this bulk movement changed a lot. The above graphs illustrate how a star drifted over the course of two different evenings. Each colored dot is a different image. These were different stars associated with different DSOs.  The main take-away is that the pixel shift is not consistent and it can even shift directions.

PHD2 Comet Tracking

I discovered that PHD2 Guiding has a comet tracking feature which I decided to exploit to move the mount. This comet tracking feature allows you to choose an RA and DEC rate to ramp the lock position which, in turn, controls where the telescope is pointed. The units for these rates are arc-seconds/hour. PHD2 Guiding has a server feature which I had been using for a few years. This comet tracking feature can be accessed via this server.

The next issue to tackle is that my LIGHT frames give me pixel values and pixel locations (Row & Column) and PHD2 Guiding wants to communicate using Right Ascension and Declination. I was lucky to find a fast screen capture routine that allows me to “watch” what any 3rd party program displays.  This means that if I can find a program that can display a liveview of my Nikon D5300, I can have my program “watch” and calculate a star’s movements.

I use DigiCamControl to control and sequence my D5300.  It also has a “Liveview” feature that display what my D5300 sees as a live video. My original scheme was to slowly slew the mount in right ascension and keep track of the star’s movements by “watching” the liveview screen. Now I use PHD2 Guiding to move the mount because this is straight forward and helps eliminate issues with declination backlash. The only caveat is that the liveview image must be oriented the exact same way as your LIGHT frames. Flipping or rotating the image is not allowed otherwise the calculations will fail.

The end result is that I can now determine which direction is right ascension and which direction is declination. You have to determine both of these directions because of how PHD2 deals with declination w.r.t. meridian flips. So now I know how to translate a pixel shift stated in X,Y co-ordinates into RA, DEC co-ordinates. Because I know the timestamp for each photo, I also know the time between LIGHT frames. This allows me to determine the differential flexure rates for RA and DEC in units of arc-seconds/hour.

The second last detail was to realize that this scheme needs to deliver the most LIGHT frames with the lowest possible pixel shifts. This meant that when a pixel shift occurs the scheme is NOT to send commands to PHD2 to bring that star back to where it was. The scheme is to watch for pixel shifts and if they occur then tell PHD2 to stop the stars from shifting any further. I believe this scheme will result in the most LIGHT frames with the roundest stars.

PHD2 Dither

The final detail was to accept that PHD2 dither cannot be used. This is a big deal to most astrophotographers primarily because dither helps to eliminate issues with hot pixels. Dither is a deliberate moving of the PHD2 lock position by small amounts between each LIGHT frame.  This causes any hot pixel inherent in the imaging camera to not occur in the same location in every LIGHT frame. Hot pixels are the most troublesome but these hot pixels are actually the extreme part of the camera’s DARK current.

I use CaLIGHTs for LIGHT frame calibration and it has excellent tools for dealing with both hot/cold pixels and DARK current. Yes…I need to generate a masterDARK library for my D5300 which some astrophotographers can’t be bothered with. The bottom line is that when I digitally develop my astrophotos using DSS and Startools, I don’t see hot/cold pixels. I don’t even see “walking noise” which is directly linked to the camera’s DARK current.

Show me the Money!

I decided to call my program FlexComp. I have been using it for 3 years now. There were some frustrating growing pains but the last two years have been consistent. I use FlexComp for all of my astrophotography. I also log tons of information for each LIGHT frame, including FlexComp data so I put together some graphs that illustrate the improvements I have seen.

On this evening I was imaging the Fireworks Galaxy…a favorite DSO for testing how good my skills are. I was using my 8” EdgeHD @ F10 which is a focal length of 2032mm. I took 44 300-second LIGHT frames with my QHY294C. The blue pen indicates the actual star movements for all 44 LIGHT frames. The orange pen shows the changes in the PHD2 Lock Position. I rescaled these values so they represent the equivalent amount of movement that would have been seen in my LIGHT frames. This graph demonstrates how much PHD2 had to move its lock position to achieve the actual star movements. Obviously, I like using FlexComp.

This graph also hints at how much cropping of my LIGHT frames is required when all of them are stacked in DSS. I only need to crop the outer 10 pixels to eliminate portions where not all of the LIGHT frames provided pixel values. If FlexComp was not running I would deduce from the PHD2 Lock Position that I would need to crop the outer 100 pixels.

This graphs compares the actual pixel shift(blue pen) with the derived shift that “might have been” according to the PHD2 Lock Position(orange pen). FlexComp was able to keep the actual pixel shift below 1 pixel for most of the night. The pixel shift “might have been” as much as 3 pixels for most of the night. The HFD of the stacked result for this night is approx. 6 pixels so 3 pixels of shift is significant. I also included the Differential Flexure(grey pen) which is the magnitude of the comet tracking ramp rate send to PHD2 Guiding.

July 9th, 2021 Fireworks Galaxy

On August 2nd, 2021 I was imaging the Cocoon Nebula. I was using my 8” EdgeHD @ F7 which is a focal length of 1,422mm. I was taking 600 second exposures with my QHY294C. The blue pen indicates the actual star movement for the evening. The exposure time for these LIGHT frames is double the length as for my July 9th, 2021 imaging run which means that FlexComp had ½ as much information to work with. The PHD2 lock position (orange pen) shows how FlexComp was trying to keep differential flexure in check. Once again, the amount of cropping of my DSS stacked result is small at 20 pixels.

FlexComp was able to keep the pixel shift low for most of the night. The pixel shift derived from the PHD2 Lock Position hovered around 4 pixels for most of the night. The HFD of the stacked result for this night is approx. 5.5 pixels so 4 pixels of pixel shift ain’t good news.

August 2nd, 2021 Cocoon Nebula

Over these cold winter months I have been studying my astrophotos and have decided to take the plunge and purchase an off-axis guider even though it’s more complicated to use. My justification is that FlexComp takes a few LIGHT frames to settle and the EdgeHD scope seems to take a while to settle down. I have found that I can initially start taking shorter exposures of 30 to 60 seconds while FlexComp is settling. Then I switch over to long exposures and keep going. Those first long exposure LIGHT frames take place when the skies are still darkening so I typically don’t use them. What hurts is when I need to perform a meridian flip. The first few LIGHT frames after the flip typically have the largest pixel shift with oval stars. I don’t like losing LIGHT frames to oval stars.

Peter

Leave a Comment