KarapuZ
410 NAJB, 10 sec, LSB 400 Hz, USB 400 Hz:
Вадим, по этому иранскому маяку есть информация на стр.120 от NORD73, который его принимал.

KarapuZ
Новая версия. Плановый ввод логгера (1-я его версия). Изменения:

1. Смена фреймворка на 4.7.2 (нужно скачать и установить его) сделано для:
- возможно там у тебя не будет баги с движением картинки и шкалы частот
- лучше поддержка масштабирования (у меня дома монитор 2560Х1440 с масштабированием, на нём "мыльно" было)
2. Шкала времени - белым, лучше читается
3. Добавлены риски времени на свертке. Большие риски - каждую секунду, маленькие - каждые 0,1 секунды
4. Добавлен расчет дистанции и азимута до маяков в базе REW - для этого надо установить QTH-locator (поддерживается только 6-значный). Тогда в колонках Distance и Azimuth обновятся значения.
5. Добавлен фильтр по ID маяка - по всей базе - достаточно просто начать вводить ID в окошко, база будет фильтроваться. Нажать крестик рядом с окном фильтра - фильтр о ID сбросится.
6. Логгер. Для логирования маяка, имеющегося в базе - надо нажать на надпись Log в его строке. Для логирования неизвестного маяка (нет в базе) нажать кнопку "Log UNID (not in REW)". Дальше там будет вроде все очевидно. Можно добавить коммент или изменить значения полей. При нажатии на кнопку Save - в подпапке "Loggings" образуются три файла: логгинг в виде скриншота (пример ниже), логгинг в виде текста и бинарный файл со сверткой. При слдедующем запуске программы (или если закрыть окно NDBView и открыть его) в списке маяков из базы в колонке Received будет стоять плюсик напротив маяков, которые были логированы (идентифицируется по триплету - "KHZ+ID+ITU").




Пример файла логгинга в формате скриншота:


Планы на следующую версию:
1. Предпостроение всех автоинтервалов. Далее прощелкивание найденных маяков - надо будет задать порог уровня автокорреляции, далее можно просматривать только сигналы, которые имеют уровень автокорреляции выше этого порога.

Просьба так же писать хотелки - буду их собирать, анализировать, менять прогу с их учетом.

vinipu
по этому иранскому маяку есть информация на стр.120 от NORD73
Ок, спасибо Вам и NORD73. Тогда, возможно и 334 NASB тоже из этой "серии".

wazzoo
Новая версия. Плановый ввод логгера (1-я его версия). Изменения:
Выглядит заманчиво! Буду разбираться.

KarapuZ
С логгером надо в первую очередь разобраться. Т.к. фактически это основа всей аналитической работы над маяками. Т.е. если принцип/формат самого логгинга годится - дальше он примерно таким и останется, можно будет нарабатывать собственную базу наблюдений. А уже над базой я буду делать примочки - сводную таблицу и конвертацию её в список логгингов, отправляемых редакторам REW, как пример.

wazzoo
С логгером надо в первую очередь разобраться. Хорошо, Иван. Машины просто все заняты пока до ночи. Вопрос - установка фреймворка
4.7.2 может как-либо негативно отразится на работе других программ?

Ещё один "Unid", 422 AW, 4,7 sec, LSB 400 Hz, USB 400 Hz:

С ним непонятно, то-ли Будёновск сменил частоту, то-ли Аральск активирован, то-ли ещё что-то другое...

Вопрос - установка фреймворка
4.7.2 может как-либо негативно отразится на работе других программ?

Это вряд-ли. Он не перетирает имеющийся, лишь доставляет новые версии библиотек. А все программы работают с той версией, под которую создавались (т.е. те, что под фреймворк 3-й например, работают с файлами от 3-ей версии и т.д.)

Еще пример сигнала на уровне шумов, еще и кривого. Гармоника полького NPR. Вначале нашел гармонику - по ней вышел на основной сигнал. Станция, конечно, малоинтересная - но пример вытягивания сигнала, который и сам то по себе еще и кривой

Гармоника:


Основной сигнал:

Сравнение настроек FFTSize и Overlap на слабом сигнале OL:

Исходно взятые наобум рекомендации в 4 Герца 90% / 2 Герца 95% - вполне рабочие, среди лучших.
Т.е. 4 Герца и 90% оверлэп можно рекомендовать как вариант настроек лучший по соотношению цена/качество - дает относительно небольшие файлы, строится быстро, меньше занимает памяти при анализе, "прощелкивание" файла идет быстрее.
А для наилучшего качества можно рекомендовать 2 Герца и 97% оверлэп.

А вот дальше 2-х Герц увеличивать разрешение не стоит - качество снижается. А точнее - оконная функция Блэкман-Харрис уже не справляется, вероятно нужна другая оконная функция.

Понятно, реальные значения Герц будут отличаться от 2/4 - зависит от ширины полосы записи. Но стоит просто брать близкие значения, возможно корректируя оверлэп пропорционально. Т.е. если будет ряд значений 1,5 / 3 / 6 Герц - то можно брать 3 Герца и оверлэп 95 например.

wazzoo
Пробую логгировать в новой версии проги - очень удобно, особенно по известным сигналам процедура происходит всего в несколько кликов мыши. Хотелки пока не сформировались, нужно время.
Исходно взятые наобум рекомендации в 4 Герца 90% - согласен, как "рабочий" вариант самое то,
а для "интересных" случаев с "кандидатом на DX" - можно рекомендовать 2 Герца и 97% оверлэп.

"Новичок", 323 AE, 30 sec, USB 400 Hz, LSB 400 Hz. В REU пишут, что это наш аэропорт Амдерма,
действительно-ли? Проходит очень ярко на Кубани, а дистанция выходит порядка 3000 km...

Принят 20190114 в 23:06Z.

Проходит очень ярко
Новый термин в нашем деле :)
Неплохой DX! Да - получается, для маяков с таким длинным интервалом надо от 20 минут записи по хорошему - здесь всего-то 45 интервалов уместилось на 22 минуты

wazzoo
получается, для маяков с таким длинным интервалом надо от 20 минут записи по хорошему - здесь всего-то 45 интервалов уместилось на 22 минуты
Да, 20-30 минут записи для маяков с интервалом ID последовательности 15-30 sec весьма желательны. На
слабых сигналах коррелятору "проще" принять решение на более длительной выборке данных. Конечно, это влияет на размер файлов спектры, но результат того стоит.
Валенсия, 340 PND, 15 sec, ещё один такой из примеров:

KarapuZ

323 AE - это МЛСП им. Ю. Корчагина (Каспийское море). У Амдермы (AE/FW) частота 326 кГц.

МЛСП им.Корчагина:
MLSP IM YU KORCHAGINA
Координаты С44°54.7902' В048°57.4602' Частота 323 kHz АЕ
Приводные авиамаяки - Страница 88

Антенна приводного маяка и Плавучее Нефтехранилище им.Ю.Корчагина:
http://www.qth.spb.ru/forum/viewtopic.php?p=52505#p52505

SDF
NORD73
Спасибо!

wazzoo
Коррелятор "взял" Гренландию, 372 OZN (5330km), причём без особого труда:

Похоже, Бруней был не случаен при обработке этой методой, и Михаил прав - это начало:).
Это IQ от 20190114_230601Z.
Кстати, обнаружил проблему при "сшивании" файлов спектры во вьювере -
образуется сдвиг в свёртке. Приходится мои двух гиговые IQ FLT32 файлы архива (по ~6 минут каждый),
перезаписывать в 16 бит и в один длинный файл. Отсюда пока в логе время приёма не соответствует истинному. Буду теперь пробовать писать диапазон маяков сразу в 16 бит и длинным файлом.

Коррелятор "взял" Гренландию
Поздравляю! Еще один крутой DX
причём без особого труда:
Да - суммарный размах 1000дБ при размахе шумов примерно в 200 дБ. Средний с/ш примерно 4,5..5 дБ в полосе 4,7 Герца. На свертке еще один сигнал виден послабее - с периодом секунд 6,5 (?) - пражский L?

Кстати, обнаружил проблему при "сшивании" файлов спектры во вьювере -
образуется сдвиг в свёртке
Я у себя тоже наблюдал такое - думал, особенности моих файлов. Хотел сделать плавную подстройку сшивки. А сейчас вот задумался и понял, почему этот сдвиг появляется. Дело в оверлэпе. Т.е. представим размер FFT в 64к и оверлэп 90%. Последняя строчка спектра - это конечное время файла минус 64к отсчетов. Предпоследняя строчка - это конечное время минус 64к и минус 6,4к отсчетов. Т.е. разница между строчками - 6,4 к отсчетов.
А при добавлении файла у нас первая его строчка - это конечное время предыдущего файла. Т.е. разница между последней строчкой предыдущего и первой нового - уже 64к. Вот этот сдвиг - равен времени 9 строчек спектра.
Буду убирать завтра - не спеши пока переходить на новый формат записи, сдвиг по любому поборем.

wazzoo
Спасибо!
Да, там пражский 372 L, но период у него 8.02 sec:

Кстати и гренландец и чех в USB полосе тоже видны.

387 GZ, 8,124 sec, LSB 1019 Hz, USB 1018 Hz, Ботсвана, такое возможно? Всего один рапорт нашёлся
по этой последовательности.
Принято 20190114_230601Z, прошёл сигнал и в LSB и в USB:



391 DDP, 10,436 sec, LSB 1027 Hz, USB 1047 Hz, Пуэрто-Рико, Аэропорт Интернасьональ Луис Муньос Марин, мы тебя слышим видим. Правда, там мощность указана в REU как 3 кило, но тем не менее,
дистанция ~9600 km. Коррелятор определил интервал только в USB полосе, в LSB сильный сигнал "поверх",
поэтому значение там можно подставить уже априори известное, манипуляция просматривается:
LSB


USB выглядит без помехи явно веселее

Ботсвана
Пуэрто-Рико
Ого, вот это дистанции! На простой LW
По Ботсване - параметры совпадают с базой. Принято в ЮАР один раз - так что вполне похоже - т.е. это явно откуда-то с того региона. Интересен конечно источник данных о самом маяке (позывной, частота, локация)

Буду убирать завтра - не спеши пока переходить на новый формат записи, сдвиг по любому поборем.
Вадим, лови пофикшенную версию:
https://yadi.sk/d/CoDWhpm8Vw7MWA
Замени ехе-ник этим.
Проверял у себя на 90%-ных файлах, склеивает идеально :)
"Правильно" на все 100 будет работать на оверлэпах, у которых 100 / (100 - overlap) равен целому числу. Т.е. при оверлэпе 90, например, мы имеем шаг 10%. Соответственно нам надо достроить ровно 9 недостающих линий. Если оверлэп 95 - то имеем шаг 5%, достроить надо 19 недостающих линий. Короче - нормально будет работать на оверлэпах 80,90,95,96,98,99

На остальных будет тоже значительно лучше чем сейчас, но будет небольшое смещение (намного меньшее чем без этой доработки). К примеру, на оверлэпе 92% мы имеем 11,5 линий для достройки. 11 линий мы достроим, останется смещение на 0,5 линии - это немного, без достройки смещение было бы 11,5 линий - т.е. в 23 раза больше.

Если на практике будет необходимость, можно добавить в программу механизм тонкой подстройки разрывов. Такие разрывы могут возникать между файлами (ты наверное знаешь этот эффект - когда дециматор отказывается кушать последовательные файлы) и даже в рамках одного файла могут быть пропуски сэмплов. Т.е. с ткаим механизмом можно будет взять, к примеру, "эталонный" маяк и вручную подправить все сдвиги до идеала - используя этот маяк как шкалу времени (в самом файле IQ есть только отметки начала и конца записи). Далее это будет учитываться на всем полотне спектра.

wazzoo
Замени ехе-ник этим.
Благодарю, Иван!
Из дальнего ещё нашёл в IQ за 14 января:
396 JC, Канада, судя по инфо из REU


394 IZA, Ибица

Канада
Ага, Нюфа, отлично! Ибица довольно стабиль прошла
Я пока мечтаю о Юконе :) допилю предпостроитель корреляций и начну наконец свой архив смотреть... А то с прогой не остается времени собственно на прием :)

Ага, Нюфа, отлично!
:), да, ещё про Канары забыл, тоже приняты, но можно сказать, на грани читаемости, 389 BX, La Palma:


За пару вечеров, в неспешном порядке просмотрел 100 kHz спектра - от 300 до 400 kHz, более 400 ID нашлось,
наверное, если найду силы и терпение, накатаю лог к отправке в REU. Но нужно добить ещё 100 kHz спектра.
Много Ирана, есть Сирия, Ливия, Пакистан. Вот север и восток закрыты у меня в этой позиции, увы.

если найду силы и терпение, накатаю лог к отправке в REU.
Есть вариант проще. Напиши, в каком формате этот лог должен быть - я в программу вставлю генератор. Собственно, так и планировалось - но мне нужно знать, в какой вид сконвертировать список логов. Вот - время пришло вставить генератор лога для REW

но можно сказать, на грани читаемости
А это как раз супер-пример того, что может сделать твой метод свертки + автокоррелятор. Без автокоррелятора этот сигнал прошел бы мимо обработки, а без свертки не опознали бы :)

wazzoo
Напиши, в каком формате этот лог должен быть - я в программу вставлю генератор. Собственно, так и планировалось - но мне нужно знать, в какой вид сконвертировать список логов. Вот - время пришло вставить генератор лога для REW
Нужно у Виктора уточнить, я последний лог года три назад слал. Яху-групп вроде как жива, сейчас зашёл
туда - движения есть. Если в проге будет формирователь лога для отправки, это здорово сэкономит время.


vinipu
Виктор, уточните пожалуйста, такая форма лога будет правильной?

Дело в том, что прога Ивана оперирует всеми необходимыми данными из примера выше (за исключением поля "Format" по известным сигналам.
Генерация таких данных в форму на автомате значительно упростит процедуру .

Если в проге будет формирователь лога для отправки, это здорово сэкономит время.

Да, конечно - это была одна из вещей, ради которой я занялся логгером, и которая учитывалась при реализации механизма логирования.

KarapuZ
wazzoo

Я отсылаю логи в таком виде:
2019.01.22 01:33 324 KFK Afyon, TUR 1900
2019.01.22 00:08 328 HIG San Sebastian, ESP 3005 Y
2019.01.22 00:08 337 MY Myggenaes, FRO 2570
2019.01.22 01:35 342.5 NWI Norwich, ENG 2269
Дата, время UTC, частота и позывной желательно представлять в таком виде (с точками, двоеточиями-редактора просят), остальное -на усмотрение. Но многие присылают и в другом виде -это же не "обязаловка"...
А вообще можно написать Пату и проконсультироваться с ним.
Вадим,результаты великолепные!

можно написать Пату
Написал на ломаном английском сюда: aunumero73@gmail.com - Виктор, это верный адрес?

wazzoo
Написал на ломаном английском сюда
Да, с форматом лога надо определиться конкретно, я сейчас в яху-групп глянул на присылаемые логи, у кого
как - дата и через точки и через тире и через двоеточие. Время тоже, то с двоеточием, то в виде 1234.
Я бы и сюда на сайт в базу частот лил данные перво-очерёдно в нашу альма матер, абы они в автоматической форме принимались по NDB хотя-бы. А так, пока набьёшь десяток частот в эту форму вручную - битый час проходит. А если частот несколько десятков, то это уйма времени...