watch calibration
1.0.0
これは、時計または時計の録音を分析し、それがどれだけ遅くなるか、速く実行されるかを示す小さなプログラムです。これを使用して、たとえば携帯電話を使用してそのカチカチ音を記録して、機械式の時計を調整できます。
$ python forier.py recording.wav 最初の推測：6.0 p/m 0.00606 Hz 更新された推測：5.9998549 p/m 1.88e-05 Hz エラーは-2.1秒 /日です
ファイルのrecording.wav 、モノラルサウンドファイルである必要があります。私の携帯電話には、組み込みのマイクを使用してオーディオを記録する「音声メモ」プログラムがあります。この目的のために非常に敏感です。
質の高い録音を使用すると、次のようなものが表示されます。
上部パネルには、録音の最後の10秒が表示されます。これにより、データの品質を評価できます。ここでは、個々のダニをはっきりと見ることができ、この時計は毎秒6回チェックしています。この例では、おそらく信号対雑音比は10ish程度です。
左下のプロットは、録音のフーリエ変換を示し、0.5〜10 Hzの範囲にズームインしました。このプロットのスパイクは、時計のティック周波数に対応しています。それは1秒あたり6倍に近く、どこにいるはずです...しかし、どれほど近いですか？
右下のプロットは、周波数を高い精度に推定するために使用されるピークへの適合を示しています。この精度は、メカニカルウォッチの周波数の安定性と簡単に一致します（これは、温度や方向の違いによりわずかに変化します。
（非常に）低品質の録音を使用すると、代わりに次のようなものが表示されます。
ここでは、個々のダニが騒音に埋もれています...しかし、プログラムはまだそれらを選びます！ただし、同じレベルの精度に達するには、より長い録音が必要です。
いくつかの異なる方法で生成された合成信号を使用してプログラムをテストしました。結果は上記のプロットにまとめられています。
測定スケールの部分的な不確実性は、記録の長さと（3/2）電力までの状態になります。また、測定の品質にも依存します。したがって、できるだけ録音を作りたいのですが、量で品質を補う方が簡単かもしれません。 5分間のくだらないデータは、完璧なデータのほぼ30秒であることがわかります。しかし、時計と電話を靴下の引き出しに5分間放置するのは、外に出てより良いマイクを購入するよりもはるかに簡単です。だからそれはあなた次第です。
データが非常に悪いので、録音でダニを聞くことさえできない場合は、問題が発生している可能性があります。静かな場所で再試行するか、より良いマイクを見つけてください。 （そして、もちろん、時計が実際にチェックされていることを確認してください。）
点線の黒い線は、実際の時計の測定値を示しています。 1日に数秒で実行するように調整したかったので、30秒または1分の録音が適切であることがわかりました。レギュレーターバーを微調整し、1分間録音し、再びナッジするなど、満足している答えが得られるまで。私はそれを1日あたり約2秒以内に規制しましたが、それが私の目標でした。これは、録音の期間にわたって100分の1未満のダニのエラーにつながります。これは非常に印象的だと思います。
上記のプロットは、Audacityを使用して生成された合成「ティック」信号を使用したテストを示しています。これは、プログラムによって報告された不確実性が、真の「1-σ」の不確実性のかなり意味のある表現であることを示しています。
コードは非常に簡単であり、ほとんどの努力は、人間の介入なしに予想通り実行することに費やされました。 Iフーリエは、入力信号を変換してピーク周波数を測定します。変換する前に、ガウスウィンドウで信号を押します。窓の形状を選択して、周波数ピークが幅が〜3の周波数ビンのガウス形状になるようにします。これは、ガウスプロファイルを使用すると正確に適合し、真の周波数の適切な推定値が得られます。プロットを見て、それがどれほどうまく機能しているかを理解することができます。
Scipy関数を使用して、ピークを自動的に識別しますが、これは非常にうまく機能しているようです。
そして、FFTの「最適な」長さを特定しようとします。これまでのところ問題はありません。
結果は、クロックの「カチカチと音を立てる」音を適切に解決できない場合を除き、サンプリング頻度に敏感ではありません。しかし、プログラムはかなり速く実行されるため、44.1 kHzサンプリングレートだけを使用しない理由はありません。これはかなり標準です。
