Triggertrap Mobile 1.0.3: Need for Speed


I know what you're thinking... It's only a few days since v1.0.2 came out... What's going on? Well, there were a few more things we wanted to include, and it turns out that v1.0.2 actually introduced a bug as well. Luckily, it's easier to fix problems in software than in hardware, so Matt has been beavering away over Xcode the past few days, and we're now happy to announce that v1.0.3 (codename Peregrine) has been submitted to Apple for approval. In our experience, it'll take around 4-5 days for it to be approved, so it'll hopefully be available for download towards the end of next week.

Changes in v1.0.3

Screen Shot 2012-06-08 at 15.16.13
  • Bug fix: Further changes the algorithms we are using for controlling the Triggertrap Dongle - this was a bug that was inadvertently introduced in v1.0.2.
  • Bug Fix: Fixes a bug where the first photo taken with the Triggertrap in a particular session was delayed for about 100-150 ms.
  • Improvement: Make it easier to select precise values in the fine-selection dial. 
  • Improvement: Calculate how long a timelapse will take once it is assembled. 
  • Improvement: Improved the triggering speed of Triggertrap Mobile by 25% (see below).

Speeding up Triggertrap Mobile

In v1.0.2, we fixed a bug that meant that Nikon users were now able to use the lag-o-meter. When Matt was improving the code, he came up with an idea: It might be possible to re-write part of the code to make the Triggertrap Mobile much, much faster.

So we did.

And we have some great news: We were able to make a drastic improvement.

We created a special test bench (using a prototype Triggertrap Shield for Arduino) to measure the speed of the Triggertrap Mobile. The improvement is pretty astounding.

Version 1.0.2 triggering speed, tested with a Canon 550D / T3i

  1. 382 ms (the first exposure was always slower - this is fixed in v1.0.3)
  2. 363 ms (in 99% of cases, this exposure is faster. In this case? Not so much)
  3. 194 ms
  4. 177 ms
  5. 163 ms
  6. 213 ms
  7. 152 ms
  8. 168 ms
  9. 160 ms
  10. 182 ms

As you can see, we have two issues here: For one thing, the first few exposures are much slower than the others, but if we ignore them, we still have an average of 176.1 ms using v1.0.2. Given the other measurements we have done, we knew that this could be improved. Especially frustrating is that even in the faster exposures, things aren't very consistent: Varying between 212 and 152 ms is a pretty big spread.

And so we set out to improve two things: Consistency, and triggering speed. In the process, we (I say we... I mean Matt. I cheered him on and occasionally brought him more coffee) completely re-wrote the Triggertrap Mobile triggering functions. Compare those numbers with the ones measured on v1.0.3, after we did our re-vamp:

Version 1.0.3 triggering speed, tested with a Canon 550D / T3i

  1. 96 ms
  2. 136 ms
  3. 140 ms
  4. 141 ms
  5. 147 ms
  6. 114 ms
  7. 116 ms
  8. 132 ms
  9. 155 ms
  10. 135 ms

As you can see, these numbers are quite different on two levels: For one thing, there's much smaller variation, but also, it is significantly faster on average: an average of 131.2 ms using v1.0.3! Which, for the mathematically inclined among you, is a speed improvement of just about 25%

Making things go even faster

On my Canon camera, there's an additional step I can take: Even when the camera is set to manual focus, and (of course) to manual exposure, there appears to be a delay in how quickly the camera reacts to shutter signals. So, if I make sure that the camera is as ready as it can be to take a photo (by setting it to Live View mode, and half-pressing the shutter on the camera before running the Lag-o-meter programme to test the speed), I'm getting even better speed metering:

  1. 85 ms
  2. 99 ms
  3. 93 ms
  4. 88 ms
  5. 100 ms
  6. 69 ms
  7. 69 ms
  8. 88 ms
  9. 92 ms
  10. 87 ms

... For an average of 87 millisecond response times!

Comment