Finding the average bpm between two heart rate sensors

    whorl
    Nov 09 2014 | 11:23 am
    I have two heart rate sensors with slightly fluctuating frequencies (bpm). I want to average these two streams by working out the time between the peaks (bpm) and triggering bangs from this new average. I am having trouble amalgamating the constantly fluctuating frequencies into a new stream stream in real time.
    In the patch i've tried to work this out by finding the peaks in the streams then calculating the time between each peak.
    But one problem is that the peaks and troughs are fluctuating, so scaling is a problem and I don't know how to apply this t a new stream, other than parsing the data severely.
    Any help is much appreciated!
    • Wetterberg
      Nov 09 2014 | 11:53 am
    • whorl
      Nov 09 2014 | 2:10 pm
      Thanks WETTERBERG, massive help.
      What i am really interested in is finding the average of the two streams and sending a bang at this frequency, adjusting in realtime to the fluctuations in both stream.
    • Wetterberg
      Nov 09 2014 | 3:14 pm
      using "pak" and "mean" is problematic, for two reasons.
      First off, it weighs the faster rate more heavily than the slower, since the faster rate passes on the old slower rate more times through the pak object. So it skews things a lot.
      secondly, mean remembers *all* its input values, which means that if the rate changes it has to counteract the weight of all previous input values to induce a change in output, if that makes sense?
      Good thing is that if we cut away the bpm conversion, you literally have a measurement of the time between each pulse, in milliseconds. Add those together, div. by two, and feed it straight into metro, like so:
    • whorl
      Nov 10 2014 | 4:54 am
      Thanks again Wetterberg, that has helped a lot.
      Do you have any idea how I might overcome the problem of isolating the peaks and troughs in the data stream? If the peak/trough objects are reset too frequently then they will pick up false positives, but not frequently enough and they will miss true positives.
    • Wetterberg
      Nov 10 2014 | 7:23 am
      I'd cut out the entire section, tbh.
      your peaks are above 800. The lead-in to it is like 300. So setting the threshold should be simple without that entire system. Besides, as you might have seen already, it's another section that skews the data by resetting at arbitrary points.
      Ideally there'd be some hysteresis and other good stuff if the *actual* EKG data turns out trickier. I can't really speak to that.
    • whorl
      Nov 11 2014 | 4:23 am
      You've been a huge help :) Thanks.