10Micron GM3000HPS Mount

Wanting at least four telescopes on a single rig, required an extraordinary mount. In total the equipment weighs about 50kg and wanting to do some imaging, the mount should have no issue with such a payload. After several months of research I ended up with two options: an Astro-Physics 1600GTO (payload 95kg) or a 10Micron GM3000 HPS (payload 100kg). The GM3000 was about 18% more expensive, but having absolute encoders for that price, I finally decided to go for this Italian mount (see figure 1). The 1600GTO could be delivered with them as well, but that would have added another 40% to its original price.

Despite having great pedigree, the GM3000 was not exactly an instantaneous success. The first one that was delivered produced that much noise while tracking that it could be heard all around the library and main building. In addition it showed jumpy behaviour, making jumps in declination up an arc minute, roughly the apparent diameter of Jupiter. After having struggled with it for nine months, in which I wrote MountMonitor to prove that it was indeed behaving badly (this in contrast to what 10Micron told me based on the log10m-files I supplied), it was finally replaced with the current mount.

The second GM3000HPS mount did not show any jumps, but still was quite noisy. During the first nine months with the first mount 10Micron had supplied a modified Beta-firmware (2.15.20) which made it a lot quieter. Installing that firmware on the second mount made it silent as well, reducing its original bee-buzzing noise to a mere trickle. The latest Beta-firmware (2.16.24) makes the mount even more silent, down to a level that it cannot be heard while tracking.

With the GM3000HPS I have been able to do unguided imaging for 20 minutes (see Deep Sky section), but it has to be said that this is not (yet) possible in all directions along the sky, especially the area around 160° to 180° in azimuth, along the equator in altitude, shows elongated stars up to 20 arc-seconds in length when taking 20 minute exposures (i.e. 1"/60s elongation).

Currently (July 2020) 10Micron is investigating data supplied by a test group of three 10Micron owners (one of which being myself), which hopefully will result in better performance. Last month I used the GTT60 as guide-scope, which showed that the elongation was not caused by focuser flexure and that incredible accuracy can be achieved with this mount when guiding. I therefore may switch to guided imaging if the next firmware again fails to deliver unguided imaging.

In September 2020 I did a deformation survey of the observatory at an accuracy of a single arc second (68% confidence level). This showed that there was not enough movement in the observatory to explain the elongations. Even the worst-case scenario the measured deformation could not have caused more than 2 arc-seconds elongation, but more likely less than a single arc-second. I examined the corresponding log10m files using Log10mGrabber, and was able to find a 97% correlation between S0-data in the log10m-files and the difference in elongation between subs in this test, a strong indication that the elongation is caused by the firmware.

In February 2021 the latest firmware (3.0) arrived (it had been installed in mounts since the beginning of that year). According to the change-log the elongation issue has not been addressed and as this firmware does not allow a downgrade, I am reluctant to install it. Analysis of a 3.0 log10m file revealed that the S0-S6 data is no longer logged, as a result of which the mount can no longer be examined in great detail, not by me, nor by 10Micron.

Tests with a new 74-point model on 21 February 2021 revealed that the elongation could be reduced to about 7 arc-seconds in 20 minutes (i.e.1 arc-second per 3 minutes). Another test done that evening with continuous updates of the mount's clock using a NTP-server did not improve tracking any further.

On 19 March 2021 10Micron wrote on their forum that "With some investigation, in many cases we found the cause of the drift. Wrong refraction data, wrong tracking rate speed, pier flexures, unstable focusers, not-stiff-enough OTA rings..., but in some cases we couldn't." The latter possibly referring to the data I produced. In the meanwhile two programmers are working in stability measurements using plate-solving of images taken with a mount of which the motors are stopped by giving them a zero RA-speed. In this way the motors (and thus the encoder-readout) stay active, which should result in a mount pointing at a constant alt/azi. The first results show that recordings made this way have a stability high enough to not explain the drift we experience, underlining the comment by 10Micron that in some cases they couldn't find a cause.

I in the meanwhile have ordered a SkyWatcher Esprit 80ED, not only for wide-field imaging, but also to use it as guide-scope fro the SkyWatcher Esprit 150ED.

In preparation of the new imaging season I created a new model of the sky on 21 July 2021 using MountWizzard4. A few weeks earlier I had finally taken the bold step to install firmware 3.0 (this new firmware has no way back). During the MW4 run I noticed that several images were not plate-solved by ASTAP. As this had never happened before I started to investigate the images and noticed that those failed plate-solves were all due to double-dotted and elongated stars. Interestingly they only occurred in the region where I had these issues before. The images taken in the process are only 5 seconds exposures, so after restarting MW4 I checked the mount using MountMonitor and by visually checking the keypad. It appeared that about 10 to 12 seconds after a slew was completed and the mount went into tracking mode (this is when the mount beeps), the RA-axis suddenly decided to move for a bout 1-2 seconds in time in RA (15-30 arc-seconds). This move took a few seconds to happen after which the mount returned to its initial position.

I reported this behaviour to 10Micron expecting it to be a firmware issue, but after analysis of my log-files, they concluded that there is a mechanical issue with the RA backlash system. The plan is now to ship the mount back to Italy coming November (2021), as the weather in that month is usually not suitable for imaging here. Hopefully this will finally solve the tracking issue.

On 5 November 2021 the mount indeed was shipped back to Italy for repairs.

Update 24 January 2022: the mount arrived in Italy the 9th of November. Solving the issue takes more time than anticipated, the mount still is with 10Micron (two months and a half now), but hopefully it will return by the end of this week as the work on it is nearly finished.

Update 22 February: three and a half month after it had left, the mount finally returned. It had received a major hardware upgrade and a new control-box. What immediately became apparent is that the RA-axis feels much sturdier. Where originally it was very easy to slightly push the RA-axis off-target, this is now no longer possible. The first models also showed significant improvement as the RMS-values dropped by about 40% (from approximately 7-8" to approximately 4-5"). Also the first night-long tests with 420s subs, showed that eccentricities all were below 0.5, which is acceptable.

Another deformation survey of the observatory, now using a telescope with camera fixated to the pier, revealed minor movement, mainly in altitude, which could have caused eccentricities up to about 0.4 and thereby might in large part explain the 0.5 eccentricity results of the 420s subs.

Although all tests so far were conducted at a limited part of the sky, I think it is safe to say that, as it is now, the mount is a significantly better performer and it looks like it is finally performing according to specs.

Update 28 March 2022: Once again drift was detected in the images of up to 21 arc-seconds per hour. This detection was done using FITSalize by comparing both J2000 and JNOW coordinates with the RA/DEC coordinates as found in the FITS-headers (recording done with NINA). In addition a comparison was made between the FITS-headers and the RA/DEC coordinates as recorded by MountMonitor. That recording showed that the mount does not output the drift (so no drift between these two). Further deformation tests of the observatory with FITSalize did not show any deformation in excess of 2 arc-seconds per hour, significantly less than the 21 arc-seconds per hour as detected by plate-solving the images. I suspect that the unguided dithering commands mess up the mount's proper tracking speed.

Currently an exhaustive report is with 10Micron for examination.

To be continued...