Direction control button switches off tracking

[GreenhillAstro]

I use the scope control buttons for positioning stars on the end of a fiber coupled to a spectrometer. For doing so, I need to click multiple times on the same button until I reach the correct position. I recently discovered that when using the move right button more than one time, the mount runs away until I press the move left button. Moreover, clicking on the move right button switches off tracking and the star rapidly drifts out of the field of view. Finally, when I use the spiral button, the mount still moves up and down, but drifts away to the right. Strangely enough, it seems to be only a problem with one direction.

SharpCap 4.1 (3/3/24) communicating to the mount through CPWI
CGEM II connected to the computer via the hand controller
CWPI 2.5.5 (latest version)
Windows 10 on a MacBook Pro

[admin]

Hi,

I have made some updates to those movement buttons recently, and at one point those updates led to some issues, so it may be worth updating to the newest version of SharpCap from the downloads page to see if that helps resolve at least some of the issues you are seeing. You should just be able to hold the button down to make the mount continue to move until you let go.

Resuming tracking after finishing the movement is supposed to be the job of the ASCOM driver (ie CPWI), but it turns out that a lot of ASCOM drivers are really bad at sticking to that rule, so SharpCap tries to reset the tracking itself for EQ mounts. I'm wondering if whatever issue is causing the movement to runaway (ie not stopping the mount when you stop pressing the button) is also causing the reset of tracking to be ignored. Let's see if the updated version helps, and if not we can try getting a log including all the communications between SharpCap and the CPWI ASCOM driver to see what's going on.

cheers,

Robin

[GreenhillAstro]

Thanks for the fast response. It will take a bit until I have time to test the new version.

Concerning keeping the button pressed:
I have a 50µm fiber and hitting it exactly is somehow demanding. I select the smallest step size and then estimate the number of clicks needed to get the star at exactly the right position. My feedback is the signal on the spectrometer which has a time delay. Keeping a botton pressed is therefore not really an option.

BTW, the multi-reticule tool is my lifesaver in this process. Through multiple attempts, I refine the location of the fiber in the camera image and adjust the location of the reticule. From then on it is easy to record a spectrum of a particular target. Unfortunately, the position will change next observation night but will be at least still nearby. It would be great to have some kind of scan function in which a given area is scanned with a particular step size. That would be particular useful when not seeing a signal on the spectrometer.

el

[ja2003]

Hi I have something similar
I use EQMOD version 2.00w to connect my laptop direct to the mount EQ6R-pro. I slew to target using Stellarium 23.4 and center using plate solve and resync using Astap via SharpCap (version 4.1.118240.0). Normally that is the end of it. However I wanted a very specific framing of the Markarian Chain so used the slew buttons on the mount control pad in Sharpcap. Guiding is controlled by PHD2 version 2.6.13. Guiding then stopped and the PHD2 log trace shows a classic ST4 cable issue (according to the tutorial on using the log viewer). Except I don't use a ST4 cable - my guide camera connects to the USB hub on my imaging camera and hence to the laptop. THe mount connects to the laptop directly via a USB cable.
In a subsequent session when I did not use the mount slew commands in SharpCap I had no problems
I have the debug log for this session - 8 Mbytes - should it be helpful
Using ASCOM Platform 6.6
The work around seems to be to use the slew buttons in EQMOD
Any insight gratefully received
Thanks
Julian

[admin]

Hi,

I'm a bit puzzled, since the PHD2 log you have included seems not to mention anything about ST4, and apart from right near the beginning (where there are 2 'star lost' entries) there appear to be no issues recorded in the log.

I'd not be surprised that PHD2 would stop guiding if you move the mount manually using the direction buttons either in SharpCap or in the EQMOD panel - if the mount moves relatively quickly, PHD2 will lose the star it is guiding on and need to be restarted. If it moves slowly then PHD2 might track the star but try to move it back into the original position (undoing the movement made manually). Different selected movement speeds in SharpCap and EQMOD might explain the different behaviour.

cheers,

Robin

[ja2003]

Hi Robin
I have obviously failed to communicate. So let me try again, trying not to leave out any steps and forgive me for the detail, my intent is to faithfully record what I did and hence why it leads me to think that the issue might have stemmed from the Move buttons.
In summary, when I used the Move buttons in SharpCap I had a problem guiding; in a subsequent session when I did not use the Move buttons I did not have any problem which leads to the hypothesis that the Move buttons could be the cause. Here is what I do, did on 9th April and subsequent days, which explain why I put forward this hypothesis.
My start up routine is:
1. Load EQMOD - ASCOM connect
2. Load Stellarium - connect to mount
3. Load SharpCap - connect to hardware
4. Load PHD2 - connect to hardware
5. Select target in Stellarium and slew
6. Adjust exposure and gain and Plate solve & resync using Astap via Sharpcap
7. Check focus and exposure time using Sharpcap tools
8. Start guiding - may or may not run calibration and or guiding assistant and have a habit of starting guiding before I am ready, so have to press the PHD2 stop button and start from looping when I am ready
9. Start live stacking and saving subs – check dither settings and brightness filter

On this occasion (9th April), because I wanted a specific framing of the Markarian chain to get its neighbours in the image, I needed to slew the telescope very slightly after plate solving. To achieve this I used the Move buttons in SharpCap - not something that I had ever had cause to use before.
What I can’t definitively remember of this session is whether I started guiding before I had done Step 6 Plate solving or before I had done the move to obtain the framing I wanted. However the Guide log (Section 1) suggests that I had started it, realised my mistake and hit the PHD2 stop button – as noted above, something that I am prone to do.
Having achieved the final positioning of the telescope I would have done Looping, Auto star select, Guide in PHD2 which started section 2 of the log file. Section 2 shows that PHD2 was not able to hold the guide star and I spent a long time trying to figure out what was happening. The lock position between Guide Section 1 and 2 is different, reflecting either the move or a choice of different guide star or both.
Hit the stop button in PHD2, started looping, auto star select, guide and again PHD2 could not hold the guide star (section 3 of the log: again star lock position is different to section 1 or 2) and gave up pretty quickly. Problem solving at 11pm is not my strength. Tried recalibrating PHD2 twice, failed and abandoned (sections 4 & 5).
Next session – did the same routine (i.e. including the move from within Sharpcap) same problem - it was repeatable and I took some screen grabs of the session.
Next day, found the tutorial on using PHD2 Log viewer and my Section 2 and 3 traces (see screen grab of section 2 of the log viewer) look very like the trace described in the tutorial which diagnoses an issue with the ST4 cable issue. But I do not use an ST4 cable, all connections are via USB, so problem not solved and other issues discussed in the tutorial do not fit. My trace shows that PHD2 is issuing move commands but the star is moving further and further away and if you leave it long enough (as I did in the repeat session) PHD2 will give a message saying "PHD2 is not able to make sufficient corrections in Dec. If you have done a meridian flip check to see if the 'Reverse Dec output option' on the Advanced Dialogue guiding tab is wrong. Otherwise check for cable snags, try redoing your calibration and check for problems with the guide mechanics". I can confirm that it was not caused by a snagged cable, recalibration did not work, I had not done a meridian flip. So next step was to talk to Dave Woods who had recently serviced and upgraded the mount –talked to him, provided the data and he was baffled but convinced the issue was not the mount. Talked to a friend – likewise baffled.

Next session did the usual routine but did not do a move from within SharpCap and PHD2 very happy, no problems.

I don’t like leaving problems unresolved and. PHD2 and the mount seemed to have been ruled out as the cause but SharpCap had not been, so I looked in the SharpCap forum and found the post to which I replied as it seemed to related – an issue with the Move buttons. I read your comment of 24th April as, yes there had been issues with the Move buttons, but the latest version of SharpCap might have fixed them. But my SharpCap had very recently updated to Ver 4.1.118240.0 and had not notified me that there was a new major update. You also commented on SharpCap trying to reset the tracking on EQ mounts. Having just written all this out, it still makes me wondered if this is all related.
I hope this is clearer – if somewhat long winded.
Regards
Julian

Screenshot of PHD2 Log Viewer - Section 2

Screenshot 2024-04-23 111317.png (143.63 KiB) Viewed 270 times

[admin]

Hi Julian,

OK, thanks for the clarification.

The move buttons in SharpCap should not turn off tracking, but certainly the evidence of your guiding graph and other factors does make it look like tracking has been disabled and therefore PHD cannot guide.

I have personally stopped using EQMOD and am now using Green Swamp Server to control my Skywatcher mount, but I do still have EQMOD (2.00w) installed, so I tested with the 'EQMOD Simulator' and can see that tracking seems to resume correctly for me after using the movement buttons in SharpCap (after letting go of the button the RA remains constant in both SharpCap and EQMOD control window). There is actually special code in SharpCap to try to make sure the tracking resets correctly after movement with EQMOD, since I had issues with that in the past. Of course, the reset of tracking may not be able to cope with all possible circumstances.

It would certainly be worth trying the most up-to-date version of SharpCap, which you will be able to get from our downloads page (the auto-updates typically lag 4 to 8 weeks behind the latest version to make sure that the auto-update versions are free of any significant new bugs). I don't think the issue described in the original post here is quite the same as yours, as I think in that case the telescope continued moving at the full movement rate, rather than stopping moving but not re-commencing tracking. Still, give the latest update a try to see if it helps.

If the latest update still doesn't help then a detailed log of communications with the EQMOD ASCOM driver can be generated in SharpCap by setting the option to log additional information about 'Mount Hardware communications' in the 'Logging' page of the SharpCap settings. Do that before opening the camera, then make the problem happen, then close down the camera and grab the SharpCap log full contents and share it here.

cheers,

Robin