Direct mount dithering during exposure

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! :slight_smile:

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 :slight_smile:

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

Dec '18

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.:face_with_raised_eyebrow:

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:

  1. It is sending the wrong dither request to the mount (10s instead of the requested 0.1s, or 500s as above)
  2. SGP is not waiting for the dither to complete before starting the settle timer
  3. 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).

For me dither won’t run at all because of decimal separator error, it just says “DM dither request sent: ms…” whatever i set it to.
I hope the devs can fix both these issues, unfortunately it seems devs aren’t doing much lately to fix issues :frowning:
I fear SGP is loosing some of it’s userbase due to small errors not being looked into :frowning:

This the response from 10Micron:

the mount communication log shows that the declination axis is indeed commanded to move for 10 seconds at 0.5x (which it does). The SGP log seems to confirm that the command is sent as a request to move for 10000 ms.
The 15 s settling time should avoid star trails in the pictures, but clearly this isn’t the way it should operate.
Regards,
Filippo Riccio
sviluppatore software 10micron
10micron software developer

Another comment from a 10m user:
I cannot help you as I’m rebuilding my equipment / observatory but before that with my GM1000 I never even entered any information in “Settle” and “for” and that worked very well. Is this needed now ?

I don’t understand why above text is bold and big.
Not intentially. Sorry.

I am finding out about the dither timing and settling etc. because I started to get trailed stars, without having changed anything in my SGP settings.
As mentioned before I never had to set any settling time before and had pinpoint stars allways. And dither did work. I could tell from shifting trough the images and by looking at the edges of a stacked image.

I hope this can be fixed soon. I think SGP is a good package. It always has served me well.

Hi Arie,

thanks for the link to the video, good to see that MountMonitor has helped to pinpoint this issue.

For those wondering: MountMonitor was written by myself for 10Micron mounts on order to visualise the mount’s behaviour. The current version 2.00 shows RA and DEC values and their standard deviations and has an option to include a seismometer to see if ambient vibrations can be correlated to anomalies seen in the RA and DEC data. There is not yet a website for MountMonitor, so far it has been explained on the 10Micron forum only.

As MountMonitor works with the LX200 protocol, it may work with other mounts than those manufactured by 10Micron and may thus be of interest for owners of other types of mount.

The software can be downloaded from my website: http://www.dehilster.info/docs/MountMonitor_v.2.00.zip

It contains a Windows help-file (CHM) with installation instructions. The software is written in Java and should run on other platforms as well, although that has not been tested yet. It connects to the mount via LAN and to the seismometer via a virtual serial port over USB. The software does not alter any of the mount’s settings, only reads data from it. I have not yet been able to implement ASCOM using Java, so any help with that would be greatly appreciated.

Nicolàs

Thank you Nicolas.

This is a conversation with 10Micron:

Me:
Filippo,
Can you tell from the log file what the duration was for the RA pulse?
Both directions respond quite differently to the 10000000000000ms !
DEC is taking the full 10s as set. But RA moves apparently very brief.
I don’t understand why they are so different.
The SGP-log shows only a single instruction line for the dither request.
How does the mount get these instructions from SGP?

10Micron:
The ASCOM driver receives a “PulseGuide” call from SGP with the duration (in milliseconds) of the pulse. The ASCOM driver then sends a request using the pulse guide commands of the mount protocol (which are :MnXXX#, :MsXXX#, :MeXXX#, :MwXXX# where XXX is the duration in milliseconds). Since the mount firmware didn’t accept durations > 999 ms, a request longer than 999 ms is split into a sequence of requests by the ASCOM driver.

What I see is that the declination is commanded by a sequence of 10 * 999 ms pulses, plus one 10 ms pulse (adding up to 10 seconds), while right ascension receives only one 999 ms pulse. The declination indeed moves for one second, and right ascension moves for 10 seconds.

Without having the log of the ASCOM driver, I guess that there may be a problem with the ASCOM driver itself. Probably SGP is sending a 10 s request to both axes and the logic that splits a longer pulse into many smaller pulses in the ASCOM driver doesn’t work correctly when multiple axes are moving. I’ll investigate.

However, the right ascension is commanded with at least a 999 ms pulse (which it executes).

Regards,

Filippo Riccio

End quote

Trust this helps finding the solution quickly.
Arie

Just did a short 5 image test.
With 0,1s dither and 15s settle I get round stars again.
However the dither in DEC is much much more than on the RA.
Actually 100x more.
We now know why this is. . . . . . .

@Jared

Can we get this issue officially logged on the bug list?

Again to summarize: From the SGP logs, it appears that when configured for direct mount guiding control, SGP is sending the wrong duration dither command to the mount (e.g. sending 10s instead of the configured 0.1s). Hopefully this will be an easy fix…! :slight_smile:

thanks!

It’s been logged and is getting addressed right now along with a couple of other direct mount dithering issues.

Thank you,
Jared