I use a 10M1000hps mount unguided. For a year everything worked just fine. For a while now I have a problem which is dither-related.
When I unselect dithering everything is fine, but with dithering enabled on direct mount and at various settle times, what happens now is that the mount does a dither halfway an exposure. Or even during a automatic meridian flip the camera exposes. I see elongated stars or even double stars. The first image of a sequence shows long flare like trails.
I have SGP 3.0.3.169. I did not change any software, but the ASCOM driver from my QHY294C camera. Again when I do not dither the images are sharp.
Hey Arie,
From the logs it looks like you had one sequence finish at 21:32:11
[03/14/19 21:32:11.721][DEBUG] [Sequence Thread] Sequence complete.
and a new sequence start at 21:34:36
[03/14/19 21:34:36.327][DEBUG] [Sequence Thread] Dispatch loop: Received SGM_RUN_SEQUENCE…
And the first frame of the new sequence started here:
[03/14/19 21:34:50.892][DEBUG] [Sequence Thread] ------------- Starting capture frame for event[0] -------------
[03/14/19 21:35:22.818][DEBUG] [Camera Thread] SGM_CAMERA_CAPTURE complete…
Looking through the logs after that point it all looks normal:
- Start capture sequence
- Check for auto-focus
- Dither and wait to settle
- Capture the image
- Repeat
Up until the sequence is paused at: 21:36:43
[03/14/19 21:36:43.488][DEBUG] [Sequence Thread] Sequence pause detected…
[03/14/19 21:36:43.488][DEBUG] [Sequence Thread] RunPostEvent requested sequence break…
[03/14/19 21:36:43.488][DEBUG] [Main Thread] PopulateDataModel: Transferring view to the data model…
[03/14/19 21:36:43.498][DEBUG] [Sequence Thread] ********* Run post sequence *********
Can you clarify what “weird things” you are seeing at the 21:35 mark?
And what was the original time stamp for the image you attached above? It would be good to map them to specific sections of the log file.
You should find all the original images from the session here in this dropbox folder.
Please let me know if you have access or not.
I did dismiss a few times the “end of sequence” to prevent the dome and mount going to park.
Then I reset the progress to 0, changed the dither dettings and reran the sequence.
At last I reran M42 only a few times. I had “slew to target” at the start of a sequence selected.
Hence the mount realigned witht the target coordinates when starting a sequence.
Arie
Which driver for the mount do you use? I had the same problem once and fixed it by switching from Per’s driver to the newest official 10 Micron driver.
Txs Explode.
But the problem occurs with all three divers I have.
The 10M one, the Baader and Per’s one too.
I tried them all. Behavior is the same.
My suspicion leans towards the QHY camera driver.
That’s the only thing that changed recently.
Hey Arie,
I had a close look at your logs and there really doesn’t appear to be anything strange in what SGP is doing or reporting in the results it get’s from the guider or camera.
As an example, looking at m42_30sec_1x1__frame1-2.fit
It shows some clear movement of the stars in the captured image. Looking at the some of the key events in log file, all looks normal:
[03/14/19 21:29:22.166][DEBUG] [Sequence Thread] DoEventGroupChange: Slewing to target
[03/14/19 21:29:32.506][DEBUG] [Sequence Thread] Telescope: Slewing has completed
[03/14/19 21:29:32.506][DEBUG] [Sequence Thread] Telescope: Settling for 5 seconds
[03/14/19 21:29:37.507][DEBUG] [Sequence Thread] Telescope: Settling has completed
[03/14/19 21:29:38.654][DEBUG] [Sequence Thread] ------------- Starting capture frame for event[0] -------------
[03/14/19 21:29:38.718][DEBUG] [Camera Thread] SGM_FOCUSER_AUTO_FOCUS message received…
[03/14/19 21:29:38.720][DEBUG] [Camera Thread] Checking for auto focus…
[03/14/19 21:29:38.737][DEBUG] [Camera Thread] SGM_FOCUSER_AUTO_FOCUS complete…
[03/14/19 21:29:38.914][DEBUG] [Sequence Thread] Resuming auto guiding (settling)…
[03/14/19 21:29:38.915][DEBUG] [Sequence Thread] Waiting for Auto Guider distance to fall below 0.5
[03/14/19 21:29:38.924][DEBUG] [Sequence Thread] Distance is below 0.5, starting timer…
[03/14/19 21:29:44.064][DEBUG] [Sequence Thread] Distance stayed below 0.5 for 5 seconds, done settling…
[03/14/19 21:29:44.100][DEBUG] [Camera Thread] SGM_CAMERA_CAPTURE message received…
[03/14/19 21:30:14.638][DEBUG] [Camera Thread] SGM_CAMERA_CAPTURE complete…
[03/14/19 21:30:15.291][DEBUG] [Sequence Thread] Created full file name: C:\Users\arie\Desktop\SharpCap Captures\test\Light\m42_30sec_1x1__frame1-2.fit
There was no dither for this image, but you still ended up with star trails.
Are you sure that there isn’t some slop somewhere in the imaging train: focuser, camera attachments, scope/mount attachment etc? And was it windy on the night you were imaging?
To me it really looks like some external factor (not the s/w or drivers) that is causing the issue.
BTW: Later in the logs you reduced the guider settle time down to 1s and then 0s - not sure why you did that, but it is unlikely to help :). If anything, you may want to try increasing your settle times to see if it helps.
Thank you Steve,
I have been looking back in older images taken with another camera.
Images taken with a ASI1600MM-C and a Canon7D do not show this behavior at all.
As from the very first image with the new QHY294 camera the problem arose.
Initial minor and hardly detectable. I had the dither at minimum amount. But when I zoom in on these images I see double spikes (newton) and oval stars. I now start to understand where the came from.
I have my set-up in a dome, so wind is not an issue.
About the settling times. I used to have the after slew and dither settling just at zero.
Increasing these values did not improve things so I set them back to what I was used to.
If it was mechanical slop, the split between the double stars should be random. But they are tiny at 0,1s and consistently bigger at 0,5s. I can’t understand how these dither settings (0,1s or 0,5s) can have this effect.
When I am back from my holliday (skiing) I will mount the ASI camera again and see what happens then.
Ofcourse I will keep you posted.
Will be interesting to see if switching back to the old camera fixes the issue.
And just to clarify your setup:
- Were you using your SW Esprit100ED or you Lacerta 10" f/4 newt for these images? (You mention your newt above, but not clear if that was for a previous imaging session or not)
- For guiding, are you using an OAG or separate guidescope?
- Do you have PHD2 logs for the same capture sessions and are you seeing movement in those logs that corresponds to the trailing seen in the images?
And to re-itterate: The star trails in m42_30sec_1x1__frame1-2.fit happened when there was no dither, so I think we can eliminate dithering as a possible cause.
Enjoy your ski trip! 
I used my 10"f/4 Lacerta Newton on my 10micron1000hps mount.
Therefor I take all my images unguided.
Confused - your logs show that SGP is connecting to and interacting with your guider (e.g. the “Waiting for Auto Guider distance to fall below 0.5” messages),
I’ve the same configuration, except the camera… QHY367c, and i’ve the same behavior with the dithering… but I haven’t changed anything in my driver , in the version 3.0.2.94 the dithering was ok for me, when i installed 3.0.3.151 the dither problems came out… repeat any driver change from my SGP star version 3.0.2.94…
Thank you very much for the moral support in this matter.
I started to doubt myself, cause what I state doesn’t make sense…
But it is what I observe and what happens to me.
I am glad (not really) that I am not the only one with this experience.
Common ground is the mount, the camera manufacturer and the software inbetween.
I cannot say when exactly the problem started to occur, In our weather we have only few opportunities to do AP. Since the last session I had a very cumbersome driver installation for a new QHY camera and a update on that one, (QHY is notorious for their software), one or two updates/upgrades of SGP etc… last night I installed QHY’s latest SDK by replacing qhyccd.dll in the SGP program directory by their latest version. Obviously I am now waiting on a hole in the clouds at the right time and the right place.
But what I read from you is that maybe I should go back to SGP 2.x ? I know that worked.
I tried an older version of SGP, but with the same result.
When I select “no guider” I still have the trails when the mount slews into position(unless I settle for 20 sec), but thereafter no dithering takes place anymore. So sharp images, but no dithering.
After swapping camera’s to ASI1600MM-C, everything is fine and perfect.
Direct mount guider and 1 sec dithering with no settling time at all. Not even for the mount slewing.
Pinpoint sharp images. Dithering happens as it should inbetween exposures.
Conclusion: the QHY software is the culprit. No real surprise . . . . . .
Here is a test run I made today.
The dither is set at 0,1 s.
The RA dithers briefly OK.
But as you can see on the hand controller and the upper graph, the DEC receiving a signal for 12s
Is this a SGP issue or a 10Micron problem?
sg_logfile_20190404161926.txt (854.3 KB)
Definitely an interesting result.
It appears that DEC continues to move/be updated while the auto-guider is “settling”.
- What happens if you disable the “Settle for X seconds” option? Do you still see DEC move?
- And what’s really interesting (to me :)) is that you don’t actually have any auto-guider connected, right? So it’s not clear to me what “settling” can actually occur here? (SGP and the non-existent auto-guide s/w have no idea whether the non-existent guide star has settled or not…)
Looking at your logs, the actual dither duration being sent by SGP is 10s, even though you have specified 0.1s - did you change this before capturing the video?:
[04-04-19 19:15:08.207][DEBUG] [Sequence Thread] Running dither…
[04-04-19 19:15:08.222][DEBUG] [Sequence Thread] DM dither request sent: 10000ms…
And again from the logs, we see that SGP is apparently waiting for the “guide star” to settle, even though there is no guide star…?
[04-04-19 19:15:08.517][DEBUG] [Sequence Thread] Waiting for Auto Guider distance to fall below 0,2
[04-04-19 19:15:08.547][DEBUG] [Sequence Thread] Distance is below 0,2, starting timer…
[04-04-19 19:15:23.839][DEBUG] [Sequence Thread] Distance stayed below 0,2 for 15 seconds, done settling…
[04-04-19 19:15:23.839][DEBUG] [Sequence Thread] Auto guider has settled…
So I guess SGP is basically just “waiting” for the 15s timer to expire before moving on. Why your DEC continues to change during this time, I don’t know. Are you using an ASCOM interface to your mount? If so, you can grab the ASCOM logs to see if any move commands are actually being sent to the mount during this 15s “settle” time.
And the final weird part is that image integration only happens after all the movement has completed, so still not clear why you would end up with trails in your final images…
Hi Steve
Thanks for the reply again.
I used the ASI1600 this time and see the same behavior.
Why I did not see that before I do not understand.
I guess I was so biassed in a negative sense to the QHY camera, that I was blinded…
As stated before I have NO real guider attached, But the only way to get a dither from SGP is to emulate one like this. All 10M users do this.
==And again from the logs, we see that SGP is apparently waiting for the “guide star” to settle, even though there is no guide star…?==
I did not write the program 
If I don’t select this the next exposure start straight away after the first dither command, and I get trailed stars. (I could quote Jared on this in another thread on this matter)
JaredFounder & Developer
Worth noting is that there appears to be an issue with the settling. Essentially if you want to settle for 5 seconds and you have a 1 second dither pulse you need to settle for 6 seconds as the pulse dither is not waiting to start the settle. Also if you have no settle then the image is immediately starting…so you’ll certainly want to have some amount of settling. Working to address this now.
Thanks,
Jared
I think that if I will set the “settle time after dither” at anything >12s the trailed stars won’t show up. But I need a clear sky to test that.
FYI
I have send this information including the mount logs to 10M. They should be able to figure out where this 10s DEC move comes from.
The whole bunch of files is at:
If you say it is 10s (my 12s was a visual guess), could that tally with the 0,1s setting but a decimal error generated somewhere in the DEC command line? 10000ms =10s
I had the 0.1s selected, did a few test runs, then downloaded a screenrecorder, figured that one out etc…
As you can see on the video I had 0.1s. selected for the whole exercise.
The logs and video are a live recording from the same event.
Another observation I have to mention.
At one stage at 17:30 this afternoon, I had the dither set at 5s.
What happend was that RA dithered briefly but the DEC jus ran away and kept on going until the exposure was finished and the next dither command was issued. I had cancel the sequence to stop it,
The log shows: (after your remark I just checked)
[04-04-19 17:30:34.755][DEBUG] [Sequence Thread] Running dither…
[04-04-19 17:30:34.766][DEBUG] [Sequence Thread] DM dither request sent: 500000ms…
500s is a bit extreme I like to believe.
It seems there is something fishy with the 0.1s setting and the actual 10000ms in the log.The dither durations to RA and DEC differ by a factor 100
And still, I never had to set any settle times before . . . . . . . .
Did you change anything in the code when you went from small and extreme dither settings to time setting?
What is the use of having the option to dither for 30s?
Indeed :).
So it seems that there is a bug (or two) in SGP and that:
- It is sending the wrong dither request to the mount (10s instead of the requested 0.1s, or 500s as above)
- SGP is not waiting for the dither to complete before starting the settle timer
- As a result, if the settle timer finishes before the dither finishes, you will see trailing in your final images.
This should all be pretty easy to test - in fact, in your images where dither was set to 0.1s and settle was set to 15s, were you actually seeing any trailing? (hopefully not).