Имеется систематический кодер 15 бит информации (4 бита инфрмационная часть, 11 избыточная) полином степени 2^4, итого длинна кода 15 бит бит, а дальше по кругу. Декодер на входе анализирует 15 бит информации и по своему закону из последовательности 15 бит выделяет комбинацию в 4 бита, причем комбинация виделяется всегда и может выделиться ложно в зависимости от количесва ошибок. Ложное выделение и требуется исключить. Хочу расширить окно анализации с 15 бит до, скажем, 60 бит(можно и больше), получиться 4 декодера на участке 60 бит. Соседние информационные части связать по какому-нибудь закону F. После декодирования 60 бит 4-мя декодерами анализировать выполнение закона F на выходе декодера для информационной части, если F выполняется, то принимаем комбинацию, если нет, то считаем это мусором или на канале слишком большое количество ошибок. Думаю еще сделать комбинацию синхропосылки, чтобы не анализировать побитово всю последовательноть, а после ее выделения поблочно анализировать данные. Может можно что-нить лучше придумать для снижения вероятности ложного выделения.

выкинуть эту портянку и поставить туда бинарную последовательность, которую выделить коррелятором.

Можно ссылку где почитать про коррелятор, если не сложно. Насколько я понял коррелятор использовать для выделения синхропосылки? И будет он работать при 20% вероятности ошибки?

1. побитово принимаем данные в лз длиной 60 бит
2. методом макс правдоподобия по таблице декодируем 4 слова. Для ускорения можно использовать 2 таблицы
- (2^15) х 4 бита только с минимальными хэмминговыми расстояниями от опорных слов для ускорения процесса поиска и синхронизации
- 16 x 15 бит с "неискаженными" кодовыми словами для декодирования
3. находим сумму мин. хэмминговых расстояний для 4-х слов из лз
4. сравниваем эту сумму с фикс. порогом. Если меньше порога, то считаем, что в лз находятся 4 валидных кодовых слова. Их потом можно декодировать.

Итого:
для быстрого варианта на каждый поступивший в лз бит нужно 4 обращения к таблице, сумма и порог. Но нужна память 16 кбайт.

для медленного варианта на каждый бит нужно 4 раза сделать поиск в таблице из 16 значений подсчетом хэммингового расстояния и выбором минимального. Но затрат по памяти почти нет. Сложность подсчета хэммингового расстояния и веса O(log( bitwidth )) т.е. невелика. Можно этот вариант ускорить за счет табличного вычисления весов для частей слова.

Это были варианты "в лоб".

Для оптимизации можно завести ЛЗ с весами хэмминга с отводами от каждого 15-го элемента. Тогда декодировать методом макс. правдоподобия придется только одно 15-ти битовое слово на один принятый бит. В этом случае удлиннение окна поиска на каждые 15 бит приведет лишь к 1 дополнительному сумматору . Для вычисления суммы весов можно использовать вариант "скользящего среднего" с вычитателем и сумматором. Таких надо 15 шт. В этом случае окно поиска можно увеличивать безгранично при фиксированной сложности.

В общем вариантов по реализации много.

Ну а "выкинь всё и сделай заново" - это, как всегда, солидно, хотя обработка 60 бит "в целом" в канале с абшг будет давать выигрыш по сравнению с обработкой по частям. Здесь спору нет.

Да что там считать то. Судя по задаче вам нужно диагностировать сам факт наличия сигнала, а не его значение. Вы хотите это сделать за счет кодирования, а можно сделать за счет увеличения базы сигнала. Например передаете значение одного бита последовательностью из 64 бит. Получите энергетический выигрыш в 10*log(64) = 18дб, при той же вероятности символьной ошибки. Ну а дальше выбираете порог сравнения исходя из вероятности ложного обнаружения. Как вариант измерить дисперсию шума на входе СФ, масштабировать с учетом усиления СФ, воспользоваться правилом трех сигм и сделать запас 3дб. Это позволит вам сделать адаптивный порог.

Это одна из задач. Другая задача это декодирование комбинации из 15 бит, в которой допустимо 3 ошибки. Если ошибок больше, то есть большая вероятность ложного выделения. К сожалению декодер не может диагностировать количество ошибок, а выделяет наиболее вероятную комбинацию мажоритарно. Вот и встала задача контролировать полученную информационную часть, либо с счет crc, либо за счет соседа. Я понимаю, что есть масса способов, кодеров и декодеров для коррекции данных и обнаружения ошибок, но у меня задача проверить на что будет способен данный кодер и декодер. Пока наткнулся на ложное выделение из-за тройной децимации последовательности 15 бит.

Сообщение отредактировал likeasm - Nov 28 2014, 12:29

К сожалению, способа, дающего нулевую вероятность ложной тревоги, в природе не существует. Сначала нужно определить допустимую вероятность ложной тревоги, а потом уже искать способ решения. Например, CRC 16 бит имеет вероятность ложной тревоги 0.02%, т.е. если на декодер CRC подать 5000 случайных пакетов, то на одном (в среднем, конечно, на выборке в несколько сотен тысяч пакетов) пакете CRC "сойдется". Существуют аналогичные оценки для различных ПУ кодов, копайте гугл. Либо моделируйте.