Oberon space

Оставлю ка я эту картинку здесь. Вдруг кто не видел еще:

Я никогда не занимался цифровой фильтрацией, поэтому то, что изложу – взгляд абсолютного дилетанта.

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

Ну-у. В принципе да, почему нет? С другой стороны этот меандр может быть весьма высокочастотным, либо низкочастотным и при этом не кратным нашим 100 сэмплам.

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

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

Затем, с помощью КА, измеряем длительности непрерывных отсчетов в буфере, например, -1 длиной 10 считаем разделителем символов, +1 длиной 3 и больше – тире, и т. д.

Затем распознаем то, что получилось между разделителями символов.

А вот этой части нам сейчас как раз и не хватает. На обероне.

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

Это не совсем так.

Во первых см. упрощения 1,2,3 задачи. они взяты не от балды, а из практики. Во вторых даже если у тебя есть идеальный сигнал (а с упрощениями оно примерно так и выходит), то все равно никто не гарантирует, что передача не прервется на половине буквы (банально вырубили передатчик до окончания передачи) и не продолжится затем с половины другой буквы. При этом, ясное дело, программа не должна впасть в маразм, она должна (возможно пропустив сколько-то точек-тире) продолжить корректно расшифровывать передачу.

Ясное дело, что поле первого "релиза" можно будет подумать как добавить помехозащищенность. Но вначале нужно обязательно выпустить релиз упрошенной версии. Лучше 20 раз по разу, чем ни разу 20 раз :-)

Я пас, времени нет.

И не вижу я там дальше никаких нюансов реализации.... Если потом не вести речь про достижение сверхбыстродействия (когда не допустимо каждый сэмпл сообщать вызовом процедуры).

Есть чисто нюансы обработки сигнала (логика декодера - его состояния и Decode).

Точечки и тире надо еще в буквы сложить. И нужно уметь восстанавливаться после сбоя (ложные срабатывания/распознования точек-тире будут точно).

Почитал я тут последние топики, и решил что эту парсерно-автоматную тематику нужно как-то разбавить чем-то более осязаемым, так что ловите еще одну задачку.

У задачки есть один нюанс - мне интересней всего увидеть идиоматическое решение на Обероне-1/07/12, то есть решение на этих языках тех, кто на Обероне (или его производных вроде КП) имеет опыт написание приложений (и желательно не на досуге забавы для, а для чего-то продакшинообразного).

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






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

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

Возможные упрощения задачи (собственно которыми, видимо, нужно воспользоваться для первого "релиза", да, чем быстрее релиз первый, тем лучше):
1) Мы знаем темп передачи данных. То есть знаем длительность точки, тире и пауз между ними. Эти длительности зашиты в передатчике.
2) Можно считать что в первой версии пользователь вполне согласен вручную подстраивать декодер выставляя уровень сигнала (то есть в первом примере он скорее всего выставил бы, что все что выше 90та это сигнал (точка, или тире))
3) Можно считать что уровень сигнала у нас либо не плавает либо плавает слабо (не будет той каки что на втором графике). Но сам уровень сигнала мы не знаем (но см. пункт 2).

Вроде бы все. Если есть вопросы - задавайте.

Во вложении примеры данных (первая колонка - номер сэмпла, вторая колонка - сами данные).

Напомню, что интересней всего увидеть реализацию на идиоматическом Обероне (1/07/12) тех кто на Обероне пишет. Но конечно принимаются решения и на других языках от других людей :-)

А сорс сдк под  мак и лин есть?

Судя по этой новости: http://www.opennet.ru/opennews/art.shtml?num=34471 таки да.
Ну и L4D под мак была сразу.

Цитата: vlad от Сентябрь 20, 2012, 03:15:10 pm

В моем варианте "поиск подстроки" это и есть "откат".

И я понял о каких "откатах" народ говорит. Тяжело бывает переключится на чужие проблемы с языка, в котором есть и сравнение строк и  поиск подстроки и пр. удобства и к которым настолько привык

Это ты про perl (где регэкспы встроенные)? ;-)