4 replies to this topic

[BucketDave]

Following on from ArdsleyAstro's and Gerd's recent threads (and my personal communications with iOptron), I thought I'd start a new thread showing how all the previous odd behaviours had been ironed out using the latest firmware (v20241201 issued on 26 March 2025).

The recent firmware updates have cured:
1) occasional and seemingly random changes in the reported DEC and RA.
2) changes in tracking rate when guiding was lost (e.g. as small clouds passed by).

So thanks to iOptron for fixing those bugs.

The tracked but unguided RA now exhibits a slow wave with a peak-peak variation of 40 arc-seconds with a 6 minute period. The long term tracking rate is pretty much bang-on sidereal.
The Fast Fourier Transform facility in PHD2 shows that the 18s cyclic component is still there and has an amplitude of 0.5 arc-seconds. There are also some similar sized components with periods ranging from 1 to 2 minutes.

Guiding with an OAG behind my 65phq (and an ASI174mm) is typically 0.9 arc-seconds RMS (0.8" in RA, 0.4" in DEC). I am using a 0.5 second guide period and high agressiveness in order to try and tame the rapid changes in RA. I have also started using ArsleyAstro's recommendation of guiding at 0.75x sidereal rate - it seems a touch better than the usual 0.5x.

Edited by BucketDave, 22 April 2025 - 11:20 AM.

[BucketDave]

So far, so good.

 

Until I came outside this morning and found that imaging had terminated early.  I had been imaging under the control of SharpCap sequencer and ASCOM for an hour, doing 30 minutes of imaging (120 second exposures of M101) followed by an auto-focus.  That had worked twice but a failure occured on the third 30 minutes of imaging.

 

Part way through the fourth frame (at 00:08:15.9), guide pulses suddenly stopped being sent by PHD2 and the Commander log terminated almost at the same moment.  Imaging continued for a further 23 minutes, albeit with no guiding, trailed stars and no dithering.   SharpCap then did an auto-focus but was unable to contact the mount to do a GOTO and SYNCH.  At which point, the SharpCap sequencer gave up and it reverted to my shut-down procedure.  Which also seemed to be the cue for Commander to start a new log file which then sat there accumulating data until 05:30 when I went outside to do my sky-flats.  I requested the mount to slew to the PARK position and it responded normally.

 

So I am scratching my head, trying to figure what failed.

1. Did the mount temporarily lose power but then restart 25 minutes later, acting as if nothing had happened ?
2. Did the ASCOM/Commander link go down ?

Option 2 seems more likely as the Commander log file stopped and closed at the critical moment (00:08:15.9:).  Twent five minutes later (at 00:33:11), the SharpCap log file reported  'Error slewing to RA=14:04:08.6,Dec=+54:13:36 : Exception of type 'DriverAccessCOMException' : No handle of the given name exists' when it tried to do the GOTO and SYNCH.  And that seemed to be the cue to restart ASCOM because just two seconds later, the Commander log file restarted.

 

I see that Commander has also been re-issued (9.0.2.1) and fixes a few bugs.  I was using 9.1.14.

 

 

Dave

[Ardsley Astro]

So far, so good.

 

Until I came outside this morning and found that imaging had terminated early.  I had been imaging under the control of SharpCap sequencer and ASCOM for an hour, doing 30 minutes of imaging (120 second exposures of M101) followed by an auto-focus.  That had worked twice but a failure occured on the third 30 minutes of imaging.

 

Part way through the fourth frame (at 00:08:15.9), guide pulses suddenly stopped being sent by PHD2 and the Commander log terminated almost at the same moment.  Imaging continued for a further 23 minutes, albeit with no guiding, trailed stars and no dithering.   SharpCap then did an auto-focus but was unable to contact the mount to do a GOTO and SYNCH.  At which point, the SharpCap sequencer gave up and it reverted to my shut-down procedure.  Which also seemed to be the cue for Commander to start a new log file which then sat there accumulating data until 05:30 when I went outside to do my sky-flats.  I requested the mount to slew to the PARK position and it responded normally.

 

So I am scratching my head, trying to figure what failed.

1. Did the mount temporarily lose power but then restart 25 minutes later, acting as if nothing had happened ?
2. Did the ASCOM/Commander link go down ?

Option 2 seems more likely as the Commander log file stopped and closed at the critical moment (00:08:15.9:).  Twent five minutes later (at 00:33:11), the SharpCap log file reported  'Error slewing to RA=14:04:08.6,Dec=+54:13:36 : Exception of type 'DriverAccessCOMException' : No handle of the given name exists' when it tried to do the GOTO and SYNCH.  And that seemed to be the cue to restart ASCOM because just two seconds later, the Commander log file restarted.

 

I see that Commander has also been re-issued (9.0.2.1) and fixes a few bugs.  I was using 9.1.14.

 

 

Dave

Last run I did was with 9.2.0.1, Had the unresponsive mount issue after doing NINA 3PPA. but was ok for the rest of the run including the meridian flip. Not had the opportunity (Clear skies) to image again since.

[BucketDave]

Just had a look at the data I took on 16th April.  That shows that the random jumps in RA are back.  The graph below shows RA (hours) against time (from 1am to 3:30 am) during a period when RA should have been constant (until 03:10).

 

 

 

The mount wascontrolled using the latest firmware (v241201) and Commander v9.1.4.

[Gert]

Hello BucketDave,

 

Interesting observations. Did you check the USB cable connection? In my HEM15 the USB 'B' cable connects to socket in the hand controller. That socket seems to be some very cheap component. I had gone through a number of USB cables and found many of them not giving a very 'satisfactory' connection and had loosened a bit over time. If there is motion on the mount and the controller 'hanging down' the cable will pull on that connection and might have given a comms failure at some point. I wish that USB standard would have some provision for a latching mechanism, but I've complained about that since I got the first USB camera (I think from starlight express) ~20yrs back.

 

Clear Skies,

Gert