kens

The minmo values recommended are quite high - more than 1" on both axes. That is limiting your guiding. Were the conditions particularly poor when you ran the GA? Looks like some cloud came over near the end Dec backlash is also evident. Did you measure it with the GA?

At face value the numbers look ok on the screen shot but really need to see the guide log. Note that the belt mod does not fix the major source of backlash which the worm/ring gear interface

Start with the OAG. I suspect the eggy stars are the result of differential flexure with the finder guider. Your guiding RMS is not hugely different in RA and Dec so you would not expect eggy stars from that. The guiding RMS vaues could be down to poor seeing.

At 1200mm FL its time to think about an OAG.

You still need a way to power the Arduino.

For continuous waveforms a Fourier transform is used to convert from time domain to frequency domain. For a discrete, that is sampled, waveform the equivalent transform is known as the Z transform and the discretised frequency domain as the Z domain. The Z filter algorithm is designed using the Z transform and operates in the Z domain. It is the digital equivalent of capacitors and inductors used to filter audio signals so I would not characterise it as adaptive. Bessel and Butterworth filters are often used in audio systems e.g for crossovers due to their characteristics. These same characteristics are useful for guiding.

It does work best with short exposures and those provide more scope for tuning. At longer exposures it still works well but offers no specific advantage over the default algorithms. It is designed for mounts that respond well to frequent, small corrections. I think the Mesu would qualify there. Large deviations due to wind will cause a relatively slow response but it will be smooth. In some cases it responds better because there is no ringing. Slow response in Dec is most noticeable as I normally recommend a low frequency response (typically a factor 8 of exposure time) This minimises or even eliminates dec reversals but step changes take longer to recover.

I know how it works - I wrote it It is a digital Bessel filter with a tuneable cutoff frequency. Unlike the other algorithms it has flat response in the pass band and no nodes in the stop band and being a Bessel filter has linear phase response. The filter is fourth order so approximately 24dB per octave suppression above the cutoff. It is the ability to tune the cutoff frequency as a function of exposure time that makes it useful. By allowing short exposure times you can reduce latency but still filter out the high frequency seeing-related deviations.

The Mesu could well benefit from the Z-filter algorithm with a shorter exposure time - especially if you are getting good enough guide images to saturate stars. The exposure factor can be set so you don't chase the seeing.

With INDI on the RPi you can use any camera supported by an INDI driver. Normally USB connected. Since you have DIY mount controller that becomes harder. If it is coded to use LX200 commands then it should be possible to get it to work. You can certainly run PHD2 on the RPi and you also have several native camera driver options there too.

You need to go through a laptop or something like a Raspberry Pi because you need a driver to operate the camera. Thinking about it, a RPi plus Arduino would be a nice combination as you can run PHD2 on the RPi and code the Arduino to work with LX200 guiding commands.

You should also consider using the Timer1 interrupt rather than using delays. Interrupts will take precedence over anything else going on at the time.

Its more critical when using an OAG. But my criteria would be: Mono (not essential but better) Reliable frame rate (usually driver dependent) Reasonably sensitive For OAG use sensitivity/big pixels and mini profile become important. I have a preference for ZWO - their drivers seem to be better. I've got the ASI120MM-S. This is the USB3 version. The older USB2 version had connection issues when plugged into USB3 hubs. One thing about the ASI120 when used with a guide scope is that it has a 1/4" thread in the back so you can use a bracket to hold it solid. Even so I stil lgot flexure. Now that I use an OAG the mini version would be better or the ASI290 mini (more sensitive but smaller pixels). I also have a Toupcam which I don't use much due to driver issues on Linux.

I'm not so motivated to move the client to Linux since it works fine on Windows. Linux excels in embedded systems like INDI and the distributed architecure of INDI makes it a natural choice. I do run a Ubuntu VM on my windows box but that is mainly for development work on PHD2 and INDI and Kstars/EKOS works fine there but its a pain to have to launch the VM for an AP session. its one of the downsides of an opensource system. ASCOM has the advantage of being a vendor driven standard so they develop the drivers whereas INDI has to be built from the ground up by enthusiasts who naturally focus on the bits of interest to themselves. With the advent of the ASIAir we might see more vendors getting on board with INDI and that would help it immensely. If vendors were developing the drivers the "team" could focus instead on Kstars/EKOS functionality and we could even see more software vendors developing INDI compliant applications - the ASIAir is an example of this.

I've been running smoothly for some time now with INDI on the AAEON-UP and Kstars/EKOS running on Windows as long as they are connected via ethernet. Wireless has been problematic but I'm almost there. The inbuilt wifi chip was flakey in terms of getting a good connection as was the little 11n USB dongle I tried. Suspecting voltage issues I got a better powerpack and that helped a bit. What helped most was using an old 11g dongle. I get a good connection but still have the odd dropout every hour or two. To solve it I have to unplug and replug the dongle. The AAEON keeps running but I then have to restart Kstars/Ekos. So my learning is that with Linux (Ubuntu 16.04 in my case) its important to get the right Wifi device. 11n seems to be an issue in particular. Having said that, the wifi setup is now about the same reliability as running a long USB cable from PC to mount and the ethernet setup is pretty much flawless. If I had a remote setup I'd stick with ethernet for speed and reliability. At home it would be nice to have faster wifi but instead I just save the images to disk and when done I hook up the ethernet (gigabit) to download everything in seconds. Over 11g it takes several minutes and even one frame takes about 20 seconds. Saving images to the AAEON eMMC disk via USB3 is instantaneous. The main thing I like about wifi is that I have just one 12V cable going to the mount. With ethernet I also need a (thin) CAT6 cable. But I've also acquired a slip ring for the power which I plan to mount where the polar scope goes. Having an Avalon mount that means I could, in theory, rotate the mount in RA endlessly without any cable twist. Overall, the reduced issues with cabling is one of my main drivers for going to INDI.

There's no known polarscope that can make sigma Oct bright enough to find easily ? I thought most polarscopes were pretty standard. My three mounts (Vixen SP, EQ6 and Avalon) all take the same scope. So I have three unused bits of kit. If you want it for AP then there are better, sometimes simpler, methods for polar alignment using imaging and/or guide camera.

Should be ok to post in that thread unless you have more general questions about Indi.

The Avalon driver is under development. You would need to build the driver from source. You can find a link to the source code on the Indi forum at https://indilib.org/forum/mounts/2411-avalon-mzero-stargo-with-lx200-protocol.html You also need to edit the drivers.xml file I use it all the time now with no issues and any problems I can help out.

The trails are in declination so they are actually caused by non-guiding This illustrates why you need very good PA when not guiding in declination. Its a bit hard to tell from a JPEG but it looks like you've got about 3 pixels of drift per subframe.The pixel scale is 8.6 as/pixel so that's around 25 arcsec of drift. You didn't mention the length of the subs but assuming 5 minutes that means your PA error was in the order of 30 arcmin which is quite large. Now that you've got PHD2 running I'd suggest using its drift alignment tool to improve your PA. That will help you get more detail since they wont be smeared. I'm not familiar with using a DSLR with HA filter but I imagine you'd want to take a set of subs with no filter to make up a synthetic lum channel and another set with the Ha filter for the nebulosity. For the no-filter case, doubling the integration time will improve SNR by the square root of 2 (1.4x). With the Ha filter you'll get light on only 1/4 of your pixels. Plus at 7nm even the red pixels will be getting just a small fraction of the sky background - in the order of 1/14th. That will affect how long you need to expose each sub.

PHD2 has an option on the Guiding tab of the brain to Auto-restore Calibration. If this is ticked then PHD2 will use the existing calibration when you start guiding. Otherwise it will start calibrating when you first start guiding. (This option can be overridden by holding down the shift key when you click the guiding button to force a recalibration). When PHD2 uses the existing calibration, it divides the RA correction duration by the cosine of the declination - or what it thinks is the declination. Or more correctly it multiplies by the cosine of the calibration declination then divides by the cosine of the current declination. So its important that it knows both the declination used at calibration and the current declination or it will issue RA corrections of the wrong duration. With a ST4 guided mount you use the "Ask for coordinates" driver at both calibration and when you guide on your target to achieve this.

Correct. The main thin is to enter the correct declination when you calculate the calibration step size. There is also an option PHD2 to set the Aux Mount to "Ask for coordinates". When you use this option, each time you start guiding, PHD2 will pop up a window asking you to enter the declination. If you calibrated with this option on, you can reuse the calibration like with an ASCOM controlled mount.

At Dec 67 I'd still use guiding. Since you are ST4 guiding: in the calculator you need to manually enter the declination (default is 0). You wont be able to set it higher than 60 so use that to calculate the Calibration step size. Then manually increase the step size by 25-30% to make up the difference for dec 67.

When you are connecting click the settings button as shown and you'll get the options for 8bit and 16bit NGC7822 is at dec 67 which is not very extreme although PHD2 recommends against it. At that declination the RA pulses need to be 2.5x longer than at the equator for a given movement. In the step size calculator make sure all the values are correct and enter the maximum 60 degrees declination. Then manually add 25-30% to the calculated value. When you are very close to the pole (say > 85 degrees) you can turn off RA guiding You'll also want your guide star to be close to your target as the relative motion difference between the two will be greater if they are at different declinations. You also want to be sure not to chase the seeing as your mount will be making large movements in RA to correct for small star movements on the sensor.

If you are not guiding in Dec then you do need very good PA. As a guide the amount of drift you get will be equivalent to the PA error over a period of 6 hours. If you want less than 1 arcsecond of drift on a 5 minute exposure your PA needs to be in the order of 1 arcminute. You can use PHD2s drift alignment tool to adjust your PA. Getting a good focus on the guidescope will help a lot. Is there a focus ring near the objective lens you can use? Also, since you have the ASI120 you may be able to use a threaded connection. Then you can use spacers to adjust the focus. To choose a guide star you can either let PHD2 choose one (Tools > Auto select star) or if you do it manually, display the star profile and ensure that it does not have a flat top. You can adjust the camera gain if there are no suitable stars. Also, when you connect the camera, select 16 bit mode. It tends to give better profiles for guiding. Since you are not guiding in Dec the guide star does not need to be very close to where you are imaging. Obviously not pointing 90 degrees away or anything like that but within a few degrees wont make much difference.

Looks like the Star Adventurer will only accept guide commands whilst in celestial tracking mode so you can't test it in daylight. PHD2 will start calibrating automatically when you start guiding. For RA only guiding you need to turn off Dec guiding as shown below. Also, you can find the PHD2 manual at https://openphdguiding.org/manual/?section=Introduction.htm Personally I would not recommend using PHD1 as it has not been supported for many years now