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 (!)
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?
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,
"Better" only because the current feature doesn't work. Is this setup selection a deprecated feature?
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.
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, 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
Thanks again for the help,
I highly recommend using PHD2 for guiding. I had problems like you are describing for at least a year, up until early July, which is when I switched to PHD2. Since then, guiding has been much much better.
PHD2 is fairly well integrated with EKOS, but it does require that you start it up separately from kstars/EKOS. This has not been a problem for me.
A very useful part of PHD2 is Guiding Assistant. I highly recommend using it for 2x or 3x your worm period before you start guiding.
Anyway, I don't mean to diss the guiding in EKOS, but it seems that implementing a guiding algorithm is a lot harder than it might seem at first. PHD2 has so much good stuff in it, plus excellent documentation. I don't know what the magic is, but I'd give PHD2 a try.
I am just now able to try out Kstars 3.3.6, after having used 3.3.4 for some time. Everything is good, except for what happens after the polar alignment procedure. I go through the mount adjustments, then click "Done", and the mount starts moving. The first time this happened, I panicked, but it turns out the mount was apparently commanded to park. This behaviour is different than the previous kstars/EKOS behaviour, in which clicking "done" just stopped the image looping and left the mount where it was (either RA +60 or -60 from zero position).
I don't like this. I never park my mount. A CEM60 wants you to power off the mount after it is parked - I don't want to do that for lots of reasons, not least of which is why should I power cycle my mount just because I polar aligned it? Parking means end of the night, not just another step in getting ready to image.
Anyway, perhaps I'm doing something wrong, or have missed an option somewhere. Thanks for any help with this.
Thanks for pointing out that about fitsviews. I was not suggesting that all be separated from Ekos, just that the fitsviewer might run in its own process or thread.
But anyway, I have not looked for any Linux FITS viewers out there. Perhaps this link is a good start? fits.gsfc.nasa.gov/fits_viewer.html
I'm late to the conversation, but this topic has been in my head for a couple months now. I'd like to chime in.
First, I'd like to add to the list of people who experience whole stack crashes when fitsviewer has a problem. It seems to happen for arbitrary use of features in fitsviewer, seemingly anything that goes beyond zooming, panning and using some of the information tabs (e.g., FITS header). The behavior is that suddenly I notice that nothing kstars-related will respond to clicks (kstars, fitsviewer, EKOS, INDI windows), then, after some time has passed, all windows disappear. I use a RPi for running INDI server and an Intel desktop machine with 32 GB RAM for kstars etc. so I don't think it's the RPi's limited memory causing this. (I've seen it happen when I just start up kstars to view FITS files and don't connect to the RPi)
Anyway, aside from an obvious suggestion to fix that problem, here are some other suggested improvements: