A Fix for the Ravages of Differential Flexure

[teamsharp]

Hi, I'm a big fan of BYE!

 

With BYE, PHD2, DSS and a few other applications, I'm able to do pretty much everything I want in astrophotography but I'm still encountering one big hurdle with my setup. That hurdle is differential flexure. I use the PHD2 comet tracking tool to make corrections to compensate for flexure drift but it's not a great solution.

 

It would be great to have a system that could automatically correct for differential flex and I think BYE could be made to communicate with PHD to do just that! Here is the basic idea I have in mind:

- Add a routine to BYE so that after it downloads a photo, it calculates the amount of drift in star positions between the last 2 (or more)photos...something like the dx and dy parameters output by Deep Sky Stacker.

- Now we know the number of pixels shifted and the time of the exposure, and that information can be used to calculate the rate of pixel shift in the X and Y directions

- Using this drift rate, BYE can now make regular commands to PHD2 to move the lock position at the same rate (but opposite direction) as the drift due to differential flexure.

- With this construct, the effects of diff flex could be almost entirely eliminated automatically and that would be awesome.

 

I hope I am being clear with what I'm proposing because if this feature were added, I think it would be hugely popular with folks that have modest astrophotography setups like mine.

 

Thanks very much,

Ken Sharp

[admin]

Not possible.

 

BYE can NOT send any commands to PHD that PHD does not accept or understand.  The only command PHD accepts and understand is dithering and that is it.

 

Regards,

[s3igell]

I hope I am being clear with what I'm proposing because if this feature were added, I think it would be hugely popular with folks that have modest astrophotography setups like mine.

 

Since Flexture is often a result of Mechanical Shifts between the AutoGuider FOV the Imager FOV (sometimes Drag on a Camera Cable; sometimes Gravity pressuring a Mounting or Focuser; sometimes Mirror Flop of the SCT Primary), there is no assurance that the degree of Deflection is Linear throughout the Previous Exposure.  So how is BYE supposed to Calculate the actual "Center" of that Deflection as a Factor of the Exposure Duration??

Also, quite often the result of Flexture is not a Discrete Difference in Star Locations, but rather a "Smear"/Elongation of the Star Image.  What portion of that Smear is due to Flexture, and what is due to Uncorrected PE??

And finally, the result of a Dither is the Random (and therefore "Unknowable") Shift of the Guide Star (and therefore the whole FOV).  Your proposal would Preclude Dithering in total.

[teamsharp]

I have collected data on my setup's response to flex and found that I can get a good fit with a second order polynomial. A system that is reacting to flex in real time could generate the coefficients for the polynomial on the fly and that is how to come close to calculated the actual "center" of that deflection as a factor of the exposure duration. I've written a java program that uses JSON messages to update the PHD2 lock position using a polynomial that has the target's time to the meridian as the independent variable. I'm a novice programmer so all I did was hard code in the polynomial but it gives good results.

 

Thanks

Ken

[teamsharp]

I also wanted to let s3igell know that the approach I'm proposing works fine with dithering. Here is how I deal with dithering in my simple Java program...every periodic update to the PHD2 lockposition is proceeded with a call to PHD2 to get its current lockposition and adjustments are made to that value. So when dithering changes the lockposition, my little program reads that new position before making adjustments for drift.

 

Unfortunately BYE is not able to send JSON messages to PHD2 to make adjustments for drift, but if someone with programming skills were to employ the approach I'm proposing, I think it would be very popular.

 

Thanks

Ken

[admin]

what is the json file you are sending?

[teamsharp]

I'm using a JSON message to call the PHD2 methods get_lock_position and set_lock_position.

 

If you Google "open-phd-guiding event monitoring" and look at the first entry you can get a better description of the available JSON message formats.

 

Thanks

Ken