When tracking, RA/Dec should remain constant, while Alt/Az change (following the object across the sky).
When parked, Alt/Az (and also Dec ) should remain constant, while RA changes -- I would want to see what hour angle the parked scope is currently pointed at; this is great information for telemetry from a remote observatory.

Kstars correctly shows the "stars sliding by" with the mount staying at the parked position.
Ekos is not updating (only in SCOPE_PARKED state).

Read More...

I have an LX200-flavor mount (It's an Astro-Electronic FS-2), and when I'm connected to the mount in Ekos, if I'm tracking at sidereal rate, then the mount coordinates update properly (RA/Dec stay the same, Alt/Az update).

However, if the mount is parked (and the motors are off), then Ekos doesn't update the mount coordinates display? This is both on the "mount" tab and on the main "ekos" tab. The INDI driver shows RA/Dec changing and Alt/Az staying the same (as they should when parked), but Ekos doesn't seem to query the driver for position updates while it's parked.

In the screenshot, you can see INDI reporting RA 9:19 and Ekos reporting RA 9:09.

Read More...

I have attempted to make FS-2 park properly by turning off the motors when parked (set rate to CENTERING, move East).

This works great, and the mount parks and unparks, and slews just fine...

...until I completely stop Ekos and restart it.
At this point, Ekos turns on tracking, but doesn't unpark the mount -- this leaves the mount in a weird state where it can't be slewed.

Can someone help me to understand how to maintain this behavior across reboots?

I also noticed that @SevenW is trying the same thing under LX200 Classic. His method is to set Alignment to :"Land". His code looks similar, but he's having a problem at unpark as well.

Is either of these methods the correct way to do this? My goal is to be able to shut down and park the mount at the end of a session, and have it sit with motors off until I get back. I have submitted a PR from my fork, so that we can discuss the code before it gets merged.

Read More...

I don't believe so; I read that thread, and it seems to be about meridian flip being bad mojo.
While I am happy to believe that MF has messed up this party, I have a pretty succinct 22k log that shows a park request, a slew of about 30º to the park position, no MF required (my park position is 90º Az / 0º Alt, CW down OTA pointing at the East horizon), and the status changing to "parked" with the mount's position stable at the target Alt/Az.

...

except the motors never turned off.

There's no indication in the logs that any "stop" command was sent to the mount anywhere near the status update to Parked.

In the thread I linked, above, there's a suggestion that the INDI FS2 driver only works with more recent versions of the FS2 firmware.
I'd be just as happy to have a checkbox that says "Send stop command after parked", which can be checked by people who have an older version of the mount hardware, and who need to either use an older INDI driver that works with older firmware (was there ever a version that worked with v1.21?), or a mod to the current version.

I am wondering if other FS2 users have ever gotten Parking to work, and if so, how did they do it? This appears to be implemented differently for almost every LX200-flavored driver.

Read More...

I am running
KStars 3.4.2 (2020-04-13 build),
Ekos (not sure how to find the version in Ekos, but I just installed a couple days ago),
indi_lx200fs2 v.2.2 interface 5.

My FS-2 controller is running 1.21.

I read on a previous thread that the mount doesn't receive a "stop" command after parking, and this looks consistent with both my debug logs and a quick peek at LX200FS2::Park().

My questions are these:
1) Is the current driver written only to support a newer version of my firmware? My understanding is that 1.26 is out, and I'm in the process of seeing if I can get a new EEPROM shipped.
2) Is it possible for me to use an older version of the driver that works with v1.21 firmware?
3) I also found a thread that showed the LX200 commands to use to stop the mount -- I'm happy to write the code and submit a PR, but I want to make sure that I don't stomp any one else's config, and I've not edited an INDI driver before.

Read More...

Note that Python is installed by default on OSX; it's used by the OS. On my El Capitan box, python was installed at /usr/bin/python, and is version 2.7.10.

For some reason, pip is not installed by default in the OSX version of Python; you can get pip at bootstrap.pypa.io/get-pip.py or you should be able to sudo easy_install pip

Read More...

I have been using a finder-style guidescope for several years, right now it's an Orion SSAG with a Kwiq Guider on an otherwise stock 9x50 finder. I also picked up the Orion 50mm Guidescope to use with a QHY 5 II L, but haven't swapped it out yet.

Essentially, I figure as long as the guider is running at a better resolution in "/px than the main scope, you're golden, especially when you figure in subpixel guiding.

I get great results with the combo, guiding the mount to within 1" most nights, or 2" if it's real windy. Best guider ever.

Read More...

First, let me thank Jamie and Gonzo and all the other contributors who have been chasing this issue really hard for the past few weeks. I haven't been able to follow every single bit of it, but you've been doing a yeoman's effort, and I, for one, am excited to try out kstars on my Mac, and grateful that INDI has such a dedicated community!

All that having been said, I tried this DMG on my (fully clean, never tried building any of this on this Mac) i7 MBP running 10.11.6, and the DMG won't install, because it requires 10.12. Is this expected?

I know that it's been asked before, and the answer was "read the thread", but if there are a set of instructions that one could follow to compile the code / create the DMG, I'd like to try it.

... or should I wait for a "public" DMG to be released, at this point?

Read More...

Hi Sean,

It was your instructions that got me all compiled and running, so follow the hints your-self-of-several-months-ago gave, and you'll get there, beer notwithstanding

I have found that which Hypervisor I use makes a big difference in my success -- I really wanted VirtualBox to work, but found myself plagued with USB problems and instability. I had much more success once I switched to VMWare Fusion. It's non-free, obviously, but the price tag isn't that big ($70 or so), and it has a much better hardware integration between the Mac host and the guest OS (which in my case was Win XP). Granted, the use case I was attempting was hooking all the photo rig to ASCOM on the XP box through the VM, so YMMV if you are only trying to send INDI TCP packets across. Still, having just one USB cable between the rig and the computer was a joy (there was a powered hub at the mount, naturally).

I lost my astro VM in a nasty astro-divorce (long story), so I'm rebuilding my software rig from scratch at the moment. Let me get the ^&$%&(*^ thing running in *(^$(&^ Windows, so I can take some pictures whenever it decides to clear up, and maybe I'll have an appetite to play with "alternative OSes" again.

Heck, I might even check eBay for cheap laptops...

Don't drink and sky,
Jimbo

Read More...

Well, this has been an interesting ride.

About five years ago, I heard about INDI, and it sounded like a path out of Windows, and in particular, sounded like a great way to use my Mac for astronomy, natively (my observatory runs in a VMWare Fusion VM at the moment). At the time, it felt like there was just not enough device support to justify trying to switch.

This time out, it looked like there was a lot more device support, great job everyone, so I decided to give INDI a go on OSX.

After two weeks of fighting Homebrew, Fink, Qt, and KDE, I'm ready to quit again, for now.

In the end, I got INDI 1.2.0 and Kstars 2.5.0 (compiled under KDE 5.16.0 and Qt 5.5.1) running on OSX 10.10.5. I never quite got all the icons working in Ekos. I couldn't get the indi_qhy_ccd driver to build on the Mac, so I tried both Astroberry 1.0, and the latest Raspberry Pi daily builds (the RPi stuff was on a RPi 2 running Raspbian Jessie), where it built, but was unable to connect reliably to either my SSAG or QHY5-IIL.

I felt like I was a couple a moving parts away from a 100% Mac solution in the observatory, and was setting up to write a port of Lesvedome (K8055 based dome under ASCOM) as an INDI driver.

Perhaps this all just works out of the box on Linux, but I'm feeling like we are still "not quite there yet" on OSX, and so I will just put this project back on the shelf and go back to ASCOM for now. Maybe I will try again in a few years, when Windows starts wearing on me again.

For the record, the only reason I am running KDE on the Mac is to run Kstars, which, after all, is part of the KDE Education package.

A suggestion to someone with a little time on their hands, write a small utility that will enumerate all of the "full names" on a given INDI server. Trying to glean that info from log files was the second-to-last straw.

Read More...

OK, I got kstars compiled using seanhoughton's method. I am now trying to work my way through getting KStars / Ekos / INDI up and running, and I'm getting a worrisome error in the logfile in the Terminal Window that kstars opens:

File opened: "/Users/jimbo/Library/Application Support/kstars/comets.dat"
klauncher not running... launching kdeinit
klauncher not running... launching kdeinit
klauncher not running... launching kdeinit
couldn't create slave: "Cannot talk to klauncher: The name org.kde.klauncher5 was not provided by any .service files"
Loading Supernovae data

I have tried running

/usr/local/Cellar/kf5-kinit/5.16.0/bin/kdeinit5_wrapper klauncher

from the commandline (which seems to be how to start klauncher, please advise), btu that spits out this error:

kdeinit5_wrapper: Warning: connect(/Users/jimbo/Library/Application Support/kdeinit5_NODISPLAY) failed: : No such file or directory
Error: Can not run klauncher !

Which leads me to believe that it's having a problem with the " " in "Application Support". Is there a way to get kdeinit to escape the space character, or some other way to get klauncher launched?

Any advice at this point would be appreciated.

Clear skies,
Jimbo

Read More...

Update:

I had to install extra-cmake-modules (ECM) manually:

brew install haraldf/kf5/kf5-extra-cmake-modules 2>&1 | tee /tmp/install.log
cd /tmp
tar zxvf /Library/Caches/Homebrew/kf5-extra-cmake-modules-5.16.0.tar.xz
mkdir build
cd build
cmake ../extra-cmake-modules-5.16.0 -DCMAKE_C_FLAGS_RELEASE=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE=-DNDEBUG -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/kf5-extra-cmake-modules/5.16.0 -DCMAKE_BUILD_TYPE=Release -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_VERBOSE_MAKEFILE=ON -Wno-dev -DCMAKE_PREFIX_PATH=/usr/local/Cellar/qt5/5.5.1_2/lib/cmake
make
make install

I got the cmake parameters out of the "install.log" file that brew created. I had to add the CMAKE_PREFIX_PATH myself, after running it the first time and having it fail to find Qt5 properly on its own.

Once I got the proper version of ECM installed, brew counted it as a fulfilled dependency, and I was able to go on to:

brew install haraldf/kf5/kf5-karchive

and am continuing through the list from there.

Read More...

I am having a rough time getting kstars-bleeding running on my Mac. I am running 10.10.5, and have Xcode 7.2.1 installed.
I am following seanhoughton's instructions, and got as far as this line:

brew install haraldf/kf5/kf5-karchive

before I ran into what looks like a dependency loop?

$ brew install haraldf/kf5/kf5-karchive
==> Installing kf5-karchive from haraldf/kf5
==> Installing dependencies for haraldf/kf5/kf5-karchive: haraldf/kf5/kf5-extra-cmake-modules
==> Installing haraldf/kf5/kf5-karchive dependency: haraldf/kf5/kf5-extra-cmake-modules
==> Downloading download.kde.org/stable/frameworks/5.16/...odules-5.16.0.tar.xz
Already downloaded: /Library/Caches/Homebrew/kf5-extra-cmake-modules-5.16.0.tar.xz
==> cmake . -DCMAKE_C_FLAGS_RELEASE=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE=-DNDEBUG -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/kf5-extra-cmake-modules/5.16.0 -DCMAKE_BUIL
==> make install
Error: No such file or directory - (/usr/local/share/kxmlgui5, /private/tmp/kf5-extra-cmake-modules20160317-7933-9a6kzu/extra-cmake-modules-5.16.0/.brew_home/Library/Application Support/kxmlgui5)

(It's looking for kxmlgui5), so

$ brew install haraldf/kf5/kf5-kxmlgui
==> Installing kf5-kxmlgui from haraldf/kf5
==> Installing dependencies for haraldf/kf5/kf5-kxmlgui: haraldf/kf5/kf5-extra-cmake-modules, haraldf/kf5/kf5-kconfig, gettext, libffi, glib, shared-mime-inf
==> Installing haraldf/kf5/kf5-kxmlgui dependency: haraldf/kf5/kf5-extra-cmake-modules
==> Downloading download.kde.org/stable/frameworks/5.16/...odules-5.16.0.tar.xz
Already downloaded: /Library/Caches/Homebrew/kf5-extra-cmake-modules-5.16.0.tar.xz
==> cmake . -DCMAKE_C_FLAGS_RELEASE=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE=-DNDEBUG -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/kf5-extra-cmake-modules/5.16.0 -DCMAKE_BUIL
==> make install
Error: No such file or directory - (/usr/local/share/kxmlgui5, /private/tmp/kf5-extra-cmake-modules20160317-8047-1vyebhq/extra-cmake-modules-5.16.0/.brew_home/Library/Application Support/kxmlgui5)

(kmlgui depends upon extra-cmake-modules, which in turn depends upon kxmlgui)

Any ideas? After about 3 or 4 days of dealing with dependencies, I got Fink to install kstars, but it did not include INDI or Ekos, so I spent another few days getting -bleeding to compile, only to run into a very nasty part-Brew, part-Fink mess that was causing runtime library problems. So I removed Brew and Fink (and all the stuff they installed) completely, and am starting from scratch with this recipe...

Best,
Jimbo

Read More...