[gegel 0]

Помогите, пожалуйста, разобраться в следующем:

Два бита данных дополняются контрольным битом (0 xor 1) и передаются в поток (это нужно для синхронизации на лету).
С выхода коррелятора (когерентный BPSK демодулятор) поступают ненормализованные значения -32767 ло 32767
Если в приянтой тройке жесткий контрольный бит не совпадает, то инвертируется жесткое решение бита с наименьшим мягким значением в тройке. Это работает ОК.

Планируется использовать турбо-декодер (BCJR) для дальнейшего декодирования битов данных (на его входе Q15).
Можно ли в данных условиях перед подачей на декодер подсчитать (скорректирвоать) мягкие значения двух информационных бит с учетом мягкого значения контрольного бита?

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

[Grizzly 0]

Самое простое - поменять знак наименьшего мягкого решения на противоположный.

[gegel 0]

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

[Grizzly 0]

А какой-то выигрыш есть от данной процедуры при "жестких" решениях без использования помехоустойчивого кодирования (я имею в виду ваши результаты моделирования)? Внимательно перечитал ваш вопрос. Этим методом вы ничего не сможете улучшить. У вас реализован расчет контрольной суммы, после этого передаются условные блоки из трех бит. Допустим, у нас канал с АБГШ. Каждый из трех символов BPSK искажается шумом. Это происходит независимо. Если символ, соответствующий биту четности, исказился на противоположный, а два информационных символа при этом верные, то вы, тем самым, "испортите" информационный бит, сделав инверсию его LLR (или заменив на противоположное "жесткое" решение). Контрольная сумма используется не для коррекции ошибок, а лишь для проверки на наличие ошибок. В вашем случае ничего исправить не получится. То есть даже одиночную ошибку исправить невозможно.

 

UPD. Нашел в каком-то источнике описание, чтобы вам стало понятнее: http://info.sernam.ru/book_codb.php?id=24

Видите, проверка на четность может только обнаружить ошибки, но никак не исправить их.

[gegel 0]

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

Например, передаем 00. Бит четности тоже 0. Принимаем -20, -70, -60 (последний - контрольный бит). По жесткому решению все ОК, контрольный бит совпадает. В турбо-декодер в составе полного фрейма длиной 3456 бит буду переданы -20 и -70. Но первый бит, очевидно, будет иметь более высокую надежность, т.к. она подкрепляется вторым и контрольным битами.

Первая мысль, которая приходит в голову: из трех бит выбирать бит с минимальной метрикой, и заменять ее на бит со средней метрикой. В этом случае в турбо-декодер будут переданы значения -60 и -70. Грубо, конечно, т.к., очевидно, для первого бита метрика будет все же  хуже -60,  но лучше -20.  Но не знаю, как сделать lege artis.  Ну, и не могу гарантировать, что это вообще верно в принципе.

ПС:  

- этот вопрос не имеет никакого отношения к мягкому Голею в соседней теме;

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

[Милливольт 0]

1 hour ago, gegel said:

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

 

Простите, но это неверно

[gegel 0]

Готов согласиться, но только аргументируйте.

Я рассуждаю так:  допустим, есть два произвольных жестких бита, и третий - их xor. Затираем первый бит (что эквивалентно его LLR=0). Можем мы его восстановить по двум оставшимся? Без проблем. То же самое я пытаюсь корректно перенести  на мягкие решения.

[petrov 6]

gegel

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

[Милливольт 0]

Пусть вероятность повреждения любого из битов - 0.1. Если повреждается контрольный, то вся посылка - в топку, о чем уже сказал ув. Grizzly.  Т.е. 10% посылок погибли невосстановимо - любая попытка коррекции приведет к заведомо неправильному решению. Вероятность повреждения двух бит с формированием псевдоправильного сообщения, т.е. ошибки на выходе, которая принимается за правильное сообщение, еще 0.1*0.1. Вероятность искаженных трех бит - 0.001, но в Вашем канале связи (если это тот же канал, с которым Вы работали) она много выше, т.к. кодер, который Вы "пробиваете", дает сигнал нестационарный в широком смысле, причем интервал стационарности у него "плавает" произвольно.

Т.о. выбранный корректирующий метод кодирования не годится даже для канала с АБГШ, не говоря уж о более сложных искажениях при передаче. Он ничего корректировать не будет, а вот вносить ошибки, выданные за правильно переданные посылки - будет гарантированно. Вне зависимости от способа декодирования.

[gegel 0]

6 minutes ago, petrov said:

gegel

Вы эти биты лучше потратьте на более мощный турбокод. 

Контрольные биты в моем модеме - это синхровставка для синхронизации на лету. Я совместил функционал синхровставки с контрольными битами специально для снижения избыточности. В модеме, о котором упоминает Милливольт (https://github.com/gegel/jackpair, там импульсный модем Кондоза на 800 bps для работы с AMR-сжатыми каналами и мой реалтайм порт MELPE на CortexM4), использовался один контрольный бит на 4 или  9 информационных, этого хватало для устойчивой синхронизации при исходном BER в 3-4%.  Но в другом проекте требования к модему более жесткие (синхронизация при 10-15% ошибок), но можно позволить избыточность.  Поэтому малой кровью было использовать один контрольный на 2 информационных.

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

Во втором проекте после модема идет турбо-декодер, поэтому логично было бы навесить на контрольные биты еще и уточнение LLR информационных бит, что и пытаюсь сделать.

18 minutes ago, Милливольт said:

Если повреждается контрольный, то вся посылка - в топку, о чем уже сказал ув. Grizzly.  Т.е. 10% посылок погибли невосстановимо - любая попытка коррекции приведет к заведомо неправильному решению.

Опять у Вас все сводится к жестким решениям. Но я только хочу скорректировать LLR информационных бит по возможности. Коррекция жестких бит на данном этапе не производится.

[Милливольт 0]

1 hour ago, gegel said:

Контрольные биты в моем модеме - это синхровставка для синхронизации на лету.

. Но я только хочу скорректировать LLR информационных бит по возможности. Коррекция жестких бит на данном этапе не производится.

Ага, понятно. Но об этом Вы в исходном сообщении не говорили, или я не понял.

В таком случае теоретически оптимальным будет такой подход (если вычислительные ресурсы позволяют): синхробит не меняется, он только свою функцию выполняет. Принятая посылка (их получается четыре варианта) подается на пирсоновский коррелятор, в памяти которого четыре варианта сообщений, причем не в виде прямоугольников, а виде экспериментального сигнала, полученного на хорошей линии связи. Т.е. на выходе коррелятора будет сообщение: "это последовательность 01 с коэффициентом корреляции с эталоном, равным, скажем, 0,78, или это сообщение 11 с R=0,2, или это сообщение 00 с R=-0,3, или 10 с R=-0,6. Ну, а дальше на оконечный декодер.

В таком варианте будет реализовано требование Котельникова об оптимальном приеме. 

Изменено 20 ноября, 2018 пользователем Милливольт

[Grizzly 0]

Хм, что-то я запутался. Как у нас синхробит не меняется, если до этого говорилось в самом первом сообщении, что третий бит есть xor первых двух? Я правильно понимаю, что идут два информационных бита, а за ними синхробит? @Милливольтверно написал, что это должно быть определенное значение, на то он и синхробит.

[des00 25]

А в чем проблема воспользоваться передачей доверия и пересчитать метрики битов, с учетом их взаимосвязи? Похожий код (блочный турбокод, на основе кодов проверки на четность) у Марелоса-Сарагосы расписан в численном примере. Там есть формула сложения вероятностей.

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

8 hours ago, Grizzly said:

Хм, что-то я запутался. Как у нас синхробит не меняется, если до этого говорилось в самом первом сообщении, что третий бит есть xor первых двух? Я правильно понимаю, что идут два информационных бита, а за ними синхробит? @Милливольтверно написал, что это должно быть определенное значение, на то он и синхробит. 

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

ГЗВ. Еще вариант задействования этого бита, если вы планируете использовать Duo-Binary турбокод, то, используя метрику дополнительного бита, можно уточнить метрику пары, нужно немного поправить калькулятор рассчет метрик в декодере. По сравнению с уточнением каждой метрики, то на то и выйдет, но может оказаться немного проще) Но, это если у вас доступ к сорцам турбо балалайки есть)

[gegel 0]

1 hour ago, des00 said:

А в чем проблема воспользоваться передачей доверия и пересчитать метрики битов, с учетом их взаимосвязи?

Это именно то, что мне нужно. Но, если можно, дайте ссылку или скажите, как это сделать в данном конкретном случае (с тремя битами).

8 hours ago, Grizzly said:

Хм, что-то я запутался. Как у нас синхробит не меняется, если до этого говорилось в самом первом сообщении, что третий бит есть xor первых двух? Я правильно понимаю, что идут два информационных бита, а за ними синхробит? @Милливольтверно написал, что это должно быть определенное значение, на то он и синхробит.

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

11 hours ago, Милливольт said:

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

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

[Милливольт 0]

59 minutes ago, gegel said:

 

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

Странно... У нас с запасом (правда, при другой задаче) успевает при частоте дискретизации 8 КГц и фреймах 10 мсек. Пирсон много не жрет, если везде где возможно, использовать целочисленные операции. Кстати, то, что я видел в Вашем предыдущем модеме с фиксированным значением синхробита - быстро и надежно синхронизировалось, но совершенно не обязательно повторится с меняющимся синхробитом. Если, допустим, медленный джиттер, потом перерыв связи и восстановление ее со сдвигом внутреннего времени? А это бывает на наших каналах.