Восстановление цифрового сигнала Опции

[iiv]

Всем привет,

есть два аппарата, общающиеся по скоростной линии по 3-м ногам аля SPI - первый аппарат шлет клок по первой линии всегда, второй аппарат непрерывно посылает на каждый клок один бит информации по второй линии, а по третьей ноге первый аппарат сообщает второму о том, что дошло ли и что дальше посылать.

Оба аппарата общаются через плиски.

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

Сейчас реализовано все так - второй первому шлет пакеты по 9кбит, после этого пакета идет CRC, если пакет пришел битый, то происходит запрос на перепосылку пакета.

Запрос возникает примерно в 20% случаев, на декодирование СРС на приемнике и старт-стоп пакета я теряю примерно 300 тактов пересылки (3%). Если уменьшать размер пакета - то оверхед увеличивается, если удлинять пакет - вероятность битости данных увеличивается. Хочется все-таки улучшить проходимость пакетов.

При детальном анализе получилось, что почти всегда битость пакета - это либо

1. один ошибочный бит,
2. один пропущенный бит (клок пропустился),
3. один случайно возникший дополнительный бит в начале передачи.

Скажите, пожалуйста, есть ли способ кодирования сигнала, который бы позволял бы исправить эти типы ошибок?

Спасибо

ИИВ

[Tiro]

есть два аппарата, общающиеся по скоростной линии по 3-м ногам аля SPI - первый аппарат шлет клок по первой линии всегда, второй аппарат непрерывно посылает на каждый клок один бит информации по второй линии, а по третьей ноге первый аппарат сообщает второму о том, что дошло ли и что дальше посылать.

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

Поддержу уважаемого Тау.

Для высокоскоростной дуплексной передачи трехпроводные синхронные интерфейсы не подходят. Скорость распространения электромагнитного взаимодействия в вакууме составляет 0,3 м/нс. Это при эпсилон вакуума 1. Диэлектрическая проницаемость материала плат на FR-4 примерно 4-6, в проводах похоже. Там скорость ЭМ волны ниже в квадратный корень из диэл проницаемости, то есть раза в 2.

Теперь учтем время распространения сигнала туда, реакцию второго устройства, распространение обратно и реакцию первого устройства. И все это должно произойти не медленнее, чем за полтакта клока. Пусть все времена примерно равны и устройства близко, примерно в метре. Тогда половина клока не менее 4*3,3 нс и клок не выше 75 МГц всего.

Используйте либо двунаправленные синхронные интерфейсы, а лучше двунаправленные асинхронные интерфейсы.

[iiv]

Используйте либо двунаправленные синхронные интерфейсы, а лучше двунаправленные асинхронные интерфейсы.

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

Список корректирующих кодов

спасибо! начал читать - довольно много, но и очень познавательно. Если вдуг книжку найдете, буду премного благодарен!

[тау]

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

на лишний клок жмотиться - неправильно. Лучше скорость поднимите , чтобы вписаться в более узкую шину, но клок от каждого передающего возмите свой, раз без клока не хочется . Несколько удлинителей в связке это плохо. Сделайте нормальный кабель.
600мбит по 4х метровому DVI кабелю пролезают запросто большими пакетами без потерь, правда в асинхронном режиме.

[iiv]

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

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

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

Фактически я снова возвращаюсь к моему исходному вопросу - надежному алгоритму восстановления пропущеных битов клока или данных.

[Виктория]

Фактически я снова возвращаюсь к моему исходному вопросу - надежному алгоритму восстановления пропущеных битов клока или данных.

Извиняюсь перед всеми, я работаю в другой предметной области и поэтому интерпретируйте это как взгляд со стороны:
Возможна потеря как клока, так и бита данных - это основная проблема, т.к. почти соотношение неопределенностей.
Если бы только потеря в данных, то вроде можно говорить про восстановление битовой последовательности, взяв на воорружение методы цифровой фильтрации.
Если бы только в клоках - дополнительные измерения по таймеру на стороне приемника/передатчика.
А так как Вы ставите вопрос, это больше похоже на NP сложную задачу.

Может выкинуть клоки? Пойти к примеру по такому пути http://www.findpatent.ru

[_Pasha]

Может выкинуть клоки?

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

Сообщение отредактировал _Pasha - Oct 6 2012, 13:22

[Виктория]

Книжка обещанная
Видать, не так давно выложили, раньше не было.

Ага, все пошли в библиотеку

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

Хорошо только топикстартеру, отдыхает поди...