Jump to content

Canada's top-tier Telescopes & Accessories
Be as specific as possible when reporting issues and *ALWAYS* include the full version number of the application you are using and your exact *CAMERA MODEL*
  • 0

D5100 bulb capture through SNAP port



Hello everyone,

I have a small question, which I am unable to solve, somehow. 

So, first of all, I'm driving an EQ6-R with EQMOD2 and PC-Direct mode. The EQ6-R has a SNAP port which can easily control the D5100 (successfully tested with the hand controller). It is connected through a COM port to my computer. According to SynScan specifications, one pin on that COM port is for shutter capture and release. EQMOD2 can also control the shutter (at least rudimentary).

Now, is there any way I could skip the whole extra serial cable ordeal and utilize the configuration I have already? It would save me some hassle. I tried using the same COM port as ASCOM, but of course that doesn't work when EQMOD is connected. Neither does it work using the COM port as Relay.

I'm a bit stumped. This seems like such an elegant solution, controlling the camera through the mount and ASCOM. Is there any possibility that this feature can be included in BYN? Or am I overseeing anything?



Link to comment
Share on other sites

  • Answers 10
  • Created
  • Last Reply

10 answers to this question

Recommended Posts

I think you're misunderstanding the situation. The d5100 cannot trigger bulb shutter over USB, so you need a shutter cable that's acting like an intervalometer anyway. How is that different than using the snap port? I still would use the USB connection that's necessary for everything else.


OKAY - I solved the issue myself.

My solution which requires no dedicated USB to Nikon shutter release cable and will work with every EQMOD mount that has a SNAP port and a simple Nikon shutter release to 3.5mm cable:

Using comm0com and creating two virtual COM devices (COM3 and COM4 for me), set BYN to COM3 device. Write an application that listens for CTS signal on the virtual COM4 port and triggers the SNAP port (SNAP2 for me) using a command to EQMOD (:Ox1 or :Ox0, x being 2 in my case).

Proof of concept done and working:



I can provide the application that does this and more exact instructions if anyone's interested.


Further proof of concept:


Settings in com0com and BYN:



So in the end, if you plan on using BYN on a camera that can't engage bulb mode from USB and have a mount with an integrated SNAP port which is supported by EQMOD (so AZEQ6, EQ6R, I think AZEQ5) you can use a normal shutter release to the SNAP port which will be triggered by BYN and have no need of building yourself a RS232 to Shutter Release cable or DSUSB.

Link to comment
Share on other sites

The ASCOM telescope interface standard does not support camera shutter control. So while EQMOD may support a shutter control command, it does not appear to be available through EQASCOM. Even if there was a configured ACTION in EQASCOM, BYN would likely need to be modified to supported it.

If you want to use BYN to control your shutter for BULB exposures, then you must have a compatible serial cable connecting the PC and the camera's remote shutter port. In addition, BYN must be correctly configured to control it.

Link to comment
Share on other sites

The SNAP Port implementation is simply another version of an Intervalometer or Remote Shutter.  All it can do is trigger the Shutter to Open for a length of time dictated by how long that COM Port Pin is actuated.

BYN does so much more - it actually "Talks to the DSLR".

If the SNAP Port were supported in BYN, the Image would only get stored on the DSLR and there would be no ability to Frame&Focus or Review your Exposures and Check Battery Status and all the other Features which BYN brings to the game.

Link to comment
Share on other sites

I understand what your solution is doing and it seems way over-complicated to me. Instead of BYN controlling the shutter directly with a DSUSB cable you are using two additional applications (one of them a custom program) just to avoid having to purchase a cable.

I hope that it is reliable enough for you.


Link to comment
Share on other sites

I'd love to not over-complicate things if I could just send a raw CommandString via ASCOM to my mount (O21 and O20 respectively) without going over the whole RS232 ordeal. But BYN does not support that and I don't think it will ever support it. Having an additional USB cable running from my DSLR to my laptop is one additional USB port blocked by a useless cord, and the DSUSB is not reusable if I ever decide on getting a proper CCD or CMOS. Since I don't know how long I'll keep the DSLR for shooting this would be wasted money in the end, if my solution works just as well. 

I now spent a few hours of finding out how stuff works and programming instead of spending money on a cable, that could break and is more effort to solder or to buy. Aside from having a reliable driver running and a small application in the background, I fail to see the downsides. BYN is still controlling the shutter directly by passing the rs232 information to the mount which triggers the shutter, with the mount being a passthrough of information between BYN and the DSLR.

From all I've heard about the reliability of DSUSB or self-made shoestring cables this seems like a more reliable solution, since it's less likely to have a hardware failure. I will report back once I've actually managed to use it in the field.

Link to comment
Share on other sites

ASCOM is all about hiding device differences from client applications.  The Platform tries hard to make all mounts appear to behave the same. Sending arbitrary command strings would break that model. While I have no say in the direction that Guylain and Chris choose to take their products, I hope that they stay hardware-neutral for ASCOM devices.

The DSUSB cable and your SNAP port cable are very similar in function. Their reliability should be similar.

My criticism is that you have extra, unnecessary points of failure in your solution. Your image capture process now relies on your custom app AND EQMOD when it does not need to. I hope that it works for you.


Link to comment
Share on other sites

CommandString is an official method by ASCOM provided through the API, but every driver can implement it as they want, or rather with the commands they want, but documented, though. The command SNAP1,1/0 or SNAP2,1/0 is provided by the EQMOD driver as a CommandString to trigger the port. My application can send arbitrary CommandString implementations to the ASCOM CommandString interface, should the implementation of SNAP change (configurable).

I understand the point of failure in software, but I'd rather have the point of failure in software than in hardware, since I trust my coding skills more than my soldering skills. And I'd rather not spend money on something that can be solved with the hard- and software at hand. If EQMOD is not running, I won't be imaging anyway. Having a small com2command wrapper running in parallel is not that big of a deal, really. All it does is listen to CTS/RTS and send either SNAP2,1 or SNAP2,0 to the ASCOM CommandString interface. It's functionally robust and cannot break. I hope it works for me too and maybe others will find this solution adequate for themselves too.

In the end, hardware or software, there are points of failure in any case because Nikon wasn't able to expose the BULB mode to USB. Thanks, Nikon.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...

Important Information

This site uses cookies to offer your a better browsing experience. You can adjust your cookie settings. By closing this banner, scrolling this page, clicking a link or continuing to browse otherwise, you agree to the use of cookies, our Privacy Policy, and our Terms of Use