Jacob Nowatzke replied to the topic 'Losmandy Gemini Dec reversed?' in the forum. 2 weeks ago

Here's some logs showing that Gemini doesn't know how to slew.

I started off prior to logging by unparking the mount and attempting to slew to Cygnus. Failed.
Slew to Vega. Failed.
Slew towards Ursa Major. Worked.... Okay?
Slew to Hercules. Worked... Okay?
Slew to Cygnus. Failed.
Slew to Draco (looking for C/2017 K2). Failed.
Started Scheduler with C/2017 K2 as my target. Fails to slew, but starts focusing. Gets to Solver, fails to slew but completes solver anyways, apparently accepting some random spot in Hercules that I'd previously slewed to (above).

This is all East (pointing West), so why can't the mount figure out how to flip to the other side?

Also, woke up this morning to the mount parked facing the east horizon. What gives?


Jacob Nowatzke created a new topic ' Losmandy Gemini Dec reversed?' in the forum. 2 weeks ago

Attached is a screenshot of the Solver module showing every time a slew occurs, it's in the opposite direction (missing step 4 because it failed due to search radius being 30deg, for step 4 I increased to 90 and it solved after a few minutes). Really tired of missing nights due to Ekos/INDI, but what other choice do I actually have? Some lame proprietary software? Oh well, going to bed frustrated and dumbfounded. ....

Okay? As I was typing this, trying to figure out how to not sound like a whiny child, the mount "automatically" flipped to west-pointing (which I don't want it to be??). At least now things move properly, but what in the actual hell is the issue, here?

Side note, I'm not posting logs- I waste more time turning logs on and off, and getting stuck in a loop where KStars just crashes all the time, so I'm not the biggest fan of logs. Plus, KStars crashes enough as is, it's basically iOS for the sky. That's a joke, but the three crashes I've had tonight, alone, plus the multiple times the scheduler fails to park my scope and I wake up to servos being burned out while my OTA is being smashed into the tripod isn't. Show me a version of KStars that doesn't crash regularly, and also when I enable logs, and I'll share a log for every issue I encounter- sounds fair, I'd say. (my PC is decent and up to date)

Any thoughts? Anybody have worse problems with Gemini? No problems at all? Same problems? Holler, I just really want to understand what's going on without having to learn how to write a program.

I don't have meridian flip engaged on the mount module, I have imaged several nights (don't get me started on those issues) without moving anything, I see no reason this should be so.... recurrent.


*now the solver is having an extra hard time with overshooting. I'll wake up to 2hrs of data, or none, I guess


Jacob Nowatzke replied to the topic 'Losmandy Gemini Slew Fails' in the forum. 1 month ago

Thanks Chris. Gemini Hand Controller reports target unreachable... But it's plenty reachable. I grabbed the laptop, went out there, got the same error on EKOS and this on controller, reset Gemini, reconnected, slews fine.

Thing is, I'd already tried this and it didn't do the trick. What would force the Gemini to think that the target wasn't reachable if I'd plate solved at that area and it "knew" that it was okay to slew? It wouldn't even slew to a spot close to the pole!


Jacob Nowatzke created a new topic ' Losmandy Gemini Slew Fails' in the forum. 1 month ago

I can park and unpark the mount all day. Every now and then I get the slew failed error.

I've tried the following:
1) reset Astroberry
2) reset Gemini
3) reset both Astroberry and Gemini
4) reset everything connected (2x ASI CCD, Pegasus UPB, ASI EFW, and of course Astroberry and Gemini)
5) run a scheduler- ran into wild happenings like slew failing seeral times before working.
6) slew with mount control in ekos, start guiding procedure, take frames..... this works. xD hahaha not ideal

I was taking multiple 300sec frames a few nights ago. Given there have been clouds lately, but I could definitely be having much more scope time is EKOS/INDI would stop being so foolish with the Gemini driver.

I'm really not in the mood to reinstall everything because without any updates since, this workflow and INDI profile were working fantastically.

Who enjoys seeing such:

2020-06-05T05:29:29: [ERROR] Slew failed.
2020-06-05T05:29:29: [ERROR] Error Slewing to JNow RA 17:52:53 - DEC 53:23:39
2020-06-05T05:29:26: [ERROR] Slew failed.
2020-06-05T05:29:26: [ERROR] Error Slewing to JNow RA 17:52:53 - DEC 53:23:39
2020-06-05T05:29:24: [ERROR] Slew failed.
2020-06-05T05:29:24: [ERROR] Error Slewing to JNow RA 17:52:53 - DEC 53:23:39
2020-06-05T05:29:21: [ERROR] Slew failed.
2020-06-05T05:29:21: [ERROR] Error Slewing to JNow RA 17:52:53 - DEC 53:23:39
2020-06-05T05:29:05: [INFO] Synchronization successful.
2020-06-05T05:28:46: [INFO] Slew is complete. Tracking...
2020-06-05T05:28:40: [INFO] Slew is complete. Tracking...
2020-06-05T05:28:14: [ERROR] Slew failed.
2020-06-05T05:28:14: [ERROR] Error Slewing to JNow RA 17:52:00 - DEC 53:23:37
2020-06-05T05:28:14: [ERROR] Slew failed.
2020-06-05T05:28:14: [ERROR] Error Slewing to JNow RA 17:52:00 - DEC 53:23:37
2020-06-05T05:28:13: [ERROR] Slew failed.
2020-06-05T05:28:13: [ERROR] Error Slewing to JNow RA 17:52:00 - DEC 53:23:37
2020-06-05T05:28:13: [INFO] Synchronization successful.
2020-06-05T05:27:58: [INFO] Slew is complete. Tracking...
2020-06-05T05:27:41: [INFO] Slew is complete. Tracking...
2020-06-05T05:27:33: [INFO] Slew is complete. Tracking...
2020-06-05T05:26:40: [ERROR] Slew failed.

I've attached logs... can I do better?

KStars 3.4.2 (Build: 2020-04-26T07:39:54Z) on Win10, connected remotely (5GHz WiFi) to RPi4/4GB running Astroberry (Linux astroberry 4.19.118-v7l+ #1311 SMP Mon Apr 27 14:26:42 BST 2020 armv7l GNU/Linux)


Jacob Nowatzke replied to the topic 'Astrohat - An open hardware RPi Hat for astronomy equipment' in the forum. 1 month ago

Eagerly awaiting any progress, willing to pay to give it a try, as far as hardware goes- I can easily fill up all the outputs. Is there still room on the GPIO for a couple I2C sensors for temp/RH and the such? You're going to give Pegasus power packs a run for their money, I suppose. I'd buy one of these over another UPBv2, no doubt.

Perhaps the biggest spec for me on this board is the 12V input to the hat- it powers the Pi, correct? Heck. YES. Much needed. Who has time for 5V when you're mobile? Too much struggle, imo.

Thanks for tackling this- it's going to be very useful. Hope you're doing well during lockdown.

Stay up,


Jacob Nowatzke replied to the topic 'Losmandy Slew goes haywire' in the forum. 1 month ago

Hey, G11 and G8 owner, here.
Do you have a real time clock on the Pi4? With StellarMate on Pi3, once I made sure my RTC was configured, the issue with the G11 resolved.
I ran into the same problem with Astroberry on Pi4 and G8, but this time with RTC, found that once I switched cables with the G11, it was good, so my cables are faulty on the G8- waiting to replace them. Are you using the latest firmware update on the Gemini2? USB or LAN? I've always stuck with the USB-B. Are you using the newer Gemini2 (with only one 12V input)?
I also had issues with the G11 after RTC issue resolved them, but that was back when I was grabbing nightly builds whenever and it resolved after reverting to last stable build, if I even remember that situation correctly- this was also with StellarMate on Pi3.

I have issues with my Losmandy mounts often- I boil it down to half me and half mount/OTA. Really not sure why I stick with it, but I see others with such great success, leaves me confused often.

Best of luck, I'm curious to see how it turns out for you. I'm currently on a mission to get the PiZeroW powered by the Gemini USB-A port with dongle and connected to the USB-B input to run the mount over bluetooth with the Pi4- one less wire up to the OTA always sounds appealing. I've only made it as far as testing power from the Gemini to make sure it can handle it but looks good- I blab all of this because learning more about the general Gemini issues will be a positive experience for us all, I hope. Sorry for the semi-hijacking, please do let us know what you find.


Jacob Nowatzke replied to the topic 'ZWO 8 Position Filter Wheel' in the forum. 1 month ago

While I'm happy for you that you've solved it, I did want to chime in to mention that the error is still present as of version 1.7 of indi_asi_efw, using KStars 3.4.2, latest Astroberry dist.

It's odd to me because restarting my remote Astroberry will sometimes bring up the 8pos efw plainly, but restarting later will revert back to the 5pos efw. What gives? If the 8pos efw is detected by EKOS, can it not signal to overwrite the old config file? May I ask for someone who is familiar with the code to explain why it sometimes chooses one and the rest of the time, the other? Trying to understand the workings behind both ekos/indi and my equipment drivers.




Jacob Nowatzke replied to the topic 'RPi4 now has booting from SSD (beta)' in the forum. 2 months 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. 9 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.