Dear Jasem, yesterday night I switched back to the Stable Stellarmate channel and after the switch all works, including UDP with AZ-GTI AltAz driver you made.
Unfortunately, as I mentioned, the driver it is based on (indi_skywatcher_altazmount) has bugs.
The first one is that, when tracking, in the Mount section the tracking button is not set to ON (both ON and OFF are greyed out).
The second, more important problem is that when tracking an object, Jupiter for instance, the mount will, every few seconds, slew on its own randomly, for example slew up a little bit, or slew left a little bit, then begin tracking again, then slew again...
When using the Alignment module, plate solving will be interrupted very often with the message "slewing detected aborting solving".
I tried by disabling the SoftPEC option, but crazy slewing continued.
I'm sure this can be solved. I'm also still inclined to think having two different AZ-GTI drivers, one based on indi_skywatcher_altazmount and the other on eqmod might not be the best road, and that it might be better to modify the eqmod based driver to work with altaz instead.
I hope Jean-Luc's driver would work with AZ-GTi so it's a win-win on all fronts. I just attempted to use an existing driver that was tailored to Alt-Az mounts but it wasn't tested good enough I suppose. Let's wait to see when EQMod Alt/Az modifications take place.
Dear Jean-Luc, as I mentioned in my recent exchange with Jasem, both skywatcherAltAzSimple and indi_Skywatcher_AltAzMount drivers are buggy on many front; particularly, with the AZ-GTI mount, the mount keeps slewing randomly for no reason, these are small slews but enough to slip from your target. When you try to do platesolve-alignment, alignment is continuously stopped by an error that says "slewing detected, aborting solving". Also, it's difficult to provide any stable piture of stars for plate solving because tracking is significantly bad. These two drivers, at least when connected through UDP with the AZ-GTI mount, give very bad results in my experience. Compare that with your driver, based on eqmod: I've been using it (in EQ) for months, never a bug, tracking is perfect, etc etc. So I believe strongly that the best would be to have an option in your driver for alt-az mounts. That would also alt-az users to profit from all future features added to your driver. For instance, recently a version of your driver added a feature to use the SNAP port of the AZ-GTI mount to take pictures longer than 30s with DSLRs (github.com/indilib/indi/issues/1181) - although pictures longer than 30s are not probably a good idea for altaz operation, it would be nice to have the feature to try. Thank you so much for your work on this driver!!!
The slews you see in AltAzSimple/AltAzMount drivers come from the way Roger (who wrote those drivers) implemented tracking: every second, perform a goto to the foreseen position. It was mainly aimed at visual observing. It explains why plate_solving alignment aborts as it detects these gotos.
Now the question is what usage for an altaz skywatcher driver (driving AZGti, AZEQ, virtusoso and all other altaz mounts I don't know of) ?
- visual: should be ok, but never heard a report here from users if any;
- planetary imaging: did not test myself, @Dirk tried to do so, but it seems he has serial port communication issues and I can't help him here. I'm not sure you need plate solving for planetary imaging, even 'tracking' is usually performed when you stack the images, but I am not used to planetary imaging;
- deep sky imaging: there you need everything, as you state in your post.
As I already said, I won't add a button in indi-eqmod for alt-az mode: first it's risky for users, and it will actually add a bunch of if/then/else in the code. It is not as simple as adding a layer between alt/az and ra/dec. Tracking would use variable speed adjustments, and you have to compute period values and make timer callbacks at a rate which depends on the stepper resolution of your mount. And you may have zero period sometimes (infiinite speed at zenith or pole, I don't remember), hence what to do there ? In Equatorial mode, tracking is just starting the RA motor... Concerning guiding I don't know if guiding programs may use Alt/Az axes, hopefully they do.
In other words, this represents a huge amount of work, refactoring indi-eqmod code first to split it into eq and altaz mode, refactoring alignment too, and then testing all that new stuff, which is at least half of the work. I still have a pair of pull requests waiting for users to confirm. AzGTi snap port is one of them, on my side I only use simulator mode, put A5 as mount code, see the snap button appear in the control panel and toggle it, but I still don't know if that actually works in real. What I mean is that I need testers, merging a 3 or 6 month branch may be time consuming (or not). And sometimes users simply vanish (that was the case for snap ports in indi-eqmod, I made the work twice).
Thus my point of view is that I don't plan to invest time to develop an altaz driver as there may be other solutions (which may need tweaking, but without testers...). And why not using an equatorial wedge if you want to plate solve? I don't know when does field rotation appear in altaz mode, but plate solving may also fail in altaz mode for that reason, even with a perfect smooth tracking. Or am I wrong ?
@geehalel: first off, many thanks for your help, which I appreciate very much. Regarding the communication problems with my AZEQ-6: I guess something went wrong on my system with the compilation of your branch of the libindi. After com problems with other devices I reverted to the current official libindi by just following the compilation instruction on the github page. After that I could connect again with the eqmod and other drivers (not with the alt-az driver, though). Any ideas what might have caused the problems ? I have I relatively clean install with all recent updates of astroberry running on a pi4. The only amendments done to the astroberry is an installation of a wifi dongle. The compilation process did finish without any errors in both cases, i.e. installing your branch and the official one.
Regarding the alt-az drivers: I have not been aware, that these drivers implement kind of leapfrog tracking. Probably for the planetary imaging I would be better of to revert to the factory driver running off the handcontroller. Once this is initialised and aligned I can connect with the synscan driver. The only thing which put me off here, is that I first have to do the manual align according to the synscan manual as the driver will not accept any input before conclusion of the initial alignment routine. I would have to install and use the visual guide scope, which I retired already and every time punch in the current date, time & stuff. It sounded so promisingly easy to do all the alignment with with ekos alignment module.
So if there currently is no decent alternative to the factory drivers I would also pitch again for having some form of an alternative for alt-az control. As much as I understand the benefits of GEM mounts, the recent advancements with EAA made many things possible, e.g. live stacking of relatively short exposures, which makes DSO much simpler as one does not necessarely need guiding and even field rotation is not a problem as the image is being de-rotated by software. I happily volunteer for testing !
The big advantage of the alt-az mounts is the time you save when setting things up. You just have to level the base of the mount and are ready to go. Setting up my stuff in GEM config takes considerably more time: in my case I have to go to my backyard as the view of Polaris is obstructed from my terrace. The tripod for my alt-az mount has rollers attached, so I can just roll the entire rig out, level it and start. I am only a casual observer. So when i have lets say three hours for observing during evening hours, I loose 1 hour for mounting and dismounting my equipment and probably 20 min. for proper alignment of the scope. Something always goes wrong, so in the end I have max. 50% of the time for actual observing. With the alt-az I would just roll in and out in 10 minutes and have the scope aligned in 5 min. So effectively the time for observation is doubled. At least in theory...
Anyway, I would very much appreciate to have a system as good as eqmod for the alt-az mount. With the advancments in EAA I would guess that more and more people will use alt-az mounts as they are simpler to use and can bring more people to this fascinating hobby.
@Dirk Thanks for giving more explanations about your concerns. I don't know either why handcompiling indi in astroberry does not work, I have looked for the repo to inspect package contents, but did not find them. I may directly inspect the image, but it would be better to ask to astroberry's maintainer. If you want to help in testing, that will be mandatory anyway. I agree with your remarks concerning setup time needed when you don't have an observatory. In my backyard I can't even see Polaris, that reduces polar alignment time, just aligning on three stars and pointing inside that triangle. That's enough for my use, I don't know if that would work for faint objects.
@Federico I made an error in my previous post, after looking at the skywatcherAltAzMount driver code, the current implementation consists in speed adjustments made every seconds. It decided me to test indoor with my AZEQ5 and the CCD simulator. I have been able to track a star, take a shot and sends it to astrometry.net (Capture and Solve). It did not resolve unfortunately, the CCD image having two big circles with no stars inside it, only two or three dozens around, and a double star just in the center (I pointed Arcturus!). I must have missed something. Anyway Ekos did not complain at all with the AZEQ5 while it was tracking, Should have a try on real sky when possible.
I really believe the skywatcherAltAzMount driver is the best option for the moment. And don't understand why you would like I make two drivers in one with indi-eqmod. And don't have plans for that before at least months.
Dear Jean-Luc, I will read and respond more thoroughly later today but I wanted to mention that the situation where AZ-GTI (and others) in AltAz can excel is in EAA (Electronic Assisted Astronomy). With my Nikon D5100 you can capture deep sky pics of short exposure (10-15 secs) at 1000 ISO and live-stack them and have a wonderful experience of almost-real-time seeing of objects you can't see with your eyes. As you mentioned, doing this requires somewhat precise tracking (sufficiently precise to avoid blurry images during the 10-15 secs of the exposure), although movement / rotation between pics is unimportant since the live stacking can correct it.
Jasem mentioned EAA was in the roadmap of Stellarmate. More later, thank you for your response!
And to the why not use the wedge, I have it, but if I bring it I also have to bring the counterweight, which adds about 4kg to the package and also requires a more serious tripod and kind of overweights the AZ-GTI at least theoretically. In AltAz you can use AZ-GTI with minimum weight and becomes perfect for traveling. Additionally, Alt-Az doesn't require polar alignment so it can be snappier to set up.
@geehalel: I can´t stress enough how thankful I am for your help and efforts !
Just posted within the astroberry section of this forum to Kaczorek, the maker of astroberry. Maybe he has some idea, what the problem is.
What makes me curious is, that the compilation of the official branch of libindi did work, apparently. At least I got a working libindi afterwards. Did I understand you correctly, that it is your assumption that the compilation of libindi does not work on the astroberry ? I have the feeling that I missed something, anybody more knowledgeable with linux would automatically do.