Last night I was doing some more imaging on NGC 2359. As expected I had
problems with the dome taking off again when the mount was synced just
before meridian flip.
When the mount was synced before the flip, the dome started to rotate to the
west basically from 202° to 280°. It stayed at 280° while the mount
fliped and as the mount finished its movement the dome started to return
to the correct position. However it took too long to come back - thus
the verifying plare solve did not work - it was trying to solve a
capture of the inside of the dome. SGP went into Recovery. During the
recovery it managed a first platesolve image download but
the dome again took off (when the sync was issued)- this time in the opposite direction: from 159°
to 079°. This time. it returned to correct position in time to get
enough of the capture to verify final position of the mount and the sequence
continued.
I had the Temma Ascom log enabled and although, there is very little
logged, you will note that there were two very incorrect syncs received
at 23:21:25 and 23:28:33. These are, I presume, what are causing the
dome to slew off one way or the other. (I could not copy the actual
Temma log file - I have included (in dropbox) a screen capture though.
Also included - the SGP log and the dome tracker log covering the times
of the problem).
I hope the logs sheds some further light on what is happening - basically
every time a solve and sync happens.
Dropbox Link
Times: 23 21 26.04 Dome takes off 78° clockwise and 23 28 33.313 Dome takes off 80° anticlockwise.
Temma Log: 23:28:33 - Sync Ra 07h26m52s Dec 37d34m12s
That could certainly make the Dome not know where it’s going as it now thinks the scope is pointed someplace totally different. When the dome sync timer runs out it will slew to where the scope says it’s pointed at. The coordinates that we’re reporting in the log are exactly what we send to be synced.
Logger.debugln( "Telescope: Syncing to JNOW RA: " + ra + " Dec: " + dec );
tel.SyncToCoordinates(ra, dec);
So I’m not entirely sure where this is getting lost in translation between SGP and the Temma driver. Is anything else connected to the Temma driver besides SGP (and what appears to be PHD2)?
Hi Jared, yes, I suppose it was an interesting find. At least it confirms (with numbers) what Chris has said… that the dome is doing what it is asked to do. Now, we just need to be 100% sure what is doing the asking.
There is one possible other connection to to the Temma driver and I really can’t be sure if it was connected last night or not…that is The SKY X (SAE). At times I do connect it to view what is available or check the altitude of a particular target at this time or that time (and sometimes position the the scope with it). I know that I did not position the scope with it last night…but was it connected???
I am 100% sure though - that as soon as the plate solve frame was ‘solved’ - that is the exact moment the dome moved off to the wrong location.
I guess now I will have to do another test to rule that software in or out.
There are breaks in the clouds tonight - I’ll try get another test done and report back.
Well - I thought with your help there Jared I had found the problem. But afraid not. The SKY X (SAE) was not running. I slaved the dome to the scope, did plate solve & sync, did recenter here, chose another target and had the scope center on it, did another center here on that last plate solve image…all was going well. The dome was going where it should.
Then…a last target to check…image from the computer solved OK and when told to center on the target…the scope went one way and the dome went the other. By the time it came back the plate solve image was of the inside of the dome …same as last night.
I won’t attach all the logs - the ones from last night tell the full story…but here is the capture of the Temma log…
I wanted to go from Dec -13 to Dec +8…where Dec +37 came from in the sync, I have no idea…EXCEPT, just as I am writing this it hits me…that is my Latitude. Does the RA make a connection with my Longitude (1° 11.1’W) at that time…(Times are GMT)?
Yes, Ascom and the Shelyak &Temma drivers are the latest available.
Seeing the erroneous sync to my latitude makes me ask…where that
information may be coming from? Both the Shelyak & Temma drivers
have those numbers but if SGP is passing the sync (from PS2 in this
case) how would the latitude information leak into the sync received and
recorded by the Temma log? This is beyond me I am afraid.
There are three things I want to try to nail this. One, I’ll do myself at
first opportunity…I’ll play with the update frequency in the slave
settings. That won’t actually ‘fix’ the source problem - but it may help
me out. (I may also try plate solving with Elbrus or Astrometry.net
(local) - but I doubt that will make any difference).
The other two things require some info. Can you or anyone else running a
Tak Temma 2 mount, check if there are similar entries in your own Temma
log (showing your particular latitude after a solve & sync). This
may be there but not affecting your particular set-up…after all I
have no problem with the mount doing what it is supposed to do. Secondly
I’d like to test an older SGP - before the JNow - J2000 info exchange
came in. If you know offhand which version that appeared in, I’d
appreciate it…otherwise I’ll just go looking through what I have here
myself.
The above may seem a bit far fetched…but I can’t think of anything else
to indicate whether this problem is emanating from SGP, Temma or
Shelyak. The problem has been there quite a long time (for sure when
this topic was raised: Odd Dome Behavior while slewing to 2nd Target - Sequence Generator - Main Sequence Software).
It was an inconvenience before, now it really is having a huge impact
on how I want to run things.
Brendan.
**Additional note: Just now noticed/remembered that PS2 also has the Lat & Long info. **
AIUI the dome is controlled by SGP and nowhere else. This means that the bad dome position command is coming from SGP. The SGP logs don’t seem to show what dome position commands it is sending.
It is likely that the reason for the bad slew is that the mount is returning a bad position. This seems to sort itself out once the slew to the other side of the meridian has been done. Getting the position data that the mount is returning will be useful.
One thing that may help is to enable the ASCOM DriverAccess Trace. This will log every message sent and received by any application that is using the ASCOM DriverAccess component - which SGP does. This can be done in the Trace menu option of either to ASCOM chooser or the ASCOM diagnostics. No need to run the diagnostics.
This will, hopefully, generate several ASCOM.DriverAccess log files, for the scope, dome and camera. With a bit of luck these will show what is going on.
Is there some way this can be reproduced without wasting good imaging time? Difficult with something that relies on imaging and plate solving.
Thanks for looking in again on this Chris. I’ll enable the trace via the diagnostics page and see what is produced. (Unsure where that will be saved - but I am sure I will find it). I’ll do some testing as soon as I have stars to plate solve & sync with.
If I put slightly different latitude values in Temma, Shelyak and PS2…if we see one particular value showing up in the Temma log - might that indicate the source of the bad sync info? (The Latitude numbers that are being passed to tell the dome where to align itself are the easiest for me to track down).
Just one point re your last post: this does not just happen at meridian flip - it appears it can happen anywhere once a solve & sync is involved. (Sometimes I don’t notice it because the dome does not move too far…and thus a subsequent plate solve image is not affected).
OK - a follow up tonight. Thanks to Chris for pointing me toward Ascom Driver Access Trace. I can see now what is happening - but I don’t know why.
Chris was right the first time around - the dome is doing what is being asked of it. Ken & Jared are also right - looks like the correct sync information is being passed to the mount.
Tonight, I connected mount, dome & camera. I unparked the mount and at that position did a solve & sync. The dome took off for a little spin - but came back again. I then solved a previous image (NGC 2359) and told the mount to center on that location. It did that OK but when verifying with the solve & sync on ‘arrival’, the dome moved off some & returned. However it did not move too far. the move did not block a second solve & sync that verified the move completed correctly after slight adjustment.
What appears to be happening - though not every sync as far as I know - is that the mount momentarily syncs to the Zenith even though the proper RA & Dec are being passed to the mount. Why this happens I don’t know. It appears to correct itself within seconds (on the test I did tonight anyway) - but the dome has already started moving and this is what is causing me problems. This would not be noticed working the mount without a dome (I guess) as the mount remains in position during this critical time.
Looks like the answer to my problem does not lie with SGP.
Chris - if you have time to look at the attached logs - whenever - just let me know if my reading of the information is correct. Any thoughts on why this might be happening?
Yes, it’s pretty clear, the mount is reporting the position incorrectly for a few seconds after the sync command.
This is something you will need to take up with the Temma driver author or mount people. It isn’t something that can or should be fixed in SGP.
One thing that may be significant is that the initial Ra is 0.003 and the sync position is 23.994. The change happening over the 0 - 24 hour boundary may be relevant.
Thanks once again for all the time you put in on this Chris. As soon as I had a look through those logs - I knew it was not SGP…but until you pointed me in the right direction I had no idea. I am still not sure if it is hardware or software - but I’ll stay with it until I get it sorted.
This is what I am getting back from the Temma driver author:
The Temma protocols require the following structure to sync:
1 - Set Sidereal time
2 – Send Zenith command
3 – Set Sidereal time again
4 – Send sync coordinates
AND
All Temma commands are dictated by the Takahashi protocols. So, the
Zenith command is required before the actual sync coordinates will be accepted
by the mount. Moreover, the latency of sending and receiving the commands
can be as much as 250 ms each. I’m not sure what I can do on my end since
I can only follow the command protocols.
So, looks like what we are seeing in the logs is as expected from Temma 2 (Takahashi). I cannot understand then that nobody else is experiencing the same problems…maybe they are not operating domes ???
What I would recommend is that the sync command block until its good and not to change the ra and Dec that the scope is reporting to bad values. Sgp has no way of knowing when this happens.
Also what do you have your dome slave time set to? Increasing that may help to make this happen less often. And while not a fix it may take care of it for the vast majority of times.
IMO it should be up to the driver to implement sync without returning incorrect values. If this requires that it has to jump through hoops to do so then so be it.
There are several ways this could be done, one way would be to block all commands while the sequence of commands needed to do a sync is done.
Expecting the application to guess that because a sync was done recently the data can’t be relied on isn’t really acceptable.
I don’t think the slave time (10 secs) has any bearing - the dome takes off immediately the sync is completed…or at least as soon as the mount reports the position (albeit the wrong position).
Tonight I have done several solves & syncs and one meridian flip during an imaging session - throughout, the dome stayed with the mount. Looks like the modified driver has done the trick.
