Hi,
I have an ASI2600MM Pro and a ASI290MC Mini and both have these "Fast Exposure" and "Fast Count" features under their INDI Control Panel Options tab. I think I know what "Fast Exposure" does, but it doesn't always do that, so I'm not sure. Also, the "Fast Count" - hmmm... Anything that is labeled "fast" looks like a good thing, so it would be useful to know what they're for. Looked under www.indilib.org/individuals/devices/came...ics-asi-cameras.html, but there's no info.
Kstars 3.7.0 on Raspberry Pi (Stellarmate) and Linux Mint 21.3
Thanks,
Charles
Read More...
Hi all,
It's been a while since I've written some Python to access INDI devices. I have a script that works great for a CCD (KAF8300). Now I have a CMOS camera (IMX571), and I'd like to programmatically set GAIN and OFFSET. But there aren't GAIN or OFFSET properties listed in the standard properties table . Instead, it looks like they are part of CCD_CONTROLS. Can someone provide some example code that would just allow getting and setting of these values?
BTW, I'm using the PyIndy.py module. If there's something better or more recent, I'd be happy to update.
Thanks for any help,
Charles
Read More...
Can you expand on that? The link says Ubuntu 18.04 and higher is supported. Are you talking about Kstars? INDI? What Ubuntu versions *are* supported?
Read More...
Hi,
I seem to be frozen at Version 3.6.3 Stable. I've followed the instructions
here
, but no new version of Kstars ever shows up in my update manager. FWIW, here's my sources list:
$ more /etc/apt/sources.list.d/mutlaqja-ppa-focal.list
deb http://ppa.launchpad.net/mutlaqja/ppa/ubuntu focal main
Thanks for the info.
Re: #2, I am referring to the text description for FILTER_NAME in the list of standard properties, which says, "The filter wheel's current slot name" (see attached), I think it needs to be corrected to say something like "A list of the names of the filter in each slot"
OK, I see the Python article link. The article is informative enough to get going, but I must say it's pretty terse. There is value in "unpacking" the details.
My thoughts were to keep the installation info, then give a very brief example so readers have some idea of what's involved. After that go into more details about retrieving and manipulating properties. Also, it would be good to know which of the fields in a property object are meant to be used, and what they contain. I will try to explain things that I ended up figuring out by trial and error, which I think is a good place to perhaps discuss the threading model.
Also, we should explain more how to use the class that inherits from PyIndi.BaseClient. I have only seen two examples, but I wonder how often I'm going to have to write something special for "newSwitch()", for example.
I think some device-type descriptions would be helpful. Filter wheels are pretty simple, but I can see the need for separate sections on cameras, streaming and definitely telescopes. I'm happy to try to start a framework for others to help fill in (!)
Charles
Read More...
In another thread, Jasem mentioned the need for
new documentation for using PyIndinew documentation for using PyIndi
. I've been searching around myself and stumbled across two links to indi.org tutorials that do not seem to be accessible in the obvious way:
INDI Python Programming
Also, this one, same title:
INDI Python Programming
These appear to be nearly identical and not reachable from an obvious point, like Community->Tutorials. I only reached them accidentally through a search of the whole web. Also, it could use some more detailed (for the novice) explanations.
Here are some other questions that keep popping up for me in my quest to control a filter wheel and a camera:
Perhaps there is a group of people interested to do this. I am a decent enough writer and would be willing to help with documentation and examples. What's the best way to collaborate on this? Is it the Development forum?
Read More...
Hi all,
I am learning how to use the Python module PyIndi to control devices. They have a pretty good CCD example, but not enough for me to be able to extrapolate to filter wheels. Does anyone have Python code to control the filter wheel (and anything else, too) using this module who would be willing to share?
Thanks a million,
Charles
Read More...
"Better" only because the current feature doesn't work. Is this setup selection a deprecated feature?
Read More...
Hello,
I discovered an issue when kstars on my laptop failed to solve the location I was pointed to. After much troubleshooting, it appears that there's an issue with the telescope parameters set in the Mount tool properly getting into the Align tool window.
The laptop has Kstars 3.4.2 (Build: 2020-04-25T20:01:00Z), and I am comparing with an older version on my desktop which works fine: Kstars 3.4.1, 2020-02-23T18:06:07Z
I have saved several telescope setups:
1) Aperture 200mm, f/l 812 mm
2) Aperture 280 mm, f/l 1764 mm
3) Aperture 80 mm, f/l 480 mm
When I switch to setup 3, the FOV field on the align screen changes as expected (129.7' x 97.8').
When I change to setup 2, the FOV field changes to 31.6' x 23.8', which is different from the desktop: 35.3' x 26.6'
Changing to setup #1, the laptop FOV field shows 31.6' x 23.8', while the desktop shows: 76.6' x 57.7'
Very strangely, if I change setup 2 to match that of setup 1, the FOV with setup 2 *does not change*. But switching to setup 3, it changes as expected. Creating a fourth setup with the same params as setup 1 stubbornly yields the same incorrect FOV.
Since this feeds into the command line for plate solving, it causes the solver to spin for 8 minutes until it finally gives up.
Not sure if it matters, but the INDI library is running on a Raspberry Pi and is version 1.8.1.
Laptop OS: Linux *** 4.15.0-101-generic #102-Ubuntu SMP Mon May 11 10:07:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux|
Desktop OS: Linux *** 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
If you need logs or anything else, let me know - I've only narrowed down the problem to this level in the daylight.
Thanks,
Charles
Read More...
Hi again,
The procedure worked great, I think, but now I have a conflict between the results from the polar alignment tool and PHD2's Guide Assistant.
I did not bother with parking; just used the HC to turn the mount to 4 hours east by the hour angle reading. I don't have any screen captures or logs, but I recall the measured polar misalignment was less than an arcminute. I've repeated this procedure several times, each time the error vector is very short (~ 10-20 pixels long), and it's difficult to make any improvements. With my image train I'm running at 0.63 arcsec/pixel, if that helps.
When I use PHD2's Guiding Assistant, it tells me the misalignment is ~ 7 arcmin. I have to wonder which measurement is correct. My guess is that PHD2 is more correct, since I can watch the DEC error slowly increase over time. If anything, maybe their scale factor is wrong, but I sort of doubt it.
Anyway, perhaps I should start a different thread on this, but I'd be interested to hear any advice. I'll get back with screen captures and logs next time I go out.
Thanks,
Charles
Read More...
Thanks, guys, this will be helpful.
The CEM60 leans heavily on "zero position" (pointing at the pole with telescope vertical) - or maybe I do, since the hand controller insists on you powering off the mount after a park. I have not tried setting a park position in EKOS, thinking that would do the same thing.
My method has been to run the polar alignment several times, starting at zero position and returning to zero position after each run of the procedure. I don't have a permanent setup so I do this frequently.
I like the idea of rotating in RA more than 30 degrees during the alignment process, and also the idea of taking the images from both sides of the mount. Tell me if this is a good idea:
1) Set a park location with an RA 60 deg east and the scope pointed at the pole.
2) Run the polar alignment process, moving 60 deg west each time
3) Auto-park back to the first position
Good idea?
Thanks again for the help,
Charles
Read More...