[vitaly_n 0]

Всем привет!

Дано: имеется некий абстрактный канал передачи данных. Имеется детектор, который как-то принимает (аналоговый) сигнал и выдаёт принятые символы Xi. Помимо этого детектор выдаёт дополнительную информацию о "качестве" приёма каждого i-го символа Li. Тут задача разбивается на две подзадачи - одна задача, если этот сигнал о "качестве детектирования" бинарный (0 или 1), вторая задача - если этот сигнал аналоговый (например, в диапазоне от 0 до 1). Теперь предположим, что по этому каналу мы передаём блоки информации с кодом контроля целостности блока, например, CRC. Этот CRC мы можем закодировать помехоустойчивым кодом с большей избыточностью, чем основной блок данных, если это поможет нам в решении задачи.

Итак, мы принимаем блок данных. Считаем принятый CRC с вычисленным от принятого блока. Если расстояние Хэмминга не более определённой разработчиком кода величины, скажем, не более 1-2 ошибочных бит, то считаем, что это ошибки в приёме CRC, а сам блок данных принят без ошибок. Иначе считаем, что сам CRC принят без ошибок, а ошибки случились в блоке данных.

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

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

Вопрос, собственно, вот в чём. Чую, что изобретаю велосипед. Соответственно, кто может подсказать, как это правильно называется по-русски и по-английски, чтобы задать вопрос гуглю, а то, может, сразу назвать автора и статью (книгу)?

[Grizzly 0]

3 часа назад, vitaly_n сказал:

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

Похоже на "мягкие" решения - soft decision/soft decoder. Там вычисляются отношения правдоподобия, но вычисляются они в демодуляторе и от FEC не зависят.

3 часа назад, vitaly_n сказал:

Если расстояние Хэмминга не более определённой разработчиком кода величины, скажем, не более 1-2 ошибочных бит, то считаем, что это ошибки в приёме CRC, а сам блок данных принят без ошибок. Иначе считаем, что сам CRC принят без ошибок, а ошибки случились в блоке данных.

На каком основании можно выдвинуть такое смелое утверждение?

[vitaly_n 0]

20 hours ago, Grizzly said:

На каком основании можно выдвинуть такое смелое утверждение?

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

[Grizzly 0]

Может быть, @des00 и @FatRobot подскажут.

В каком-то смысле полярные коды похожи, где по "плохим" подканалам передаются, например, нули, а по "хорошим" нужная информация.

[des00 25]

On 3/8/2021 at 11:05 AM, vitaly_n said:

Итак, мы принимаем блок данных. Считаем принятый CRC с вычисленным от принятого блока. Если расстояние Хэмминга не более определённой разработчиком кода величины, скажем, не более 1-2 ошибочных бит, то считаем, что это ошибки в приёме CRC, а сам блок данных принят без ошибок. Иначе считаем, что сам CRC принят без ошибок, а ошибки случились в блоке данных.

Если честно, вот этот момент мне совсем не понятен. Особенно исходя из описания как вы планируете использовать CRC для принятия решения о наличии местоположения ошибки. Но, не суть.

Из вашего описания, мне тоже не совсем понятно о чем идет речь. Вижу 2 варианта:

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

2. Коды с жестким входом, но работающие в режиме мягкого декодирования на основе алгоритмов Чейза. В этом случае составляется карта ненадежных символов/бит, эти биты стираются, проверяются гипотезы на жестком декодере и выбирается наиболее близкая. Так например можно декодировать код Галея с количеством ошибок превышающими половину хэммингова расстояния.

А еще, с помощью добавления CRC, усложняется блок принятия решений в декодере полярных кодов. Там накапливается апостериорная вероятность, выдвигаются гипотезы и дополнительно проверяется на CRC. Можно почитать в 3GPP документах. В вашем случае, можно сделать вот так:

Принимаете данные + CRC, определяете d-2d наименее надежных символов, составляете список возможных кодовых слов, проверяете их на CRC, из прошедших выбираете наиболее близкий по евклидовой метрике. Получите что-то вроде декодера максимального правдоподобия.

 

ЗЫ. начать можно с расмотрения/реализации мягкого Галея

ЗЗЫ. Естественно все зависит от длины кода, с очень длиными кодами будет тяжело строить такой декодер.

On Soft-decoding of the (24, 12, 8) Extended Golay Code up to Six Errors.pdf Simplified Algorithm and Hardware Implementation for the (24, 12, 8) Extended Golay Soft Decoder Up to 4 Errors.pdf

[FatRobot 4]

Ого, приятно быть в одном ряду с большими учеными. По существу вопроса:

Детектор выдает "мягкое" решение + есть оценка SNR. Все это конвертируется в LLR, и декодер уже работает со значениями LLR

https://uk.mathworks.com/help/comm/ug/digital-modulation.html#brc6yjx

Работает он так уже лет 50, см., например, декодер Витерби

https://uk.mathworks.com/help/comm/ref/viterbidecoder.html

 

Смысла передавать CRC более надежным способом нет. Если не хватает детектирующей способности, то нужно увеличить разрядность полинома CRC.

Или увеличивать корректирующую способность кода. 

[vitaly_n 0]

Моё почтение!

10 hours ago, des00 said:

Если честно, вот этот момент мне совсем не понятен. Особенно исходя из описания как вы планируете использовать CRC для принятия решения о наличии местоположения ошибки. Но, не суть.

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

 

За упоминание алгоритма Чейза и ссылочки на статьи - спасибо! Нашёл по мягкому декодированию в последней главе в "Теории и практике кодов контролирующих ошибки" Блейхута и в четвёртой главе "Кодирование с исправлением ошибок в системах цифровой связи" Кларк, Кейн. Буду читать.

 

PS Посмотрел список Ваших проектов. Очень заинтересовал "контроллер SDRAM". У меня есть вот такая проблема. Spartan 6 + IS42S81600F-7TL. Частота 128 МГц. Использование такое - прилетает пакет 332 байта, они записываются, каждый байт в новой строке нового банка, затем другой байт из другого столбца той же строки вычитывается + precharge. После приёма/передачи каждого пакета базовый адрес столбца сдвигается. Между пакетами - авторефреш. Внутри пакета авторефрешей нет. Проблема вот в чём. После простоя с авторефрешами первое чтение косячное с вероятностью примерно 10%. Такое ощущение, что "глаз" выдачи данных для первого чтения меньше остальных. Остальные 331 байт в пакете вычитываются идеально. Сделал отдельный клок для стробирования чтения, пытался двигать его по фазе - победить проблему так и не смог. Не сталкивались с такой проблемой?

 

PPS А, может, ещё вот по такому вопросу сориентируете? Сейчас у меня есть решение канальный код 8B10B + поверх него код Голея (23, 12, 7). Исправляет 3 байта из 23. Spartan 6 LX9. 2BRAM + пара сотен LUT и регистров, но полезный поток получается 307,2 Мб/с из 800. Возникла дурная мысль поискать помехоустойчивый код, который в дополнение к основной функции исправления ошибок сочетал бы ещё в себе и полезные свойства канального кода 8B10B - DC-balance и clock recovery, ну и давал бы КПД не менее 38,4% при той же корректирующей способности. Не слышали о таких? (Разумеется, ресурсы FPGA очень жалко!)

Изменено 9 марта, 2021 пользователем vitaly_n

[des00 25]

20 hours ago, vitaly_n said:

PS Посмотрел список Ваших проектов. Очень заинтересовал "контроллер SDRAM". У меня есть вот такая проблема. Spartan 6 + IS42S81600F-7TL. Частота 128 МГц. Использование такое - прилетает пакет 332 байта, они записываются, каждый байт в новой строке нового банка, затем другой байт из другого столбца той же строки вычитывается + precharge. После приёма/передачи каждого пакета базовый адрес столбца сдвигается. Между пакетами - авторефреш. Внутри пакета авторефрешей нет. Проблема вот в чём. После простоя с авторефрешами первое чтение косячное с вероятностью примерно 10%. Такое ощущение, что "глаз" выдачи данных для первого чтения меньше остальных. Остальные 331 байт в пакете вычитываются идеально. Сделал отдельный клок для стробирования чтения, пытался двигать его по фазе - победить проблему так и не смог. Не сталкивались с такой проблемой?

Вам лучше создать отдельную тему в подфоруме плис и более подробно расписать задачу. Что-то мне подсказывает что дело не в фазе тактовой, этоже SDRAM, тактовая одна, все привязано к ней. А вот циклограмма вашего обмена не совсем ясна. Если ломается сразу после смены записи на чтение, то может быть дело не в совсем корректной реализации bus turn around или еще каком моменте разворота шины. 

20 hours ago, vitaly_n said:

PPS А, может, ещё вот по такому вопросу сориентируете? Сейчас у меня есть решение канальный код 8B10B + поверх него код Голея (23, 12, 7). Исправляет 3 байта из 23. Spartan 6 LX9. 2BRAM + пара сотен LUT и регистров, но полезный поток получается 307,2 Мб/с из 800. Возникла дурная мысль поискать помехоустойчивый код, который в дополнение к основной функции исправления ошибок сочетал бы ещё в себе и полезные свойства канального кода 8B10B - DC-balance и clock recovery, ну и давал бы КПД не менее 38,4% при той же корректирующей способности. Не слышали о таких? (Разумеется, ресурсы FPGA очень жалко!)

Не совсем понимаю зачем такой кодек 1/2 в оптике, точнее даже не так, зачем такой кодек в связи на оптических линях, 3 из 23 дает коэффициент битовых ошибок ~1e-1. У вас воздушная связь что ли?

А варианты можно предложить разные, смотря что требуется и какие требования предъявляются. Например замена 8B10B на 64B/66B кодек, отказ от 8B10B в пользу проприетарного аддитивного скремблера и собственной кадровой синхронизации. Но это копейки.

Гораздо больше можно получить от кодирования. Определитесь со структурой и порогом ошибок, задержкой, а уже от этого определитесь с декодером. Если вам кровь из носу нужен жесткий код исправляющий 3 битовые ошибки на блок из 23 битов, то беглый расчет показывает что Галлей оптимальный).

Укороченный байтовый RS GF(256) 249/255. При усечении до 30 байт даст в лучшем случае исправление 3-х байтов на блок при избыточности 1.25. Правда в худшем случае будет 3 бита. Различные варианты БЧХ GF(2^5...2^8), для аналогичного уровня ошибок на блок из 23 бит показывают избыточность близкую к Галею. Но вам точно это надо? 

[vitaly_n 0]

1 hour ago, des00 said:

Не совсем понимаю зачем такой кодек 1/2 в оптике, точнее даже не так, зачем такой кодек в связи на оптических линях, 3 из 23 дает коэффициент битовых ошибок ~1e-1. У вас воздушная связь что ли?

А варианты можно предложить разные, смотря что требуется и какие требования предъявляются. Например замена 8B10B на 64B/66B кодек, отказ от 8B10B в пользу проприетарного аддитивного скремблера и собственной кадровой синхронизации. Но это копейки.

Гораздо больше можно получить от кодирования. Определитесь со структурой и порогом ошибок, задержкой, а уже от этого определитесь с декодером. Если вам кровь из носу нужен жесткий код исправляющий 3 битовые ошибки на блок из 23 битов, то беглый расчет показывает что Галлей оптимальный).

Укороченный байтовый RS GF(256) 249/255. При усечении до 30 байт даст в лучшем случае исправление 3-х байтов на блок при избыточности 1.25. Правда в худшем случае будет 3 бита. Различные варианты БЧХ GF(2^5...2^8), для аналогичного уровня ошибок на блок из 23 бит показывают избыточность близкую к Галею. Но вам точно это надо? 

А это и не оптика. Это медный кабель (точнее, даже 12 кабелей), причём, в условиях электромагнитных помех от рядом расположенного промышленного оборудования (сервоприводы, искрящие реле, коллекторные электродвигатели и т.д.). Да, конечно, можно взять дорогой экранированный кабель и задавить помехи, но проблема именно в том, что он дорогой...

Задача была такая - с минимом ресурсов сделать более-менее рабочий канал передачи данных не менее 250 Мб/с. В центре стоит Spartan 6 45T, заполненный на 75%. К нему подключаются 12 периферийных устройств на Spartan 6 LX9 или даже LX4. Соответственно, никакие тяжеловесные 64B/66B туда просто не влезут.

Специально выводил отладочные сигналы наружу, чтобы смотреть, как часто возникают ошибки в пакетах. На хорошем дорогом кабеле ошибок почти нет - одна за день может случиться. А вот на дешёвом кабеле (обычный офисный Ethernet Cat.5e) - ошибки в 1 бите возникают очень часто, ошибки в 2 битах - редко, ошибки в 3 битах - крайне редко. Иногда встречаются длинные пакеты ошибок длительностью до 2 мс, ну это смертельно и непобедимо при помощи кодирования. (Это запуск коллекторного мотора такие помехи даёт.)

В общем, отбой воздушной тревоги! Если сходу не назвали - глубоко рыть не надо. Сам разберусь. Я тут уже прикинул, что примерно получается. Посмотрел на коды длиной 12, 14, 16, 18, 20, 22 и 24 бита с максимальной длиной не более 4 одинаковых бит подряд. Расстояние Хэмминга d, очевидно, только чётное. Итак, при d=4 интерес представляет код длиной 14, для d=8 24-битный, но как его декодировать - ещё даже не думал. Скорее всего, оставлю то, что есть, вряд ли придумаю лучше и экономнее...

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

1 hour ago, vitaly_n said:

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

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

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

[vitaly_n 0]

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

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

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

У нас жёсткий реалтайм - через 20 микросекунд устаревшие данные просто не нужны. Совсем. Поэтому у нас другой метод - в случае выявления таких помех конструктору станка делается внушение, после чего он провода от серводвигателя размещает на другую сторону портала подальше от кабелей с нежными данными... Сервопривод с векторным управлением - это, доложу вам, охрененная штука! Прямоугольный ШИМ сигнал с крутыми фронтами амплитудой 300 вольт по трём фазам... У меня даже квадратурный энкодер с дифференциальным сигналом RS-422 с ума сходил от таких помех!

[des00 25]

13 hours ago, vitaly_n said:

А это и не оптика. Это медный кабель (точнее, даже 12 кабелей), причём, в условиях электромагнитных помех от рядом расположенного промышленного оборудования (сервоприводы, искрящие реле, коллекторные электродвигатели и т.д.). Да, конечно, можно взять дорогой экранированный кабель и задавить помехи, но проблема именно в том, что он дорогой...

Задача была такая - с минимом ресурсов сделать более-менее рабочий канал передачи данных не менее 250 Мб/с. В центре стоит Spartan 6 45T, заполненный на 75%. К нему подключаются 12 периферийных устройств на Spartan 6 LX9 или даже LX4. Соответственно, никакие тяжеловесные 64B/66B туда просто не влезут.

Оптика решит все ваши проблемы + обеспечит запас на расширение вашей системы. SFP модули на гигабит дешевые, они и оптические пачкорды в любом более менее серьезном магазине. 

Quote

Специально выводил отладочные сигналы наружу, чтобы смотреть, как часто возникают ошибки в пакетах. На хорошем дорогом кабеле ошибок почти нет - одна за день может случиться. А вот на дешёвом кабеле (обычный офисный Ethernet Cat.5e) - ошибки в 1 бите возникают очень часто, ошибки в 2 битах - редко, ошибки в 3 битах - крайне редко. Иногда встречаются длинные пакеты ошибок длительностью до 2 мс, ну это смертельно и непобедимо при помощи кодирования. (Это запуск коллекторного мотора такие помехи даёт.)

Важно же не только сколько ошибок но и на каком периоде они появляются. Короткие коды плохи тем что их избыточность велика. Делал систему на HDMI кабеле, проприетарный протокол, 6.25 Гб/с полезного трафика на артиксе 100. Структура ошибок в кабеле из ларька была пакетной от 1 до 4 бит на блок 1024 бита. Укороченный БЧХ 980/1000 4 штуки в ряд, с временным перемежением решили проблему. Но  в следующей версии ушли на оптику 10Гб/с. 

ЗЫ. У нас есть институт сильноточной электроники, они одно время тоже любили медь, но потом поняли что оптика надежнее, проще и лучше. Для низких скоростей дешевые китайские пластиковые волокна, для высоких нормальные)

[vitaly_n 0]

49 minutes ago, des00 said:

Оптика решит все ваши проблемы + обеспечит запас на расширение вашей системы. SFP модули на гигабит дешевые, они и оптические пачкорды в любом более менее серьезном магазине. 

Увы... У нас только половина применений допустит такое, а другая половина требует передачи данных по сверхгибкому кабелю (миллион изгибов с радиусом кривизны 10 см, и этого хватает примерно на 2 года эксплуатации). В принципе, LAPP делает такие кабеля с оптоволокном (правда, там радиус изгиба больше), но там проблемы и с трансиверами, и с инструментом... Скажем, это надо каждому инженеру набор для разделки такого кабеля брать за $2000... Я один раз брал на эксперименты - бухту кабеля, трансиверы на 125 Мб/с, набор для разделки - мне это долго ещё потом припоминали... В общем, дешёвые - это только для ширпотребного коммуникационного оборудования со стационарной установкой, для подвижного случая дешевле и доступнее получается всё-таки медь.

[petrov 8]

vitaly_n

Сколько должно по одной витой паре передаваться? 250 Мегабит/c?

[vitaly_n 0]

11 minutes ago, petrov said:

vitaly_n

Сколько должно по одной витой паре передаваться? 250 Мегабит/c?

Угу. В "сухом остатке".