title: Algorithm to determine the effective "phase difference" between two signals with different frequencies?
body: <p><strong>The quick version:</strong></p>
  
  <p>What algorithm could I use to determine the "phase difference" between two square wave signals with <em>different</em> frequencies, if the only information that I have is the time at which each rising edge occurs?</p>
  
  <p><strong>The detailed version:</strong>  </p>
  
  <p>I'm working on an embedded software project, and I have run across an interesting problem. I am collecting data from two <a href="http://www.instronics.com/sensoronix_hall_effect_zero_speed_sensor.html" rel="nofollow noreferrer">hall-effect speed sensors</a>, which are each aimed at one of two meshed gears, as shown in the following diagram:</p>
  
  <p><a href="https://i.stack.imgur.com/2cXjQ.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/2cXjQ.png" alt="meshed gears and pulse signals"></a>
  </p>
  
  <p><strong>note:</strong><br>
  As <a href="https://stackoverflow.com/users/110026/jaime">Jaime</a> pointed out, the signals in this diagram would actually have identical frequencies. The real hardware has several more gearing stages between the two target gears, some of which are connected by shafts instead of meshed teeth, so I <em>do</em> end up with two square waves that have different frequencies, and the ratio between them is still a constant. I wanted to simplify the diagram to get to the meat of the matter, but it looks like I simplified it too much!<br>
  <strong>/note</strong></p>
  
  <p>The speed sensors output a square wave signal whose frequency is directly proportional to the rotational speed of each gear. The rising (and falling) edges of the square wave occur when the leading (and trailing) edges of a single gear tooth pass by the sensor.</p>
  
  <p>I know how many teeth are on each gear, and based on this information I am able to accurately measure the rotational speed of each gear based on the frequency of the square wave signals.</p>
  
  <p>To measure the frequencies, I have each speed sensor signal connected to a high-speed capture timer pin on the embedded controller. The capture timers automatically detect the rising edges of the square wave signal, load a register with a value that represents the time at which the transition occurred, and trigger an interrupt. The capture points for each signal are indicated in yellow on the diagram. The interrupt service routine looks something like this:</p>
  
  <pre><code>struct
  {
      long previousTime;
      int frequency;
  }
  sensors[2];
  
  void CaptureTimer_Interrupt(int channel, long transitionTime)
  {
      long timeDifference = transitionTime - sensors[channel].previousTime;
      sensors[channel].frequency = CONVERSION_FACTOR / timeDifference;
      sensors[channel].previousTime = transitionTime;
  }
  </code></pre>
  
  <p><strong>What I would like to do:</strong>  </p>
  
  <p>I would like to be able to detect small differences in the <em>relative</em> timing of these two square wave signals. I call this the "phase difference" for lack of a better term. If the two signals had the exact same frequency, this would be straightforward, and <a href="http://en.wikipedia.org/wiki/Phase_(waves)#Phase_difference" rel="nofollow noreferrer">phase difference</a> would be the correct term to use.</p>
  
  <p>Here's what I'm getting at: If I were to record the two signals over a long period of time, and then artificially slow down (or "stretch out") the high speed (blue) signal by a factor of 16/9, it would have the exact same frequency as the lower speed (red) signal, and the two signals would have some measurable phase difference, i.e. the time difference between a red signal interrupt and a blue signal interrupt. I would like to compute this same time difference (or something equivalent) without having to record the signals over a long period of time. Resources are limited on the embedded controller, so storing large arrays of past transition times is not an option.</p>
  
  <p>Has anyone run into this before? The actual project has several such gear and sensor arrangements, so I'm looking for an elegant algorithm that I can reuse. Thanks in advance!</p>