syoma 1 1 апреля, 2020 Опубликовано 1 апреля, 2020 · Жалоба Привет. Надеюсь, что это верный форум для этого. Помогите, пожалуйста решить такую задачку или толкните в правильном направлении, как это решать: Допустим есть один доморощенный протокол обмена 32-х битными словами по последовательному каналу с DC-балансировкой. Передача закодирована таким образом: - Start of Frame закодирован, как 0x335 (1100110101b) - 32-хбитное слово сопровождается 8-битной контрольной суммой (простой XOR) - полученное 40-битное число кодируется 8B10, получаем 50 бит - в итоге посылаем и принимаем 60 бит. - декодирование в обратном порядке. В итоге требуется оценить насколько будет надежно работать данная схема передачи в присутствии помех, а именно: - какова вероятность, того, что рандомный шум, который может изменить 1,2, 3 или больше бит в посылке, будет принят за правильный пакет? - какова вероятность, что приемник декодирует шум, если передатчик не подключен (тогда на линии AC шум) - как повысить помехоустойчивость такой схемы, если есть возможность изменить алгоритм подсчета контрольной суммы? - или схема хреновая сама по себе и желательно ее вообще поменять? Как вариант, думал сделать такой декодер в матлабе, да побомбить его рандомными испорченными пакетами, но чего-то я уверен, что есть более стандартные методы сделать то же самое, только правильно. Не подскажете, какие? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 27 1 апреля, 2020 Опубликовано 1 апреля, 2020 · Жалоба 17 minutes ago, syoma said: - полученное 40-битное число кодируется 8B10, получаем 50 бит - как повысить помехоустойчивость такой схемы, если есть возможность изменить алгоритм подсчета контрольной суммы? Можно попробовать обрезать код BCH (63,45,7) до (50,32,7) с исправлением 3-х ошибок. Но нужно проверять насколько он получится сбалансированным по DC. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 1 апреля, 2020 Опубликовано 1 апреля, 2020 · Жалоба 29 minutes ago, blackfin said: Можно попробовать обрезать код BCH (63,45,7) до (50,32,7) с исправлением 3-х ошибок. Но нужно проверять насколько он получится сбалансированным по DC. Мне сперва хотелось бы оценить текущую схему. Исправление ошибок не требуется, важно именно распознать целостность фрейма и отбросить поломанный. Помимо помех, есть подозрение в том, что приемник может тупо декодировать шум, как полезное сообщение. Как такое может произойти, я не очень понимаю - ведь вероятность такого должна быть вообще мизерной. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 27 1 апреля, 2020 Опубликовано 1 апреля, 2020 · Жалоба 6 minutes ago, syoma said: Мне сперва хотелось бы оценить текущую схему. Ну, XOR это вообще ни о чем.. Для обнаружения ошибки нужна CRC-8. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tpeck 0 1 апреля, 2020 Опубликовано 1 апреля, 2020 · Жалоба 1 hour ago, syoma said: - полученное 40-битное число кодируется 8B10, получаем 50 бит - в итоге посылаем и принимаем 60 бит. Вот этого не понял ( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
petrov 7 1 апреля, 2020 Опубликовано 1 апреля, 2020 · Жалоба Как такое может произойти, я не очень понимаю - ведь вероятность такого должна быть вообще мизерной. Обычно в таких случаях она запросто получается вовсе не мизерной. От DC можно избавиться модуляцией. Сама постановка вопроса бессмысленна, любые помехи приводят к любому результату. Надо моделиравать наихудший случай канала при котором должна обеспечиваться заданная вероятность пропуска, ложного обнаружения, ошибки и т. п. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 1 апреля, 2020 Опубликовано 1 апреля, 2020 · Жалоба 1 minute ago, Tpeck said: Вот этого не понял ( 32-бита число + 8-битная контрольная сумма=40 бит. При перекоде 8B10B из каждых 8 бит получаем 10. Т.е. из 40-битного числа получается 50-битное. + 10 бит Start of Frame = 60 бит "on wire" 17 minutes ago, blackfin said: Ну, XOR это вообще ни о чем.. Для обнаружения ошибки нужна CRC-8. Допустим, так оно и есть. А как их можно сравнить, не делая натурных тестов? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tpeck 0 1 апреля, 2020 Опубликовано 1 апреля, 2020 · Жалоба 53 minutes ago, syoma said: + 10 бит Start of Frame = 60 бит "on wire" 1 hour ago, blackfin said: Теперь понял. Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 30 июля, 2020 Опубликовано 30 июля, 2020 · Жалоба В общем упрощаю задачу: Надо передать четыре 8-и битных числа по последовательному каналу в виде одного пакета. На стороне передатчика по ним считается 8-и битная контрольная сумма, которая передается пятым байтом в том же пакете. На стороне приемника все эти 5 байт принимаются и контрольная сумма проверяется. При несовпадении принятой и подсчитанной приемником контрольных сумм пакет считается принятым ошибочно и отбрасывается. Допустим алгоритм подсчета контрольной суммы может быть выбран произвольно. Единственное условие - в результате должно получиться 8-и битное число. Как теоретически и практически проверить стойкость конкретно выбранного алгоритма к возможным ошибкам при передаче? Т.е. вероятность того что конкретный пакет с ошибками покажет правильную контрольную сумму и будет ошибочно принят? Нужно ли отдельно считать вероятность для одного, двух, трех и т.д. ошибочно принятых бит? Как это сделать правильно? Я так понимаю, что есть определенный предел из-за ограниченного количества бит в контрольной сумме, но я так понимаю, что можно сделать намного хуже, если выбрать неправильный алгоритм подсчета. Как это правильно посчитать и проверить? Для проверки я могу генерировать рандомные числа и вносить побитовые ошибки, чтобы сравнить теоретическую вероятность с практической. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 30 июля, 2020 Опубликовано 30 июля, 2020 · Жалоба Коды, исправляющие ошибки. Вот, что вам нужно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
arhiv6 20 30 июля, 2020 Опубликовано 30 июля, 2020 · Жалоба 41 минуту назад, syoma сказал: Как теоретически и практически проверить стойкость конкретно выбранного алгоритма к возможным ошибкам при передаче? Т.е. вероятность того что конкретный пакет с ошибками покажет правильную контрольную сумму и будет ошибочно принят? В этой статье сравнивали стойкость различных видов контрольных сумм. Там же описано, как именно проводились тесты. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 30 июля, 2020 Опубликовано 30 июля, 2020 · Жалоба 6 minutes ago, arhiv6 said: В этой статье сравнивали стойкость различных видов контрольных сумм. Там же описано, как именно проводились тесты. Та видел я ее. Не нравится мне там подход к тестированию стойкости - теория как-то не строится с практикой. 39 minutes ago, ViKo said: Коды, исправляющие ошибки. Вот, что вам нужно. Как один из вариантов, пробую ATM HEC, который по идее может корректировать один бит и детектировать 2 ошибочных бита. Но мне в принципе коррекция не нужна - я могу отбросить пакет и он передастся заново. Поэтому желательно все-таки большая вероятность детекции, чем коррекция. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 30 июля, 2020 Опубликовано 30 июля, 2020 · Жалоба Я намекаю, что при передаче 32 информационных битов с помощью 60 битов вы можете распорядиться дополнительными битами более эффективно, чем просто высчитать xor. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 30 июля, 2020 Опубликовано 30 июля, 2020 · Жалоба 2 minutes ago, ViKo said: Я намекаю, что при передаче 32 информационных битов с помощью 60 битов вы можете распорядиться дополнительными битами более эффективно, чем просто высчитать xor. Забудьте про XOR, то я неправильно написал. Вычисляется нормальная контрольная сумма. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Eddy_Em 2 30 июля, 2020 Опубликовано 30 июля, 2020 · Жалоба On 4/1/2020 at 4:31 PM, syoma said: 32-бита число + 8-битная контрольная сумма=40 бит. При перекоде 8B10B из каждых 8 бит получаем 10. Т.е. из 40-битного числа получается 50-битное. + 10 бит Start of Frame = 60 бит "on wire" А не проще уж тогда дублировать пакет? Все равно у вас почти 64 бита уже получается. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться