I'm in KStars Build: 2019-10-03T08:23:19Z on my desktop right now. On my laptop (build in signature, more frequently used), I have my artifical horizon functioning just fine. I can't save it, however, because I get the wonderful invalid polygon error. I surely must have succeeded in the first place with it by luck, because I can't recreate it in my desktop without getting the invalid error, weather by manually typing out the points or drawing it, or even drawing some random would-be restricted area.
When I try to create another one on my laptop, it doesn't even mind that my new drawing is probably going to fail, it's concerned with the old polygon (which displays perfectly and doesn't touch the horizon at all, nor does it end with a zero, it only begins with a zero in the altitude).
Further, when I was typing in some of the points, I could type "39" and then hit space- the cursor would not advance for two lines of points, but on the third it went back to normal behavior.
Now I don't know if the whole "first and last points must be on the horizon" just happens to be required to allow the function to exist, but I'm drawing the thing in the first place because I don't see a horizon where my scope stands, at all, and I'm even further restricted by trees and buildings, so of course that requirement was odd in my perspective from the beginning, but there must be some way by which that requirement can be ousted? I mean, my art.horiz which is actually working doesn't come close to the horizon, so why require two points to be as such? I'm sure it's technical, so I assure you the question is rhetorical.
I didn't find a video on the process, but I think it would be a quick and valuable addition to the tutorial video lineup. The KStars Handbook (pg.48 of who knows what version- could use a version/date on the first page) directions for art.horiz doesn't really reflect the issues I have personally seen with the tool, and so I've listed them here.
Tired and a little cranky (probably much of the moon and cloud effects), but thought it useful to list out the issues I've seen with this tool over the past week. Can I even incorporate it into Ekos? I don't think so, and if not, consider it a point on the wishlist for sure.
The cool thing is, I somehow have it working on the machine I use the most- I don't know how. The lame thing is, I can't do anything else with it or duplicate it or further understand it.
ajt68 wrote: Very nice post, and totally agree with all the sentiments raised. I too am here developing, mainly because my focuser wasn't supported, so wrote the driver for it. That's what I like about open source, if it doesn't do what you want, then implement it!
I remain in awe and so impressed by individuals who can simply write in code when it's needed, especially for drivers. Watching Jasem find some random error in a pile of driver code for my focuser in TeamViewer gave me the slightest idea as to just how clueless I am in regards to coding for devices. It's certainly far past any arduino code with which I've played in the past, and even that quickly becomes too advanced for me.
I'm hoping to get into this on the Ekos side of things in order to create and/or edit tooltips- I imagine the code wouldn't be so difficult, but I do fear that I might require a bit too much hand-holding to be introduced to the ability to do so. I'm sure I will pick up hints here and there, but until then I remain 100% dependent on coders like yourself.
Hi Jerry, did you get dithering working while using PHD2? I've been binning2x2 while using internal guiding with direct pulses instead of using an ST4 cable, using 5pixel dithering every frame. It's been working well, even though it seems a bit overkill, but now I'm trying to experimenting with the settle setting, because I notice that with some dithering instances, tracking has a difficult time catching up, likely due to backlash.
I would imagine that if you have "receive external guide frames" checked (of course in the guiding options tab in options under the guiding module), dither would work just as well with PHD2 as with the internal guider.
I'd like to know what you find, just to have the knowledge going forward.
Rob, thank you for your kinds words- and for looking past my grammatical errors-I'll have to edit them seeing as this post has been stickied. I certainly agree with what you've said here, and I hope it doesn't generally seem as if I've discounted those who edit code and provide such valuable input as you do. I recently used your installation script to do what I had failed while trying on my own a couple years ago. It was only after seeing so many companies come out with similar Pi-powered control units of which I thought, "hey, that's just what INDI has been doing, except they're open-source!", and then I saw StellarMate, and felt compelled to purchase the OS up front. A month later, I used your script to install another Pi3 indiserver over a MATE image, and I plan to use that very machine as a slave to my SM to control the mount, or at least as soon as I find the time to edit the connection. Again, a straightforward script (I believe I originally had used your pre-script, written instructions, even) which evolved out of your work, and some input from others, did for me in minutes that which would have taken me at least a couple of hours- you have saved me valuable time and resources, many times now. I have no contempt whatsoever, for people like you who are dedicated to this community in such a way- and I should have made this much more clear in my above post.
Also, I can't possibly resonate more, with your sentiment here. It honestly feels too good to be true sometimes- I managed ~2hrs of LRGB subs between writing this tonight, before clouds hit- something I would have been lucky to get 0.5hrs, had I been going with my original workflow. The cherry on top was to walk outside with my scope cover, take care of some dew, and pull out my phone to park the mount with KStarsLite app, not having to lug my laptop around with me. It's a brilliant thing, this project. I am skeptical, however, that there's some sort of magic going on behind the internal guider- I certainly never achieved these RMS values with other software... and come to think of it, this is the first night in my just over two years of astrophotography that I've actually collected more than one night of data on a target.
rlancaste wrote: Before I switched to KStars/INDI, my images were not so good with pretty poor guiding, a directly USB connected laptop with software that crashed frequently, had to use multiple programs to get everything to work, and I had to align by centering stars in my image and using the hand paddle. Now that I use KStars/INDI, my images are much higher quality, my guiding is now almost perfect, all my equipment is accessed remotely over wifi, I align my scope in seconds with plate solving, and the software crashes less frequently.
Thanks again, for your comments and contributions, Rob. My only extensive coding experience is in R language, which has little place in astronomy, so I consistently find myself depending on people just like you to help me succeed in working with other types of code when it comes to new software. You help translate a seemingly cumbersome and novel task into a more friendly and understandable workflow, and this means the world to people new to such an environment.