Jacob Nowatzke replied to the topic 'RPi4 now has booting from SSD (beta)' in the forum. 2 days ago

This new beta applies all the same to a USB3 thumb drive, yeah?


Hi All,

Been out for a while, back into it. I'm wondering where KStars stores the saved Region files from Artificial Horizon Manager in Windows(10)? While I have you, how about for Linux and Mac?

I spent a few hours toying with the polygon tool. It's a pain, no doubt, but useful nonetheless. Instead of building multiple Regions, indicating multiple polygons, I'm after a single polygon. I recently relocated- I have about 7hrs x 20deg of sky in the middle of the redwood forest, but luckily I can see the pole and Polaris. I just want to define the trees all around me. I'm after this file so I can edit it myself if possible. Here's what I've been doing to get around it in a very tedious fashion:

  • Draw a 72-gon around the horizon; all 0°Alt,
  • Finish with 359°59'59.9R"Az; without closing,
  • Then 00° 00' 00"Az, 45°Alt; go around to make 360-gon with varying altitudes,
    ->Entering anything between this 00°Alt and 02°Alt will automatically become 00°Alt... so technically a 358-gon.
  • End at 00°Az, 00°Alt to close the total polygon.

Things that would have made this experience easier, for future reference:
  1. Insert a row in the Points section, in between previously-entered rows
  2. Make a duplicate of a Region for smooth, safe editing/testing
  3. Copy/paste Az/Alt rows and/or columns
  4. Edit multiple cells in a column at the same time (a fella can dream)
  5. Save as (for Region)
  6. Open (for Region)
  7. Draw a polygon. Invert selection.
  8. -> It's much easier to draw an area as if it were an obstructing object, but then it is seen as such- to invert an obstructing polygonal area would have made this process the simplest, I think.

What I'm after at this point is the text of the Region file so that I can edit and make a template that draws a 360-gon at 00° 00' 00"Alt, then continues with another 360-gon at 01° 00' 00"Alt (as well as separate script that uses a 72-gon for when I don't want to deal with the huge 360-gon). I'll use this red band over the horizon to edit Altitude coordinates of the (00° 00' 00"Az, 01° 00' 00"Alt) pairs to draw my appropriate Region.

Am I missing something completely, here?
At any rate, I am simply after the text file. If I was apt to coding, I'd certainly offer up my time to write a script. This tool is very valuable to me, if I can get it right. Drawing out trees isn't any fun, but I'm sure there will be improvements to the tool as time progresses and more important features are streamlined. Amazingly, KStars didn't crash once for me while I was building this ridiculous polygon! That made me happy (thanks dev team). I will compile these experiences to send to KDE team in a feature request whenever is clever to do so.

I'm still trying to wrap my head around this Artificial Horizon function, so it's incredibly likely that I breezed over something fundamental without noticing. Just writing this post to gather my thoughts.


Jacob Nowatzke created a new topic ' Artificial Horizon hiccups' in the forum. 8 months ago

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.


Jacob Nowatzke replied to the topic 'Dithering question when using Phd2 and Ekos' in the forum. 8 months ago

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.

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.

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.

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.