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

[Andrey Prokopovich]

31 января параллельно SL запустил RR тестовую версию, улучшенную Андреем Прокоповичем. ...Основная цель тестов - узнать какое время софтина без глюков работает. А если глючит, то почему. 

Ну, Ваня ты загнул про улучшения... Автор любезно предоставил исходники для отлова места падения программы, пока известно, что падает программа совершенно молча, что м.б. характерно для неких косяков со стеком. В программу вкомпилирован дебагер ЭврикаЛог... Ждем падений... Не исключено, что сама ее перекомпиляция в новой Делфи 2010 исправило некие проблемы и программ падать перестанет (автор компилировал ее в Делфи 5).

[Andrey Prokopovich]

А вот как раз это надо проверить, бывает ли у этой версии глюк, когда аудиофайл она сохраняет, но в таблицу не заносит это событие.

Так вроде все просто. Количество файлов и событий должно быть одинаково, если нет, то есть баг (если руками ничего не терли).

[Andrey Prokopovich]

... Выяснить первое куда сложней, потому как до того человека ехать далеко, а ещё ж надо постоять у него над душой...

Т.е. есть только возможность дать ему exe'шник? Вообще у меня была мысль добавить в программу функционал в виде возможности отсылать отчеты по HTTP/FTP... если у председателя есть инет, то было бы весьма удобно

[Andrey Prokopovich]

В смысле отсылать отчёты? Т.е. программа автоматически в определённое время подключает компьютер к интернету, отправляет отчёт и отключается от инета? Это было бы просто здорово!

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

Вообще-то мне кажется разбиение на папки вообще не нужно, все аудиофайлы имеют уникальные имена - этого достаточно. По названию файла можно запросто скопировать файлы за определенную дату, если есть в этом необходимость.
У меня при попытке как-то упростить схему работы, все мысли приходят к единому файлу evt, но работать с ним сложно будет, когда он разрастется. А один большой файл - это подобие БД, только не оптимизированное никоим образом. Как вариант, для надежного хранения данных можно уйти от формата "evt" и хранить все в БД, например SQLite или FireBird (установка СУБД на комп не требуется). В итоге - надежность и удобство работы с данными - выборки за любой период одним кликом мыши, и не надо голову ломать, как "создавать сводный отчёт для RAMEDA и RMOB из нескольких выбранных табличек за несколько дат".
Еще отрицательный момент, что программа "собирает" события в своей таблице (StringGrid), и периодически записывает в файл, но не дописывает, а переписывает с ноля. С каждым новым ивентом процесс замедляется, а если их будет 100... 500 тысяч - это уже процесс, с БД такого не будет в принципе.

[Andrey Prokopovich]

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

[Andrey Prokopovich]

Ваня я ж тебе и в Скайп писал и в чат, что не ставь первую дебажную сборку!

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

А как ты без диаграммы узнал, что их 660?

Да не мучайтесь вы с RR! Это детские шалости. Несерьёзный софт.

Странный у тебя подход, однако 

[Andrey Prokopovich]

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

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

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

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

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

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

[Andrey Prokopovich]

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

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

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

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

[Andrey Prokopovich]

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

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

[Andrey Prokopovich]

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

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

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

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

[Andrey Prokopovich]

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

[Andrey Prokopovich]

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

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

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

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

[Andrey Prokopovich]

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

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

[Andrey Prokopovich]

http://www.tvcomm.co.uk/radio/how-to.html

For advanced users, there's some information here on how to program Spectrum Lab to count and record meteors rates.

Да, но там не простой FM приемник нужен:

The basic requirements are for scanning receivers which can receive the appropriate frequencies in USB or CW modes...

[Andrey Prokopovich]

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

В файлах .evt длительность сигналов сохраняется, да и в отчет (.rep) экспортируется

Код: [Выделить]

Date/Time    |   Duration, s  | from begin, s

[Andrey Prokopovich]

Возможно ,что улучшению надежности выделения мерсов  может послужить критерий возрастания разности амплитуд соседних отсчетов, или как еще можно сказать возрастание  дисперсии, при этом возможно даже не потребовалась бы и АРУ.

Попробовал переписать (дописать) еще и детектор по дисперсии, но считал дисперсию ряда данных частотного спектра (FFT), для наглядности разместил 2 индикатора рядом, первый - уже имеющийся пикдетектор, второй - показывающий значение дисперсии. Как Вы и предполагали - второй реагирует более интенсивно на изменения в сигнале.
Но, по ходу дела, раз уж связались с FFT, возникла мысль добавить детектор как у SL, что даст возможность работать и в ТВ диапазоне. А детектор у SL довольно простой, глянем на скрипт SL, основные моменты детектора (триггера), они т.с. self-explaining:
Peak_amplitude=peak_a(900,1200)
Average_level=avrg(900,1200)
Если (Peak_amplitude > Trigger_level) то сработка триггера и слежение за событием. Все это можно реализовать.