Neither do I. Dithering should have zero impact while capturing, hence my question about relating captured frames and log sections (to see whether there is overlap).
If your guiding is perfect *during each whole capture*, then you might (might) have a big flexture issue, or you might have a big difference between your CCD resolutions that makes guiding inefficient, but all this sounds unlikely. Last frame is even either tracking off or tripod hit... My opinion is that we should better apprehend the problem if guiding is constant, and to guide permanently, you need to remove dithering from the equation.

-Eric

So that is what i‘ll do next session.




Gesendet von iPhone mit Tapatalk

Well, you had quite a few dithering failures. Does tracking continues but autoguiding stops? re-acquire? re-aquire on a hot pixel - use darks. I guess I would sit with it and watch how it handles each frame (shorter ones) and dithering. not sure if settling is required in options. I think it automatically settles the dither before taking the next pic - maybe measure the amount of time to offload the image to disk and set this time in the settle option.

How would i know if autoguiding stops and tracking continous? And why should tracking NOT continou? What does re-acquire mean? My english is not so good, sorry?

What is interesting maybe is, that the egg-form of the stars always points in the same direction. And in the bginning, i recognized that the "guiding marks" where all left of the center.

Those are good questions, that's why I say you'd have to watch the progress while imaging. Maybe the logs will say but watching its behaviour and checking is very helpful. I actually found a problem when I heard the scope making weird noises - not in the logs -lol. When it says dithering failed, then I imagine its no longer guiding or it has to re-aquire the guide star - i.e. find a new guide star and start tracking it. If you do not use darks with your guide cam, its easy for the guider to lock on to a hot pixel and you will have no guiding.

Also, look for possibility of guiding being interfered by the image download which can take a lot of time, causing the guider to stall for a while, maybe even lose the guide star.

OK. Good points you are talking bout.

Especially the camera download time could be the key, since it was the first time i used the g2 cam.
And what i know bout it now is that it takes some time to get the pictures from the cam.
Last time i was using guiding via kstars, it was my dslr. there is not such a long download-time.

I´ll definetly have a look on that.

Atm testruns with guiding, without dithering. Funny that, on an object very deep near horizon in the south, my guiding hits run out of the cross to the right. Same setup working good on cassiopaia region. How come? Suggestions? Weighting problems? I even had a failure when calibrating...

Taking testshots atm on hpersei

Cheers, Niki


Gesendet von iPhone mit Tapatalk

I noticed your guiding pulse lengths are 0. Something wrong there. Check guide options, configuration - two axis and auto star

and you have corrections for the graph turned off. Good to turn that on to see what's happening.

When and where exactly are you calibrating? Did you calibrate just before this target, or in another direction, possibly flipped? Having offsets on a side of the drift plot is not always a problem, but I haven't followed on changes to the internal guider lately.
If the drift plot is elongated to the right, it means that guiding corrections are slowing down the mount too much when it tracks too fast. Or, on the opposite, it means guiding corrections can't catch up on the mount tracking too slowly. It all depends on the root cause. Limiting pulse lengths can help to diagnose which is which.
If the drift plot is centered to the right, it means that you have an early offset that can't seem to be recovered. Early offsets are not a problem with guiding, as long as the initial capture doesn't contain the drift from the original center to the new one. However, this may cause some guiders to consider there is too much deviation and abort the capture.
But before tweaking guiding, as you mentioned, overweight or incorrect balance should be investigated: perhaps the weight of your setup is causing the mount to track too fast or too slow.

-Eric

Good point worth investigating, yes.

-Eric

Two axis was on, autostar was off...




Gesendet von iPhone mit Tapatalk

Because i thought so, i calibrated new on every new testobject. What i saw from time to time, when doing so, was, that the mount seemed to "not be strong enough" to give the guiding pulses enough power. Please excuse this very "picturey" spoken words, but i think you know what i mean..
Like: Dec axis forward. . . ok, dec axis reverse. . . . . . . . . . . . . . . . . *nothing happens* or even one time i got an error containing "too much backlash"...
Unfortunately today, cloudfileds are disturbing my tests too...

I had a look on the guiding pulse lenghth. Could be coincidence.. There are lots of numbers there, and sometimes just zero...

Had a look on my weighting one more time, changed it a bit. Can it be that this is sooooo extremely sensitive?

On the other hand, considering all this problems, i have to say, that i never had so big problems with guiding when using my MGenII... This points out that it must be
a problem with the internal guider... Or the settings of it...

I changed the setting of the Pulse(?) now to 800. ATM its working ok.

Changed too much now, so i am not sure what caused the improvement...Letting a 600sec session run now on flame nebula, clouds are gone now, so maybe there will be some pictures usable. I have one 600sec image here, thats ok now.

Unprocessed, only debayered Screenshot of flame with 600secs here.

so long, i`ll keep you updated...