Where does table data come from?

[PrismaPhonic]

Hi!

I would like to translate this into a Rust crate. After pouring over the repo, I understand most of it, but one thing I don't understand is where this table data came from:

https://github.com/ISUE/PitchPipe/blob/d053a59b0027e021230a12a397835d0e5ac3e5d4/filters/euro60.table.js#L3

It appears to be useful for a 60 hz signal. Is it useful for any 60 hz signal? How would I produce similar table data for other signal types?

[PrismaPhonic]

@crpittman

[crpittman]

That is a grid representing the parameter space for the filter for 60 hz data. It covers fixed ranges of values for jitter, cutoff, and beta as described in this snippet:

PitchPipe/filters/euro.js

Lines 35 to 58 in d053a59

	Grid = function(table) {
	var table = table;
	/**
	*
	*/
	this.precision = function(jitter, cutoff_hz, beta) {
	// Jitter level goes up in steps of 1/3 start at 1/3
	jIdx = 3.0 * jitter - 1.0;
	jIdx = Math.min(jIdx, 15);
	jIdxLo = Math.floor(jIdx);
	jIdxHi = Math.ceil(jIdx);
	// Min cutoff goes up in steps of 0.05 starting at 0.05
	fcIdx = cutoff_hz / 0.05 - 0.05;
	fcIdxLo = Math.floor(fcIdx);
	fcIdxHi = Math.ceil(fcIdx);
	// Beta from 0 to 1.0,
	vals = this.GetBetaIndex(beta);
	bIdx = vals[0];
	bIdxLo = vals[1];
	bIdxHi = vals[2];

I believe this should enable appropriate search for parameters fitting any 60 hz signal. However, I am uncertain of how you would generate this parameter grid for other signal types. I believe it is calculated from the 1€ which we then cached in a 3D table. @etaranta do you recall how this grid was generated?

[PrismaPhonic]

Ahhh, that's very useful to know! I was under the impression from reading the paper that it might need to be generated based on the noise variance of the input signal, but it sounds like I misunderstood that section of the paper some

[PrismaPhonic]

One other question I have regarding handling ringing. I noticed something a bit funny in the code:

https://github.com/ISUE/PitchPipe/blob/d053a59b0027e021230a12a397835d0e5ac3e5d4/filters/euro.js#L234C1-L240C1

Multiplying by 0.0 in this case make the (1.0 - alpha) preceding it useless based on order of operations. I'm guessing that was a mistake?

I wasn't able to find anything in the paper regarding what formulas were used to handle ringing

[PrismaPhonic]

I finished porting the library to Rust: https://github.com/PrismaPhonic/Pitch-Pipe-RS

I was able to build a small Apple watch app using the rust library (over FFI) and ran the calibration multiple times getting the same result every time (I made sure to set the sampling rate to 60hz).

I feel very unsure that table is usable for any 60 hz signal because the tuned values I got were really bad for smoothing out the accelerometer data.

I got a min cutoff of 0.1 hz and a beta of 0.00005. When I set this up for the use case of exercise repetition counting, The data was wayyyyyy oversmoothed. Peak acceleration was not retained. The tuning settings indicated that I had max peaks around 0.5 (G's of force, user acceleration, so removing the effects of gravity), but the final settings plugged into a one euro filter ended up surpressing the peaks all the way down to 0.12. Previously with the normal one euro filter defaults (1 hz min cutoff and beta of 0.007) I was getting concentric peaks that were more than double the eccentric peaks for my test case, which was to be expected.

I also found that the tuned settings caused significant lag, which is to be expected with a min cutoff and beta values set so low.

I can only conclude that either the table is not appropriate for all 60 hz use cases to determine precision, or the pitch pipe tuning method is wildly inappropriate for coming up with one euro filter settings for smoothing accelerometer data

[PrismaPhonic]

To elaborate on the lag bit - I had max lag set to 0.08 (80 milliseconds) and am seeing lag in the order of 6 seconds. So the auto tuner seems to not achieve desired lag targets and doesn't seem to preserve max signal either - and I can only assume that the table isn't appropriate for all 60 hz use cases, or the study data was fabricated. In any case, I'm going to update the README for my port advising that no one use it until I can get this sorted

[etaranta]

Hi Peter, Sorry I'm not in position to properly reply. Unfortunately, I don't have access to my old source and I'm away from home for a while. So I'm trying to recall some details from memory. First, iirc, we estimate lag by measuring the filter's response to an edge where the signal drops from an estimated higher amplitude down zero. A filter will end up bouncing around the target, and so we can optionally measure how long it takes until the ringing falls below the noise threshold. The zero in that calculation represents the filter's strength in suppressing noise to zero. (Low pass of noise on a zero signal) That zero was left in to show in code what we were averaging with, but I agree in retrospect, this was not as clear as it could be. Second, the table was generated for our use case, but will work in a lot of situations. Iirc, we used the techniques in the paper to estimate the maximum amplitudes and used pitch pipe to estimate precision for various euro filter values, which we cached in the table. I've not worked with watch data specifically, but it's possible the low frequency data is very different from our desktop use case, and this is why the result is suboptimal. In other situations, I used pitch pipe directly without caching data, such as with Kinect and Vive data. You may want to do the same here. The general process is: 1. Estimate amplitude of low frequency data (I typically use 1, 2, and 3 hz) 2. Estimate noise 3. Generate synthetic signal based on 1&2 4. Run your filter over the synthetic signal and measure results. The fourth step can be very application-dependent. This where you decide what matters most: precision, lag, overall shape, etc and measure your filter's effect on the performance measure. In our case, we allowed a certain maximum lag and selected the parameters that minimized errors within that range. I suspect the approach we took won't necessarily be optimal for your case. Sorry I cannot dive in deeper at this time. If you have more questions, I will try to reply, but my responses will be somewhat sporadic for awhile. Respectfully, Eugene

…

On Sat, Apr 13, 2024, 12:46 Peter Farr ***@***.***> wrote: To elaborate on the lag bit - I had max lag set to 0.08 (80 milliseconds) and am seeing lag in the order of 6 seconds. So the auto tuner seems to not achieve desired lag targets and doesn't seem to preserve max signal either - and I can only assume that the table isn't appropriate for all 60 hz use cases, or the study data was fabricated. In any case, I'm going to update the README for my port advising that no one use it until I can get this sorted — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQVXKEO3WUDLO6BTVQQ5S3Y5FOQFAVCNFSM6AAAAABGDB7VK2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJTGY4TQNZZGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>