Подходящий файл нашли. Что дальше?
Обрабатываем его утилитой ebnaut_ifft3b.exe. Но сначала нужно заполнить файл sr.txt
Первое значение в нем точная измеренная компонентом Sample rate correction SR. Но ведь она все время плавает! Да, нужно взять некоторое среднее (на глаз) значение, с точностью до одного-двух знаков после запятой. Это легко сделать. Главое, чтобы единицы герц были правильны. Ну и десятые тоже.
Дальше в файле указываем коэф децимации и длину ффт. И наконец центральную частоту ффт. Все эти параметры мы видели на вкладке FFT.
Получили wav файл. Запускаем ebnaut_rx, заполняем код, crc, длительность символа, количество символов сообщения.
Что указывать в поле
Freq offset? Пусть мы ищем передачу на 8270.005. Насколько нужно сдвинуться от центральной частоты fft (8270.1)? Считаем: Freq offset= 8270.005 - 8270.1= -0.095 То есть сдвигаемся вниз, это понятно.
Ну а в поле
Time offset? Пока не знаем! Нам нужно узнать точное время начала записи в файле. Для этого выбираем
наш wav файл. Запускаем декодер кнопкой Start. Немножко ждем, когда надпись initialising сменится на phase pattern 0,0,0,0, останавливаем. Видим на экране точный момент начала файла.
Посмотрите пример вот здесь:
http://136.su/index.php/topic,6.msg18681.html#msg18681Файл начался в 16:58:49.6, а передача началась в 21:00:00 - как же избавиться от этого сдвига?
С помощью поля Time offset!
Давайте опять считать: 21-17=4 полных часов=14400сек; и еще 60-59=1 полная минута=60 сек, и 60-49.6=10.4 сек от неполной минуты. Всего 14400+60+10.4=14470.4 это "чистый" сдвиг.
Как видим на картинке введено несколько иное значение. Дело в том, что необходимо еще учесть задержки, которые происходят внутри программы SpectrumLab при формировании экспорта fft. Эта задержкаа в точности равна длительности четырех отсчетов получаемого после преобразования wav файла. Она указана на экране: Sample rate 0,342935
Четыре отсчета длятся 4/0,342935=11,664 сек. На эту величину запись искомого сигнала запаздывает, прибавляем:
14470.4 + 11.664 = 14482.064
И последнее: на передаче сектрумлаб вносит задержку начала передачи 0.3 сек. Добавляем сюда и получаем то, что и есть на учебном экране: 14482.364 сек
В общем не мудрствуя, для данных настроек децимации и длины FFT, можно просто к найденному чистому сдвигу добавлять 11,964 сек.
А что, это так важно? Все эти десятые доли при длине каждой посылки в десятки секунд?
Да, важно! При совсем хилом сигнале сдвиг на десятую секунды лишает декода! У нас же прием прямо у самой границы Шеннона получается, тут на волосок сдвинулся и все, ничего не получилось. Сдвинулся в другую сторону - и вот она победа!
PS а почему тут в примере Freq offset=0? Потому что Стефан тогда вещал точно на 8270.1 и дополнительный сдвиг не требуется.