According to other posts - here or on facebook - two focusers work. You may have to twiddle with persistent serial settings, though: indilib.org/support/tutorials/157-persis...al-port-mapping.html I have not tried that myself.
After doing a polar align, I notice that the pointing model that is derived from that happens to be degenerate in (like) 60% of the time. Ok, what do I mean by that:
The PA process plate-solves three pictures around Polaris, that means the orientation of the celestial sphere in relation to mount coordinates is determined by three points, that all are next to each other. This means that the accuracy of the solution can diminish fast away from the pole and lead to large pointing errors.
Behaviour that I observed is that the first slew after PA is way off, then taking a new plate-solve (sync) does not fix it. You can even experience that the scope slews to below horizon after that solve or more than 120° away to your target. I even on one occasion, directions where inverted for DEC, but not for RA (or vice versa). My „fix“ so far has been to clear the model or even to power cycle the mount and restart Kstars/Ekos. Then do a plate-solve (sync) in the vicinity of my target, which then usually gives dead on slew-to-targets.
Questions on understanding:
1) Are the PA solves used to built the pointing model or not? (My opinion: should not be used.)
2) What pointing model is there after PA?
3) Where is the pointing model (using EQmod with a AZ-EQ6 GT Pro)? Ekos? Driver/EQmod? In the mount?
4) What exactly happens on „Clear Model“ in mount tab?
5) Can I see the transformation function(s) somewhere?
Question on how to mitigate:
7) What should the exact procedure be, to get an accurate pointing model? Please assume mobile use (PA necessary each time).
Would pointing, ca 5° off of Polaris during PA help to avoid that?
9) If the pointing model is degenerate (as above), is there a way to avoid restarting Kstars/Ekos?
Thanks in advance, Jens (Grimaldi)
No, that would mean to write an INDI driver. I have currently no plans to do this, as I am building an Ardufocuser, which will also include a temperature sensor...
Maybe this here helps: Radek supports another sensor in the astroberry-diy driver, see here: github.com/rkaczorek/astroberry-diy
You can attach, e.g. a BME280 sensor.
I have some scripts here, to do environmental monitoring of my imaging sessions, as part of Astroberry's panels:
I have not created an INDI driver and do not intend to create one at the moment.
Best regards, Jens
The situation has not changed much:
Raspian buster has become oldstable, but still is on 2.7.
bullseye has become stable and is on 2.9.
Astroberry is still based on buster.
So still the advice is to install wpasupplicant 2.9 by hand following these steps: www.indilib.org/forum/astroberry/6229-ca....html?start=12#52158
Hi John, did you see my direct message to you? Thanks, Grimaldi
A line starting with „un“ means „unknown“ and „not installed“. Happens when a package is mentioned or requested by another package, but is then finally not installed or was not in the repository. See header printed before the table. These can be safely ignored and to be honest I removed these entries for clarity. Sorry for the confusion this has caused.
What are the Versions? Please run the following command and post output:
$ dpkg -l indi-bin indi-gphoto libgphoto2\*
A working config on Astroberry is (last tried a few weeks back, due to clouds) is:
||/ Name Version Architektur Beschreibung
ii indi-bin 1.9.2-1 armhf INDI server, drivers and t
ii indi-gphoto 3.0-8 armhf INDI GPhoto (DSLR) Camera
ii libgphoto2-6:armhf 2.5.27 armhf gphoto2 digital camera lib
ii libgphoto2-port12:armhf 2.5.27 armhf gphoto2 digital camera por