[thermit 1]

1 час назад, Милливольт сказал:

Автору темы она не подойдет точно...

А что там у автора темы? 

[gegel 0]

13 hours ago, des00 said:

Хммм.....В статье указан пример двух кодов проверки на четность. Рассмотрим эту статью. Рассмотрим ту строку, которая с ошибкой. Правило кодирования из статьи 0/1 -> +1/-1.

Кодирование: данные 01 -> четность 1 -> кодовое слово 011

Канальные метрики на входе декодера проверки на четность: 4.0, 1.0, -1.5. Т.е. ошибка во втором бите данных. Вероятность говорит что это слабый ноль. 

Используем то что дал код и уточняем метрики битов : 3.0, -0.5. Т.е. метрика второго бита, стала очень слабая единица (положим дискрет метрики 0.5). Метрика первого бита, была очень сильный ноль, стала сильный ноль. (т.е. ошибка уже тут исправилась).

 

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

0/1 -> -1/+1:    -4.0 -1.0 1.5

Подставим в мои формулы выше:  

llr0 = -8 +abs(-1-1.5) -abs(-1+1.5)=-6

llr1= -2+abs(-4-1.5)-abs(-4+1.5)=1     

Если пропорционально уменьшить все метрики вдвое и опять вернуться к правилу кодирования из статьи, то получим ваши 3.0 -0.5.

Но, к сожалению, это работает хуже в сравнении с простым инвертированием наименьшей метрики в тройке бит. Модель - канал с Гауссовским шумом, добавляемым после BPSK (это другой проект, он не имеет отношения к AMR-сжатым каналам).

 

23 hours ago, Grizzly said:

@gegel то есть даже формулы, которые с MAX, а не abs, дают худший результат по сравнению со сменой знака менее надёжного решения?

C МАХ-log  результат чуть лучше, реализовано так: после каждого взятия abs, если результат меньше максимального индекса якобиановской таблицы, добавляю значение из таблицы по индексу к результату. А алгебраической разницы между вариантами с МАХ и abs нет.

22 hours ago, Grizzly said:

Кстати, а что происходит с "жёсткими" решениями после разных коррекций LLR? И какая модель канала?

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

5 hours ago, thermit said:

Дык, есть же практически готовые решения. Ecall, например.

 

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

Автору темы она не подойдет точно...

Почему же? Если речь идет о моем проекте модема для AMR-сжатого канала (https://github.com/gegel/jackpair/blob/master/Src/mdm/plsmdm.c), то там много чего взято с eCall (вейвформы пульсов в модуляторе, процедуры подсчета LLR в демодуляторе и т.д.). Разница лишь в том, что eСall работает с пакетами и обеспечивает гарантированную доставку, а у меня поток с допустимым уровнем ошибок. Поэтому полностью отличаются механизмы синхронизации.

На самом деле это импульный модем, предложенный Кондозом (https://github.com/gegel/jackpair/blob/master/docs/Kondoz_modem.pdf), с дополнениями из дипломной работы Andreas Tyrberg (https://github.com/gegel/jackpair/blob/master/docs/Turtborg_PulseModem.pdf) + моя синхронизация. Битрейт - 800bps.

Символ длиной в 24 8KHz PCM сэмпла содержит один пульс, занимающий 3 сэмпла в 4-х возможных позициях, и кодируется 3-мя битам: два определяют позицию, а третий - полярность. Это соответствует алгебраической кодовой таблице AMR-кодека, и в тесте дает хорошие результаты вплоть до AMR режима   6.75kbps. 

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

Что касается речевого шифратора для аналоговых УКВ радио, то сейчас реализован вариант на новом бюджетном Cortex M4 Nuvoton M481LIDAE (192 MHz, 160K RAM, 512KROM), и там используется BPSK модем 1200 bps + куча всяких рюшек для быстрой синхро и борьбы с уходом частоты во время замираний (быстрая и медленная синхро, прогнозирование ухода и поиск лага с учетом вероятности как близости к прогнозируемому значению) и т.п. На практике работает изумительно: жалобы обычно на звучание MELPE (тут ничего не поделаешь), но не на модем. Обмен  32 -байтными шифроключами в начале сеанса связи, защищенными Голеем, надежно выполняется за  1-2 сек в каждую сторону даже в очень тяжелых условиях.    

[Grizzly 0]

2 часа назад, gegel сказал:

Эти данные не вписываются в теорию

Возможно, и вписываются :)

В случае инверсии вы "потрогали" только один бит, который обладает наименьшей надежностью. Такая по сути жесткая коррекция есть попытка исправить ошибку, а контрольный бит теоретически этого сделать не может. При этом "сильный" бит не трогается. Жесткие решения ухудшатся. В случае корректировки LLR для обоих битов вы можете уменьшить надежность "сильного" бита, это нехорошо для турбокода. В случае 2D кодов за счет разных проходов и получения таким образом независимости LLR, а затем их пересчета, происходит лучшее уточнее и рост LLR.

 

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

P.P.S. Поискать бы публикации, где есть сравнение для турбокодов, как ведёт себя вероятность ошибок на выходе от входной и от модуля LLR.

[des00 25]

6 hours ago, gegel said:

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

0/1 -> -1/+1:    -4.0 -1.0 1.5

Подставим в мои формулы выше:  

llr0 = -8 +abs(-1-1.5) -abs(-1+1.5)=-6

llr1= -2+abs(-4-1.5)-abs(-4+1.5)=1     

Если пропорционально уменьшить все метрики вдвое и опять вернуться к правилу кодирования из статьи, то получим ваши 3.0 -0.5.

Но, к сожалению, это работает хуже в сравнении с простым инвертированием наименьшей метрики в тройке бит. Модель - канал с Гауссовским шумом, добавляемым после BPSK (это другой проект, он не имеет отношения к AMR-сжатым каналам). 

 

C МАХ-log  результат чуть лучше, реализовано так: после каждого взятия abs, если результат меньше максимального индекса якобиановской таблицы, добавляю значение из таблицы по индексу к результату. А алгебраической разницы между вариантами с МАХ и abs нет.

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

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

[gegel 0]

On 11/24/2018 at 12:03 AM, Grizzly said:

Возможно, и вписываются :)

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

Итого:  
1. Если передавать два бита и третий - контрольный (XOR двух информационных), то, используя метрики, можно успешно корректировать как жесткие решения информационных бит, так и их метрики (мягкий выход).
2. Для коррекции метрики можно к канальной метрике каждого бита добавить внешнюю, полученную из метрик двух остальных бит с помощью формулы:  Lextr(u XOR p) = sign(u)*sign(p)*min(|u|,|p|)
3. После алгебраических преобразований получим эквивалентную формулу:

l0  =  ( k0<<1 + abs(kc-k1) - abs(kc+k1) ) >> 1

l1  =  ( k1<<1 + abs(kc-k0) - abs(kc+k0) ) >> 1
Она возвращает тот же результат, но кажется менее ресурсозатратной для ARM-процессора (не содержит ветвления в min). Хотя надо смотреть по коду, генерируемому компилятором, а лучше замерять к-во тактов. Для плисины вообще не в курсе, возможно, первый вариант проще будет. 

Для чего мне это надо:
1. Как верно заметили на форуме, контрольные биты лучше выбросить (сузить полосу) или использовать в турбо-кодеке.
2. Но они у меня выполняют и другую функцию: обеспечивают синхронизацию. Фрейм разбивается на пары бит, для каждой рассчитывается контрольный бит, они собираются вместе и передаются в виде "хвоста" в конце фрейма, в порядке, обратном к порядку передачи информационных бит. Это дает возможность с точностью до сэмпла  определить (и подстраивать на лету)  лаг, указывающий на конец фрейма. 
3. Синхронизация использует предварительные жесткие решения битов, что позволяет с минимальными вычислительными затратами, используя сдвиговые регистры, вычислять количество ошибок четности всех контрольных бит фрейма для каждого возможного лага (вновь поступившего сэмпла). Усреднение этого значения для 8 последних фремов позволяет после каждого принятого фрейма выбирать лучший лаг. Это прекрасно работает, обеспечивая стабильную синхронизацию до четко подсчитанного уровня BER, ниже которого уже нет смысла демодулировать.
4. Но это не идеально. Лучше было бы использовать свой турбокод, работающи с короткими с элементарными кодами типа (7,4) и научиться столь же просто выполнять синхронизацию на лету, используя малозатратное жесткое декодирование этих элементарных кодов в предварительных жестких решениях (как в "прямом" части, так и после интерливера). На досуге займусь.

Еще раз всем спасибо за помощь, главное - требуемый результат получен!

[des00 25]

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

Короткого турбокода не существует хорошего. банально нечего турбодекодировать. Самый короткий сверточник с каким работал 6 байт данных, а 2D блочник на ваши хотелки, это тот самый (8,4) на SPC кодах, Поэтому тут ох и ах) Как вариант nD треллис модуляци и декодирование ее по витерби.

[gegel 0]

Да, сдвиги все знаковые (в C-коде они и есть знаковые по умолчанию), т.е. эквивалентно умножению,делению на 2. Просто сдвиги в ARM архитектуре входят в сами команды. Хотя, наверное, компилятор и сам это оптимизирует, можно просто умножать/делить на 2 в исходнике.

Я не имел ввиду короткий турбокод, т.е. длину всего фрейма. Фрейм для турбокода вполне может быть под тысячу бит. Но элементарный блочник (8,4) должен очень легко декодироваться жестко, т.к. это надо будет делать на каждом поступившем сэмпле и усреднять суммарное к-во ошибок во всем фрейме  по каждому лагу. Лучшим есть табличный вариант, без всяких циклов.

Т.е. декодируем дважды:

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

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