Electronic – arduino – Which hardware to measure velocity via string/wire wheel attatchment

Using a hall effect sensor as Starliner suggested will be one way to interface with the wheel. Achim and Shutterdrone's suggestion to use a reed switch makes more sense though, given the supporting hardware a hall effect sensor requires to get a clean digital signal.

You might be able to pickup a magnet and sensor from a broken bicycle computer but if you can't, a local component store should have one of each in stock. The advantage of a recycled sensor and magnet is the you will already have the mounting hardware.

There is a page on the arduino wiki on ReadingRPM signals. To calculate the speed multiply the RPM value by the circumference of the wheel (2 * pi * radius [in meters]). The result will be in meters per minute.

Edit: I've notice that the linked code is for systems with two pulses per revolution. One magnet is sufficient for your task. Additionally, for a bicycle computer you'll probably want the result to be in KPH (or MPH if you live somewhere that still thinks that's civilised). I've made some (untested) mods to the code on the wiki to print out KPH and pasted them bellow.

volatile byte revolutions;

unsigned int rpmilli;
float speed;


unsigned long timeold;

void setup()
{
  Serial.begin(9600);
  attachInterrupt(0, rpm_fun, RISING);

  revolutions = 0;
  rpmilli = 0;
  timeold = 0;
}

void loop()
{
  if (revolutions >= 20) { 
    //Update RPM every 20 counts, increase this for better RPM resolution,
    //decrease for faster update

    // calculate the revolutions per milli(second)
    **rpmilli = (millis() - timeold)/revolutions;** EDIT: it should be revolutions/(millis()-timeold)

    timeold = millis();
    **rpmcount = 0;** (EDIT: revolutions = 0;)

    // WHEELCIRC = 2 * PI * radius (in meters)
    // speed = rpmilli * WHEELCIRC * "milliseconds per hour" / "meters per kilometer"

    // simplify the equation to reduce the number of floating point operations
    // speed = rpmilli * WHEELCIRC * 3600000 / 1000
    // speed = rpmilli * WHEELCIRC * 3600

    speed = rpmilli * WHEELCIRC * 3600;

    Serial.print("RPM:");
    Serial.print(rpmilli * 60000,DEC);
    Serial.print(" Speed:");
    Serial.print(speed,DEC);
    Serial.println(" kph");
  }
}

void rpm_fun()
{
  revolutions++;
}

Also, I've enabled 'community wiki' on this, which I think means other users can edit it. If my maths is wrong (and you can prove it!) jump in and fix it for me. :)

To do this measurement, there are two well-established methods:

TDR

Apply a pulse input (either the rising or falling edge of a square wave), and measure the time for the edge to propagate to the far end of the trace. The delay measurement is done with an oscilloscope, and high-end oscilloscopes have TDR plug-in modules available to automate this measurement.

Key requirements for your measurement equipment is that the pulse source should have a very fast rise time, and the cables connecting it to your system under test should not slow the edge down too much. The oscilloscope must have sufficient trigger accuracy and timebase resolution to measure the arrival time with the accuracy you want.

Group Delay

Use a vector network analyzer (VNA) to measure the phase response of your trace. The group delay (derivative of phase with respect to frequency) gives the propagation delay through the trace at each frequency. You'll be interested in all the frequencies contained in your signal under normal use, so for digital signals that would be from some low frequency determined by your coding scheme up to a high frequency determined by the rise and fall times of your edges.

In this case the quality of the stimulus is less critical than in the TDR case, but you do need to carefully calibrate the VNA and interconnecting cables on a daily or half-daily basis, using a quality calibration kit, to be sure of getting a meaningful measurement.

More difficulties

If your traces are layed out as tightly-coupled differential lines, you would want to do these measurements using differential stimulus and measurement. Unfortunately, appropriate gear to do the measurements differentially is not widely available. If your traces are single-ended, or differential but layed out as uncoupled lines, then a single-ended measurement is appropriate.

Also, as Mazurnification points out in his answer, how you connect your test gear to the traces is critical. If you can arrange to test between two connectorized ends of the trace, that's the best. If you are trying to test traces between chips on a populated board, that's almost impossible. If you have an un-stuffed board, you may be able to connect to it with some kind of probes. But more likely you will just build some test coupons onto the panel with your boards that let you connectorize traces of the same geometry as the ones you are worried about.