Это небольшая программа, которая анализирует запись часов или часов и рассказывает, как она медленно или быстро работает. Вы можете использовать это для регулирования механических часов, используя, например, сотовый телефон для записи тикания.
$ python fourier.py reform.wav Первоначальное предположение: 6,0 п/м 0,00606 Гц Обновлено догадается: 5.9998549 P/M 1.88E-05 HZ Ошибка --2,1 секунды / день
File recording.wav
должен быть моно звуковым файлом. У моего мобильного телефона есть программа «Голосовое меморандум», которая записывает звук с использованием встроенного микрофона. Для этой цели достаточно чувствительно.
С помощью хорошей качественной записи вы увидите что-то вроде этого:
На верхней панели показаны последние 10 секунд на записи ... это позволяет оценивать качество ваших данных. Здесь вы можете четко увидеть отдельные тики, и что эти часы тикают 6 раз в секунду. В этом примере соотношение сигнал / шум, вероятно, составляет около 10 лет.
В нижнем левом графике показано преобразование Фурье записи, увеличенное до диапазона 0,5-10 Гц. Спайк в этом сюжете соответствует частоте клещей часов. Это близко к 6 клещам/в секунду, где это должно быть ... но как близко?
Нижний правый график показывает соответствие к пику, используемое для оценки частоты до высокой точности. Эта точность легко соответствует частотной стабильности механических часов (которые немного изменяются из -за различий в температуре и ориентации, среди прочего).
С помощью (очень) низкой качественной записи вы вместо этого увидите что -то вроде этого:
Здесь индивидуальные клещи похоронены в шуме ... но программа все еще выбирает их! Однако вам нужна более длинная запись, чтобы достичь того же уровня точности.
Я проверил программу, используя синтетические сигналы, сгенерированные несколько различных способов. Результаты суммированы на графике выше.
Дробная неопределенность в масштабах измерения падает с длиной записи до (3/2) мощности. Это также зависит от качества вашего измерения. Таким образом, хотя вы хотите сделать столь хорошую запись, насколько это возможно, может быть легче восполнить качество с количеством. Я считаю, что 5 минут дерьмовых данных примерно в 30 секунд идеальных данных. Но оставить свои часы и телефон в одиночестве в ящике для носков на 5 минут намного проще, чем выходить на улицу и покупать лучший микрофон. Так что это зависит от вас.
Если данные настолько плохие, что вы даже не можете услышать клещи в записи, у вас могут быть проблемы. Попробуйте еще раз в более тихом месте или найдите лучший микрофон. (И, конечно, убедитесь, что ваши часы на самом деле тикают.)
Пунктирная черная линия показывает измерения настоящих часов. Я хотел настроить его, чтобы работать с несколькими секундами в день, и нашел запись 30 секунд, или одна минута была достаточной для этой задачи. Вы подталкиваете стержень регулятора, записываете на минуту, снова подталкиваете и так далее, пока не получите ответ, с которым вы довольны. Я регулировал это примерно через 2 секунды в день, что было моей целью. Это переводится на ошибку менее чем на соту, я думаю, что довольно впечатляет, что довольно впечатляет!
На графике выше показан тест с использованием синтетического сигнала «тика», сгенерированного с использованием Audacity. Это показывает, что неопределенность, сообщаемая программой, является довольно значимым представлением истинной неопределенности «1-σ».
Код довольно прост, и большая часть усилий пошла на то, чтобы сделать его предсказуемо, без какого -либо вмешательства человека. Я преобразую входной сигнал, чтобы измерить пиковую частоту. Перед преобразованием я ударил по сигналу гауссовым окном ... Я выбираю форму окна, так что частотные пики будут иметь гауссовую форму с шириной ~ 3 частотных бункеров. Это может точно соответствовать гауссовому профилю, что дает хорошую оценку истинной частоты. Вы можете посмотреть на сюжеты, чтобы понять, насколько хорошо это работает.
Я использую функцию Scipy для автоматического идентификации пиков, что, кажется, работает довольно хорошо.
И я пытаюсь определить «оптимальную» длину для БПФ. Пока нет проблем с этим.
Результаты не чувствительны к частоте отбора проб, если только они не слишком низки, чтобы адекватно разрешить «тикающий» звук часов. Но программа работает довольно быстро, поэтому нет никаких причин просто использовать частоту отбора проб 44,1 кГц, которая довольно стандартная.