Z-filter guiding algorithm now available in dev release

[Ken Self]

Previously called the Butterworth filter, the Z-filter is now available in 2.6.5 dev3 as an experimental offering. The name change is due settling on the Bessel filter as the optimum both in theory and practice but does not preclude definition of either Butterworth or Chebyshev filters. Like all the other algorithms it uses a low pass filter to attenuate the influence of  short period, seeing induced movements whilst responding strongly to long period, mount induced deviations. The difference is that it is actually a family of filters that can be tuned to suit the guide exposure being used. Plus the filter design gives a flat response across the whole of the long period pass band then rolls off sharply at shorter period

The use case for this algorithm is guiding with short guide exposures and/or poor seeing. The guiding parameters for the Z-filter are currently selected via a drop down list which selects the two parameters of Order and Corner.

Order determines how sharply the response rolls off so a higher order ignores the deviations from seeing more than a lower order filter. Order 4 is recommended as a starting point. You might select a  lower order if your mount has some relatively short period error that you want to correct for.

Corner determines the period where the roll off starts. Multiplying the guide exposure by the corner parameter gives the period. A 2s guide exposure with a corner of 8 has the same response as a 1s guide exposure with a corner of 16 or a 4s exposure with a corner of 4. A recommended start point is a corner value that results in a period of 4 to 8 seconds.

If you are currently using a guide exposure of 2s you might want to try 1s instead with a corner of 4 or 8. Note that with a shorter guide exposure the guide graph starts to look a bit ugly as the seeing becomes more visible.

I'm keen to see guide logs where the algorithm gets used

[Al Moncayo]

Ken,

I'll definitely try this one. Bessel filters are my favorite of the ones I typically use (at my day job), because they are inherently Gaussian in nature.

Will report back in a couple of weeks as I have to wait for ongoing scattered high clouds to dissipate in my area. On second thought, light scattered high clouds would degrade seeing so maybe now is the best time to test this... :)

Al

[mahaffm]

Likewise, I will give the new Z-filter a try. may be a several days before the rain and clouds clear out. I will download and test a soon as possible.

Regards,

Mark

[Brian Valente]

Hi Ken

 

I’m trying this out now and I’m not sure I follow all the variations

 

I have relatively poor seeing (not terrible, but in the los angeles valley, so lots of light pollution, air movement, etc.) and a stubborn but not huge 32 sec PE

 

So I am trying the Bessel 1 corner 8 with a guide exposure of 4 seconds.

 

(however now that I’m seeing the results I may switch to a Bessel 1 corner 16 and guide exposure of 2 seconds)

 

I hope I’m understanding things correctly

 

Also I’m not entirely sure when I’d use Bessel 1 vs Bessel 2?

 

 

 

 

 

Brian

 

portfolio https://www.brianvalentephotography.com/

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ken Self]

Hi Brian

The corner value has the most effect. Using a corner of 8 with a guide exposure of 4 seconds probably would not achieve much. The exposure time effectively filters out any seeing effects with a period less than 2x the exposure time - so anything shorter than 8 seconds in your case. Using a corner of 8 with a guide exposure of 4 seconds means the Zfilter is filtering anything shorter than about 32 seconds and therefore only correcting anything with a period longer then 32 seconds.

I've been getting good results with a corner x exposure in the range of 4 to 8 seconds. The key is to keep the guide exposures as short as possible so small corrections are made quickly - so the mount does not get to move far off track. The limiting factor is how well your mount can respond to small, fast corrections.

The order (Bessel 1 vs Bessel 2 or 4) determines how well the algorithm discriminates between the short period seeing and long period tracking errors. I've been able to do more objective testing and it looks like the higher orders work better. Previously I thought the larger values of order were introducing some delay which is why I stopped at 4. So I would recommend the Bessel 4 filter and in future releases I think I will provide only Bessel 4 and maybe Bessel 6.

You'll see in this dev release there is an option in the Settings menu on the graph for Corrections to Scale. This will show the correction pulses at the same scale as the graph so helps you see if you are chasing the seeing.

I'd be interested to look at your guide logs

Ken

[Brian Valente]

Hi Ken

 

Okay I think I follow – I will try Bessel 4, maybe 1-2 seconds and the corner value of maybe 32 or 16 respectively – sound good?

 

Here’s my log from last night – I definitely had some issues going on, could very well be with incorrect guiding paramters. There were also some hardware updates on my mount that I’m testing as well

 

 

 

Brian

 

portfolio https://www.brianvalentephotography.com/

 

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Ken Self

Sent: Wednesday, August 1, 2018 1:39 AM
To: Open PHD Guiding <open-phd...@googlegroups.com>

--

[mj.w...@gmail.com]

Brian said:   "Okay I think I follow – I will try Bessel 4, maybe 1-2 seconds and the corner value of maybe 32 or 16 respectively – sound good?"

If I've understood Ken's instructions, he suggests using exposure x corner = 4 to 8

Your suggested 1 x 32 = 32, or 2 x 16 = 32  are the same values as your previous 4 x 8 which Kens said was too high ?

Michael

Wiltshire UK

[Brian Valente]

Mmm I think you may be right

 

I guess I’m not clear what “corner x exposure” refers to – is that the corner value multiplied by the exposure time?

 

 

 

Brian

 

portfolio https://www.brianvalentephotography.com/

 

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of mj.w...@gmail.com
Sent: Wednesday, August 1, 2018 3:32 PM
To: Open PHD Guiding <open-phd...@googlegroups.com>
Subject: Re: [open-phd-guiding] Z-filter guiding algorithm now available in dev release

 

Brian said:   "Okay I think I follow – I will try Bessel 4, maybe 1-2 seconds and the corner value of maybe 32 or 16 respectively – sound good?"

--

[Ken Self]

That's it. Start with a corner times exposure of 4 to 8 and if you think you are chasing the seeing then increase it. 

[Ken Self]

Thanks for the log Brian - very informative. If you look closely you can see how the corrections in RA are much smaller than in Dec for similar deviations. You could probably set the min movement in RA to 0.0 so you get more frequent but smoother corrections.

I see that with your dither scale your dithers are often less than 0.3.  What ar ethe spikes I see in RA? I thought they were the dithers at first but they don't line up with the dither events.

Is that a Losmandy mount? I see it has the well known 32 second PE. This is where you want the corner times exposure to be somewhat less than 32. A product of 8 would help suppress the 32 second error.

[Bill McLaughlin]

I gave the system a quick try last night (TOA-130, STT-8300 self-guide, Paramount ME with Pro-Track and SGP). The guiding looked super on a guide-only try but when it was SGP triggered, it would not achieve star centering and stable guiding in order to start a main camera exposure. Log prolly not worthwhile since I quickly gave up and switched to Hysteresis in order to complete my imaging session.

[Al Moncayo]

Ken,

Please find attached a log of some testing I performed tonight. My imaging camera is not fully set up (spacers to achieve proper simultaneous focus with guide camera), so I used the opportunity of decent, not great, seeing to evaluate the z-filter.

My setup is an 8" RC of FL=1600mm on a CEM120 mount. I'm using an OAG with a QHY 5III-178 camera. My Orion SSAG, while perhaps arguably better from a guiding perspective, is a bit flaky on my USB interfaces. I may try that one on another night.

I'd say that it works quite fine on the first serious try. Tuning of parameters relative to particulars about a given mount may be a bit tedious but the algorithm seems to have lots of compliance range for adjustment without destroying guiding... :)

Al 

[mj.w...@gmail.com]

I gave it a try last night, but I forgot to enter my custom guide speed, so I was getting very poor Dec even before I tried the Z-Filter.

So no logs for you yet, will try again tonight.

It did raise some questions:

Like Brian, in practice it turned out I'm a bit confused by the settings too.

1)  If I select 2 x 4, does that mean I have to set the guidecam exposure to 2secs, or is that another variable?

2)  Do I set RA and Dec the same, or can I choose the best for each axis?  Or even leave Dec on Hysteresis? 

Michael

Wiltshire UK

[Ken Self]

Hi Bill, I'd still like to look at the log to see if there is a reason for it not stabilising. Its odd that it should misbehave when SGP is in use. 

[Ken Self]

Thanks Al, theat log looks ok except for the oscillation around 00:32 to 00:34. The corrections look larger than I would expect there. That coincides with when you switched to 1s exposures although it settled soon after. It looks best when you had a low MinMo setting - nice smooth corrections. You could try a Bessel Order 4 filter.

[Ken Self]

Hi Mike

The Order parameter determines how well the algorithm ignores high frequency seeing effects. I'm now recommending the Order 4 filters based on what I've seen so far. The Corner has the most effect. The value you choose for that should, when multiplied by the exposure time, give a value around 4 to 8. So you choose your exposure time as short as you can while still getting a good SNR on your guide star. Lets say its 1 second. For that I would recommend a Bessel Order 4 Corner 4 or Bessel Order 4 Corner 8. If you could get as low as 0.5s then use a  Bessel Order 4 Corner 8 or  Bessel Order 4 Corner 16. Or if you don't have any good guide star and need to go to 2s then use a Bessel Order 4 Corner 4. There is no Corner 2 filter because the exposure time itself has the same filtering effect.

So in short - choose your exposure time first then select a corner value accordingly. You can go with even higher corner values but at some point you will see some PE from the mount start to creep in.

In general you can use the same settings on Dec or you can use a higher corner value since there is no periodic component. One side effect I'm looking into is that with a high corner value and large dec drift the graph settles off centre. As long as it stays constant it wont affect imaging but some people may find it off putting. Solutions are to choose a lower corner value, get better PA or just use another algorithm. Whilst testing it can be useful to use another algorithm for Dec (or vice versa) as a control. 

[mj.w...@gmail.com]

Thanks Ken

So there's Exposure, and Order x Corner in the dropdown.

And aim for Exposure x Corner = 4 to 8

Michael
Wiltshire UK

[Ken Self]

Yes! 

And if anyone can think of a better name than corner I'm open to suggestions. A short name that means "the number that you multiply by the exposure time to give the time period where the components of the waveform start to become attenuated" is what I need. :)

What I may need to do is to add some code that can detect the exposure time and any changes to it and let you choose a "virtual exposure time" instead and have it set/reset the Corner automatically.. That would be more intuitive. 

And  instead of order values I could instead describe them as "Soft", "Moderate" and "Hard" in relation to the degree to which aggressiveness kicks in

How does that sound?

[mj.w...@gmail.com]

Yes for a better name, but it's early days for me so I won't comment until I've had more experience.

Attached are logs for tonight's attempts. 

LX200GPS on permanent pier. Has Buck's Gears but still a lot of Dec backlash as you'll see.

200mm Guidescope

ZWO ASI 120MM Guidecam

Michael

Wiltshire UK

[Al Moncayo]

Corner (or perhaps bandpass cut-off?) make sense to me. In my realm, the term we use is 3 dB bandwidth :)

Anyhow, regarding my log of last night, if you look at the second of the two sessions you will see that I used z-filter for both RA and DEC. I noticed that under this condition, I began to see correlation between the two axes. Is this expected? I was a bit surprised to see this. Maybe it was just a coincidence. There was certainly not a long time - only about 3 worm periods - so it is possible that it was just happenstance.

Finally, when you qualify my log as "looks ok", what specifically are you interpreting? Are the results you see as expected? From a guiding perspective is it good, bad, or just OK?

Thanks,

Al

[Al Moncayo]

One other question, and quite possibly way off topic... (sorry)

Why is FFT of DEC time series not part of the log viewer application? I find myself wondering what I may deduce about my mount's electro-mechanical response if I had the FFT result available? I'm thinking to write a matlab program to do it on the side. I would be shocked if this question had not been asked a zillion times before. I'm kind of new to these groups, so please bear with my ignorance.

Al

On Friday, August 3, 2018 at 3:25:35 PM UTC-7, Ken Self wrote:

[Ken Self]

Hi Al - I meant it in terms of what I expected to see very generally. Namely that the corrections looked somewhat sinusoidal and in phase with the deviations. Here is an example of what I mean. You can see that for similar deviations in RA and Dec that there is much less high frequency response in RA so the corrections look smoother. 

Now if I look more deeply at that section: on the FFT plot  there appears to be a strong response at around 24s which is attenuated by about 1.5dB by guiding. Given that you had 1s exposures and a corner of 4 (or did you change that on the fly?) that should be attenuated somewhat more. So understanding why that didn't happen and working out how to tune out that 24s response could improve your guiding

[Ken Self]

The FFT analysis is fairly new. I've just recently downloaded the source to do exactly what you are suggesting to help my own analysis. I'm also putting the Uncorrected and Corrected plots on one graph for comparison and want to add the transfer function as well. Another thing I'd like to see is the RMS of the guide correctionsRight now I'm just doing it quick and dirty but if I can polish it up in due course then maybe it can become a standard feature?

You can also use PemPro log viewer to view the dec FFT

[Andy Galasso]

On Fri, Aug 3, 2018 at 7:32 PM, Al Moncayo <a.mo...@verizon.net> wrote:

Why is FFT of DEC time series not part of the log viewer application? I find myself wondering what I may deduce about my mount's electro-mechanical response if I had the FFT result available?

Is your Dec guiding is periodic? I'd be concerned if I saw any type of oscillation on dec; analyzing the frequency components would be the least of my concerns. Without any dec guiding your guide star will slowly drift in dec (polar alignment, refraction, flexure); the drift will be in one direction (north or south) and will not change direction for many minutes, possibly hours. You really want your dec guiding to be correcting just the slow drift. If you have oscillation on dec it means you are chasing seeing and the cure is to increase your min-motion setting and maybe also reduce your aggressiveness setting.

Sometimes dec backlash can cause a periodic saw-tooth (or sometimes square-wave) pattern in dec. The period of the saw-tooth is not very interesting... it depends on the amount of backlash and how much stiffness there is in the dec axis, and the total amount of dec corrections sent, and it changes as the dec axis balance shifts over time. I don't really see how analyzing the frequency of the saw-tooth could provide any useful information ... correct me if I am wrong.  The fix for a dec saw-tooth or square pattern is to mechanically tune the dec backlash if possible, and to back off the dec guiding (increase min-mo and maybe reduce aggressiveness) so you get predominantly uni-directional dec guiding (very infrequent dec direction reversals.)

Andy

[mj.w...@gmail.com]

Hi Ken

Are my logs posted on the 4th no good?

Michael
Wiltshire UK

[Ken Self]

Hi Michael

Sorry - I missed them. The backlash is certainly a problem for you and having a 6 second delay while it corrects would not help your RA guiding either. That's 8 seconds unguided each time when you have 2s exposures.

What were the conditions like - it seems they were quite variable

With the amount of backlash its hard to draw conclusions. PPEC and Hysteresis seem to work quite well for you. Next time you try the Zfilter I'd suggest you use Order 4 Corner 8 for RA (with 1s or 2s exposures) and keep the MinMo at 0.1 or even 0. If you feel like you are chasing the seeing a better approach is to increase the Corner value. On the Dec axis, I'd push the Corner value higher - 16 or 32 to keep the reversals to a minimum. Also with Order 4.. Those values are the same as your best run in the log but I suspect it was as much a function of the conditions as the algorithm.

[mj.w...@gmail.com]

Thanks Ken

Deliberately chose a lowish Dec to mess up the seeing a bit.

At higher Dec the guiding is okay with PPEC and Hysterisis and 2 secs exposure, none of those horrible reversals, around 1 arcsec per axis.

I'll certainly try your suggestions at higher Dec and report back.

Michael
Wiltshire UK

[mahaffm]

Hi Ken,

It's taken me a while but I have my mount back up and running in the observatory so Sunday I took a few hours to test out the new Z-filter. I wasn't sure what all the setting options were for so I just pick something and did some guiding. My mount PA is not the greatest, need to tweak the PA a little bit, my PE was running around 4 arc-minutes. typically i aim for under 1.5 arc-minutes. Anyway, attached is the PHD2 log file for your review from Sunday night.

As a side note, I mainly used the Z-filter on the RA. I ran the Bessel Order 1, Corner 8.0 then switched over Bessel Order 2, Corner 8.0. If I remembered correctly I was guiding at 1 seconds as well as 1.5 just to see if I was able to detect any differences. 

I hope the log files will be helpful for your testing.

The log file was too large to attached here. Below is the Dropbox link

https://www.dropbox.com/s/v2324eg43we3mge/PHD2_DebugLog_2018-08-05_214212.txt?dl=0

Regards,
Mark

[Ken Self]

Hi Mike

Can you also send the guide log? The attached file is the debug log

Thanks

Ken

[mahaffm]

Hi Ken,

Oops, sorry about that but after I sent you, what I thought was the guide log but apparently was the debug log, I cleaned up my observatory computer files and deleted all of the remaining PHD2 files in the PHD2 folder. The next time out I do another run and I'll be sure to send you the correct file.

When testing the Z-Filter is there anything in particular you would like to see or me to try? Typically, I set the PHD2 exposures to either 1.5 or 2.0 seconds. those times seem to work best for my mount. would you like to see some shorter exposures? Also, any hint on what you think I should be using for the Bassel Order and corner? Maybe to many questions but I do want to give you useful data. I typically run with the predictive PEC. do you want me to run some Predictive PEC and Z-Filter maybe so you can compare if there is any improvement?

Thanks,
Mark

[bw_msgboard]

Hi Mark.  Not to speak for Ken, but I think a number of us would like to see a back-to-back, straight-up comparison of guiding performance between your normal choice of guiding algorithms and whatever you choose from the experimental set.  You’d probably need to run for at least 20 minutes with each approach to make a fair comparison.  So if you typically run with PPEC and Resist-Switch, that would be the baseline.

 

Thanks,

Bruce

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of mahaffm

Sent: Wednesday, August 08, 2018 5:35 PM
To: Open PHD Guiding

--

[Ken Self]

I agree with Bruce - we also need to a bit scientific about it. So do a run with your normal settings. Then do a run with the Zfilter on 1 axis only and your regular algorithm on the other axis. If its RA then use Order 4 Corner 8 and MinMo 0.1 or less.

If its Dec then use Order 4, Corner 16 and MinMo 0.1 or less. If you have time for additional runs then swap axes and/or halve your exposure time but keep the same settings.

If you can also take some star images concurrently that would help. Getting small round stars is what its all about. 

[mahaffm]

Ken, Bruce,

No problem, I'll plan on doing as suggested. I'll try to plan on running each test between 20 and 30 minutes. I'll do a "Normal" run using PPEC, then switch over to Resist-Switch. Following those I'll work on RA only Z-Filter, DEC only Z-Filter, Both RA and DEC Z-FIlter. and maybe follow up with back to PPEC and Resist-Switch. I never took any star images with PHD2, I assume Ken that is what you're wanting, star images out of PHD2? I need to see how that is done. I'm sure it shouldn't be to difficult.

It might be awhile before the skies clear. I live in Ohio and August is not a very good time for imaging. Lots of humidity, Dew accumulates very quickly in the evening , clouds and rain. Looking at the 15 day forecast is showing the same, lots of clouds and rain. I'll do my best to get you some data as soon as possible.

Thanks,
Mark

[bw_msgboard]

Hi Mark.  I think what Ken is referring to is that the goal is to get small, round stars in the main-camera images – in other words, the overall goal of guiding.  Guiding frames won’t be useful for judging this sort of thing.  So you could just measure star sizes and elongations in some typical main-camera images for the different guiding schemes.

 

Thanks,

Bruce

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of mahaffm
Sent: Thursday, August 09, 2018 5:53 AM
To: Open PHD Guiding
Subject: [open-phd-guiding] Re: Z-filter guiding algorithm now available in dev release

 

Ken, Bruce,

--

[Brian Valente]

Hi Ken/all,

 

I am back from travels and had a long session with the new suggested parameters – logfile attached

 

There are a few settings variations towards the beginning, but I left it for the longest runs at the end

 

Overall the FWHM is very low (for me), though RA performed lagged a bit so the eccentricity is a little higher than I’d like, and there seems to be oscillations in the guiding, but overall it seemed much better in terms of results

 

 

 

Brian

 

portfolio https://www.brianvalentephotography.com/

 

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Ken Self
Sent: Thursday, August 9, 2018 4:08 AM
To: Open PHD Guiding <open-phd...@googlegroups.com>
Subject: [open-phd-guiding] Re: Z-filter guiding algorithm now available in dev release

 

I agree with Bruce - we also need to a bit scientific about it. So do a run with your normal settings. Then do a run with the Zfilter on 1 axis only and your regular algorithm on the other axis. If its RA then use Order 4 Corner 8 and MinMo 0.1 or less.

--

[Al Moncayo]

Hi Andy,

I agree with your comments, but based on expectation. The reality is that there might be something lurking in there that is periodic and having the FFT result may lead to an indicator of what the problem may end up being.

From the several experiments I have run, I see wildly different DEC guiding performance. Some days it is significantly better than RA, other days it is on par, and still others it is much worse. I'm getting that sinking feeling that it is entirely due to seeing variations.

When I disabled DEC guiding altogether, I tend to get well-behaved trends and acceptably small high-frequency variations. Drift is slow as we would expect. However, there are those days that I've seen rather large displacements and even some oscillations. To me, that is unexpected and warrants further investigation.

Now that my setup is becoming closer to permanent, I will continue monitoring and will report back once I've been able to run extended tests with good seeing..

Al

[Andy Galasso]

Hi Al,

I'm not opposed to making changes, but I'd like to see a sample guide log to see what you are describing.  If you experienced periodic oscillation in Dec in a session within the last 60 days the log will still be available in your log folder.

Andy

[mahaffm]

Hi Ken,

Believe it or not but we actually got a couple hours of open skies, lots of humidity tho, But I was able to give a quick test using both the PPEC and Z-Filter only on the RA for both. Take a look at let me know if you see any difference in the guiding between the PPEC and Z-Filer. Sorry but that's all I was able to get done, clouds were moving in.

Thanks,

Mark

[Al Moncayo]

Ken,

Please find attached some testing from last night. Finally there was reasonable seeing. Humidity was somewhat high, so still not the best seeing possible in my area. I tried to be systematic this time and have included star field images (5 min single sub of luminosity) to compare stars.

- PPEC + Resist Switch (baseline that I had worked on recently with Bruce to optimize)

- Z + Z, using 2 sec exposure, order=4, corner=4

- Z + Z, using 1 sec exposure, order=4, corner=8

- Z + Z, using 3 sec exposure, order=4, corner=4

- Z + Z, with some other tweaks

For each of the first four, I have included a corresponding jpeg. They are all stretched equally and minimally processed. No dark, flats, or bias compensation either. Camera was at ambient temp (~20C). Note too, that I am breaking in my new 12" RC. I've already determined that its collimation was off out-of-the-box. I'll need to adjust it but for purposes of these comparisons, I'd say the collimation error wasn't of material consequence. It is present in each case, after all. I must admit that trying to image at 2432mm native focal length with OAG on a 4/3rd sensor is feeling like a stiff challenge -- quite a lot more difficult than what I was used to previously.

Final important note is that I switched back to my SSAG pro guide cam. In spite of its flaky USB behavior in my set up, if I get the sequencing just right it is quite stable and reliable. More importantly, it seems to be way better for guiding than my QHY 5III-178 -- which presumably was supposed to be a better guide camera due to its sensitivity and low noise. I do see that the SNR is dramatically better with the QHY, but I'd take a low SNR (20ish) vs. hundreds if the end result is much better guiding. As a critical side note, I found out that the way to make the SSAG pro work very well is to enable ROI in PHD and enable 12 bit mode in the camera's ASCOM control (gain=15%). This has the side-effects of forcing 1x1 binning only and disabling the ST-4 port, but again, as long as SNR is adequate, it works very nicely! ST-4 not being available is no issue either since I'm guiding through ASCOM.

The frustrating part of last night is that I ran the Z algorithm tests while waiting for my actual imaging target to creep up above the tree line. The fourth case which you will see in the second log ending around 3:13AM was the one I used to begin imaging NGC891. Annoyingly, Windows 10 decided to reboot my machine while I was asleep and while imaging was steadily in progress! Ouch!! I've now disabled the reboot action in the update scheduler and hope to never ever have this problem again...

I suppose not all was lost because this morning I discovered that my focus had shifted a bit so I would have been more disappointed to process all LRGB data only to find that the end result was out of focus. So many little details... Lol. You will see the measly 40 minutes of luminosity that I obtained attached too.

Al

[Brian Valente]

>>> Annoyingly, Windows 10 decided to reboot my machine while I was asleep and while imaging was steadily in progress! Ouch!!

 

 

Slightly OT, but that happened to me as well last night!

 

Must have been a mass windows update

 

 

 

Brian

 

portfolio https://www.brianvalentephotography.com/

 

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Al Moncayo
Sent: Wednesday, August 15, 2018 7:36 AM
To: Open PHD Guiding <open-phd...@googlegroups.com>
Subject: [open-phd-guiding] Re: Z-filter guiding algorithm now available in dev release

 

Ken,

--

[Al Moncayo]

Hi Andy,

Here is a log that you may look at. This is one of several cases which I can't explain. DEC appears to have some kind of periodic behavior that PHD tries to manage, but the signature is still there. It doesn't always happen though. My cable management is clean and the scope is well-balanced, so I have to wonder if it is a mechanical weakness and whether or not it occurs only when the scope is pointed at specific regions of the sky. I'll be more careful with documentation to see if I find any correlation. It didn't occur to me to run GA and see what DEC was doing intrinsically. Shame on me.

Al

[Andy Galasso]

Hi Al,

Thanks for the log.  I believe your dec axis behavior is fairly typical for what we often see.  There is a certain amount of declination backlash so that when the guide pulses reverse direction from north to south or vice versa, the pulses have no effect until the slop in the gears is taken up. After a direction reversal some of the motion of the motor is stored up in the dec gear train as mechanical strain (or "stiction") and when there are enough cumulative guide pulses applied the strain is overcome and the axis lurches forward. This causes an overshoot of the guide star requiring another direction reversal and the process repeats. 

Here's an example from your log. Notice the delayed reaction of the axis (backlash) and the overshoot (stiction):

Another example from after you enabled Z-filter on Dec:

again, we see the same symptom -- delayed reaction then overshoot.

Optimal Dec guiding would avoid direction reversals and sidestep the dec axis backlash and stiction problems. Ordinarily the best practice in phd2 for mounts with dec backlash and stiction (i.e. virtually all mounts) is to use the resist switch guide algorithm (which tries to avoid reversals), and to increase the min-motion setting to avoid chasing seeing. The guide star will slowly drift in Dec due to polar misalignment; ideally phd2 should be applying corrections to counteract the drift and nothing else. Here's an example of well-behaved dec guiding from another mount. Notice the very infrequent dec corrections in one direction only:

You should be able to achieve similar results on your mount by keeping the direction reversals to a minimum (for example use resist switch and increase dec min-move until you are no longer chasing seeing.)  There may be a a way to minimize reversals in Z-filter as well... I'll let Ken comment on that.

The RA axis is a completely different beast because it is always moving forward in one direction; guide pulses on RA only cause the tracking to speed up or slow down. Backlash and stiction do not come into play because there are no direction reversals of the gear train. Periodic error in the gear train is the dominant concern in RA. Z-filter has good potential on RA because it may be able to filter the high frequency seeing variations and correct the periodic error without chasing the seeing. (PPEC, Hysteresis and Lowpass2 are also low-pass filters and can effectively correct PE without chasing seeing.)

HTH,

Andy

[Ken Self]

On the dec axis you need to increase the corner value so that the short period movements are ignored. 16 or 32 or even 64 are better choices as the drift is seen as a very low frequency movement

[Al Moncayo]

Hi Ken and Andy,

Here are a couple of follow-up logs. I purchased and added extra counterweights to reduce moment arm effect after I swapped the 8" RC for the 12" RC (was counterweight shy the previous night so they ended up all the way at the bottom of the CW bar in the previous logs). I was also pointing in a slightly different direction. I re-used the calibration from the previous night. Incidentally, Ken, what are your comments about the experiments that I ran? Based on what I saw, there appeared to be only very subtle differences between the cases. The single 300 second subs were not really any different. My thinking was that if I can capture a sub over a period greater than the ~240 second worm cycle then it would be a reasonable comparison. Or no?

In these new logs, while the guiding seemed substantially better than the previous logs, my test images showed systematic star elongation in the east-west direction. In the 0816 log in particular, the PHD log viewer's scatter plot shows an RA drift bias. Is this the probable cause of the elongation? I've read a few folks indicate elongation in spite of good guiding. Honestly, this is the first time that I've observed such phenomenon and I am attaching a surface plot of an example star showing it.

Andy,

Regarding your comments about DEC in particular, note that I made some adjustments and managed to reduce the frequency of DEC corrections significantly (to look like the example you shared). But this was only during particular time intervals. During some time intervals I still observe the possible stiction effect that you were describing. I put a few annotated diagrams together to highlight this. You had mentioned backlash as a possible culprit, but every time I have run a calibration then a GA characterization I've seen that the mount exhibits very small backlash. As a result, I've generally disabled backlash compensation in PHD. Speaking of GA results, are those saved somewhere? In the debug log? I've not seen them in the guide logs. Otherwise the only way to capture them is with screen image captures.

Al

[Ken Self]

Hi Al

I agree that there is no discernable difference between the algorithms. Your thinking regarding the images sounds reasonable. One thing is for sure and that is that overall you are guiding very well - substantially less than 0.5"

Having just done some more calculations on the Z-filter algorithm I now realise that the Corner value needs to be divided by 4 and multiplied by the exposure to give the equivalent exposure. Previously I had thought it needed to be divided by 2. So a 4x4 filter at 2s behaves equivalent to a 2s guide exposure. I think I was able to identify which part of your log was for the 1s exposures with a 4x8 filter (corresponding to the image labelled as such) and that combination is also equivalent to a 2s guide exposure. Both the numbers and the image look very good.

To get the most from the z-filter you should lean towards shorter exposure times, keep minMo low and set the corner value appropriately. In the next release I'll divide it by 4 to make it easier to calculate the equivalent guide exposure time.

And as I mentioned earlier, you should try to use quite large corner values on the Dec axis. If you are using an exposure time of 1 then a corner value of 32 gives an equivalent guide exposure of 8s and would hopefully reduce the number of dec reversals

As regards the 0816 log I notice that the SNR is quite a bit less than usual - around 10. I assume this is why you increased the exposures to 3s. With 3s exposures the movements due to atmospheric disturbances are being filtered naturally by the exposure and would be masking the movements seen by the imaging camera. The guiding responses to those movements is also delayed till the end of the exposure. Obviously its difficult to reduce the exposure time in these conditions although you could try binning the guide camera and increasing its gain as much as possible.

If that isn't possible then your best bet is probably the PPEC algorithm 

[Andy Galasso]

On Fri, Aug 17, 2018 at 10:29 AM, Al Moncayo <a.mo...@verizon.net> wrote:

Hi Ken and Andy,

In these new logs, while the guiding seemed substantially better than the previous logs, my test images showed systematic star elongation in the east-west direction. In the 0816 log in particular, the PHD log viewer's scatter plot shows an RA drift bias. Is this the probable cause of the elongation? I've read a few folks indicate elongation in spite of good guiding. Honestly, this is the first time that I've observed such phenomenon and I am attaching a surface plot of an example star showing it.

Elongation despite good guiding is the signature symptom of differential flexure. I think you are using an OAG, which *should* eliminate DF, but it could still be present if for example the guide camera were somehow moving relative to the OAG.  Another possibility would be that it could be an optical issue (collimation?).  Another possibility is field rotation, but I think you can rule that out since you polar alignment is good and your subs are relatively short.

 

Andy,

Regarding your comments about DEC in particular, note that I made some adjustments and managed to reduce the frequency of DEC corrections significantly (to look like the example you shared). But this was only during particular time intervals. During some time intervals I still observe the possible stiction effect that you were describing. I put a few annotated diagrams together to highlight this. You had mentioned backlash as a possible culprit, but every time I have run a calibration then a GA characterization I've seen that the mount exhibits very small backlash. As a result, I've generally disabled backlash compensation in PHD.

The guiding looks great as long as the reversals are avoided, so I think you are on the right track tuning the guiding to minimize reversals.  You could go further following Ken's advise to increase the corner value. Another option would be to use Resist Switch on dec which avoids reversals by requiring multiple consecutive frames exceeding the min-motion value before reversing.  De-tuning polar alignment also helps reduce reversals (as long as the mis-alignment does not produce excessive field rotation.)

 

Speaking of GA results, are those saved somewhere? In the debug log? I've not seen them in the guide logs. Otherwise the only way to capture them is with screen image captures.

GA results are in both the guide log and debug log. Search for "GA".

Andy

[mark matzner]

Hi Ken, Andy, Bruce and Group

As soon as weather permits, I'll be trying the ZFilter algorithm in RA on my CEM120 (non-encoder).  My intent is to leave the DEC at "Resist Switch", which has been working well so far.

The scope is a deforked 12"LX200 Classic OTA, reduced to 2182mm focal length.  Guiding is via an off axis guider, through a 0.50x reducer to a Lodestar camera at 1090mm.

So far I've tried PPEC and Hysterisis with moderate success.

Based on my understanding of what has gone before on this thread, my intention is to start with the following:

1.  Bessel Order 4 Corner 8.0

2.  Exposure 1.5s

3.  Minimum Move 0.10px

A couple of questions:

a)  Should I create a new profile for this algorithm?

b)  Is a new calibration required for this algorithm change?

c)  Should I do a GA with this new algorithm?

Thanks,

Mark

[Ken Self]

A new profile is a good idea and you wont need to re-calibrate. You also don't need to run GA. Keep your exposure time as short as you can. Using a corner value of 8 with 1.5s exposures is equivalent to a 3s guide exposure in terms of filtering.

[mark matzner]

Hi Ken,

Here are the most recent PHD2 Log Files from Aug 7th to last night, Aug 20th.  Hard for me to draw conclusions.  Passing clouds and increasing moon don't help.

Maybe the "cluster" is a bit better with ZFilter.

1.  PHD2 Guidelog_2018_08_07_205605    NGC6781

   a)  PPEC Guiding RA

   b)  ResistSwitch DEC

   c)  Exposure 3s

   d)  Sections 3 & 4:  NGC6781 (Ha) sop-west & east

2.  PHD2 Guidelog_2018_08_15_231421    NGC6781

   a)  Hysteresis RA

   b)  ResistSwitch DEC

   c)  Exposure 1.5s

   d)  Sections 1:  NGC6781 (OIII & SII)  sop-east

3.  PHD2 Guidelog_2018_08_20_204541   NGC6781

   a)  ZFilter, Bessel Order 4, Corner 4, MinMov 0.10px RA

   b)  ResistSwitch DEC

   c)  Exposure 1.5s

   d)  Sections 2 & 3:  NGC6781 (Ha) sop-west & east

Mark

https://www.dropbox.com/sh/67hysy5ts7ooa82/AACcIydRZnedhg9waKoVGBVOa?dl=0

[Ken Self]

Hi Mark
Just a quick response while I analyse the results. When you halve your exposure time you should use a corner value of 8.

It took me a while to realise this and here is why. With a 3s exposure, all components less than 6s are filtered by Nyquist apart from aliasing. When you reduce to 1.5s and apply a corner of 4 you get a corner period of 6s. At face value this is the same but in fact it is only where the response starts to roll off with decreasing periods. So the real cutoff is closer to 3s rather than 6s. That means you are effectively applying something like the None algorithm on the 1.5s exposure.

Cheers
Ken

[mark matzner]

Thanks Ken,

it's probably too late in the day to catch you, but ....

I'm really confused now.  If I stay with the 1.5s exposure, should I use the corner value of 8?

My math has quick working for me.

Thanks,

Mark

[Ken Self]

Sorry about the confusion Mark.I only just worked it out myself.

Simplistically, if you stay with 1.5s exposures vs 3s exposures then use corner 8. I'll simplify this in the next release