High speed Photography

oracacle

Senior Member
I was looking around the 'net for random things, as you do when I came across this: http://letsmakerobots.com/node/22058

Seemed like and interesting project for my own use, however I can not see for the life of any mention of response time. So I did little testing with a 28x2 and an old micro switch I had here. I used the santa scope to crab some readings at 16mhz (as seen in the attached chart, CH1 is switch, CH2 is an output set to go high), so even at that modest clock speed response time should not be an issue.

the sound detection was done with a circuit found here: http://www.picaxe.com/docs/picaxe_sound.pdf. would the delay in this circuit that is going to be appreciable by comparison to the picaxe response time.

is it also possible to have the output of the sound detection circuit connected to both and ADC and b.0 so that fine adjustment (to compensate for environment) can be made while using the high speed response of the hardware interrupt?

test code

Code:
[color=Blue]setfreq m16[/color]
[color=Black]init:
      [/color][color=Blue]let [/color][color=Purple]w0 [/color][color=DarkCyan]= [/color][color=Navy]5000
      [/color][color=Blue]hintsetup [/color][color=Navy]%00010001
      [/color][color=Blue]setintflags [/color][color=Navy]%00000001[/color][color=Black],[/color][color=Navy]%00000001 [/color][color=Green]'int0 b.0
      [/color][color=Blue]let [/color][color=Purple]dirsb [/color][color=DarkCyan]= [/color][color=Navy]%11111110[/color]
[color=Black]Main:
      [/color][color=Green]'do stuff here
      
      [/color][color=Blue]goto [/color][color=Black]main
      [/color]
[color=Blue]interrupt:
      high b.7 
      pause [/color][color=Navy]500
      [/color][color=Blue]low b.7
      pause [/color][color=Navy]500
      [/color][color=Blue]let [/color][color=Purple]flags [/color][color=DarkCyan]= [/color][color=Navy]0
      [/color][color=Blue]setintflags [/color][color=Navy]%00000001[/color][color=Black],[/color][color=Navy]%00000001
      [/color][color=Blue]return[/color]
 

Attachments

hippy

Technical Support
Staff member
I cannot see any reason not to connect the sound sensor to an analogue and digital input at the same time though with the caveat that it is often a recommendation to never feed an analogue signal into a digital pin.

The latency time shown looks to be about 100us which seems about right at 16MHz. Running at a higher operating speed will improve that, as may polling rather than interrupting, though an interrupt would likely be needed if you do need to loop to take ADC readings.

As to latency in the sound detect circuit I have no idea and there will probably also be some latency in triggering the flash and the flash going off.

Depending upon what you want to achieve it may be easier or better to do it entirely in hardware.
 

oracacle

Senior Member
Later in the project I would like to add in variable time delays, and strobe to multi expose a long exposure - a lot more testing is needed at this point
I would have thought that an interrupt would have been faster than polling (presume you mean an if statement loop here).
As for ADC I could add a switch in there to stop it being too much of an issue.

As it happened I actually am thinking about having the sound circuit in a small enclosure to, so could be used as a standalone (also means interchangeable devices for light or other detection devices).
I will order some hardware later on when I am not so tired before I set anything in stone. I will also test other ways of receiving the input and see what I get when I get up this evening up this evening.

Although being able to capture a bullet leaving the muzzle of a gun would be nice, its not mandatory, running some maths and with the current delays, presumed bullet speed of 550m/s, mic 10cm from muzzle, the bullet would have travelled 24.4cm. the closer the mic is to the source of sound, the faster the response should be no matter the distance of the camera from the object. moving the mic just 5cm further away would increase the distance to 32.5cm, with the camera 1m away
 

hippy

Technical Support
Staff member
You might be right that polling isn't quicker than interrupt. I am not sure anyone has measured it and compared the two. I neglected to consider polling requires extra processing to determine the activation has occurred whereas that happens automatically with the interrupt handling.

The problem will be if it's all over by the time the event has occurred, is detected, causes the trigger and flash. The usual method to overcome that is to trigger on some pre-event to the event being captured. I am not sure what sort of times we are talking about. There has been past discussion on high-speed photography which may give some answers on feasibility.
 

AllyCat

Senior Member
Hi,

Firstly, bear in mind that the DP/PCB/Santa 'scope only displays "real time" signals down to 0.5 ms/div (0.2 for a single trace); displays below that are sampled and can produce "misleading" results. Also, for the type of signals you may be measuring, download the very latest version of the software (v1.0.9 dated yesterday) from Womai's dpscope/pdamusician website, which fixes a "display intelligence anomoly" of previous versions. ;)

AFAIK interrupts in all PICaxes are actually polled, but by the Operating System rather than the user. So the interrupt latency depends on the particular instruction being executed in the "main" program. If it's a Pause, then the interrupt can be very fast, but it can be very slow with a "blocking" command. Then, there's the complication that some of the "complex" (and slow) PICaxe commands are created by the Program Editor from sub-elements, so I believe the interrupt may be faster than the execution time of a "line of code". I don't know how long the "longest normal" command takes to execute (it's a topic I was going to raise myself), but a RETURN (from subroutine) takes over 2 ms (with a 4 MHz clock).

The audio circuit you showed has a feedback time constant in the first stage of 100 us (100k * 1n) so the gain will fall above just a few kHz. Similarly, the output "integrator" (or low pass filter) has a time constant of 47 us, but only charged during part of each audio cycle. So perhaps the audio circuit will respond in "a millisecond or so".

Overall, many of the elements might be around a millisecond: the time for sound to travel (in air) 1 foot, PICaxe interrupt latency, audio detection time and perhaps the electronic flash delay/duration itself. That's probably good enough for the "breaking / exploding" type of picture, but a bullet itself will probably have travelled a foot or more.

Cheers, Alan.
 

fernando_g

Senior Member
Back in 2005 I also built a similar sound-triggered flash circuit, which was later published in the February "06 issue of Nuts & Volts magazine. It relied upon on opamps and CMOS logic though......

One of things one becomes aware quite quickly is that sound travels at aprox 1ft/sec. Which means that by moving your microphone's position, significantly different results will occur.

How fast does the flash itself triggers? If it is one of those simple, trigger to ground flash units, it is in the order of 10 microseconds or less. I measured that by using a photodiode in reverse photocurrent mode (for fastest response), and measuring on a scope the time between the trigger signal and the photodiode's response.
 

oracacle

Senior Member
I have ordered some bits for testing and alike (its amzing I went for a few bits and bought £60 pounds worth), I will see if I can measure the difference between the to different input types now.

also speed of sound is 340m/s, electromagnetic wave front propagation in wire is around the speed of light 299792458m/s, a slow muzzle velocity is 550m/s. so with a presumed input and process delay of around 0.00125s the bullet would have travelled 0.6875 meters if I were to detect the projectile leaving the barrel.

as it currently stand the little spread sheet that I have made up which takes into account the distance of the mic from the source of the sound (presume muzzle) the speed of wave propagation and distance of the camera I can quite accurately determine the distance of the bullet from the muzzle.

mic distance: 10cm
camera distance: 3m
input delay: 0.00125 (from what has been said here)
result: 84.93cm

Edit:
Well ran a quick test at 16mhz for interrupt vs. an if loop, see attached chart. channel1 was used triggered from the switch in both events, blue and red lines are for interrupt test, green and purple are for polled test.

This was done with the dpscope download from the picaxe site as the download for http://www.pdamusician.com/dpscope/downloads.html did not detect the PCB scope

polled code
Code:
[color=Blue]setfreq m16
let [/color][color=Purple]dirsb [/color][color=DarkCyan]= [/color][color=Navy]%11111110[/color]
[color=Black]Main:
      [/color][color=Blue]if [/color][color=Purple]pinb.0 [/color][color=DarkCyan]= [/color][color=Navy]1 [/color][color=Blue]then
            high b.7
            pause [/color][color=Navy]500
            [/color][color=Blue]low b.7
            pause [/color][color=Navy]500
      [/color][color=Blue]end if
      goto [/color][color=Black]main[/color]
 

Attachments

Last edited:

AllyCat

Senior Member
Hi,

Did you download the correct program from the pdamusician site, the "Santa" (PCB) scope needs the software for the DPScope-SE ? I believe that both 'scopes suffer(ed) the same "display anomoly", but only the -SE version has been fixed at this time (files dated 21/10/14).

I'm not sure what your graphs show, but bear in mind that they are just joining "spot" samples with straight lines. Also, the interrupt latency will depend on when (in the polling loop for example) the event actually occurs. The scope's persistence mode can be useful to show the "envelope" of the data transistions.

However, your figures seem plausible; I suspect the greatest delay may be through the audio amplifier itself.

Cheers, Alan.
 

oracacle

Senior Member
I downloaded the SE version, the SE version is what I managed to download from picaxe too.

the other primary delay will be with the flash, and for that matter flash duration. the flash duration can solved using an air gap flash.
after watching this there maybe other ways that the sound can be detected that is faster, I have a small peizo here (the type you glue to a surface), maybe a transistor will be need to boost the gain to allow it to be used with a digital input but should in theory be faster than 3 transistors etc.

as far as I can tell, the charts show around 0.0001-0.0002 second delay for interrupt. and around 0.0006 second for an if loop poll to be processed. as far as I can tell the results are always around the same, with the interrupt consistently faster

even if the picaxe does take 0.002 second to respond its still plenty fast enough for most instances that it will be used in (550m/s * 0.002s = 1.1 meters). Even though it would be nice to go that fast, the cost of things like air cap flash guns, and finding a range that is willing to go along with some hair brained plan cooked up in the small man cave by a introvert that only interacts with real people when needed is very unlikely.

I suppose this project can migrate to something like duino if higher speeds are needed and the delays on other parts of the system can be negated
 

oracacle

Senior Member
its quite a lot when we are talking thing moving faster than the speed of sound,
on a side note I did find something called camera axe based on an arduino uno. it is able to use sound but am not sure how fast it is, or for that matter how they interface with it. there are some little thing around the net that suggest the adc on arduino can be made to be as little as 16 microseconds (http://forum.arduino.cc/index.php/topic,6549.0.html). however my skill set with that system is rather limited, and this project is going to be touch too much to learn it on for a minute (I freaking hate libraries too).

I have thought about dedicated ADC IC too, but have only just started there. however during my research into the camera axe I found that they use a 74hc4050 buffer, but I cant view the schematics they have posted (http://www.cameraaxe.com/files/ca5/eagleCA5Shield.zip originally posted here http://www.cameraaxe.com/builders-guide/), I would be very grateful if some one could post a copy if they have better luck extracting it
 

Dippy

Moderator
Those pictures are really impressive - even the Mick Jagger impersonation :)

How will an external ADC help? You still have to transfer the data and process it which takes time.
If you code PICs (compiler) you have access to much faster ADC and processing.

If you can't get the original (and impressive) PICAXE information then it may be worth looking at using more hardware and less software to give you faster response times.
i.e. leaning towards fernando's method. Or comparator?
What are you hoping for in terms of response time? Keeping in mind the speed of sound and micropohone response.

I'd look into a bank of LEDs rather than a flash tube.
 

oracacle

Senior Member
I would like to go as fast as possible while being able to add variable delay time and multi exposure control, hence the adage of a processor

My current flash is a 95 LED ring flash rated for 95 CRI
 

oracacle

Senior Member
Well after actually sleeping at night for once - well sort of, I woke up at 4am I decided to have a look at some imaging.
after a few little experiments (using a micro switch as input) I found that my flash duration is far too long as can be seen in the image attached, even a slow hand press showed sine's of movement so I will need to save some pennies for a new flash with a short duration (exposure was 1 second in a dark room, iso 100 f3.5).

so next I thought I would move to using the out and out speed of an DSLR shutter. the fasted reaction time that can be hoped for is only achievable in mirror mode, so I made some code changes and test again. the system seemed to work for a simple hand press. so I found a heavy bolt to drop on onto the switch, no detection. I turned up the clock speeds (64mhz) and all was good again, even at 1/2000 second (ISO 2000) some movement was visible. so I turn up the wick a little, the other shot attached is ISO 6400 and shutter of 1/4000 second. as you can see the bolt had bounced about 25-30mm before the image was captured, this distance was the same for all the shots of controlling the camera directly at which ever shutter speed was used. The bolt was dropped from about 30cm.

I will find the quoted shutter release time for the D7100 and try and come up with some meaningful numbers for the camera, but the flash side of the system may have to wait for a while

camera test code:
Code:
[color=Blue]setfreq em64

symbol [/color][color=Black]focus      [/color][color=DarkCyan]= [/color][color=Blue]b.6
symbol [/color][color=Black]shutter    [/color][color=DarkCyan]= [/color][color=Blue]b.7[/color]
[color=Black]init:
      [/color][color=Blue]let [/color][color=Purple]w0 [/color][color=DarkCyan]= [/color][color=Navy]5000
      [/color][color=Blue]hintsetup [/color][color=Navy]%00010001
      [/color][color=Blue]setintflags [/color][color=Navy]%00000001[/color][color=Black],[/color][color=Navy]%00000001 [/color][color=Green]'int0 b.0
      [/color][color=Blue]let [/color][color=Purple]dirsb [/color][color=DarkCyan]= [/color][color=Navy]%11111110
      [/color][color=Blue]high [/color][color=Black]focus        [/color][color=Green]'reguired for nikon camera
      [/color][color=Blue]high [/color][color=Black]shutter      [/color][color=Green]'lock mirror up
      [/color][color=Blue]pause [/color][color=Navy]20
      [/color][color=Blue]low [/color][color=Black]shutter
Main:
      [/color][color=Green]'do stuff here
      
      [/color][color=Blue]goto [/color][color=Black]main
      [/color]
[color=Blue]interrupt:
      high [/color][color=Black]shutter      [/color][color=Green]'fire shutter 
      [/color][color=Blue]pause [/color][color=Navy]20
      [/color][color=Blue]low [/color][color=Black]shutter
      [/color][color=Blue]pause [/color][color=Navy]1000        [/color][color=Green]'wait for some time
      [/color][color=Blue]high [/color][color=Black]shutter      [/color][color=Green]'lock mirror up after shutter fired
      [/color][color=Blue]pause [/color][color=Navy]800
      [/color][color=Blue]low [/color][color=Black]shutter
      [/color][color=Blue]let [/color][color=Purple]flags [/color][color=DarkCyan]= [/color][color=Navy]0
      [/color][color=Blue]setintflags [/color][color=Navy]%00000001[/color][color=Black],[/color][color=Navy]%00000001
      [/color][color=Blue]return[/color]
Edit:
Camera is rated for 0.055seconds shutter response, meaning the bolt was moving around 45cm/second - seems a little fast. with a presumed response from the picaxe of 0.0002. 0.0552/0.025 = 0.4529m
 

Attachments

oracacle

Senior Member
I thought it maybe worth while doing some testing with the micro switch beyond dropping objects on it. after a few failures to fire I got this

Succes-1 by f2268d215cc925918731918f4efa0289, on Flickr

and the aftermath
Aftermath-1 by f2268d215cc925918731918f4efa0289, on Flickr

and the second success
Succes-2 by f2268d215cc925918731918f4efa0289, on Flickr

I will be exploring the use of flash further, these shots were taken at ISO 6400, f5.6 and shutter of 1/8000. due to using the camera instead of flash there was around 0.055 second delay to the switch activation and the image being captured. There is no doubt in my mind that I still have a lot to learn about this field of photography
 

oracacle

Senior Member
Back in 2005 I also built a similar sound-triggered flash circuit, which was later published in the February "06 issue of Nuts & Volts magazine. It relied upon on opamps and CMOS logic though......

One of things one becomes aware quite quickly is that sound travels at aprox 1ft/sec. Which means that by moving your microphone's position, significantly different results will occur.

How fast does the flash itself triggers? If it is one of those simple, trigger to ground flash units, it is in the order of 10 microseconds or less. I measured that by using a photodiode in reverse photocurrent mode (for fastest response), and measuring on a scope the time between the trigger signal and the photodiode's response.
Some thing have arrived, inclusive of photo diode, did you use a "proper" scope? The PCB scope does not seem to be able to find a discernible difference between the picaxe sending the signal to the opto couple and the flash sending signal to the diode. There is also a noticeable difference in flash duration depending on how long the pins is held high, so far I have gotten to as low as a pause 50 at 64mhz which I presume is 0.00625 second of the pins being held high. As for the flash itself, I have learnt that a lot of flashes will increase their duration as power goes up due to the fact it takes linger to discharge the capacitor - not sure how I stand as I am currently using an LED flash
 

Dippy

Moderator
I don't quite follow oracacle's post, but can't you use pulsout to trigger the flash?

Does the ready-made (?) flash have some electronics which might 'get in the way'?

It may be time for you post your latest schematic and your test-points so that:
a) people can see your setup and where you've measured.
b) suggest improvements.

Response time of a photodiode depends hugely on the type and how you've biased it
With all-hardware electronics you could get teeny-weeny delays if done correctly.
 

bfgstew

Senior Member
The main problem with high speed photography is the time the camera takes to open the shutter and the flash to fire, in most instances the subject has dissappeared long before everything is fired. The easiest way round this is to have the camera shutter open in a dark room, this will speed things up considerably as you only have the flash to fire. This is how most high speed photography is done, else you end up going down the expensive and dangerous air gap flash set up!!!!!!!
 

oracacle

Senior Member
air gap is normally used for ultra high speed, and no matter how fast the flash the electronic have to be able to fire the flash in time for the event. the standard way of getting anything high speed is with the flash, my camera as a 0.054 second shutter activation time from mirror up - this is fine for some things but not for others.
I have actually been working towards using the flash, I have shacked a connection to it as I don't currently have a PC sinc hot shoe (it on the list for the future of all goes well). I have attached a diagram of the test circuit so far. the photo transistor is the one from the picaxe shop (http://www.picaxestore.com/index.php/en_gb/led022.html) and is connected with the flash side to +v.

the PCB scope show that the line to the opto and from the photo diode goes high at exactly the same time as far as I can tell - don't think its fast enough to detect the difference, or I have set it up wrong - I have a banging migraine that has lasted 2 days now.

the flash does have electronics in it, but it hard to tell if they are getting in the way - most flashes will have some form of electronic in them. However I did learn that, the higher the output of the flash the longer the duration - http://www.scantips.com/speed.html

my camera has a sync time of 1/250s, this is not flash dependant so the the flash should be much faster when used alone

flash:
http://www.aputure.com/blog/2012/03/16/amaran-halo-ring-flash-led-released/
 

Attachments

bfgstew

Senior Member
I used the comparitor pins on the 40X2 one set for lightning detection, the other set for sound detection, using a variable to set the trigger level, a pot to set sensitivity on one pin, the input on the other, output to an optocoupler directly to flash (for sound) and to camera (for lightning) both work fine.
 

oracacle

Senior Member
I have thought about using such an idea, however due to the read time, and the fact that an if statement would be required it would be slower than doing comparison out of the picaxe in hardware. this hardware can then activate the interrupt and the picaxe add in any extra delay that will be needed, and strobe if required

I am still waiting for some mics to arrive so I can bread board the sound circuit, other ideas are welcome for sound driving to a digital input.
 

oracacle

Senior Member
Pulsout pin, 1 works fine for the flash, but is way too fast for the camera.

the graph shows the high vs low setting on my flash with a pulsout of 1. the green and blue line show the state of the picaxe pin while the purple and red lines show what data the photodiode received from the flash. it looks as thought the flash can see into the future and fire before the picaxe has sent the pin high, however I am slightly concerned about flash duration. At more than 0.1 seconds its longer than I expected and maybe too long for this project.
 

Attachments

oracacle

Senior Member
Well most of the components that will be needed for the project have arrived. The sound detector has been assembled and the first test has been carried out. My current flash has far to longer period to be useful for this application but will be fine for initial testing - I have a Meike MK910 on it way from Hong Kong, which should be plenty sufficient enough for this job

the attached image was taken in a dark room with the picaxe controlling the shutter in bulb mode, and firing the flash. The main loop will have some code in it at the end for cancelling the job, but will be kept lite

test code:
Code:
[color=Blue]setfreq em64

symbol [/color][color=Black]flash      [/color][color=DarkCyan]= [/color][color=Blue]b.7
symbol [/color][color=Black]focus      [/color][color=DarkCyan]= [/color][color=Blue]b.6
symbol [/color][color=Black]shutter    [/color][color=DarkCyan]= [/color][color=Blue]b.5[/color]
[color=Black]init:
      [/color][color=Blue]let [/color][color=Purple]w0 [/color][color=DarkCyan]= [/color][color=Navy]5000
      [/color][color=Blue]hintsetup [/color][color=Navy]%00010001
      [/color][color=Blue]setintflags [/color][color=Navy]%00000001[/color][color=Black],[/color][color=Navy]%00000001 [/color][color=Green]'int0 b.0
      [/color][color=Blue]let [/color][color=Purple]dirsb [/color][color=DarkCyan]= [/color][color=Navy]%11111110
      [/color][color=Blue]pulsout [/color][color=Black]flash, [/color][color=Navy]1
      [/color][color=Blue]high [/color][color=Black]focus        [/color][color=Green]'reguired for nikon camera
      [/color][color=Blue]pause [/color][color=Navy]100
      [/color][color=Blue]high [/color][color=Black]shutter      [/color][color=Green]'shutter needs to be kept high in bulb mode[/color]
[color=Black]Main:
      
      [/color][color=Blue]goto [/color][color=Black]main
      [/color]
[color=Blue]interrupt:
      pulsout [/color][color=Black]flash, [/color][color=Navy]100
      [/color][color=Blue]low [/color][color=Black]shutter
      [/color][color=Blue]low [/color][color=Black]focus
      [/color][color=Blue]pause [/color][color=Navy]5000
      [/color][color=Blue]let [/color][color=Purple]flags [/color][color=DarkCyan]= [/color][color=Navy]0
      [/color][color=Blue]setintflags [/color][color=Navy]%00000001[/color][color=Black],[/color][color=Navy]%00000001
      [/color][color=Blue]return[/color]
the picture does show that the flash fired the instant the hammer hit the hazel nut, so I don't think that reaction time is going to be much of issue. Hopefully the new flash does not take too long to arrive so I can get some more updates and press on with this little project
 

Attachments

oracacle

Senior Member
I have hit the first problem, I will most likely be using an AXE134 as a display. the problem arises as using N2400_64 is not accepted by the PE6, however the AXE164 run at 16MHz, I would suppose there are 2 options, either switch the 28x2 speed down for screen communications or find a common speed they can work are - maybe N9600_16 for the display and N9600_64 on the 28x2. any thought on this?
 

oracacle

Senior Member
Its been a about a week now, I am still waiting on the flash to arrive, but have been working on the circuit and software and have gotten some where close to where I think it should be. I have the circuit (see attached) running on breadboard with the sound detector on a built onto a piece of strip board.

after the suggestion about using the comparator, which I initially dismissed, I decided to revisit the idea. after some head scratching and figuring out what I needed to do I was able to use the IVR for a base detection line and the sensors variable resistor to alter the sensitivity to a satisfactory level. Changes can be made alter if more adjustments need to be made.

I have a test programme with full function working on the bench (needs a few tweaks), but it needs a lot of tidying up and commenting added so I will post it when I can.

there maybe other things I want to add at a later date, however I am open to suggestion on changes to the circuit, so please feel free to make some suggestions.
 

Attachments

oracacle

Senior Member
I have been doing a little more work on the project the last couple of days while waiting. I made a few small hardware changes, a few software changes. I have attached both. the code isn't fully commented as yet. Hopefully I have covered most bases with the exception of a variable thresh hold on the picaxe using the IVR, that may well have to wait until the new flash get here and I moved onto a new version of the software.
 

Attachments

oracacle

Senior Member
I have hit a couple of snags in the current design. The first problem revolve around the use of the torch, I presume there is some form of current issue. if the torch is switch on - pulling around 300mA from the batteries - the system detect a signal even when there isn't one and fire the flash.

the second problem revolves around the interrupt itself, the system is needing a restart to clear. if the run is aborted meaning no flags were created from the routine and setintflags off is given, without a restart it fires with no input what so ever (once the interrupt is re-enabled), even with no sensors plugged in.

I suspect a voltage ripple issue with the torch, however I am at a loss for the interrupt issue, I have a feeling that I am missing something completely obvious but have become code blind over the course of the last few hours.

I have attached a copy of the programme I am currently using, the interrupt is down near the bottom, under the label of "program". There is also the circuit diagram for the hardware too
 

Attachments

oracacle

Senior Member
Both problems were being caused by something altering the interrupt flags, moving the comparator configuration command to after the torch state change in and adding the same command to remove the interrupt flag from the comparator solved both problems
 

oracacle

Senior Member
Early testing is looking quite good
http://youtu.be/zdWs2Ng3R9I
this was shot at 60FPS with a Nikon D7100, which will be used for the capture of the images. I will try and get a still done and uploaded in a bit.
The sound detector was 1m from the source of the sound (the sound was an old bearing sleeve being dropped onto the table). With sound travelling at 340m/s it took 0.0029s for the sound to reach the detector, and from my understanding with previous testing @ 16mhz the entire system should be responding in around 0.0003 seconds. Hopefully that will fast enough for when the meike flash arrives

this image was shot in mirror up at 1/8000s 6400 iso and f3.5. mirror up give the shutter 0.054 second response time, so this shot was captured about 0.055 seconds after the moment it hit the surface of the desk

Drop-test by f2268d215cc925918731918f4efa0289, on Flickr
 
Last edited:
Top