kens

When using ST4 select "on camera". It is also useful, but optional, when using ST4 to also select as Aux Mount "Ask for coordinates". If selected then every time you start guiding you are prmpted for your declination. This lets you reuse your calibration. Otherwise you need to calibrate every time you start guiding, or at least when you change declination. The declination does not need to be entered precisely, within a few degrees is sufficient. It allows PHD2 to adjust its RA guiding to suit the declination. https://openphdguiding.org/manual/?section=Tools.htm#Ask_for_coordinates_aux_mount

@gregk01I just did an experiment that might help you. I started up PHD2 and connected to the StarGo driver without any USB connection to the mount. The StarGo driver popped up a window asking for the COM port so I clicked OK. It was happy with this even though the selected COM port did not even exist. The connection went ahead as though everything was OK and the guide log shows pretty much the same as yours. So make sure that (a) Your USB cable is correctly connected to the mount and (b) that you have selected the correct COM port

The data is showing RA Guide speed =0; Dec guide speed =0; RA=0; Dec=0, PierSide =Unknown. The non-reporting of RA and Dec suggests something more fundamental. With the Avalon mounts you need to set up the StarGo application by loading up a configuration file for the type of mount being used or it just wont work. Seeing as it is a new mount for the OP it is possible that this step has been omitted.

The mount is not reporting any information via ASCOM. I'd suspect an issue with the setup of the Stargo application. e.g. It may be configured for the wrong type of mount.

If you could attach your guide log that would be helpful

If the orientation of your guide camera does not change and your mount can report declination to PHD2 and you got a good calibration near the equator then reusing the calibration should be fine. You only need to recalibrate near your target with ST4 guiding. If you are worried about your guiding, attach your guide log and ask either here or at the PHD2 support forum https://groups.google.com/forum/#!forum/open-phd-guiding

I usually disbale Star Mass detection: https://openphdguiding.org/man-dev/Advanced_settings.htm#Guiding_Tab Or it could be a camera or USB problem? PHD2 has an option to save lost star images as well. It is normally enabled to some level so you may be able to view/post one or more of those. Not related but your guide rate is very low at 0.1x sidereal. You should increase it to 0.5 to 0.9

Is it possible to use an astro camera (i.e. no lens) with the eyepiece style of grating? I'm thinking along the lines of an eyepiece projection tube to hold the grating with the camera on the end of the tube.

I've been dealing with a similar issue. I had my ASI1600MM-C and AS1120MM-S plugged into a powered USB3 hub (so not using the ASI1600 USB) and that plugged into an Aaeon UP Core computer. All powered from the same 12V source. A lot of the time the ASI1600 would not get connected so I would have to unplug the USB cable and replug it. Never had a problem connecting to the ASI120. At first I thought I would need to delay sending power to the ASI1600 till after the computer had booted but that didn't help. So I'm now trying with a delay in sending powerto the computer so it boots after power has been applied to all the other devices. So far this has been working reliably for a few days. I suspect the issue may be due to the powered USB3 hub needing some time to register the ASI1600 before the computer boots and searches for attached USB devices.

Please attach the log file rather than a screen shot.

Make sure you aren't guiding on a hot pixel. Your guiding RMS is less than 0.1 pixels which is suspicious

There is nothing magical or optimal about unity gain. It is just a value of amplification that causes one ADU to rcorrespond to one electron captured by the sensor. The charge on the sensor is converted to a voltage which is then amplified before being converted to a digital value in the ADC. Collectively, the errors introduced are quantified as read noise. If you are aiming for maximum dynamic range then try zero gain. But if you find that for a given integration time you have only a small number of subs then quantization error could be manifested in the result. If so the using a higher gain and more subs may be beneficial - but at the expense of saturation of brighter parts of the image.

Its more the case that CMOS sensors generally have lower read noise so shorter subs are possible. You want the subs to be long enough on any sensor type, that the shot noise dominates the read noise. That way, stacking more shorter subs approaches the efficiency of longer subs in terms of getting a given SNR versus integration time. The length of the subs needed for shot noise to dominate read noise depends on gain and sky background. You want to expose so that the sky background equates to somewhere in the order of 3 to 10 times the read noise squared. When you can control the gain, lower gain gives more dynamic range but higher read noise. Once you get beyond 10 x read-noise squared you are getting more saturation with little gain in stacking efficiency. Below 3xRN squared you need more integration time to get SNR equivalent to longer subs. For the ASI1600, the optimal minimum gain is around 76. If your sub lengths at that gain are workable then use that. For NB you may need a higher gain to get workable sub lengths but with higher gain you lose dynamic range. A maximum gain of 200 gives a reasonable dynamic range - 10.5 stops; which gives some room for stretching. If you want something in between then unity (139) is a good choice. You don't need gain to be more precise than those three values and you don't need to be too precise with the actual values. I tend to use 70, 140 and 200 as they are easy to remember. Another factor with the ASI1600 is that it has a 12bit ADC so quantization noise is a consideration, especially at low gain. That can be overcome with more subs - say 40 or more. You are talking 50 to 100 subs so that is not really an issue for you.

In that last log PHD2 was communicating with the mount. But it looks like you were trying to calibrate at the pole (declination 90). You need to calibrate near dec 0 to see any movement in RA.

According to the log you were trying to calibrate at the celestial pole (Dec 90). Try calibrating closer to the celestial equator (Dec 0). Near the pole, any movement in RA makes only a small movement on the camera. Also, alter your step size back to 1000ms (or use the calculator) to give around 12 steps.

You've attached the Debug Log by mistake. Please attach the Guide Log and we should be able to help ypou.

I assume you are commenting on my post. Whilst it is easy enough to get a weights down position with a spirit level it is harder to get the declination aligned to the pole. The tutorial I linked shows how to use the SPA Tool to help point the OTA at the pole rather than for polar alignment. Any tool that calculates the centre of rotation could be used. Indeed, one could set a longish exposure time and rotate the mount to get an arc and eyeball the centre of rotation. If the mount is already polar aligned then the centre of rotation is close to the pole and adjusting the OTA in declination can bring that point to the centre of the FOV at which point you are at dec +/-90 within a few arcminutes. Any residual offset that is orthogonal to the declination movement is due to cone error. If that is substantial you would need to shim the OTA to bring the centre of rotation to the centre of the FOV.

I use the Static Polar Align (SPA) tool in PHD2. If your polar alignment is already good you use SPA to find the centre of rotation of your mount. Then adjust in declination to bring that point to the centre of your field of view. Any offset that is at right angles to declination is due to cone error so you may want to adjust that too. Once centred set your mounts home position there.

Please post your guide log

There is a floor on practical sub length. Once they cease being shot noise dominant and become read noise dominant you need more integration time to reach a given SNR. And at some point the individual subs may not have enough SNR to stack. And you also get to a point where download time can be significant leading to more wasted imaging time. So let's say that lower limit is 30s and your mount has a worm period of 600s and PE of 30" p-p. So every 300s it moves 30" and in 30s it moves around 3" which would be noticeable.

Yes - I made an arithmetic error. To investigate further I tried to work out the optimal binning ratio that gives the best improvement of SNR over expected. Lo and behold the optimum is 1.414 which has an SNR 1.707 vs the expected 1.414. Could that be a clue as to the source of the discrepancy?

On the principle that "you don't get something for nothing" I would think the discrepancy arises from using upsampled pixels. The signal per upsampled pixel is not the same as if they were real pixels so when you bin red with orange, green and blue, intuitively you are introducing noise. Otherwise you could upsample 4x before binning 6x6 get an even better result of 2.0

The main issue from poor polar alignment when guiding is field rotation causing elongation of stars If you plug in the details of your specific imaging situation into the field rotation calculator at http://celestialwonders.com/tools/rotationMaxErrorCalc.html you can se if field rotation is an issue. It gets worse the closer you are to the celestial pole but for the vast majority of likely situations, 5 arcmin is indeed good enough.

60dB gain (gain 600) is way too high. You have less than 4 stops of dynamic range there. I keep the gain at 200 (20dB) or lower where the dynamic range is a bit less than 10 stops. Typically I use gain 75 for luminance, 139 (unity) for RGB and 200 for narrowband unless I an get a reasonable exposure at 139.