// SPI interrupt routine
ISR (SPI_STC_vect)
{
  byte c = SPDR;  // grab byte from SPI Data Register
  
  // add to buffer if room
  if (pos < sizeof buf)
    {
    buf [pos++] = c;
    
    // example: newline means time to process buffer
    // if this is set to 255 and master sends 255 then the whole things goes buck ape
    if (c == 249)
      process_it = true;
      
    }  // end of room available
}  // end of int

Sometimes I can't resist an optimization opportunity when I see one.  You are declaring a byte array of 300 bytes that will never overflow because pos is a byte.  sizeof buf will never be reached.  You'll never overwrite beyond the end of the buffer.  You will have a limit of 256 bytes, but you will shave a few clock cycles.  Since it wraparound to 256, do you need an overflow check?   Overflow checks are important in many programs, but you never overflow because the byte becomes its own overflow preventer.  Remove the overflow check for extra performance, if you've got a buffer bigger than the index variable, and if the buffer-full behavior isn't important.

This will perform slightly faster.  It will have different behaviour when the buffer is full, it will start overwriting the beginning of the buffer again and suddenly discard the last 256 bytes of data (you'll have to test if this behavior is undesirable or not), but might work more reliably at a slightly higher speed.  Since you're hosed anyway if the buffer is full, we probably don't care in what way it overflows?  (depends on the application).

Here's a faster ISR which also is fixed-cycle (cycle count does not vary due to lack of "if" statement)

byte incomingByte; // Preallocate for performance
ISR (SPI_STC_vect)
{
  incomingByte = SPDR;
  
  // pos never overflows past 256, so we'll never overwrite beyond end of buffer, it wraps around
  buf[pos++] = incomingByte;  

  // This becomes true the first time incomingByte equals 249
  process_it |= (incomingByte == 249);
}

So the location of the camera when the shutter fires is not that important, it's the RATE of travel that matters, and that has to be constant within some limits?

Correct.  The rate (including consistency & non-variability) is critical.

(3) I have full control of the moving object, so I can automatically reposition the moving object to be in front of the lens.

How you do that with all the above variables I don't know but I believe you

It's moving objects on a screen, completely generated by software, and the same software program can also be directly connected to the Arduino moving-camera rail via a USB cable.  The software becomes all-knowing if it controls the moving objects and it also controls the Arduino camera rail.  There are many techniques that I can do, such as:

(1) (if theres no feedback) Cover the entire screen with several copies of on-screen moving test-pattern.  The test-pattern can be full-screen, so it no longer matters where/when the camera starts moving -- the camera will "scroll" along with the horizontally-scrolling test pattern, and take a picture anytime before the camera reaches the edge of the screen.

--and/or--

(2) (if there's feedback)  I'd simply physically position the left end of the rig precisely at the left edge of the screen, and manually position the camera at on-screen target "X" displayed by my software program on the left edge of the screen.  Then when everything's set up, I click a button -- and the software triggers the camera to start accelerating....  You transmit position feedback over the USB cable (notch count on cogwheel = notches sent down the cogwheel belt, converted to millimeters in linear distance).  Then once the camera has finished accelerated to a specific speed (e.g. 960 pixels per second at the monitor's dpi -- see below for calculations)  My software immediately ensures a moving object in front of the lens based on last-known positional information (+/- 1-2cm inaccuracy is okay -- it just simply means the object is not perfectly centered).  Trigger the camera shutter.  Viola!  The Arduino rail just needs to continuously transmit me motor rotation or position info in real-time over USB, I can do/calculate the rest based on a known "home" position (e.g. setting up the rig in front of a screen in front of an on-screen "X" marker).

How do I know where to put the moving object on the screen?   You'll see that I'll position the rig in front of a displayed "X" on the screen.   Knowing the dot pitch of the monitor is important to me, but that's my job.  For example 960 pixels on a monitor at 0.25mm pitch, is 240 millimeters long.   My standard test patterns are moving at 960 pixels per second.  So to determine the necessary camera movement speed, I know the resolution of the display (e.g. 1920x1080p), then I use a measuring tape to find out how many millimeters wide the display is.  Then divide by horizontal resolution width (e.g. 1920).  That's dot pitch -- the width of a single pixel.  Then multiply this number by 960 (for test pattern movement speed) to program the desired camera-movement speed (the calculator will be built into my software).  Viola.  I now know how fast I need to move the camera at, and I also can know exactly where to display the moving object (if there's motor feedback, combined with cogwheel), to be in front of the camera lens -- as long as I've pre-positioned the whole rig first at a starting "home position".

This is the easy peasy part... I'll do (1) if there's no feedback info, but I prefer to also be able to do approach (2), so I prefer you to use a cogwheel & cogwheel belt (And a motor-position sensor) -- that way, by known distance between cogs (e.g. 1mm per cog) and by knowing motor position -- then all that information can be easily converted to linear position information along the rail.  

Your hard part is the tricky science is maintaining motor speed at a high accuracy, the momentum, the dynamic speed-maintaining (more-or-less camera-mass independent, as long as it's a relatively lightweight camera).

[--> The more important criteria is precision of the camera motion <--]

--> The more important criteria is precision of the camera motion <--

(1) Camera positioning is not as critical.
(2) Timing of the shutter is not as critical.
(3) I have full control of the on-screen moving objects through my software, so I can automatically reposition the moving object to be in front of the moving camera lens (via feedback mechansim if needed), or use a larger area or multiple copies of on-screen moving objects, so that it doesn't matter what part of the screen the camera is pointed at.  
The job is capturing motion blur behaviours in exactly the same way as eye-tracking effects.

Shutter latency randomness is not as big an issue as thought.
The shutter can be electronically held halfway down (shutter button modification) so that shutter lag becomes more predictble.
Error of shutterlag +/- 200milliseconds is acceptable, because I have control of other variables.
As long as the rail is long enough that the shutter will probably occur while the camera is in steady motion, it will work.
At 250mm/sec, that's 25mm per 1/10sec.  The rail can even be just 500mm long, with 200mm acceleration, 250mm section of smooth-coast (picture taking section), and 50mm of deceleration.  Then we have a safety margin for shutter lag of +/- 500 milliseconds.  See?  Shutter lag isn't important, even for a short rail.
Many compact cameras have a very small error in shutter lag if I do the half-press first

To the camera's perspective, the moving camera in front of a moving on-screen object, the on-screen object is more-or-less stationary to the camera (barring various effects such as sample-and-hold (eye-tracking, pixel persistence, etc) motion blur, etc.)   So there's a big window of opportunity for the shutter to open for 1/10sec, sooner or later.

--> The more important criteria is precision of the camera motion, perfectly tracking the on-screen object <--

This rig needs to use a screwmount, so it can use almost any camera.
It shall not be camera specific.

My favourite mechanism is the cogwheel belt (used by inkjet printers).  Using cogwheel belts, and precise motor control on the cogwheel driving the cogwheel belt, inkjet printers move cartridges at over 1 meters/second with near-perfect accuracy (submillimeter precision).  How do they spray a dot at an exact location otherwise; it's rather impressive how accurate inkjet heads are even at 1 meter per second movement.   So let's use the same cogwheel belts that these printers use (but with variable speed, and good speed feedback for dynamic speed adjustment).   Although the design goal is 250mm/sec, I will give an additional bonus money to a mechanism that can move accurately at 500-700mm/sec (for a mass of a compact camera), since that means I can test moving objects on 60" HDTV's with moving objects moving at 960 pixels per second.  This may mean the rail needs to be 1 meter long, to allow sufficient acceleration.

Although it can be targeted at a favourite camera, the rail ultimately shall not be camera specific.  Rail must be tripod-screw mount (that tiny screw hole at the bottom of all cameras), and permit experimentation with all sorts of different cameras.  Smart electronic feedback motor speed control, to adapt to any mass, up to a limit.  Faster adjustable coast speed achievable for smaller/compact cameras, slower adjustable coast speed achievable for larger/SLR cameras.

Ideally, this is what I want:
1. I type in the display screen's DPI into my own software
2. My own software displays moving objects
3. My own software calculates the speed your camera needs to move it at.
4. Via a serial command over USB cable, my own software commands your Arduino-powered camera rail to start moving now at a precise speed.
5. You can even leave the shutter operation details to me.  Just move the camera precisely for long enough (e.g. move accurately to my own specifications for 1 full second).

If necessary to achieve 1mm/sec accuracy, linearity differences (e.g. belt stretch, etc) can be cancelled out using a separate calibration pass and an appropriate multiplier to compensate (calibration details TBD).  (This may not even be necessary, if you find a good metric cogwheel belt and a good metric cogwheel, etc.)

My software will handle triggers and calibration of timings (e.g. calibration for latency of acceleration, calibration for shutter lag, shutter trigger, etc).  Ideally, you are responsible for the design of the mechanical operation and the ability to accept serial commands over the Arduino's USB/serial bus, to command the rail to begin accelerating to a precise speed, and then keep maintaining the speed for at least 1 second at 250mm/sec.  Leave the rest of the details to me.
BONUS FEATURE: Ideally, I'd like your Arduino rig to give me continuous feedback (over serial) of the camera's current approximate position (+/- 1cm) relative to start position.   This can be easily implemented by giving me motor-rotation speed feedback, which can be translated to cog-gear-count on the cogwheel-belt.   Quite very doable.  That way, I can synchronize my on-screen moving object to the position of the moving camera.  And also know when acceleration is finished and the camera is in steady motion (this becomes my shutter trigger).  Your job is to keep the camera moving at a steady speed for as long as you can.  

Preferably, the rig needs to be strong enough to be portable, since I'll want to travel with it, and put it on all sorts of table tops, in front of all kinds of displays, of all kinds of brands/models/sizes.

Yes, pictures of construction is a bonus.  Parts should be parts purchaseable from online stores, if possible.  (I can buy the parts for you, shipped to your address).   Scavenging is acceptable, but this is an open-source project that will be published online, and it needs to be easily reproduced & replicatable by other people.  Therefore, a list of links to online purchases for every component in the project, is ideal, if preferred.

I currently have a strong contender of a person who has given me a resume & credentials (webpages of existing projects), with a price quote within my budget.  If you want to apply to do this creation, please email me a 1-page (or more) email message explaining your proposal and your pre-existing experience (resume and web pages with proof of your electronics abilities) -- email mark[at]scanningbacklight.com ...  Submissions are still being accepted till December 7th.

Addendum: That was fast!
One application by an electronics engineer has now been received already.
I am accepting proposals from anybody until December 7th, and want to compare all the qualified ideas before money leaves my pocket.

[I need an Arduino-controlled device that moves a camera horiziontally approximately 0.25 meters per second while taking a picture for 1/10th second.]

Hello,

I made a post in this thread, but since I need collaborators for my project.
http://arduino.cc/forum/index.php/topic,133035.msg1009342.html

I need an Arduino-controlled device that moves a camera horiziontally approximately 0.25 meters per second while taking a picture for 1/10th second.
This is for an experiment -- scientific measurements of display motion blur.  (Cameras taking pictures of moving test pattern objects on screen)
I can build it myself, but my time is quite short/lacking.   I can write Arduino programs myself, and I can create electronics circuits.

Essentially, camera starts moving, accelerates, [BEGIN precision requirement] then takes a picture for 1/10th second [END precision requirement], then camera decelerates to a stop.  I only need one picture, but when the shutter is open, the precision requierments apply.

Here are my preferred requirements:
(1) Must fit on a desk (ideally less than 1 meter long (1 to 3 feet long) maximum 4 feet long. Less than 1 feet deep).
(2) Speed control: 1mm per second increments, up to at approx ~300mm per second.  (more is desirable -- but not needed now)
(3) Speed error: +/- 1mm per second error (@250mm per second)
(4) Positioning error: +/- 1 centimeter (Manual shutter timing fine-tuning should be manageable)
(5) Amount of time the precision is required: 1/10th second (macro mode)
(6) Moving mass required: Typical point-and-shoot camera (1/10sec allows use of lightweight camera w/manual exposure ability)

Acceptable precision degradations, if certain parameters are expensive/difficult to meet:
(2b) Speed control: 5mm per second increments (= 0.5mm per second difference during 1/10sec exposure)
(3b) Speed error: +/- 10mm per second (= 1mm error during 1/10sec exposure)
(4b) Positioning error: +/- 5 centimeter (I can do multiple attempts until subject matter is fully in the frame)

The movement mechanism can be anything:
- Stepper motors and a metric threaded screw.
- A hacked inkjet printer mechanism (with the camera mounted to what used to be the cartridge holder)
- A conveyor belt mechanism.
The camera will be computer/Arduino controlled (using a modified shutter button wired to the computer, or by using Canon CHDK custom firmware modification).

The precise details are left to you, but the system must be reasonably cheap and easy to build copies of (100% open-source build instructions, with photos -- will pay extra $ for your photos taken while you build the device).   I'll be publishing the stuff on my BlurBusters blog.

You can also contact me directly at mark[at]scanningbacklight.com

Sincerely,
Mark Rejhon
The BlurBusters Blog

[[BEGIN precision requirement] then takes a picture for 1/10th second [END precision requirement]]

I don't care about start/stop details, as long as I can keep resetting it and repeating. What I need is a photograph successfully taken automatically (Arduino-controlled shutter, Canon CHDK fimware or modified shutter button) at an approximately exact horizontal position, while the camera is horizontally moving at an accurately measurable speed.  The start/stop can be as messy or continuous; but ideally, I'd like something that fits on a desk, no more than for feet long.  It also needs to be transportable to different sites, so I'll mount all of this on a portable platform.

Essentially, camera starts moving, accelerates, [BEGIN precision requirement] then takes a picture for 1/10th second [END precision requirement], then camera decelerates to a stop.  I only need one picture, but when the shutter is open, the precision requierments apply.

Here are my preferred requirements:
(1) Must fit on a desk (ideally less than 1 meter long (1 to 3 feet long) maximum 4 feet long. Less than 1 feet deep).
(2) Speed control: 1mm per second increments, up to at approx ~300mm per second.  (more is desirable -- but not needed now)
(3) Speed error: +/- 1mm per second error (@250mm per second)
(4) Positioning error: +/- 1 centimeter (Manual shutter timing fine-tuning should be manageable)
(5) Amount of time the precision is required: 1/10th second (macro mode)
(6) Moving mass required: Typical point-and-shoot camera (1/10sec allows use of lightweight camera w/manual exposure ability)

Acceptable precision degradations, if certain parameters are expensive/difficult to meet:
(2b) Speed control: 5mm per second increments (= 0.5mm per second difference during 1/10sec exposure)
(3b) Speed error: +/- 10mm per second (= 1mm error during 1/10sec exposure)
(4b) Positioning error: +/- 5 centimeter (I can do multiple attempts until subject matter is fully in the frame)

A conveyor belt?  That could work, too.  I'd put the camera on the conveyor surface, even duct tape it down, and press a button to start moving the belt (letting logic and triggers do the work for me).
I have a discarded inkjet printer too, just in case I use its ink cartridge platform as my camera platform.  However, I'm open to ideas of easier-to-build solutions that fully meets my accuracy requirements, as my spare hobby build time is limited.  
[P.S. If someone is willing to build this for me, there's some money in it for you, above and beyond parts cost.  I will give you some publicity in my blog, if you open-source the build instructions.]

I have purchased the LED ribbons now, through a supplier on Alibaba.  About 7 dollars per meter for LED's that are 21-22 lumens 6000-6500K, Epistar (Taiwan) branded #5050 chips, (1000 lumens per meter at 60 LED per meter).  About 35 dollar per reel of high-brightness neutral-color CRI 70-75 LED's.  They are perfectly adequate for my needs at a reasonable brightness-versus-cost ratio. They are only CRI 70-75 but this is acceptable. The switching time is sufficiently fast (LED phosphor decay is short -- far less than 1 millisecond).  The cost was a bit higher than I hoped to pay, but I need an ultrathin light source (a big panel that's less than 2" thick) that can switch on/off at strobe speed levels, with precision strobe length control.  And, if I overvolt carefully, I can get at least 3000 lumens per meter (60 lumens per LED) in short strobes -- since LED's can be overdriven if strobed for really short periods.  So I can output over 50,000 lumens from a two-square-foot ultrathin strobe panel, with better and easier control than xenon strobes -- I need to do 120 precisely-controlled full-brightness strobes per second.   An 800 watt PC power supply will be supplying the 12 volts necessary for the 250 watt surges of light (more, if I use an overvolted surge circuit).  Here's a small section of the LED ribbon, I took pictures of:

...

...

A simple Arduino Photodiode test showed that phosphor decay (after turning off) is undetectable without an oscilloscope -- far less than 1 millisecond.  So they are satisfactory in high speed light switching capabilities for low cost!   Fiour prebuilt MOSFET switches is what I'm getting (at four channels each), with separate channels controlling a few sections of ribbons, since I need 16-section strobe control.

Hello,

This is for a scientific experiment on exact motion blur measurements.
I am trying to construct an Arduino-driven rail that can move a small camera sideways at a precise speed: 0.25 meters per second (about 10 inches per second).
(I'll be using a CHDK-modified arduino-triggerable Canon camera)

These are my requirements:
- I'm taking 1/10th second camera exposures while the camera is moving sideways
- So, I only need +/- 1mm precision for only 1/10th second.
- Inaccuracy during acceleration and deceleration is okay.
- Rail can be short, e.g. half a meter long -- just as long as I achieve precise 0.25 meters per second (controllable in approx mm increments if possible) for the 1/10th second interval I need to take the photo

How would I construct a rail?   I could take apart an inkjet printer, mount the camera on top of the cartridge holder, and use the Arduino to move the inkjet head platform (moving the camera) at a precise speed.  Any alternatives?  Ideas?

Thank you for your reply.  I am aware the FET's can switch fast, but I was worried about them burning up during switching.

I will have to decide if I want to go for my own FET circuit, or buy a premade driver circuit.  
This driver circuit is quite attractive, as it contains everything needed; just direct wire to the Arduino, direct wire to the LED ribbon trips, direct wire to the 12V power supply, no other components needed.  It now boils down to a simplicity vs cost scenario.

Ok, partially answered my own question.

There's a ready made board that can be used directly with LED ribbons:
http://arduino-info.wikispaces.com/Brick-4ChannelPowerFetSwitch

This one is rated for 200,000Hz switching capable -- perfect for my needs.
http://www.elechouse.com/elechouse/index.php?main_page=product_info&cPath=&products_id=1812
They are $18 each for 4 channels (10 amps per channel, 16 amps total), and can switch

On the other hand, if I am controlling 16 ribbons, the costs of these boards add up rather quickly.  But the power and safety features (optoelectrically isolated) is extremely attractive.

The first device must be a common-source stage, with a drain load resistor to the +12V rail (something like 1k perhaps).  This will level convert from 5V to 12V (and invert the logic).  This can then drive the second devices gate at suitable levels to actually turn it on.

This looks like the right circuit to drive a 12V 3A load for my project (LED ribbon).   Can I drive the load at 2Khz (switch on/off 2000 times a second) with this circuit, without wrecking the FET?

Also, are there alternatives to this circuit, e.g. a single component that integrates an equivalent of this whole circuit into it -- logic-controlled high-amperage 12V amplifiers in a single package?  (even if a few dollars extra)

EDIT -- Found a ready made multiple-channel Arduino amplifier board suitable for 12 volt control.
http://www.elechouse.com/elechouse/index.php?main_page=product_info&cPath=&products_id=1812

Hello,

This is one of my first Arduino projects, but I have worked with electronics many years ago.

I want to connect my Arduino connected to segments of several feet of LED ribbon, which requires 12 volts and a few amps.

I want to run at least 2Khz PWM dimming on the entire LED ribbon (I can indirectly detect PWM at 1Khz through the fast-eye-roll stroboscopic effect, so I need a higher frequency).  I don't want to use voltage dimming because it's for a special project that requires custom PWM control, perfect for an Arduino sketch.

I'd wire a MOSFET (source, emitter) inline with a power supply connected to the LED ribbons (which already has built-in current limiting resistors), and switch the MOSFET using the Arduino.   I just want to be able to switch 12 volts on/off very rapidly and efficiently, and cheaply, since I'll need to control several LED ribbons separately.  I'm open to alternatives to a TO-220 MOSFET package (60V 100W capable component, logic level gate), but LED ribbon amplifiers are expensive and I can get these transistors cheap.

Can I pull this off directly connecting the Ardiuno pin to the gate of a common TO-220 MOSFET of sufficient amperage ability, as long as I have a heatsink attached to the MOSFET?   I don't think I need a resistor before the gate, but would a Darlington type circuit for better switching efficiency?    Are there other good combined discrete component (e.g. SmartFET's, etc) that can do this fast high-power switching job efficiently with minimum component count?

Thanks.