Re: INDI AP driver
Michael Fulbright <mike.fulbright@...>
Gabe,toggle quoted messageShow quoted text
I would say compared to a year ago the current INDI driver is on much better footing that before! If you have a spare machine or laptop I'd recommend giving it a shot. You don't need as beefy a machine as Windows requires for a good user experience.
When I first tried the INDI driver I could unpark and slew around so that was promising.
But then trying to sync the mount was a problem - it was using the old low precision LX200 commands!
So when plate solving and iteratively slewing to a target you were off quite a bit if you expect the typical few arcsecond resolution we achieve in imaging.
So I started with fixing that problem.
Then I found others which I have fixed since:
- the driver didn't properly control slew rates - FIXED
- pulse guiding didn't work - FIXED
- couldn't enable/disable PEM - FIXED
- Poor control of park positions - FIXED
- No ability to use meridian delay - FIXED
- mount initialization was crude and required user intervention each time - FIXED
Combined with EKOS (kstars imaging module) and PHD2 you have a software solution comparable in many ways to SGP.
My experience with the INDI developers has been overall positive and they are responsive to suggestions and attending to bug reports. Much better than most software vendors I deal with!
The main area I don't have much experience with is unattended automated imaging. I have moderate light pollution and only image one narrow band filter per night and with my East horizon blocked I just use meridian delay and have the scope run through a sequence without a meridian flip. My carbon fiber Newtonian rarely needs refocusing (night temps stabilize quickly here) so I usually only refocus manually a couple of times during the night.
So where I could use some help is for people to test automated runs (while supervising the mount initially at least) and give me feedback.
To you point about developing software under Linux - that was one of my primary reasons moving to INDI.
I like writing astroimaging utilities and mostly in Python and I find the environment under Linux much more appealing.
Using chroot's or containers I can build entire imaging software stacks in a "blob" and have multiple of these stacks on the same machine so I can do several development projects in parallel. And if I want to setup another machine I just move the blob over and I have my entire imaging environment ready to go.
The idea of having to duplicate my old Windows imaging stack on a new machine (where you can't just ghost the drive) just gives me the shivers.
Add in my refusal to ever load Win10 on any machine there just doesn't seem to be much of a software horizon for Windows for me past when Win7 loses maintenance in 2020. Until Microsoft puts a true opt-out mechanism for their telemetry in their non-Enterprise offerings that is a complete non-starter for me and many people I work with.
I have no idea how you would run simultaneous parallel software stacks (drivers and software) of different versions for testing under Windows. Presumably it is possible but under Linux that is a standard practice these days.
On 2/21/2018 12:09 AM, gshaughnessy@... [ap-gto] wrote: