One question do you use LAN or Wifi for your connections - I use Wifi (connected by Realvnc)?

Something else I have noticed since 2.5 now getting double click of lens shutter and or Mirror Lock - but they arn't he correct number of seconds - e.g. 2 secs mirror lock last click noise maybe 5-10secs after image is displayed.

Also black images are starting to appear if you change ISO settings or exposure length.


Just tried it after changing to nightly and install/update - no difference same error :-(


Ok thanks for the help but I am going to abandon my Indi project till next year. I need to be able to trust whats going on and DSLR on Indi with my Canon 100d is playing ball. Good luck with your project - clear skies


get the following at the end when i fails :
63.917067 ptp_usb_getresp [usb.c:428] (0): PTP_OC 0x911c receiving resp failed: PTP Device Busy (0x2019)
63.917096 camera_unprepare_canon_eos_capture [config.c:450](0): 'ptp_canon_eos_resetuilock (params)' failed: PTP Device Busy (0x2019)
63.917136 ptp_usb_sendreq (2): Sending PTP_OC 0x1003 (Close session) request...
63.917160 gp_port_write (3): Writing 12 = 0xc bytes to port...
63.917265 gp_port_write (3): Wrote 12 = 0xc bytes to port: (hexdump of 12 bytes)
0000 0c 00 00 00 01 00 03 10-99 02 00 00 ............

63.917309 ptp_usb_getresp (2): Reading PTP_OC 0x1003 (Close session) response...
63.917332 gp_port_read (3): Reading 1024 = 0x400 bytes from port...
63.930826 gp_port_read (3): Read 12 = 0xc out of 1024 bytes from port: (hexdump of 12 bytes)
0000 0c 00 00 00 03 00 01 20-99 02 00 00 ....... ....

63.931010 gp_port_close (2): Closing port...
63.932171 _close_async_interrupts (2): canceling transfer 0:0x55083df0 (status 0)
63.932267 _close_async_interrupts (2): canceling transfer 1:0x55080358 (status 0)
63.932305 _close_async_interrupts (2): canceling transfer 2:0x55080530 (status 0)
63.932341 _close_async_interrupts (2): canceling transfer 3:0x55080708 (status 0)
63.932376 _close_async_interrupts (2): canceling transfer 4:0x550808e0 (status 0)
63.932411 _close_async_interrupts (2): canceling transfer 5:0x55080ab8 (status 0)
63.932446 _close_async_interrupts (2): canceling transfer 6:0x55072a30 (status 0)
63.932481 _close_async_interrupts (2): canceling transfer 7:0x55072c08 (status 0)
63.932515 _close_async_interrupts (2): canceling transfer 8:0x55072de0 (status 0)
63.932550 _close_async_interrupts (2): canceling transfer 9:0x55072fb8 (status 0)
63.932585 _close_async_interrupts (2): checking: transfer 0:0x55083df0 status 0
63.932611 _close_async_interrupts (2): checking: transfer 1:0x55080358 status 0
63.932635 _close_async_interrupts (2): checking: transfer 2:0x55080530 status 0
63.932658 _close_async_interrupts (2): checking: transfer 3:0x55080708 status 0
63.932682 _close_async_interrupts (2): checking: transfer 4:0x550808e0 status 0
63.932706 _close_async_interrupts (2): checking: transfer 5:0x55080ab8 status 0
63.932730 _close_async_interrupts (2): checking: transfer 6:0x55072a30 status 0
63.932754 _close_async_interrupts (2): checking: transfer 7:0x55072c08 status 0
63.932778 _close_async_interrupts (2): checking: transfer 8:0x55072de0 status 0
63.932801 _close_async_interrupts (2): checking: transfer 9:0x55072fb8 status 0
63.932855 _cb_irq (2): 0x55083df0 with status 3
63.932890 _cb_irq (2): 0x55080358 with status 3
63.932922 _cb_irq (2): 0x55080530 with status 3
63.932953 _cb_irq (2): 0x55080708 with status 3
63.932984 _cb_irq (2): 0x550808e0 with status 3
63.933014 _cb_irq (2): 0x55080ab8 with status 3
63.933045 _cb_irq (2): 0x55072a30 with status 3
63.933078 _cb_irq (2): 0x55072c08 with status 3
63.933109 _cb_irq (2): 0x55072de0 with status 3
63.933139 _cb_irq (2): 0x55072fb8 with status 3
63.935317 gp_filesystem_reset (2): resetting filesystem
63.935386 gp_filesystem_lru_clear (2): Clearing fscache LRU list...
63.935409 gp_filesystem_lru_clear (2): fscache LRU list already empty
63.935434 delete_all_folders (2): Internally deleting all folders from '/'...
63.935458 lookup_folder (2): Lookup folder '/'...
63.935482 lookup_folder (2): Found! / is 0x55064b30
63.935506 recurse_delete_folder (2): Recurse delete folder 0x55064b30//
63.935529 gp_port_free (2): Freeing port...
63.935549 gp_port_close (2): Closing port...
63.936353 gp_filesystem_reset (2): resetting filesystem
63.936418 gp_filesystem_lru_clear (2): Clearing fscache LRU list...
63.936437 gp_filesystem_lru_clear (2): fscache LRU list already empty
63.936460 delete_all_folders (2): Internally deleting all folders from '/'...
63.936484 lookup_folder (2): Lookup folder '/'...
63.936562 lookup_folder (2): Found! / is 0x55064b30
63.936585 recurse_delete_folder (2): Recurse delete folder 0x55064b30//


Thanks for looking but this occurs across AMD64,RPI3 and UpCore running Fedora 28 ,Ubuntu Mate and Ubuntu.

It also occurs with both my Canon 100d camera's (one mod , one not mod) - not used or connected at the same time :-) !

Even using the command line it does exactly the same - fails above 9.5 secs and repeats capture - "unspecified error" and failure to download. I will see if I still have the log.

This error is just like the one I had over a year ago,diff versions of GPhoto2 and OS, which caused me to go back to Windows.

The cable is only 40cm long and its a Lindy Cromo so shielded !

The only common theme here is the Canon 100d camera - which works 100% on Windows / Apt / BYEOS,

Did your test do long exposures of over 9.9secs (20,30secs) and did you repeat them 3 times one after the other ! And no repeat captures - hence images are over exposed !

What version of Gphoto2 and associated Lib files are you using on your system ?


Clive Stachon replied to the topic 'Shoestring USB-serial with StellarMate' in the forum. 1 week ago

It might be a dirty word (Windows) but have you tried it on Windows to see if it works - might not be the BT


Clive Stachon created a new topic ' Udev rules for USB camera's' in the forum. 1 week ago

On my Fedora 28 set up afer Fedora is updated it reinstalls the mount sharing for my Canon DSLR and I have to do the FAQ DSLR tricks again plus even after unmounting the camera (its Gnome) the permissions for the USB device are wrong and the CONNECT fails.

So I created a new rule to change the permissions to 0666 which seems to work even if I unplug and reinsert the USB camera cable.

However I notice that there are rules (very long) that Gphoto2 provide which just looks,amongs other things, for a PTP device but this seems not to be working on Fedora 28. I have read somewhere that if the rule is too long( 1ms ?) Udev will drop the rule - is this true or is it per line in a rules file !


Update - this method of using the SW Windows App Pro under Wine seems to be working very well - no real problems.

For the next trick I am going to use Udev to create a symbolic link between a TTY por and call it COM1 - doubt it will work but worth a try to remove Ser2net option.

Has anyone tried using Udev to create a COM por for a Wine run program ?????? Did it work


When set to zero in the driver and the camera (I presumed the Driver would set the value but I set it disabled manually anyway) no failure or 2nd capture but image is very very dark even on 12800 over 20secs - and no I didn't leave the lens cap on LOL!

dup Logs - ok wasn't 100% sure so sent it all.

Thanks for looking :-)


some more testing and logs

Also found how you can clear configuration by accident (and not knowing how it works) press save before you have connected as this destroys the .xml file and when the "connect " BUTTON loads THE DETAILS HAVE ALL GONE.

p.s. Cannot Indi/Kstars etc put all the logs in one place (even if you use links) - make life easier

Simple question is Canon DSLR usage a no go as far as Indi is concerned ??

Honest answers please :-)


Clive Stachon replied to the topic 'Cannot launch KStars through VNC' in the forum. 2 weeks ago

You dont need a display or a display adapter ,as Alacant suggested, you just need a Dummy HDMI plug like this - it fools Linux into thinking there is a real monitor connected and so gives you headless platform. I know because I use one with my Up Core - its not perfect as the refresh rate can be seen but it gives you a workable headless set up quickly.

If you can then find a better way great please post one that works for ALL Linux platforms - Holy Grail would be easier to find LOL


more info done on 2nd machine running Fedora 28 same camera - i now no why i was getting a black screen - if gphoto2 fails to download from then on it gets the first image in ram every time. If you watch the back of the camera the figure in the bottom right keeps flashing plus when you switch off the camera it says saving image(n) where n is the number of images stuck in the queue i guess.


here are the logs hope that helps

1. First test using camera with mirror lock enabled and mirror lock set to 1 sec in Indilib DSLR
No errors occur BUT no pictures are created - all black
happens if using fits or Native
tried from 10 secs to 60secs all the same changing iso 100 to 12800 makes no difference

2. Test 2 with camera Mirror lock set to disabled and mirror lock set to 0 in IndiLib driver

ALL captures take 2 attempts but you do see a 1 non black image
No image downloading message is seen as per test 1
same for FITS or Native

During the day images appear and no errors using Test 1 Mad
Camera connected o APT runs and produces as one would expect according to ISO and Exp Time

Ok I might be doing something wrong but what it doesn't make any sense.

Boards is UP Core 2gb / 32gb atom proc running Ubuntu 16.04 and up todate Indilib/Kstars


Hi sorry for not replying had a disaster with kstars field trial - nothing but blank screens and the odd capture restart.

I understand the need a custom driver when using 2 dslr however this does not explain why the settings loaded by Indi change from session to session when I have NOT changed anything and NOT done a save config. Its seems to be around the image info which corrupts the X,Y,UM etc settings and you cannot using SET to change and "Clear DSLR" (which I assume should ask for image X,Y and sensor details again. As I say it does not happen everytime and I cannot see anything else (disc problem etc) thats causing that.
Example last night was a failure but reconnected the same kit/camera in house and bingo I can take images (even up to 40secs) of a in door image - I am investigating if its a power problem (Field trial uses 12v 100amp Hr battery and Dc-Dc) so for now thanks but I am going back to the drawing board and do something else - Star gazing :-)


If you set the Indi "Mirror Lock Code" to 0 and the Camera settings to "No Mirror lock" iNDI dSLR ALWAYS fails over 10 secs and automatically retries when it works ok - so takes 2 goes to take 1 exposure PLUS the image is over exposed.

If I set the Mirror Lock Code to 1 and set Mirror lock enable in camera it takes exposures over 10secs correctly without a retry.

The earlier attached logs above clearly show this.

Hope that makes sense ! :-)


Yep the problem is you cannot set "No Mirror Lock" - this should be what happens when you set the value to Zero but doesn't work so if you set the setting manually on your camera Indi Dslr Driver complains and runs the exposure twice as the first one fails to download (also shown by "recording image" when you switch off the camera which can only be removed by taking out the batteries). Change the Mirror Lock setting back to 1sec and all is OK.


Ok thanks for that.

But what is the difference between save ,load and default.

Under normal usage on other software the work flow would be
1. Save - any changes made to the Dslr configuration under Indi Devices are saved and will be loaded next time.
2. Load - load the last saved config
3. Default - load the hard coded settings as held by the Indi Dslr driver.

So if I dont use Default or Load configuration then the settings that appear in Indi Devices should always be the same as the last one "Saved" !

Is that not correct ?



3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!