360000 bph

[demartis]

I'd like to add 360,000 BPM for calibrating my mikrograph (with an incredible resolution of 1/100th second). Any suggestions on how to develop this? Only adding it to MAX_BPH and PRESET_BPH doesn't work obviously, how can I enable the code to process such a high beat rate? Thanks

[xyzzy42]

Might help to increase the audio sample rate to 196 kHz, since each audio sample is now a 10x larger portion of the beat.

Using the current lastest code from the branch new-stuff, try taking a look at the spectrograms. It could be that the beats are so close together that the movement components are still vibrating when the next beat occurs. I.e, the watch makes a continuous sound rather than a series of ticks.

There is a debug mode. I would start by looking at the auto-correlation graph, and see if it has distinct peaks.

It it does, then it could be the peak finding heuristics are not allowing peaks that close together to be detected correctly.

The error due to the audio sample size will be significant for the earliest auto-correlation peaks, i.e. 10x higher than normal. It might cause the std dev check to fail.

[demartis]

Tried even new-stuff branch thanks. I added to my presets even 120000 and 180000 for debugging purposes: PRESET_BPH : ... 120000, 180000, 360000, 0 };

When running, it looks like the interface gets stuck when trying 180000 or 360000. Lower values are fine. When trying to close the application, it doesn't close, and I see the following in the console:

/Volumes/work/projects/tg/build/tg-timer

(tg-timer:3990): GLib-CRITICAL **: 13:10:22.132: Source ID 16 was not found when attempting to remove it

(tg-timer:3990): GLib-CRITICAL **: 13:10:22.133: Source ID 17 was not found when attempting to remove it

So I have to force the stop.

When debugging (tg-timer-dbg) I see that it stucks in infinite loop on:

cycle = 39639 new_estimate = 0.000000
max = 16829274.000000 med = -0.000538 cnt = 1
cycle = 39640 new_estimate = 0.000000
max = 16829274.000000 med = -0.000538 cnt = 1
cycle = 39641 new_estimate = 0.000000
max = 16829274.000000 med = -0.000538 cnt = 1
cycle = 39642 new_estimate = 0.000000

[xyzzy42]

Looks like it's getting stuck in an infinite loop.

I suspect it's related to the peak search bounds. An area around the estimated location of the nth cycle is searched. The size of this area is a fixed delta of ±20 ms. That is enough to capture most of the tick sound, without getting to the next tick for most rates. But at your rate it's much too large. It's going to get a negative index for cycle 1. That's no good. And the estimate has dropped to zero, so it's not making any progress.

Look at compute_period(). Change the factor for delta to something like .004. And the divisor of sample_rate in the estimate computation to 250. Add a debug for the initial value of estimate before the for loop starts. And send the debug output to a file so it's possible to go back and see the results in cycle = 1, 2, etc. before it's gotten broken.