×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

[SOLVED] Canon 6D and indi_gphoto_ccd, errors

Where did you read that? Jessie packages are the official ones I build on daily basis.
8 years 3 months ago #6570
The topic has been locked.
  • Posts: 365
  • Thank you received: 32
Ah, I must have misread it, I read a line in the tutorial saying "Raspbian Jessie, Wheezy packages are no longer supported". I read it as if both weren't supported. Anyway, trying to fix my wifi Ubuntu mate issue, maybe it is a better option anyway.
Last edit: 8 years 3 months ago by Vincent Groenewold.
8 years 3 months ago #6572
The topic has been locked.
  • Posts: 365
  • Thank you received: 32
<not relevant>
Last edit: 8 years 3 months ago by Vincent Groenewold.
8 years 3 months ago #6581
The topic has been locked.
  • Posts: 365
  • Thank you received: 32
I'm sorry to have to come back to this issue but it looks like something in the updates caused this to re-occur. I now went to a system as standard as possible, installing Kubuntu and Jessie on the Pi. Kubuntu definitely works better with Kstars, but my DSLR problem of not being able to go over 30 seconds cause Bulb isn't supported is totally back.

Any ideas what may be causing this now?

Thanks and greatly appreciated
8 years 3 months ago #6599
The topic has been locked.
  • Posts: 365
  • Thank you received: 32
To bring some more information to the table, this is the output from gphoto2 (part of it):
(I also have debug output for gphoto if needed)
Waiting for 60 seconds for events from camera. Press Ctrl-C to abort.
UNKNOWN PTP Property d194 changed
UNKNOWN PTP Property d1c3 changed
UNKNOWN PTP Property d1c7 changed
UNKNOWN PTP Property d1bf changed
UNKNOWN PTP Property d1d3 changed
UNKNOWN PTP Property d1c0 changed
UNKNOWN PTP Property d1d3 changed
UNKNOWN PTP Property d1a3 changed
UNKNOWN PTP Property d194 changed
UNKNOWN PTP Property d1c3 changed
UNKNOWN PTP Property d1c7 changed
UNKNOWN PTP Property d1bf changed
UNKNOWN PTP Property d1d3 changed
UNKNOWN PTP Property d1c0 changed
UNKNOWN PTP Property d1d3 changed
UNKNOWN PTP Property d1a3 changed
UNKNOWN PTP Property d105 changed
UNKNOWN PTP Property d108 changed

Ending with:
UNKNOWN Camera Status 1
UNKNOWN PTP Property d11b changed
UNKNOWN PTP Property d1c3 changed
UNKNOWN PTP Property d1c7 changed
FILEADDED capt0000.cr2 /
UNKNOWN Camera Status 0
Last edit: 8 years 3 months ago by Vincent Groenewold.
8 years 3 months ago #6602
The topic has been locked.
Maybe it is related to the recent "Mirror Lock" change, I asked the author to investigate.
The following user(s) said Thank You: Vincent Groenewold
8 years 3 months ago #6603
The topic has been locked.
  • Posts: 27
  • Thank you received: 32
Hello, I'm the author of the recent "Mirror Lock" change.
First, I need more information about your current configuration, most importantly if you're using a serial cable or not. I haven't been able to find this on this thread.
According to gphoto documentation, the 6D should work for exposures > 30 seconds only with a shutter on serial port which triggers the shot (an example here: www.covingtoninnovations.com/dslr/CanonRelease.html ).

Thanks
Marco
8 years 3 months ago #6605
The topic has been locked.
  • Posts: 365
  • Thank you received: 32
Hi Marco and thanks for investigating!

My current setup (which has worked fine for some time) is that I use a Raspberry Pi2 to which my Canon 6D is connected via USB. On the Pi I run the Indi-server which uses indi-libgphoto (built against gphoto2) to execute commands. The Pi has a wifi connection with my computer inside.

As said, this worked fine before, but now is causing the same problem I had before. Back then it as solved by going from Wheezy to Jessie on the Pi, I now run Jessie but to no avail. It seems something changed to gphoto somehow.
8 years 3 months ago #6606
The topic has been locked.
  • Posts: 27
  • Thank you received: 32
It is possible, I've had many many problems with gphoto on my camera (EOS 350d), sometimes I had to compile it manually from a stable version.
Anyway, let's keep investigating if it's something that might be caused by the mirror lock feature:
if you enable debug logging on the gphoto ccd driver, you'll be able to see a line like this when the shooting process is about to get started:
Starting exposure (exptime: <milliseconds>, mirror lock: <number>
.
If mirror lock is not zero, and you did not specify either a mirror lock value in GUI neither a serial port, then we might have a problem :)
Also look for a line like
Warning: Bulb mode isn't supported.  exposure limited to maximum camera exposure
If you see that, then there's really something wrong with gphoto, since the mirrorlock feature kicks in a bit later.
Thanks
Marco
8 years 3 months ago #6607
The topic has been locked.
  • Posts: 365
  • Thank you received: 32
So I just went ahead and installed gphoto 2.5.9 stable. Same thing, so that's not it. :)

I switched on debugging, loads of stuff in it but no "Starting exposure", I can't find the string at least, same for "mirror lock". Not there it seems.
Last edit: 8 years 3 months ago by Vincent Groenewold.
8 years 3 months ago #6608
The topic has been locked.
  • Posts: 27
  • Thank you received: 32
The string should be definitely there, maybe it's just not where you're expecting it.
It should be in the "device" panel of indi, not in the main ekos page.
You might also want to look at the indi server stderr, maybe launching it manually with the "-v" option.
8 years 3 months ago #6609
The topic has been locked.
  • Posts: 365
  • Thank you received: 32
Haha, well I'm such a lucky guy. Installing gphoto 2.5.9 apparently did something to indi_gphoto as it can't run it. Reinstalling the dbg file caused an error. :)

Anyway, I thought you meant the debugging on the gphoto2 terminal. I guess I first now have to reinstall my Pi to correct this indi_photo problem, will be back in 30 min.
8 years 3 months ago #6610
The topic has been locked.
Time to create page: 0.761 seconds