tres
Most cars tend to reflect a lot of light because they often got a lot of glass, chrome, and other reflecting parts on them.
Is that going to be a problem for the sensor? If so, is there a way to cope with it?
No, I expect not.
And a more general concern: How well do IR sensors work in bright daylight situations? (The sensor will obviously be mounted horizontally)
As long as you do not get direct sunlight in the sensor I expect they work well.
The distance will be in the range between 10 and 150cm.
HOw fast will the cars pass?
How many samples do you want to take of the passage?
The Arduino is very fast. It could probably sample 100 times a second without breaking a sweat.
I'm not sure how IR can be used to determine distance though? I guess you could strobe an IR emitter and measure the strength of the reflected IR, but that would only work for surfaces that uniformly reflect IR, which cars definitely aren't. IR is well suited to detecting if something is/isn't there, rather than how far away it is. It seems like an ultrasonic ping sensor would work better for measuring distance?
For logging, you could log to the built-in internal EEPROM but you only have room to store 1024 samples. If you store only one sample per car, only 1,024 cars could pass you before you run out of room. Plus you have to take your device off the bike and bring it to a PC (or bring a laptop out to the bike) to download the results. I suggest an SD card instead -- more room, easier to download.
palavro:
The sensor I had in mind is the Sharp GP 2 Y0A 02 YK. Actually I'm not sure if it is IR, it only says "optical". This will not work on the surface of a car?
Ah, the datasheet says it works based on triangulation. So, it would not work on a mirror placed at an angle to the sensor, because the light would be sent off some other direction. But for shooting a car with the sensor aimed perpendicular to it, I would think it would work (though some error may be introduced by curved body panels).
Neat sensor!
I see. Well, even if there's no formula to describe the curve, you can always do what the automotive engineers do -- make a map. You can test the unit under static conditions at, say, 1cm intervals between 0 and 150cm, and record each analog voltage at each distance (divide by 4 to convert the 10-bit number into a more easily manageble 8-bit byte).
Now out in the field, you can use the map to decide what distance a sampled voltage equates to.
const byte distanceMap[150] = { 12, 16, 18, 25, 39, 54, 67 } //etc
loop()
{
byte sample = analogRead() / 4;
byte i;
for(i = 0; sample < distanceMap[i]; i++); // semicolon ; here deliberately -- empty loop
byte distance = i;
}
An array of bytes, 150 bytes long, will easily fit on an Arduino.
+1 for the map solution
if you want to use less bytes for the array you can use MultiMap - http://playground.arduino.cc/Main/MultiMap -
Note 1: the linear search misses a stop criteria for end of the array.
for(i = 0; i<150 && sample < distanceMap[i]; i++); // semicolon ; here deliberately -- empty loop
Note 2: with 150 elements a linear search takes on average 75 compares, a binary search would need 9 compares (in theory, in practice about 25).
palavro:
Thanks for the code, it already scares me.
The Arduino programming IDE makes things easier, but, you'll still need some programming skills. We (probably) won't write your program for you, but we can sure help. 
RTC (i2c, says ds1307 based)
If your budget can support it, consider the DS3231 as it uses the same software library but is more accurate.
is there any drawback picking a Nano/Mini/Micro over a bigger board?
Well the Nano has USB on board, so it's plug'n'play for programming it. The Mini/Micro, on the other hand, requires a USB-serial adapter to program it. Since you're probably not going to need to program it after you finish debugging, this is probably not a big issue. But selecting a 3.3V board (i.e., not the Nano) is ideal as it makes talking to the SD card easier.
If my choice of hardware is complicating the coding than I'd rather swallow the bitter pill of getting an Uno or the like in a case outside teh bike.
No problem, using a Mini or Micro will not change your code BUT the SD card library is rather big (13KB!) so you will want to make sure you get a 32KB (Atmega328P) Mini/Micro and not the 16KB version.
robtillaart:
Note 1: the linear search misses a stop criteria for end of the array.for(i = 0; i<150 && sample < distanceMap[i]; i++); // semicolon ; here deliberately -- empty loop
Thanks for catching my bug.
Note 2: with 150 elements a linear search takes on average 75 compares, a binary search would need 9 compares
I don't think speed is an issue here, as the Arduino will spend most of it's time waiting for that 39ms sensor readout and even 150 compares is going to take way less than 1ms.
I don't think speed is an issue here, as the Arduino will spend most of it's time waiting for that 39ms sensor readout and even 150 compares is going to take way less than 1ms.
Think you are right 
In practice binary search is complexer than linear search. It has (in practice) about 2x the number of compares.
Furthermore there are other tactics than binary search, that might even be better.
- most of the time the distance is large so starting at the end of the array might give almost instantaneous hit, reducing the average quite a lot.
however when the car passes it will take additional time. - check the middle element(75) first and then working down to 0 or up to 150 ==> would half the average.
- start with the previous found index first and go up/down from there.
- extrapolate the last 2(n) found values to estimate a starting point. (quite math expensive)
palavro:
But selecting a 3.3V board (i.e., not the Nano) is ideal as it makes talking to the SD card easier.
The Sharp sensor requires 5V, I assume I can use the USB power supply that powers the arduino for it?
Oh dear, that does make things more complicated. I recommend you stick with the 3.3V Arduino as you'll be both sending and receiving to/from the 3.3V SD card. For the Sharp sensor, you can read the higher voltage with a simple voltage divider (two small resistors).
So, timing -- your Arduino clock will drift relative to the sensor and you may eventually end up sampling the voltage right in the middle of the sensor's transition from one voltage to another. If you don't want the occasional erroneous reading, you'll want to power off the sensor and power it back on to make sure you stay synchronized -- this will require two more small inexpensive parts, a current-limiting resistor and a transistor. Or just live with a few inaccurate readings.
Let's talk about power supply -- USB is fine for testing at home, but will you use something like four AAA NiMH batteries on the bike? Because they could power the sensor directly, and the Micro/Mini has an onboard voltage regulator you can tap in to for the SD card. (Alkaline batteries would be a little on the high side for voltage.)
The only downside to powering the sensor directly from battery, is battery voltage varies with battery charge. You can compensate by using the AREF pin on the Arduino to reference battery voltage though (through another voltage divider).
The best I could find is this Pro Mini 3.3V / 8Mhz Clone plus an FTDI Breakout.
Please note that the FTDI boards (USB-Serial) come in 5V and 3.3V flavors as well -- make sure to select 3.3v!
Well since the output is less than 3.3v, you can ignore all the stuff about AREF then. Have you seen the discussion on
They mention a lot of the things we've already talked about, maps, taking/averaged repeated samples, etc.