HDSSTV - что это такое?..
(Эту информацию любезно представил Виктор, UT1WPR,
которую мы публикуем полностью)
Привет всем поклонникам SSTV и других цифровых видов связи!
Спасибо Игорю, EX2U. Прочитав его бюллетень, я обратил внимание на ранее мне неизвестную информацию о новом виде SSTV, так называемом HDSSTV. Поиск в интернете по этому ключевому слову привел всего лишь на одну-единственную страничку. На ней в полном объеме Бэри Сэндерсон (Barry Sanderson) KB9VAK собрал и выложил всю информацию, впервые озвученную на ежегодном хэмфэсте в Дэйтоне (2001 Dayton Hamvention Presentation).
Материал оформлен датой 8 Мая 2001 года, так что неудивительно, что мало кто о нем знает. Вероятно тот, кто имеет доступ к абсолютно свежим изданиям QST, просто не обратил внимания на эту cтатью, тем более, что в журнальном варианте она выглядела
скорее анонсом, нежели рабочим материалом. Интересующихся отсылаю к первоисточнику: http://svs.net/wyman/examples/hdsstv/index.html
Теперь понемногу о том, что мне удалось понять и проверить.
Во-первых - это не есть в чистом виде "новый вид SSTV". Скорее, я бы назвал его новым в радиолюбительской практике (в других областях этот и ему подобные методы давно применяются) методом кодирования информации для передачи ее на КВ. Разработкой и тестированием метода занималась и занимается группа радиолюбителей из Америки и Австралии:
W9NTP Dr. Don Miller
W8ZCF Farrel Winder
W0LMD Dr. Robert Suding
KB4YZ Dave Jones
VK3LM John Wilson
VK3CQE Alf Coupe
VK4CS Jim Schafer
W4HTB Hank Cantrell
Метод базируется на двухуровневом кодировании Рида-Соломона (Reed-Solomon coding). Для тех, кому теория кодирования хорошо знакома, этот метод не будет откровением.
Применены два уровня: внешний (306,178) и внутренний (8,4). Почему именно так - объяснение на этой же странице по ссылке: Why 2 levels of coding. Увы, я не могу полностью привести перевод всего материала - лимит личного времени. У меня передо мной около 80 листов распечаток с сайта с текстами, диаграммами и формулами.. Надеюсь, извинили?..
Кодированная с избытком информация поступает на так называемый модулятор (не надо стразу представлять себе принципиальных схем, все о чем я веду речь реализовано программно). Применена девятиступенчатая фазовая модуляция по восьми звуковым поднесущим. Т.е. в канале передачи одновременно "звучат" восемь тонов:
590 Гц
820 Гц
1050 Гц
1280 Гц
1510 Гц
1740 Гц
1970 Гц
2200 Гц
На приемной стороне принятая информация программно декодируется с получением максимально достоверной точности. Предложенная авторами программа кодирования имеет возможность кодировать выходную информацию с разными уровнями избыточности: 5, 10, 20, 30 и 40 процентов. Соответственно, степень защищенности
информации в канале также разная -
чем больше избыточность, тем больше вероятность стопроцентного восстановления информации.
Вот вкратце, что там есть из теории. Естественно, на сайте все гораздо глубже и подробнее - но это уже для желающих.
Теперь для нетерпеливых - "как это делается"?
Скажу сразу - никакого упоминания о типичном SSTV интерфейсе пользователя нет и в помине. Как я уже упоминал, разговор идет лишь о концепции, основном принципе и деталях алгоритмики. В эфир передается заранее сгенерированый звуковой файл в формате ".wav" с 16-ти битовыми выборками на частоте сэмплирования 11025 Гц. На приемной стороне сигнал с трансивера посредством звуковой карты записывается в этом же формате в файл с таким же расширением (допустимо расширение ".sw"). Затем полученный файл обрабатывается программой декодирования и в результате получаем практически копию исходного, переданного файла графического формата.
Для желающих экспериментировать, что нужно?
Linux Операционная система
gcc Компилятор Си
xxgdb Отладчик
gnuplot Построитель графиков
Xfree86 XWindows System
xv Манипулятор изображений
xpaint Графический редактор
gs Конвертор печати
tcl Командный язык
gawk Язык программирования
fvwm Windows manager
xfm Файл-менеджер под XWindows
xterm Эмулятор терминала
mc Миднайт Коммандер
joe Текстовый редактор
xwave Запись и редактирование звука
sox Звуковой конвертор форматов
Для тех, кто знаком с Линуксом - ничего специфичного здесь нет. Разве что, xwave может быть заменена на одну из аналогичных программ. Главное, чтобы она удачно собралась в той версии дистрибутива, в которой вы работаете.
Основная программа кодирования - это написанная под tcl программа make-pm7b-wav. Она в нужной последовательности и с необходимыми параметрами запускает ТРИ программы одна за другой. В результате порождается звуковой файл. Для примера, если кодируется файл test.png - на выходе получится файл pm7b20_test.png.wav, где цифра 20 указывает уровень избыточности, заданный вами. Декодирование на приемной стороне осуществляется программой pm7b-demod-decode.
Результатом ее выполнения являются два файла: копия графического файла с той или иной степенью достоверности и текстовый файл анализа процесса декодирования. Глубина анализа задается при компиляции самой программы-декодера. Этот файл может являться входным для gnuplot, которая в свою очередь может представить большинство информации об ошибках и восстановлениях в виде графиков и диаграмм.
Что проделано мной?
Ну, во-первых, пришлось поработать программой "PartitionMagic"и освободить несколько гигабайт на винчестере. На них и установил Линукс. Где-то пару лет назад я в целях самообразования работал с дистрибутивом "RedHat". Учитывая прошлый опыт, я выбрал "Slackware" - принципиальной разницы между дистрибутивами нет, есть разница в мелочах, сильно затрудняющих совместимость.
Затем проинсталировал взятое на оригинальном сайте программное обеспечение. Небольшое различие в дистрибутах Линукса (math.h) легко исправилось "ручками". Процесс компиляции прошел нормально и без ошибок. Итак, я теперь готов оказывать посильную помощь (увы, как механическое пианино) всей команде разработчиков и тестеров.
Что я заметил?
Вот тут вот я и понял, что это все не более чем концепт, причем довольно сырой. Для начала я "извлек" из страницы автора образцовый рисунок формата ".png" и преобразовал его в файл ".wav" Все сработало! Выход звуковой карты переключил на усилитель и решил прослушать, как же все-таки ЭТО звучит. Гм..
Хрр-трр-прр - очень похоже на типичную
пакетную передачу, и в то же время сигнал особенный, таких я не слышал. Заголовочная часть позволяет безошибочно на слух определить именно этот вид.
Увы, засилье компьютеризации оставило меня без магнитофона (вся "домашняя" музыка на компактах или эмпеги) - не на чем было с имитировать канал. Решил просто переименовать порожденный звуковой файл в любое другое название. "Натравил" на него pm7b-demod-decode.. О диво! В каталоге появился файл с первоначальным именем! Т.е. тот же самый .png -файл. Собственно, чему удивляться - ведь именно это и старались получить авторы.
Взял я другой файл, чуток побольше. К примеру, из своей библиотеки для SSTV обмена (а должен заметить, что авторский файл был размером около 2 килобайт - формат ".png" идеально подходит для графических файлов с высокой регулярностью. Позже закралась мысль, а ведь на подгонку похоже..) я взял картинку типичного ".jpg" формата размером около 25 килобайт. Кодирование и преобразование моей картинки длилось.. 4 минуты! (CPU Celeron-466, 128M RAM) Мда... Да и с
декодированием не сложилось. Во время выполнения программы вместе с сообщением "Terminated" программа "вывалилась" в оболочку, оставив какой-то мусор под названием pm7b-scratch.
Итак, у меня сложилось впечатление, что программы еще сыроваты, для демонстрации результатов были взяты те файлы, на которых все "летело со свистом", что до полного окончания еще очень далеко. Настораживает последовательный метод решения задачи кодирования. В принципе это и должно занимать массу времени. Путей применения данной концепции в SSTV в привычной для нас форме пока не видно.
Однако:
- Как мало я еще знаю в этой области
- Как много знают те, кому по роду профессиональной деятельности приходится подобными разработками заниматься
- И кто знает, что нас ожидает за очередным поворотом технократической гонки?..
Подвожу итог:
Ох как было бы неплохо подключить сюда и наших ребят. Хотя бы для первых шагов - повторить то, что уже прошли американцы и австралийцы. Не говорю уже, чтобы продолжить работы в этом направлении.
Материал №2. Прошло некоторое время с момента отправки моего первого бюллетеня, касающегося HDSSTV. В результате сформировался узкий круг заинтересованных людей. Увы, не совсем пока еще готовых к проведению экспериментов. Но есть огромный плюс - вопрос обнародован и информация по этой тематике медленно поползла по умам. Вполне вероятно, что со временем радиолюбители придут к тому же выводу, что и я. Не всегда самостоятельно можно решить проблему. Иногда полезно заинтересовать и привлечь людей со стороны, ближе знакомых с предметом, экспертами в тех или иных областях. Ну, а возле них и сам Бог велел набираться уму-разуму.. Вот такое вот отступление.
Пока по результатам обратной связи я сделал вывод, что есть проблемы со сборкой файлов-программ. Это вполне вероятно. Если дистрибутивы Линукса разнятся не только по названиям, но и несовместимы сверху вниз по версиям - трудно получить у всех одинаковый результат. Поэтому для облегчения проведения экспериментов я решил поместить собранные файлы и все необходимое на ftp-узел. Желающие могут взять их оттуда по стандартному анонимному доступу. Адрес: ftp://ut1wpr.polynet.lviv.ua/hdsstv
Примечание:
примененная платформа - Slackware Linux v.8, Kernel 2.4.5, libc-2.2.3
В указанной ftp-директории находятся пять архивных zip-файлов. Распаковывать нужно только WinZip-ом. Имена файлов внутри архива не соответсвуют стандарту DOS, могут быть проблемы. Далее помещаю как-бы инструкцию по применению распакованных программ.
Нижеперечисленные файлы должны быть executable (chmod +x *)
make-pm7b-wav
bin2sym307pm7b
flt-clip-scale-wav
mod-pm7b
pm7b-demod-decode
make-pm7b-wav - этот файл последовательно вызывает в работу три других файла: bin2sym307pm7b -> flt-clip-scale-wav -> mod-pm7b используя при этом 2tone1180-1520v4-3sec.flt и chirp3b.flt для формирования лидерной части и переходного чирпа.
Синтаксис командной строки (для примера обработка файла xa14.png):
./make-pm7b-wav xa14.png 3
где: 1 - 5 процентов избыточности
2 - 10
3 - 20
4 - 40
Должен получится звуковой файл xa14.png.pm7b20.wav . Этот файл можно передавать любой программой, способной проигрывать wav-файлы.
На принимающей стороне в этот момент должен быть включен компьютер на оцифровку входного звукового сигнала с параметрами 11025 выборок в секунду на 16-бит амплитуды моно с записью в файл с расширением wav.
Имя файла не имеет значения, т.к. программа декодирования-демодуляции в случае удачи извлечет имя исходного файла из входного потока. Для примера, сохраненный звуковой файл будет иметь имя test.wav, тогда синтаксис командной строки на демодуляцию-декодирование будет: ./pm7b-demod-decode test.wav > test.dat
Кроме файла xa14.png будет еще создан текстовый файл test.dat в котором будут записаны все данные процесса декодирования, много данных... Очень удобно для дальнейшего анализа. Особенно, с применением gnuplot...
В архивах также находятся два специально созданных файла для настройки передающего канала:
2tone1180-1520v4-12sec.wav
multi-tone1_1-2-4-8-tones_3amps.wav
Базовые рекомендации - максимально сохранять линейность передающего и приемного трактов. Напоминаю, у авторов эксперименты производились на двадцати (приблизительно) ваттах мощности. С учетом восьми поднесущих получалось чуть более двух ватт на поднесущую. Движки микшера должны находится в позиции от четверти до половины уровня. Все неиспользуемые входы-выходы должны быть отключены.
Материал №3. DIGSSTV, HDSSTV и просто SSTV
Освежив в памяти основные положения и принципы HDSSTV,"попробовав на вкус" портированный в Виндовз вариант под названием DIGSSTV попробую подвести итог. Однако, без права на истину в первой инстанции. Прошу не забывать, что все эти материалы дискутируемы. И чем больше будет обсуждений и высказываний, тем свежее и конструктивнее могут оказаться новые идеи.
Для начала хочу вернуться в прошлое. Все знают (а некоторые и помнят) первые связи в режиме SSTV. Механические передатчики с валами развертки на передающей стороне, ламповые громоздкие аппараты с трубками сверхдлинного послесвечения на приемной стороне.
Постоянные перекалибровки частот черного и белого, жуткие нестабильности гетеродинов самодельных трансиверов. Ну очень непохоже на сегодняшнее легкое журчание компьютеров и сверхнавороченность при подготовке формированию картинок.
Однако уже тогда у меня возникал вопрос, на который я и по сей день не совсем уверен, что знаю ответ. А почему, собственно, SSTV? Slov Scan TeleVision - это понятно. Однако я провожу различие (не знаю, как другие) между телевизионными передачами и передачами факсимильных изображений. Если со вторыми все ясно (передача НЕПОДВИЖНОГО изображения, цветного или чернобелого), то насколько правомочно называть передачу такого же изображения ТЕЛЕВИДЕНИЕМ? Не знаю, как для других, а для меня ТЕЛЕВИДЕНИЕ прочно связано с передачей ДИНАМИЧЕСКИХ, ДВИЖУЩИХСЯ изображений. И если производить оценку названий именно с этой точки зрения, то сформировавшееся направление радиолюбительской связи под названием SSTV должно скорее именоваться HAMFAX. Вот вам и первая тема для легкой дискуссии.
Теперь поговорим о HDSSTV и DIGSSTV. Тут вообще совершенно непонятно, какое отношение все это имеет к SSTV в нашем его понимании. Внимательно прочитав мою предыдущую заметку о принципах HDSSTV можно обратить внимание, что первоначально файл с графической информацией превращается в звуковой файл и лишь потом передается в эфир. При этом файл обрастает так называемыми заголовком и хвостовиком. Примененный метод избыточного кодирования делает невозможным правильное декодирование на приемной стороне файла, принятого без заголовка или без хвостовика.
Первое и весьма значительное! Картинку любительского SSTV изображения можно начать принимать С ЛЮБОЙ СТРОКИ ИЗОБРАЖЕНИЯ. При этом ВСЯ ОСТАВШАЯСЯ ЧАСТЬ будет принята, и лишь человек сделает правильный выбор - какая часть более важная, та что принята или та, что усечена. Многие любители SSTV пользуются этим свойством для передачи НЕПОЛНОЙ картинки, желая сократить время на вызов или подтверждение. При использовании DIGSSTV или HDSSTV время передачи картинки (простите, а почему мы все время говорим про картинку?) разное. И оно зависит от степени сложности картинки, от типа примененного графического формата (степени сжатия). Т.е. от ДЛИНЫ ПЕРЕДАВАЕМОГО ФАЙЛА.
Тут еще уместно упомянуть о "втором рождении" такого метода, как HELL. В условиях слабых сигналов зрительный анализ "картинки текста" зачастую позволяет "восстановить" такую его часть, которую даже современные методы кодирования/восcтановления вряд-ли восстановили бы. Аналитическая мощь человеческого мозга пока еще не имеет себе равных "в железе". Именно поэтому в кабинах современных суперистребителей и сидит до сих пор человек.
Я плавно подвел вас всех к выводу, что для данного метода по сути ВСЕ РАВНО, ЧТО ПЕРЕДАВАТЬ. Картинка, записанный голос, исполняемый файл - все это обобщается одним словом - ФАЙЛ. И лишь наличие достаточно удобного программного интерфейса для манипуляции с преобразованиями файлов из одного формата в другой и пренаправлением этих файлов в/из поток данных звуковой карты, "подстраивают" программу DIGSSTV под SSTV приложение.
На мой взгляд, радиолюбителям предложен новый метод передачи информации на КВ. Достаточно быстрый (прослеживается аналогия с MT63), с мощной системой кодирования/восстановления информации. Подобные методы сейчас широко используются в каналах "борт-земля", цифровой телефонии и других приложениях на высоких скоростях и очень высоких частотах. Вполне возможно, что более пристальное изучение этого направления, наложение на него какого-либо протокола может дать новый толчок в создании магистральных каналов на КВ для построения любительских (как мы сейчас пока еще говорим) пакетных сетей.
Возвращаясь к теме SSTV выскажу свои соображения. Мне кажется, что методика передачи изображения ФАЙЛОМ не совсем уместна в применении SSTV. Уж если, выражаясь языком разработчиков программ, составлять спецификацию на разрабатываемый метод, то он должен:
- иметь высокую достоверность передачи в условиях очень плохого соотношения сигнал/шум (возможность восстановления максимальной части разрушенной во время прохождения информации),
- иметь возможность начать прием или прервать передачу практически в любом месте потока с минимальными при этом потерями (трудно пока выразить это в числах),
- иметь интерфейс для работы по удобству не хуже существующих программ,
- при всем этом иметь возможность исполнять свои функции на приемлемой аппаратной части (не у всех может дома стоять СуперКрэй).
И хочу повторить - очень хорошо, что подобные работы в этом направлении ведутся. Активнее подключайтесь. Посмотрите вокруг, если рядом есть специалисты этой отрасли - не стесняйтесь, учитесь у них, задавайте вопросы, стремитесь к новым разработкам!
До встречи на КВ SSTV (все же не нами придумано, не нам разрушать :-))
Кто имеет возможность и знания - прошу связаться со мной для пробных работ в эфире. К сожалению, условия проживания таковы, что мне доступны лишь два диапазона - 40 и 20 метров. В основном я работаю на 20 метрах.
Особую благодарность хочу выразить Сидорчуку Ю.И., чье мужество и терпение позволили мне хоть чуть-чуть приблизиться к основным понятиям в области избыточного кодирования. Остается лишь сожалеть, что он не коротковолновик. Но процесс его "вовлечения" идет... :-)
Виктор, UT1WPR, 73!
Связаться со мной можно или по пакетной сети:
ut1wpr@ut1wpr.lvv.ukr.eu
или по электронной почте:
(Прим. Файл для инсталяции программы DIGSSTV можно скачать по адресу: http://users.origin.net.au/~crac/ )