Журнал радионаблюдений метеоров

[1212Lupus]

feliix, спасибо за информацию о своей системе -- очень интересно! Я так понимаю, что вы радиолюбитель? На счёт оптимизации -- надо подумать. Я имел опыт замены ПЧ-фильтра магнитолы (стандартный с полосой 250 кГц заменил на более узкополосный). Сигнал сильно искажался, но сигналов становилось больше -- т.к. селективность улучшалась.

Что касается RR. Я думаю, для FM-сигналов это самая лучшая на сегодня программа (если не заморачиваться определением длительности сигналов). Хотя, конечно, надо её доработать на стабильность. Для TV самой лучшей является SL. Я пробовал много программ для обоих методов, и такое моё мнение. Сейчас я всецело за TV -- но это пока не уничтожат в Европе всё аналоговое вещание. Потом снова вернёмся к FM, видимо... 

P.S. Термин RS, который я применил, переводится как "radio-meteors", т.е. радионаблюдения метеоров -- для краткости. Не хочется называть MS, как принято у НАМ'ов -- всё-таки немного разные цели методы.

[Andrey Prokopovich]

Что-то я не припомню такого. 

В "ASTRO-Ty$@" писал 28.01.2010 20:59:24

За 5 суток 660 сигналов при среднем фильтре импульсных помех.  Диаграмму не строит.
Так там же идет нумерация  мрсов. Сразу все видно.
 

Ваня, без обратной связи от пользователей ничего улучшить не получится, это, кстати всерсия, в которой мной не вносилось никаких изменений, просто собрах ехе'шник в новой среде программирования и добавлен дебаггег - для отлова места падения.
Как я понял программ не упала. В таблице был список событий, особенно имена файлов интересуют, если нет, то этот баг я нашел совсем недавно..

Значит я не верно понял насчет улучшения RR. Вобщем, очень интересует ответ на вопрос какое время без глюков работает софтина неделю, месяц или может год
Андрей, планируешь ли улучшить программу? Как повится новая версия дай знать. Это я видать погорячился насчет топки RR.  Не знаю что произойдёт быстрее - или я разживусь приемником с SSB или появится адекватная безглюковая версия RR. 

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

[felix]

Я понял Виталий. Тут вот выше такая строчка ( B SL есть скрипт, который для наблюдений с SSB на TV позволит автоматизировать работу. Для FM только ручной подсчет. )
 Я все же попытаюсь продетектировать FM как SSB . Очень жалко терять мощность несущей надо только технику подготовить к этой процедуре . SL конечно классически универсальна , только ей тоже на вход желательно  соответствующее подавать блюдо.  Вот я и хочу попробывать ей FM в SSB соусе предложить . Хорошо бы еще от ограничителя избавиться , а то ведь безжалостно срезается самый крутой и мощный  передний фронт мрса.

[felix]

Правильнее наверное сказать не как SSB  , а как CW  (Телеграфный сигнал) При этом и несущая и боковушки будут смещены на 500-1000гц и несущая зазвучит как в случае с ТВ  даже если диктор или музыка молчат.  Ну это все понятно . Сигнал конечно станет неразборчив ,но ведь нам и программе важно только есть он или нет. В отношении ,что будет если ТВ переведут на цифру, то главное чтобы мощность не уменьшили. Сигнал конечно будет совершенно не узнаваем , но я опять же повторяю главное для программы -  есть он или его нет. Фактически он и так жутко искажается и доплером и резкой сменой интенсивности ,так что можно думаю быть на этот счет спокойными. Метеоры что-то  совсем на убыль пошли . Интересно, что это был за всплеск активности позавчера. Не знаете случайно какой-нибудь сайт, где можно посмотреть текущую активность . Я  что- то ничего найти не могу. Все. Пока.

[КiteKat]

Я вот смотрю, в РР как-то странно с созданием таблицы, то ли я не разобрался. Начинается с того, что при нажатии "создать новую таблицу" надо бы добавить возможность задавать местоположение таблицы и её название, а не просто автоматически присваемое неинформативное "noname".

Имя таблицы можно и нужно изменить при её сохранении.  Много лет назад мне показалось такое решение удачным. 

[КiteKat]

Еще отрицательный момент, что программа "собирает" события в своей таблице (StringGrid), и периодически записывает в файл, но не дописывает, а переписывает с ноля. С каждым новым ивентом процесс замедляется, а если их будет 100... 500 тысяч - это уже процесс, с БД такого не будет в принципе.

Когда все только начиналось, о круглогодичных наблюдениях речи не было. Нужна была программа, которая как-то что-то ловит. А сейчас, с новыми запросами пользователей, конечно, и формат таблицы и способ хранения данных "устарели". Это я так оправдываюсь.

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

[Andrey Prokopovich]

Когда все только начиналось, о круглогодичных наблюдениях речи не было. Нужна была программа, которая как-то что-то ловит. А сейчас, с новыми запросами пользователей, конечно, и формат таблицы и способ хранения данных "устарели". Это я так оправдываюсь.

Нормально, это сейчас как раз меняю, будет на БД SQLite CSV. 

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

В принципе, что бы грамотно развивать проект, можно скажем так разделить правки интерфейса и математической обработки, если у Вас есть конечно желание заниматься (я в них ничего не трогаю).

[felix]

to Сергей . Два слова в отношении концепта для SSB . Я тут выше немного пофантазировал
в отношении оптимизации обнаружителя сигнала . К сожалению я не знаю ,как у вас это все происходит в программе  . Программа мне лично нравится ,но надо бы ее сделать более понятной для оптимальной настройки .Тут ведь и передний фронт мрса , как самый мощный ,не хочется терять и несущую, хоть в FM  она не такая уж выразительная по мощности как в АМ . Может даже добавить переключаемое окошко FM/AM/SSB/CW. илинию порога компаратора как  в HR Если с помощью гетеродинирования сместить спектр немного выше герц на 500-1000несущая должна уже быть слышна с частотой величины этого смещения ,подобно телеграфному немодулироанному сигналу CW . А это уже будет  дополнительный весомый довесок  в отношение сигнал\шум в системе.
С фильтрацией импульсной помехи тоже надо оптимально выбрать стратегию чтобы не "выплескивать с водой ребенка", как говорят в народе .Это ведь могут быть короткие  ,но весьма мощные импульсы от ненасыщенных и поэтому практически как бы импульсных метеоров.  Для эксперимента я поставил у себя заведомо "жесткий" режим чтобы получше отсеить "ложняки" .Количество регистраций резко упало .Какой тут оптимальный критерий при установке в окошке нужной цифры?.Конечно хорошо бы промоделировать ситуацию в разных вариантах и оптимально настроить обнаружитель, а грубо говоря выжать из него все что можно еще  выжать.
В качестве пожеланий к программистам- было бы очень хорошо   автоматически выводить на сайт 3-5 дней наблюдений из надежного источника и обновлять информацию в текущем режиме , как к примеру выводится информация по солнечной активности на сайте http://www.sec.noaa.gov/today/html сохраняя в архиве прошедшие наблюдения.
Все ,пока, а то уже слишком много злоупотребляю вашим вниманием .Удачи всем.

[lazyBSD]

Андрей, твоя модификация программы есть в открытом доступе?

[Andrey Prokopovich]

Андрей, твоя модификация программы есть в открытом доступе?

Виктор, есть тестовая сборка, ибо процесс перехода на БД как раз идет.

[lazyBSD]

А что за структура данных, что понадобилась БД? CSV нельзя обойтись?

[Andrey Prokopovich]

А что за структура данных, что понадобилась БД? CSV нельзя обойтись?

Структура данных простая. Потому и СУБД выбрана простая, а вообще БД - для удобства выборки ибо из тексового файла не выбрать данные для нормального отчета, в настоящее время отчет неоднозначный т.к. (цитата из файла отчета):

Программа не учитывает возможные перерывы в записи.  Также не учитываются часовые интервалы с 0-вым количеством сигналов.

А еще это избавит от множественных файлов событий, все будут в одной таблице БД, можно выбрать для анализа/отчета любой произвольный период, сравнить произвольные периоды между собой и т.п., что не возможно сделать при настоящей файловой структуре хранения. Сначала была мысль сделать некое объединение файлов событий - но это решение ч-з.. 

[lazyBSD]

Сначала была мысль сделать некое объединение файлов событий - но это решение ч-з.. 

Так напиши лучше отдельную разгребалку файлов -> .sql файл, типа:

insert into foo (f1,f2,f3,f4.... ) values (n1,n2,n3,n4...);
....

Это быстрее, проще, универсальнее и правильнее.

[Andrey Prokopovich]

Ты имеешь ввиду разгребалку фалов нынешнего формата evt? Если не делать на БД, то все равно надо бы уйти от старого формата, на тот же CSV, а уж его импортировать можно куда угодно.

[lazyBSD]

Ты имеешь ввиду разгребалку фалов нынешнего формата evt?

Да.

Если не делать на БД, то все равно надо бы уйти от старого формата, на тот же CSV, а уж его импортировать можно куда угодно.

Так я думал, что ты стараешься не поломать evt. Если к нему не привязываться, то, конечно, лучше сделать CSV, а дальше -- как кому больше нравится.
Только писать нужно автоматом в файлы, названия которых будут, например, rr_Station_ID_дата-время-запуска-программы.csv .

[КiteKat]

to Сергей . Два слова в отношении концепта для SSB .
...
 

felix, до переключателя АМ/SSB/FM ещё как до Луны. У вас, у наблюдателей, совершенно разная техника, антенное хозяйсвто, и разные методики наблюдений, с которыми и вам самим до конца не все ясно.  А хотите вы и того, и этого, и побольше. 
Придется много времени потратить на экспериментальную работу. Сколько много, я даже не знаю. Нужно понять, уразуметь, что именно программа должна фиксировать. А чего она фиксировать не должна. Вы попробуйте составить формальное описание отличительных признаков полезного сигнала. Это не 5-и минутное дело.

По настройке могу сказать следующее. У меня лично качественно лучшие(субъективно)  результаты получались при среднем фильтре. Но это у меня. Чтобы уменьшить количество ложных срабатываний, играйтесь со смещением уровеня автоподстройки.

Это ведь могут быть короткие  ,но весьма мощные импульсы от ненасыщенных и поэтому практически как бы импульсных метеоров

Мощные, но короткие импульсы меторного происходжения, на FM, в моих тестах, программа фиксировала на ура. Если длительность всплесков меньше... уж не помню сколько мс, программа их не фиксирует, потому что смысла нет. Если длительность импульса от метеора сопоставима с длительностью всплесков от индустриальных и пр. помех, в городских условиях, чего там фиксировать. Одни помехи. Я этой проблеме не один и не два дня посвятил. Постарался как раз не выплеснуть ребенка и одновременно уменьшить количество ложных срабатываний. Были тесты, во время которых эфир просто гудел, или жужжал, не знаю, как правильно сказать. Кто-то че-то втыкал в розетку, в общем. Программа справлялась с этой ситуацией, ухитряясь фиксировать мрсы. Я на Геминидах и Леонидах в 2004/2005-м годах тестил. Во время относительной "тишины" в эфире, фиксировались "слабые", т.е., очень тихие сигналы, на слух я бы их точно пропутил.
Для различных условий наблюдений были добавлены три различных фильтра, смещение порога срабатывания при его автоматической подстройке. А уже не так давно, по просьбе Альфреда, добавил регулировку времени автоподстройки. А для возможности раздельной фиксации двух "близкосидящих" сигналов, уменьшил дискретность регулировки "останавливать запись через..." с 1 с  до 0.5 с.
Вы вникните. Я Альфреду говорил об этом. Софт предназначался изначально для городских условий, бытовой приемной техники и FM-диапазона. Предполагалось регистрировать мощные мрс-ы (во время пиковой активности потоков).
Естественно, программа работает и в других условиях, с любым источником сигнала. А как именно она себя ведет, я без понятия. Альфред предоставил мне приличный кусок записи, за что ему спасибо, который я гонял в различных режимах. Программа работала, так как и должна. Насколько она практична и применима для наблюдений, не мне судить.  Улучшать что-то в алгоритме регистрации нет смысла, имхо, для новых веяний времени нужна новая идея, новая программа.

[КiteKat]

В принципе, что бы грамотно развивать проект, можно скажем так разделить правки интерфейса и математической обработки, если у Вас есть конечно желание заниматься (я в них ничего не трогаю).

Если найдется идейный вдохновитель и руководитель пректа, буде он, проект, состоится, если смогу быть полезен, если смогу работать в команде, почему бы нет.    Будем посмотреть.

Надеюсь, модераторы нас не побьют.

[Andrey Prokopovich]

Только писать нужно автоматом в файлы, названия которых будут, например, rr_Station_ID_дата-время-запуска-программы.csv .

Еще мысль, потом пользователь может отравлять CSV файлик на сервер, где его импортировать в единую онлайн БД...   

Если найдется идейный вдохновитель и руководитель пректа, буде он, проект, состоится, если смогу быть полезен, если смогу работать в команде, почему бы нет.    Будем посмотреть.

Отлично, будем пробовать.

[lazyBSD]

Еще мысль, потом пользователь может отравлять CSV файлик на сервер, где его импортировать в единую онлайн БД...   

Station_ID в названии файла, задуман именно для этого.

[SERIV]

Был  на базе запустил RR (экзешник называется  project).Cредний фильтр импульсных помех. Некая вариация суточной численности мрсов есть:
Время начала патрулирования: 07.02.2010 11:10:37
 ---------------------------------------------------
| Интервал патрулирования | Количество сигналов     |
 ---------------------------------------------------
|                     7_2_2010                      |
 ---------------------------------------------------
|      11.00-12.00        |          14             |
|      12.00-13.00        |          11             |
|      13.00-14.00        |          11             |
|      14.00-15.00        |           4             |
|      15.00-16.00        |           3             |
|      16.00-17.00        |           2             |
|      17.00-18.00        |           1             |
|      18.00-19.00        |           4             |
|      19.00-20.00        |           3             |
|      20.00-21.00        |           6             |
|      21.00-22.00        |           7             |
|      22.00-23.00        |          11             |
|      23.00-24.00        |          12             |
 ---------------------------------------------------
|                     8_2_2010                      |
 ---------------------------------------------------
|      00.00-01.00        |          12             |
|      01.00-02.00        |          17             |
|      02.00-03.00        |          10             |
|      03.00-04.00        |          19             |
|      04.00-05.00        |          15             |
|      05.00-06.00        |          15             |
|      06.00-07.00        |          23             |
|      07.00-08.00        |          13             |
|      08.00-09.00        |          12             |
|      09.00-10.00        |          14             |
|      10.00-11.00        |           9             |
|      11.00-12.00        |           9             |
|      12.00-13.00        |          16             |
|      13.00-14.00        |           5             |

Подождем первого глюка. Если неделю продержится то это радует. Раз в неделю буду приезжать и перезапускать. Пусть глючит дальше на здоровье.  Ну само собой я сравню данные с SL за тотже интервал времени. Если будет хорошая корреляция, перехожу на RR.