@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.
I've played a little yesterday evening with the skywatcherAltAzMount driver. I've used the AZEQ5, 150/750 scope with a DMK41 and a 50/206 guider with a ASI120mm. Nothing aligned. Capture/solve/slew to target works great with the ASI120@206 in 4/5 iterations, but strangely with DMK41@750 it solves but does not slew at all. I suspect a problem with V4l2 devices as the laptop also has a webcam. Sync is not working, there were 3 sync points that I tried to delete, but then tracking became weird. Looking at the code, Sync is only allowed when the mount is parked. I made some images of Dumbbell @10, 30, 60 and 120 seconds to observe star drift/rotation. A silly question, I wonder if the field rotation axis is always centered with the sensor center, or is actually the scope axis. By the way I also noticed regular jumps as depicted by @Federico. I suspect the Aux encoders which are not disabled on AZEQ, and/or the tracking algorithm which updates its data every minute. Lastly I tested guiding, when calibration succeeds (I suppose RA/Az axis does not move enough at ~50° altitude using standard guiding rates), those jumps disturbed the algorithm too much (added to field rotation as the guide star was selected on an edge of the image). Guiding in AltAz mode is quite silly, however the guide tool shows the drifting graph (see the jump @45s) and almost every points are in the upper right corner (field rotation presumably, I did not make the calculations). I may use that to test Alt/Az tracking, selecting a centered star as guide star.
Thus I've learned a little more, and your posts also help me to understand what were your concerns and what you would need. As I understand it, alignment is not primordial as long as Capture/Solve/Slew is working, guiding is of no use as your setup does not have a guider, and you only really need a smooth tracking. What I have in mind as a first step is to create a new driver out of the existing indi repos, hence astroberry users may compile it without disturbing their installation. I will derive it from indi-eqmod and/or indi-skywatcherAltAzMount and then concentrate on the tracking feature. I'll keep you informed when that will be initiated and when I will need you to perform tests.
@geehalel thank you SO MUCH for your work. Indeed, having a driver available to track correctly to be able to plate solve as a quick sync technique would be amazing. Let me know whenever there is something to test. All my very best and again, thank you. Federico
@geehalel: regarding your question of the field rotation axis: I guess as long as the axis of the mount and the guide scope are parallel, the center of the rotation axis should be the center of the sensor, i.e. the distance between mount axis and guide scope axis is far too small to cause any parallax as the points projected on the sensor are at infinity. Things should become more complicated, once both axes are not (perfectly) aligned: in the extreme case of the guide scope axis being perpendicular to the mount axis, there is no more rotation, only translation. In between there should be a mix between rotation and translation, i.e. the center of rotation is moved away from the center of the sensor. My understanding is, that the deviation introduced by such misalignment is what is coined "cone error". Maybe you find some hints in the logic regarding cone error correction to model this; there should also be some literature where this is being described / worked out.
Does this makes sense ?
on second thought: as long as both axes are not perfectly aligned, the center of rotation moves rapidly away from the center of the sensor: let´s assume we have a 1.5 degree fov with our guide scope. If the alignment error between mount and guide scope axis is more than 0.75 degrees, the center of rotation is already off the sensor. I think you can calculate the center of rotation by calculating the fov of your guide scope / sensor combination and substract the deviation angle of the scope axis and mount axis in degrees. How many pixels this equates to, you can derive from the fov calculation. The direction of the deviation should be the opposite of the axis deviation in relation to the sensor orientation.
This is without guarantee. Just my understanding.
on a third thought: I probably should have rather asked you, what you are aiming at. With my hints above, I was in "equatorial mode". In Alt-Az there is no rotational axis of the rig itself. If you want to derotate the exposures made on an alt-az mount, I think the way to go is by star pattern alignment, i.e. agnostic of any mechanical rotation calculation.