See my response in the other thread, that you posted a week ago. Summary: gphoto2 needs to work correctly with your old camera model, to have nikon or gphoto ccd drivers to work correctly.
Read More...
Sorry for being late to the party. The Nikon driver is based off of the gphoto2 library. When you can get bulb exposures with gphoto2, then you can try either the indi_gphoto_ccd or indi_nikon_ccd. Before connecting make sure your camera is in bulb mode.
Read More...
On Raspian / Raspberry PI OS: You need to set the WiFi country in raspi-config correctly. If this does not stick, check /etc/default/crda and add your country in that file.
Read More...
Excuse us, could you please provide the following information:
1) What are you trying to achieve? And why?
2) Where‘s the mount and camera connected? Type of host? Network Connection of that host?
3) How are you trying to connect from iOS/Android (in a VM??)
4) What works? What doesn‘t work?
Read More...
Focuser Pro is NOT open source (at least not for a DFSG definition of the term). It is personal / academic use only at best and a copyright nightmare at worst, e.g. it states in myfocuserpro2-designs.pdf: "The schematic, code and ideas are released into the public domain. Users are free to implement these for their personal use, but may NOT sell projects based on (or derived from) this project for commercial gain without express written permission granted from the author." Then it goes on to state that "you cannot sell kitsets or assembled units to others". If the first sentence was true, none of the restrictions would be possible. In other documentation the source code is MIT, which allows commercialization.
For this reason I went with ardufocus.com/, which _is_ Open Source (GPL, as long as you don't use the PCB, which is CC-BY-NC-SA). This one is supported by the moonlite focuser driver, which is part of indi.
Read More...
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.
Read More...
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)
Read More...
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
Read More...
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:
github.com/jscheidtmann/astroberry-serve...panel/files/envpanel
I have not created an INDI driver and do not intend to create one at the moment.
Best regards, Jens
Read More...
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
Read More...