Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for bulb capture over SNAP Port #617

Closed
rootdarkarchon opened this issue Jun 11, 2018 · 7 comments
Closed

Support for bulb capture over SNAP Port #617

rootdarkarchon opened this issue Jun 11, 2018 · 7 comments

Comments

@rootdarkarchon
Copy link

Hello,

the original EQMOD allows bulb capture for cameras that don't have BULB over USB utilizing the SNAP port on the mount (EQ6-R, AZEQ6). Would it be possible to implement this somehow so I could utilize shooting bulb with my D5100? Currently I am running a Windows based setup with software where I can set up bulb over telescope mount and download the images separately. I would love to switch to a Linux based approach, this USB issue is one of the reasons I cannot.

A suggestion would be exposing the SNAP port functionality as a ttyUSB device so it can act as a fake serial shutter, so the integration with GPhoto DSLR functionality will be easy.

@vdelord
Copy link

vdelord commented Oct 10, 2018

Hi, I just bought an EQ6-R too and being able to trigger my camera sequentially through the mount and snap port would be really nice. On my setup I don't download the photos until my shooting session is done. It would be nice to remove the need of a link between my raspberry and the camera.

@geehalel
Copy link
Contributor

Hi,
I've implemented snap port control some months ago, it is on my repo in the eqsnap branch. I've just resynced it with the current libindi repo so you may test it with your mount. There is a small python script in the repo (eqsnap1.py) to launch at startup which will allow the gphoto driver to control the snap port as if it was a serial port (/tmp/eqsnapport1).
I would need the mount code for the EQ6-R as snap port control is only activated for EQ8, AZ-EQ6 and AZ-EQ5 (2 ports for the AZ-EQ5, not sure for others).

@Blueshawk
Copy link
Contributor

Blueshawk commented Dec 23, 2018

Woot. I did a search after getting an EQ6-r myself, after realizing the snap port might be useful for my non tethering k-50 and found this. Looks like a good start. :D I think I saw the protocol around somewhere. Hopefully somebody will find it soon. If not, sniffing the serial line from the synscan controller to the mount may show the needed command to trigger it.
@vdelord I've been using a flashair card to get data previews from a piggybacked camera(that k50) that is currently using an external intervelometer to trigger and set exposure.

@Blueshawk
Copy link
Contributor

I noticed a shutter port in indi_pentax_ccd(and I think maybe gphoto_ccd?) Would this be the other end of that train? My eq6r reports in indi status as an azeq6, making me think the same code from that driver might be worth a try. Aren't most of them using synscan protocol? My eq6r came with a synscan control pad but I'm using a direct serial-usb cable now. I might tinker with this if I get time but my plate is pretty full right now.

@geehalel
Copy link
Contributor

geehalel commented Jan 7, 2019

Yes the shutter port comes from gphoto_ccd and is the other end to use. When using indi_eqmod snap port it will be a virtual port managed by the python script I referenced above.
As the EQ6-R reports as the AZ-EQ6 you may have a try if you want. I'll make a pull request after someone tests it. Thanks.

@knro
Copy link
Contributor

knro commented Mar 5, 2019

Hello all, how is this feature coming along? Was it tested by other in EQMod with @geehalel branch?

@knro
Copy link
Contributor

knro commented Sep 18, 2019

Thanks for the report. Please open this issue in the 3rdparty repo issues --> https://github.com/indilib/indi-3rdparty/issues

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants