KStars-bleeding Version: 5:15.12+r5636.250~ubuntu15.04.1

I believe I installed this the 6th of March. I notice there's an update, I'll grab that before heading out next.

I also reported a separate issue which looks like it is a Southern Hemisphere issue with the parking in eq_mod.

Read More...

Not thinking clearly last night - couldn't remember where to find the best version number...

KStars-bleeding Version: 5:15.12+r5636.250~ubuntu15.04.1

I installed this on the 6th of March.

Read More...

Since updating earlier this year to the latest kstars-bleeding, parking is failing reliably. It tries to park upside down for lack of a better term. Slightly alarming when it first happened.

HEQ5Pro
KStars 2.5.0
indi 1.2.0
Linux (x86_64) release 3.19.0-15-generic (xubuntu on a late 2008 MacBookPro)

Unfortunately I seem to have not captured the corresponding kstars log output by mistake. I'll do so in the next few days as this is an easy one to reproduce inside.

Looking at the eqmod log, it looks like it gets rather confused as to the location of the observer with the latitude and longitude being set to 0 at one point.

Read More...

This is exactly the same problem I saw after I updated a month or two back. I originally had issues with the centering method (Aug 2015?), and despite upgrading after the I ended up just using the calculate azimuth error to adjust the mount by hand. I had a very good idea how many turns on the adjustment knob was required and could get to better than 5" error after 2 repeats.

Post recent update, I found the calculated azimuth error was the opposite direction, I.e. If the mount was too far East it reported as West. Realising this and correcting for it resulted in a successful alignment. The wrong direction would result in the doubling of the error each time as reported in this thread.

I haven't had the chance to produce the detailed logs for this. I went to our club site on the Friday with the intent on collecting logs for this and another issue and it clouded over by the time I got the scope out!

I'm located in the Southern Hemisphere and had initially though it might be a southern only issue but clearly not.

Read More...

I tested the fix for the first issue last night (removal of if statement and idx = 1) and it seemed to work fine. I was able to use short exposures correctly with a Upload value of Both, didn't notice any adverse behaviour yet.

Predictably it's forecast to be rainy for the near future so I can't test how this works with alignment or focusing

Read More...

Attempting to produce the logs for this revealed the second issue is limited to a Upload value of Client so maybe it's related to this issue after all…

Issue is that kstars (it could be indi_gphoto) stays in the Downloading… state after the second exposure when using a Upload value of Client. Local or Both seem to work fine, though I'm sure I saw it with Both before. Only the first image is downloaded and displayed in the FITS Viewer. Indi and the driver appear to be non-responsive after this point (can't disconnect and indiserver process remains after killing kstars) No further use is possible with the camera.

Logfiles attached.

Andrew

I've finally had the time to debug some of the issues that have bugged me...

Latest indi 1.2, though was also present in 1.1
Latest kstars-bleeding from the repo 5:15.12+r5636.250~ubuntu15.04.1 (as also present 6 months ago)
Xubuntu 15.04
Canon 20D (unmodded) with indi_gphoto

First issue is that unless I use the external serial bulb control, the camera always takes a 30 seconds exposure, regardless of what exposure setting I use. So specifying 5 seconds results in a 30 second exposure. I've always used the upload option of Both.

I've debugged this one through and found the issue in gphoto_driver.c at line 591 in gphoto_start_exposure()

// Not using bulb mode
// If we need to save to SD card as well, set idx to 1
if (gphoto->upload_settings != GP_UPLOAD_CLIENT)
idx = 1;
else
idx = find_exposure_setting(gphoto, gphoto->exposure_widget, exptime_msec);

So that says it will respect the exposure setting only if UPLOAD_CLIENT is used. Index 1 for my 20D is 30 seconds, hence the resulting behaviour. Specifying an upload setting of Client results in correct length exposures as expected.

I can obviously remove this (and it already has been commented out a few lines above by someone) but I'm wondering if I'm going to break anything in doing so. I really can't understand why the upload setting would affect the exposure length. Hopefully someone can enlighten me Being a software developer (bit rusty on the C) I have no problem customising my local install but would good to fold this back in as well.

I'm guessing no one has noticed this as generally we're more interested in bulb exposures, however this is a pain for focusing and alignment.

Second issue I'll log separately, but it relates to something either in kstars or indi_gphoto hanging when using an Upload value other than Local.

BTW Nice to see the scheduling and mosaic support added, as well as phd2 support.

Andrew

Read More...