Progress with FSQ106

[Ryderscope]

Further to my previous thread here (http://www.iceinspace.com.au/forum/showthread.php?t=188998), I have bitten the bullet and swapped out the focuser on my FSQ106 with a new FTF3515 from Feather Touch. A very nice piece of hardware it is (if a tad expensive!). The improvement in the data quality is huge with what now appears to be a nice flat field as measured by the tools in Pixinsight and examined visually.

I am, however, still having difficulties with star alignment when registering the images taken either side of the meridian so there is definitely something awry with the data. I've tried RegiStar and Pixinsight and both give me the same (bad) results. That is that the bright stars do not quite line up in the registered images. Blinking back and forth shows the bright stars to be not aligned. If I take this data through the full image integration and channel combination process I know that I will finish up with coloured flares around the stars which is not good.

There is a link here to a Dropbox folder (https://www.dropbox.com/sh/0io1r3boiz8e2hc/AACjx57GJJo2sKgWTe1Asqmxa?dl=0) which contains pre and post meridian flip images. I have saved the raw and calibrated subs in *.fits format and *.xisf format.

The attached images show the output from the aberration inspector script and the FWHM eccentricity script in Pixinsight. These indicate that the data is clean and the field is relatively flat with no obvious tilt or field curvature. If I take the time to peer very intently at the brighter stars in the images I can maybe see some slight elongation that is different in the pre and post flip images but it is very small and I am needing to zoom in to 200% to pick anything. At the end of the day though, there is something in this data which is causing the brighter stars in a registered image to not line up.

I'm working on the assumption that I may still have some residual tilt that my eye and the PI tools are not picking up. This being the case, I would like to hand over this data to my learned colleagues on this forum to see if anyone wants to forensically analyze this data and see what can be found.

Thanks for looking,
Rodney

[Ryderscope]

FWIW, I've downloaded an evaluation copy of CCD Inspector to give it a run. Attached are the curvature map plots extracted from same. As I am not familiar with the use of CCD Inspector, I am hesitant to try and interpret these results. If others who are more experienced could chime in and interpret this for me this would be good.

The plots are one for the pre meridian flip image and one for the post meridian flip image. I've set the image parameters in CCD Inspector to make my configuration which is an image scale of 2.09" and pixel size of 5.4 microns (QSI683).

[multiweb]

Looks very good. :thumbsup: The two CCDIS plots are very consistent across the meridian flip which is what matters.

[gregbradley]

Congrats on your focuser solving that issue. Unfortunately its all too common a story with FSQ's. Let's hope they finally got on top of it with the EDX4. My EDX3 was really good but obviously there is sample variation with them.

I just registered your subs in CCDstack 2 with the CCDIS plugin.

Looks perfectly fine to me. Perhaps your registration software is the issue here.

I find CCDstack 2 and the CCDIS plug in to be very good. It only fairly rarely fails (usually when the subs are too far apart in alignment. Then I do a manual align and then redo CCDIS and it usually works.

Greg.

[strongmanmike]

Bah!..ditch that CCD Inspector/PI analysis palava :rolleyes: its bogus and not what people look at, it is the final image that counts and from those mozaics you posted...well?...in the immortal words of Gary Coleman.. "watch you talkin bout Willis..?" (https://www.youtube.com/watch?v=Qw9oX-kZ_9k) :shrug:

If you have some registration issues it is your registration software, or how you use it, that is the likely culprit ;)

Mike

[Ryderscope]

That's very interesting Greg. I will download a trial version of CCDStack and give it a shot.

[Ryderscope]

Thank you Mike for bringing things down to reality. I've never had this sort of a problem before and accept that I may be getting down to minutia. I do suspect though that if I run the full data set through the workflow it will show up in colour flares around the stars. I do agree though the sometimes we can drill down into the sub pixel level and get lost in the haze :)

[Ryderscope]

Hi Greg, I've downloaded CCDStack and the CCDIS plug, aligned the two frames and then ran the blink function. When I blink them I am seeing exactly the same problem. I've uploaded a MP4 video file of what I'm seeing in the CCDStack window. Click here to access video (https://www.dropbox.com/s/8j9mayslm38kg1v/NGC3293_CCDStack_Blink2.mp4?dl=0) . Note that it seems to be only the brighter stars that are misaligned.

Edit: This video here

Thanks,
Rodney

[gregbradley]

I only used the .fits files. XSIF does not work in CCDstack. I think its an image format for a processed image.

I only use .fts when registering. The only operation I do on the RAW files are calibration -darks/flats/biases depending on the camera).

Your lettering system - I assumed r means registered, so I didn't use those.

So in your dropbox you should really only have the RAW fits files, nothing registered once before. Calibrated fits are fine.

I have never seen CCDstack do that. Only if they in fact did not register.

Is the blinking of what? It looks like one is preregistration and the other is post registration. Did you do a combine? CCDIS tells you when registration fails. Did it say it failed?

Is this what you did?

I am downloading those files again and will run CCDStack CCDis on it
with the accurate box ticked.

Also why do all the fits files have the same file name? Are they copies of one image or are these different images?

Greg.

[Ryderscope]

I also only used the fits files, the calibrated versions. Did not do a combine, only used the align (register) function. The steps implemented were:
- Open images *_2021022707_c_cc.fits & *_2021023456.fits
- Stack -> Register -> CCDIS 'align all' -> Apply 'Apply to all'
- Image select tool 'Blink'
My understanding is that this should blink the open images which have now been aligned.

For clarity I have removed the registered files and XISF files from the Dropbox folder.

[Ryderscope]

Sorry, I just saw this comment. Attached is a screen shot of the directory of the Dropbox folder that I have linked to. There are two subs and I had included the raw and calibrated version of each. Were you registering the same image maybe but the raw and calibrated version?

Just to be safe anyway, I have removed the calibrated versions from the Dropbox folder. There are two files contained therein:

NGC3293_V2_300sec_Green_20210207_02 2707.fit (pre meridian flip)
NGC3293_V2_300sec_Green_20210207_02 3456.fit (post meridian flip)

Rodney

[Joshua Bunn]

HI Rondey.
Could it be that the bright stars have bloomed a little, and that is what you're not seeing line up when registering?
Regards
Josh

[Ryderscope]

By blooming, do you mean over saturating the pixel well causing it to leak charge into adjacent pixels? If yes, maybe but I don’t see that with the QSI camera on my TSA120 so my presumption would be probably not. The QSI is an anti blooming CCD as well.

[Atmos]

Having looked at the raw files I’m wondering whether it is a collimation issue. Given that the stars look pretty good (appears to be some tilt... or is it!) I’m thinking that the FSQ is collimated but not into the centre of the mechanical axis, this may answer why the image seems to rotate around the top left corner.

It may also answer why the smaller stars remain quite still across the FOV but the larger ones are moving. If you look at the bright stars without any stretch their central PSF remains largely unchanged but as you look at the brighter flare, that’s what’s “moving”. I’m thinking that this is how the light is collimated, light further from the central optical axis has to move further across which gives it a different incidence angle. If the optical axis isn’t central to the mechanical then when it’s flipped 180° it isn’t symmetrical. Although the stars are in the same place the lights angle of incidence is different; non-symmetrical.

That’s my theory.

[Ryderscope]

Hmmm, quite plausible Colin but hard to tell. I do note that the image angle reported in the fits headers of the pre and post meridian flipped images shows that the change was 179.49 degrees rather than 180. I am assuming that this is due mount mechanical issues and probably a red herring. It could explain why the two images appear to rotate around a centroid in the corner.

Nevertheless, my working theory at the moment is that there is a small collimation issue combined with some tilt. I will do some more work on this to see if I can confirm this. I am preparing myself for the possibility that the OTA may have to be sent to Tak for service. If this is necessary I will be asking some more questions as I have now idea how one goes about that.

[gregbradley]

I finally got those 2 files - thanks for separating them.

I aligned them with various CCDstack and I see what you mean. The small stars are fairly static but the brighter ones are moving slightly.

I also did a star alignment in PixInsight and got the same result.

Odd. Is a lens loose in your lens cell or something? Odd its only on the brighter stars.

Greg.

[Ryderscope]

Thanks Greg, there is nothing loose are far as I can tell and it is only a relatively small aberration but still worth chasing down if it is possible to address. It is looking more to me like a combination of some small tilt and collimation issues. Now that I have CCD Inspector I can do some more objective tests to see.

And on that note, I would like to ask a specific question. When I run CCDI it shows a tilt of 9% - 10% and a collimation error of around 4". Are these sorts of figures indicative of underlying problems that need to be chased down or are they small enough that you wouldn't normally bother? Is there a benchmark for this sort of testing? Sorry for asking basic questions but I am not that familiar with using CCDI.

[Atmos]

Something worth trying the next night you can is when you cross meridian rotate the camera 180°. This will keep the subject in the correct orientation and may help narrow things down.

[Ryderscope]

I've conducted a rotation test by taking a 60 second image, rotating the camera about 90d and then taking another 60 second image. Guiding was operating fine at the time.

Attached is a zoomed in annotated screenshot of the stars in the centre plus a copy of the CCDI curve plot. Whilst the elongation in the stars is only small it is definitely there and definitely moves with the rotation. This indicates that the issue lies with the OTA which is what I was suspecting.

So the main question here is whether I will really need to do something about it as the aberrations may be such that they don't show up in the final processing. I'm going to finish the data capture on my current object and see how it lands.

[Joshua Bunn]

Hello Rodney,


I had a chance to blink through your images in CCDStack, I see what you mean. So, all you did between these two image is a meridian flip? To me, image ....23456 is much softer than the other, almost out of focus I would say, but I see there is only minutes between the images, same temperature and the same focus position. But, something has to be moving. If the orientation of the camera to the OTA has not changed between images, then that says to me, there is some flexure somewhere.



All stars in the image are affected by it, but it seems the aligning algorithm has chosen the smaller stars to align on, making it look like the larger ones are moving.


Without shifting anything, can you take 2 or 3 images on a row of, say 60 sec exposure or less, pointing more or less east about 45 deg altitude, then flip the meridian and do the same pointing west, don't rotate the camera. Use the RED filter. do you notice any elongation of the stars or shifting focus, and if so, is the orientation of the elongation different in each side of the meridian with respect to everything that is in front of the camera?



In your last post, you rotated 90 deg, is the rotator after the focuser? if it is, when you say the cause could be with the OTA, that would also include focuser sag if there is any.


Regards
Josh

[gregbradley]

Odd one Rodney. I have never seen CCDstack behave like that before with
multiple scopes.

Are you using the silly Tak mounting clamshell?
If so after some more tests I would think you’d be better off with a set of rings.
I used SoCal rings in my FSQ. ADM make rings as well.

Flexure is the likely culprit. You’re not there yet with that.

Greg

[Ryderscope]

Joshua, Greg - answers to your questions and more information:

Attached are snaps of my imaging rig. We have:
* FSQ106 -> Feather Touch Focuser -> mechanical adapters -> QSI683
Note: no reducer in image train
* Orion 80mm F5 guide scope -> ASI120 mini guide camera
* Parallax tube rings on both OTA and guide scope
* Skywatcher EQ8 equatorial mount

"So, all you did between these two image is a meridian flip?"
Yes

"To me, image ....23456 is much softer than the other, almost out of focus I would say, but I see there is only minutes between the images, same temperature and the same focus position."
I noticed this as well.

"Without shifting anything, can you take 2 or 3 images on a row of, say 60 sec exposure or less, pointing more or less east about 45 deg altitude, then flip the meridian and do the same pointing west, don't rotate the camera."
Worth a shot - will do.

"In your last post, you rotated 90 deg, is the rotator after the focuser?"
No, it isn't. See attached image of the focuser showing where the manual rotator (captains wheel) is on the Feather Touch focuser. The arrow is indicating the point of rotation. The only thing between there and the OTA is the adapter that screws on to the OTA tube.

"Are you using the silly Tak mounting clamshell?"
Yuk - no :D. Parallax tube rings all round.

So the summary of all this is that the consensus seems to be that the issue is flexure and is not with the OTA. I still have an open mind on this and will continue to explore further. I would rather have the issue being flexure as this is something that is more under my control. However, the logic behind the camera rotation test indicates that the problem lies on the OTA side of the rotation point and I cannot ignore this.

Being new moon now of course the weather forecast for the next three days is overcast :( so it may be a few days before I can get back on to this.

Thanks for all the contributions so far.

[gregbradley]

Could it be something stupid like the filters are loose. If they lean they can cause image shift. Are your filters and filter wheel all secure?

Greg.

[Stefan Buda]

I've done forensics on two problematic Taks so far, one being an FSQ106, and I found borth Captains wheel rotators to be seriously unreliable for maintaining proper alignment.

[multiweb]

Rodney's Tak doesn't have one. He has a camera angle adjuster (CAA). Did you have issues with these as well? I have one on my old Q. It's pretty tight machining. Nearly as tight tolerances as a bearing pressed in a bronze bush. That's how it felt when I took it off and put it back in.

[Joshua Bunn]

I wouldn't be surprised to find out that what Stefan says about the captain's wheel, to be true, if you're using one. On the other hand, I've done tilt measurements on a CAA from someone else, and found there to be untreatable tilt/movement in it, with it being fully tightened up. You need something that locks down in the same position every time, especially when pixel peeping :)


Regards Joshua

[gregbradley]

If you are using the CAA try removing it and see how you go.

A prime suspect.

Greg

[Ryderscope]

I'm not running with the Tak CAA Greg. I've swapped out the entire Tak focuser with the Feather Touch unit and did not re-install the CAA.

[gregbradley]

Oh sorry, I thought you left it in.

With the Feathertouch its worth knowing th escrew undeneath the focuser is a lock not a tension adjusting screw. One post here on IIS mentioned they damaged their focuser thinking it was a focuser tension screw.

Feathertouch focusers are great but not perfect. I remember Yuri from TEC Telescopes testing their FT 3545 focuser. Upside down it had less flex than right side up so it can move slighty. Worth checking. Is there any slight movement in it if you grab the end of it and apply some force with your hand - is there any give? Make sure its correctly tensioned up.

I have had a few FT focusers and never had an issue with them. They are also beautifully made. But really the best focusers I have used are the AP ones.

Stainless steel drawtube. Never seen anyone else do that. My car would not dent or flex that! Not that this helps you.

If you shake the scope a bit do you hear any lenses rattling?

Why don't you ask Claude for his opinion?

Are your filters well secured and can't lean forward? I saw an issue once with 1mm thin filters leaning forward and giving odd results.

Are you using threaded adapters to attach your camera? Try grabbing your camera and see if there is any give.

Greg.

[gregbradley]

This is worth a read about FSQ106EDX4.

Touchy stuff.

https://www.cloudynights.com/topic/758255-how-i-fixed-elongated-stars-astigmatism-and-coma-in-my-fsq-106ed/#entry10916851

Greg

[strongmanmike]

Yeah... I'm sorry but some people are just a liiittle too perfectionistic he he :). The amount of aberration present in that "before" shot would be unnoticeable in a final image after a a multi frame additive process across the sky, especially if a meridian flip is incorporated...

Still, if you can be bothered and are not worried about pulling your $8K scope apart a little :eyepop:... hey, knock yourself out :thumbsup: I suspect nobody will notice the improvement unless you pointed it out with close up comparisons :)

That said, given the seemingly fickle vulnerability to the phenomena, sounds like there would be a lot of FSQ's out there that would suffer from this very minor, variable aberration issue caused by slightly miss aligned elements... but it is all but invisible in final images.

Mike

[gregbradley]

True, but in Rodney's case the defect is visible and unlikely to be invisible in the final image.

It may be that one or more of these lens adjusters may be a tad loose allowing an element a freedom of movement it should not have.

Greg.

[Ryderscope]

Thanks Greg and Mike for continuing the discussion on this. I've finished grabbing a basket full of data on an area around NGC3293 with the QSI683 camera running on the FSQ106 and have started the processing on same. From initial inspections it does appear that the aberrations won't make their way into the final image. I will leave it to others to inspect, pixel peep, and see what can be found :)

Having said that, the QSI683 camera is much kinder to this scope than my new ZWO ASI6200 so we may not have heard the end of this story yet. I do agree though that we can get hung up on the minutia at times and the real test is what we finish up with on the screen. Any image that passes the discerning gaze of the viewer on this forum is doing well.

Best,
Rodney

[strongmanmike]

Yeah probably, I was mainly commenting on the CN thread :)...but I am not suggesting one shouldn't pursue improvement, but like the obsessive compulsion to get absolutely perfect polar alignment (if that even exists) especially by those with high end mounts :rolleyes:...when all they want to do is point at one object each night and track it for hours :shrug: So, whether a target lands 1, 5 or 10 arc min from centre of the FOV after a GOTO, is of no importance what so ever...:shrug: ...but they will hammer away and not take images until those PA numbers are perfect :lol:....or worse :eyepop: essentially never image at all :lol:

Mike

[strongmanmike]

Look forward to checking out the final result Rod :thumbsup:...as long as there are no worms :whistle: :lol:

Mike

[gregbradley]

Yes there are those on CN that seem to complain about extremely minor defects. I am sure the Tak distributor in the US is familiar with them.

But these new small pixelled CMOS cameras like the ASI6200 and QHY600 full frame sensors are mercilous in showing up defects. Seemingly more than the % difference in pixel size with the larger pixelled cameras.

I suppose if there was a full frame version of the 4.54 micron KAF8300 we would have seen some complaints then as well.

But if you lose sight of the real purpose of imaging, which of course is to take as good an image as you can, then yeah you've lost the plot.

Greg.

Greg.

[Ryderscope]

Time for a quick update on progress.

I've grabbed sufficient data with the FSQ106 now with both of my cameras (QSI683 and the ASI6200) to produce results that I believe I will be happy with. The optical aberrations that show up with image registration are small enough to get evened out during image calibration, registration and integration. The QSI683 is much kinder to this this scope with the larger pixels and smaller sensor though it is obvious when collecting data with the ASI6200 that there is still some work to do.

Capturing data with the ASI6200/FSQ106 initially showed definite tilt issues but I've managed to even this out quite a lot using the Gerd Neumann Camera Tilting Unit (CTU) that I have in the image train. It is easy to use as the adjustment screws are on the outside of the unit and easily accessible whilst watching the screen and downloading images. Whilst I have some work to do yet, I am pleased with the results so far.

Refer to this post (http://www.iceinspace.com.au/forum/showthread.php?t=189942) for my first published image taken with this combination.