Take Control Of Your DSLR With PiXPi

If you’ve ever tried to take a picture of a fast moving object, you know how important timing is. You might only have one chance, and if you hit the shutter a bit too early or too late, the shot could be ruined. Past a certain point, no human camera operator can react quickly enough. Which is exactly why [Krzysztof Krześlak] created PiXPi.

In the past we’ve seen high-speed flashes designed to “freeze time” by illuminating the scene at the precise moment, and while PiXPi can technically do that, it also offers a few alternate methods of capturing that perfect moment. The idea here is to give the photographer the best chance of getting the shot they’re after by offering them as many tools as possible.

Essentially, PiXPi is a microcontroller that allows you to orchestrate your DSLR’s trigger, external flashes, and various other sensors and devices using an easy to use graphical programming interface from your smartphone. So for example, you could program the PiXPi to trigger your camera when it detected a loud enough noise.

But the device also allows you to be a bit more proactive. Rather than sitting back and waiting for a signal to fire off the camera, the PiXPi can directly take control of the action. As an example, [Krzysztof] has created an electronically triggered valve which can release a drop of liquid on command. Using PiXPi, the photographer can quickly put together a routine that triggers a drop, waits the few milliseconds it takes for it to hit the target, and then snaps a picture.

The goal of the 2019 Hackaday Prize is to develop a product fit for production, and naturally a huge part of that is having a well thought-out design. But if you’re ultimately looking to sell said product, it’s also very important to keep the needs of the end user in mind. To that end, we think [Krzysztof] has done a great job by not only making the system very flexible, but keeping it easy to use.

32 thoughts on “Take Control Of Your DSLR With PiXPi

  1. I have made one of these but the problem is the undocumented, variable time it takes for modern DSLRs to actually operate the shutter after they get the trigger. Nikon are fairly stable and fixed around 300 ms but Canon can be anywhere, seemingly at random between 100 and 400. Other makes seem to be anywhere in between.

    I toyed with the idea of listening for the shutter mechanism but that doesn’t let you start things off before the shutter.

    If anyone has a solution I would love to know it.

      1. That still wouldn’t remove the issues between the time delay between the trigger signal being sent and the photo being taken. (Shutter lag)
        And using a camera in sutterless mode just operates it in rolling shutter, which introduces other issues which are not good for fast moving subjects.

        The easiest way to do this is to control the exposure with strobe – open the shutter in a dark room, trigger the strobe (which usually operates at a tens of thousandths of a second duration) then close the shutter.

        1. If you have a strobe that “operates at a tens of thousandths of a second” then you must be firing off an old-skool flashbulb (or one of those new weak-ass LED flashes). The slowest strobe I ever measured was a Balcar 1200 W-s pack, at 8 milliseconds. My Metzes (50-80 W-s) are next, at 3 ms. Most hotshoe flashes and internal camera flashes come in around a millisecond. When operating in ‘auto’ mode, where the exposure is terminated when sufficient light has arrived, most hotshoe flashes (including those monster Metzes) get down to sub-100 microseconds at close range.

          If you want less than 30 microseconds or so, you need to get exotic: high voltage air-gap flashes or (if you’re OK with low light levels) high-speed LED flashes like the Vela One.

          1. That’s not entirely accurate – most modern hot-shoe flashes (speedlights) use a capacitor discharge which they ‘quench’ early to reduce the strobe’s brightness and, because it’s coming from a limited charge source, the brightness reduces greatly over time, which means that, if you reduce the power output (say going to 1/16th) then you get significantly reduced timing.

            Using the data someone else gathered here:

            For full power a Nikon SB-24 takes 1/213th (about 4.7ms), but, drop it to 1/16th power and it only takes 1/5,208th of a second (less than 0.2ms).
            With a Canon 580EX, you can get all the way down to 50.4us without costing the earth. The tradeoff is that it’s at 1/128th power.

            While they’re not going to be as bright as the ‘exotic’ (read: expensive) solutions, they’re a good solution if you’ve either already got them or can work within their limitations (one can even sync several cheap strobes together to increase the light again if you need more illumination).

    1. The standard way of dealing with shutter lag is to open the shutter prior to the event, then fire a flash at the appropriate instant. This is what the PixPI and Camera Axe and many other similar devices do already.

      1. Yup, and many devices have additional controls so they (1) turn off the room light (desklamp on a relay), (2) open the camera shutter on bulb mode (3) wait a few seconds for the vibration from the mirror to end (4) do the thing and fire the flash(s) (5) close camera shutter (6) room lights on

        Pre-releasing the mirror I believe eliminates the erratic shutter lag?

        1. Yup, just like krzysztof demonstrates in the video.

          As others have said here, most of the indeterminacy in the shutter delay is the autofocus operation. Turn that off and set manual exposure, and the shutter delay becomes constant.

          You’d think that with modern live-view cameras there would be a way to lock up the mirror indefinitely, and trip the “shutter” (i.e., begin an exposure) a fixed (ideally zero) time after the trigger. I’d love to find one that offers that. It seems, though, that consumer-grade cameras want to finish their current live-view video frame and do some other fumbling around for many milliseconds before the exposure actually starts.

        2. exactly this you can also do with PiXPi I already tested some standard relay module from ebay ;)

          But in past i also came with another idea as it was not handy to connect relays to wires which I already got in room which i’m using for photos(basement basically :p )
          To overcome this without any tweaks in electrical installation I connected light sensor and sound sensor to pixpi and created controlling sequence in such way that it will wait until light is turned off and then, shutter was opened after detecting sound flash was triggered and it was done, so it can be one of example of elasticity of this device as when i was designing it I did not had such use case for light sensor in my mind but i was able to accomplish it, just by replacing controlling sequence from android app ;)

    2. And for what it’s worth, I measured a Pentax K100D to be 105 milliseconds between shutter press and start of exposure (i.e, between the remote contact closure and the hot shoe contact closure) every time (within my measurement accuracy of a millisecond or so). I have not repeated the measurement on my later bodies, because I have not noticed variability in shutter lag on them either.

  2. The article certainly leaves a lot of questions hanging. The “Pi” name first made me think this was based on a RasPi, but that is not the case — just “marketing” and I guess he should get points for that. What is that big chip in the middle of the board? — that is my first question. Next is whether this uses a USB tether to control the camera or is it using a remote release cable. I guess I will have to dig some to find out what is really going on here.

    1. This is a Hackaday Prize entry, so the point is kind of to go to the project page and interact/follow along with it as it progresses through the contest. All of your questions, and any others you might have, will be answered there.

    1. Yep. There are many commercial offerings that do this and much more, for example StopShot by Cognisys has been around for years. I’m not sure what the hack is with this project. It doesn’t seem to do anything different that wasn’t already done years ago.

      1. Oh yeah we should raise the bar for articles on this site. I recommend we take inspiration from the patent office. Sufficiently novel. No prior art. Not obvious to a practitioner skilled in the art. Only then should it be allowed on HaD. And we also need a disput system to take down any articles that can be shown not to comply. HaD will be so awesome.

      2. I think there’s plenty of value in showing people how to DIY the equivalent or better of a commercial product. Something that was done 5 years ago might not take advantage of newer technology that might make the whole thing easier to use such as the cell phone interface to control it.

  3. I bought these and took the inside out:

    Then fitted this. This pic is an early one that has been seriously messed with during development, several iterations since then. It has two inputs and four outputs, two hotshoe and two jack plug. It runs a web page on which you can set delays for all inputs and outputs

  4. As pointed out above … the general problem with all these approaches (there are so many of them I lost track) is that USC and Disney can be quite picky about following up on their Lightstage patents.

  5. Hello all,
    first of all…wow thanks for posting my project here :)
    I’m happy to see that lot of discussion is going on here I feel obliged to share some insights.

    @John Dickinson regarding shutter lags i was also struggling with this problem and i discovered that waking up of camera can help greatly here. Waking of camera means trigger focusing(manually it will translate to pressing to half shutter button, there’s also “wake” block for pixpi app, you can say that camera is woken, when for example lcd/icons in viewfinder are iluminated ;) ). after when camera is wake shutter lag seem to be very repetable and for Nikon D600 which I used was rated precisely at 50ms and when camera is in sleep mode it can float, for mentioned Nikon it was randomly between 300-600ms.
    Anyway using shutter to catch some good quality photo can be tricky, even highest shutter speed can give some motion blur and also you will need a lot of light, but I used it when I created this “demo movie” and in photos which you will see in this movie you will not see some superior quality ;), so generally just for taking photos it’s better to use high-speed method photography method which relies more on flash triggering in right moment instead of shutter.

    I saw some comparsions to products already available on market and indeed there are some general similarities as in general high speed photography is not a new invention, but there are also some significant differences, mainly I mean that this device can be freely configured/programmed using graphical programming interface on smartphone app(it’s powered with Google`s blockly library) combining it with changeable modules(connected to ports which have configurable direction :p ), high speed photography is not an limit here as i currently working on modules which utilizes stepper motors(for sliders/rigs/rotation table) it gives more freedom comparing to that what is already commercially available i was inspired a little by PLC controllers which are commonly used in industry, so maybe it’s something like PLC controller for photographers.

    Also another thing is that I heard opinion that rarely creating of product is about creating a breakthrough, it’s more often on making something better, so in such case, it’s a good sign that you can see spot some similarities ;). Think about raspberry pi, it’s awesome, but are they inventors of computer? ;)
    Some similarity of “PiXPi” name to “RaspberryPi” was spotted ;), yes it’s intentional, but reason behind it it’s more sentimental than commercial, it’s tribute for raspberry as first prototypes was based on it and i think if raspberry pi will not exists, this project will not exists too ;), currently it’s powered by VoCore2(which btw. is also great;) ), but still running linux, also boards dimensions are very close to raspberry dimensions.

    There was question about usb connection to camera, it’s currently not available(there’s only uart-usb interface for accessing vocore’s serial terminal), but it’s something on which I want to work in future as it will extend possibilities heavily(control of more than just shutter, but all camera parameters and also photo transfer), currently i know this is possible as i already made a prototype with [host]USB port in place of one flash port and it seem promising, but on another hand i know that it will increase complexity of software, so currently I focus more on full utilization of possibilities which presented hardware offers, but it is something that will be exiting to do.

    So thanks all for sharing you opinions, soon I will publish more updates on project page, so just follow if you are interested ;)

    1. Yes I to discovered that the lag stabilises, provided focus is on manual, on Nikons (and some others) when half pressed The jack plugs are three wire and the software does that. It will also drive a stepper motor for macro shot stitching. All in all you can get some cracking pictures with it, sadly I don’t have any. I do not really have that much interest in photography, I made them for a friend a few years ago and enjoyed doing it. :)

      There is however no way to get round the need for an expensive flash if you want to go really fast.

      1. exactly one pin on jack is to focus, second to trigger, third is common, so just shortening focus to commons pin for 1ms do it’s job.
        Regarding expensive flashes, you don’t necceserly need some special flashed, just this compact’s one will do it’s job pretty wel, I’m using nikon sb-900 as i already got them, but cheaper alternatives fo ex. Yongnuo will also perform, set to low power they give quite short pulses.

          1. Don’t mix & match your flashes though: the lag from trigger-to-flash is different for different models, and causes a double image: dozens of microseconds difference.

            Avoid the new modern all-digital breed too: At least the cheap ones I tested have several microseconds of jitter in that trigger-to-flash time too: it acts like the trigger signal is being polled by a slow processor, and it just gets around to responding to the trigger when it gets around to it. Annoying.

            You can reliably get a short, bright flash by replacing the big electrolytic capacitor with a much smaller film or ceramic one (but watch the ESR), reducing the loop inductance, and increasing the flash voltage. You can usually get away with almost double the voltage before it self-fires. It’s not exactly a hotshoe flash any more, any you’re actually better off scratch-building it, but that’s the price of doing this stuff.

    2. Agree, incremental improvements are great! The control software is the key to this project. I built something years ago, in the days before we could add BLE and WiFi to microcontroller projects, and quickly lost interest as configuring it was a pain, and writing something easy to configure was clearly a big job, if not impossible using a 2-line LCD and a few buttons!
      The programmable interface makes this very nicely flexible.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.