![](https://electronix.ru/forum/uploads/set_resources_23/84c1e40ea0e759e3f1505eb1788ddf3c_pattern.png)
![](https://electronix.ru/forum/uploads/set_resources_23/84c1e40ea0e759e3f1505eb1788ddf3c_default_photo.png)
ASN
Свой-
Постов
483 -
Зарегистрирован
-
Посещение
Репутация
0 ОбычныйИнформация о ASN
-
Звание
Местный
- День рождения 13.03.1975
Контакты
-
Сайт
Array
-
ICQ
Array
Информация
-
Город
Array
Посетители профиля
6 945 просмотров профиля
-
Вы хорошо знаете ФЗ-44, ФЗ-223? ЕПоЗ от "Ростех"? Там очень четко прописаны процедуры, если им следовать (контролировать, чтобы следовали), то уровень коррупции будет приемлемым. По то, что "для 80% иностранного софта существуют наши аналоги". А кто будет компенсировать затраты на приобретение, переобучение и перевод ЭД в новый формат? Где гарантия, что отечественные производители софта будут оперативно реагировать на ошибки, недочеты? Плавали, знаем. Чем тогда OpenSource плох? Пока я не услышал четкого и конкретного плана-графика перехода, с мероприятиями, финансированием.
- 10 ответов
-
- импортозамещение
- отечественный софт
- (и ещё 8 )
-
RedMine - это CRM. Конечно, можно в ней с помощью ссылок вести архив и КД (в частности, Э3), но мы ее используем именно как CRM: переписка, задачи по исполнителя, ЭД и т.п. Для схем Altium Valut, интегрированная через ID в Лоцман с прикрепленными DataSheets с сетевого диска. Удобная автоматическая генерация перечней, спецификаций и ведомостей покупных. Для КД, лучшее Лоцман. Это PLM. Там есть модуль WorkFlow, но как-то не завели.
-
Из официальных "Лоцман-PLM" (больше всего понравилось сочетание удобство/цена). Для себя - CRM RedMine с плагинами.
-
ПЛИС наши (Россия)
ASN ответил White тема в Работаем с ПЛИС, области применения, выбор
Речь строго о технической информации. ВЗПП-С озвучил, сколько к примеру, будет стоит 044 и срок поставки? Вопрос выбора элементной базы - "техническая информация". Напряжение питания банков IO (для 074) - это тоже "техническая информация". -
ПЛИС наши (Россия)
ASN ответил White тема в Работаем с ПЛИС, области применения, выбор
Цены и сроки поставки - это главное. Извините, но ВЗПП-С сообщил не информацию, а намерения. Все как обычно. Опять "тень на плетень" Особенно шикарно выглядит тезис, про "...ТС064, ТС084, ТС094, ТС104 - больше их не будет". То есть, деньги освоили и "всем спасибо, все свободны". Доверия ВЗПП-С нет. -
Передача речи (или видео) и файлов данных - это разные задачи. В первом случае, эффективен FEC для небольших кадров данных, во втором - HARQ. Универсальное решение будет одинаково плохо работать в обоих случаях.
-
OFDM не тренде?! На основании каких данных появилось такое заключение?
-
Спасибо за развернутый ответ по обнаруживающей способности. Я имел в виду практическую статическую вероятность неправильного детектирования. То есть, если на 100 млн. пакетов проскочит один искаженный, то это допустимая вероятность. Про "заранее узнать". Есть набор возможных принятых последовательностей, которые отличаются определенными байтами, расположенными в произвольном порядке группами. Из эти групп можно сформировать отрезки. Так вот, для CRC можно подсчитать значение частичной CRC для этих отрезков и XOR'ом найти какая комбинация дает верную контрольную сумму.
-
Все верно. Детектировать RS может при достаточной длине проверочных символов. И исправлять. А как обстоит дело с одновременным детектированием и исправлением? Сколько сможет детектировать дополнительные 4, а не 22 проверочных байта RS? Причем с учетом исправления. Речь о том, чтобы разделить задачи списочного декодирования и детектирования ошибки. Использование CRC более обобщенный метод. Я имел в виду возможность использования разных реализаций кодирования. Естественно, надо считать, где результат получиться лучше. P.S. Не подскажите, а есть описание быстрого алгоритма проверки по RS? Не встречал просто, может плохо искал. Более быстрый, чем простое вычисление остатка от всей последовательности (а если вариантов много, то и вычисление остатка также будет много). Мне CRC нравится за простой XOR. Есть что-то такое для RS?
-
Зачем поверх? CRC32 - хеш-функция от данных. Данные и хеш-функция защищаются помехоустойчивым кодом: можно RS (просто), можно свёрточный код с большим K (сложно). Хоть ошибки, как указал уважаемый petrov, все равно будут, их уровень будет меньше, но вот только достаточно этого? Вот насчет каскадного кода не уверен, что для "жестких" решений даст существенный выигрыш. Уж лучше простое повторение (исходя из скорости).
-
Этот механизм реализован в нескольких изделиях, продающихся более 10 лет (без подробностей - NDA). Именно для речи. Все прекрасно работает.
-
Так в том-то и дело, что вариантов выхода декодера может быть много (списочный декодер). Тут CRC и подскажет, который из вариантов верный. И если кадра от данных "развалился", то это можно обнаружить иначе . И скомпенсировать другими средствами (например, CNN). Это же не данные в чистом виде. P.S. По рзелульаттам илссеовадний одонго анлигйсокго унвиертисета, не иеемт занчнеия, в кокам пряокде рсапожолены бкувы в солве. Галвоне, чотбы преавя и пслоендяя бквуы блыи на мсете. Осатьлыне бкувы мгоут селдовтаь в плоонм бсепордяке, все-рвано ткест чтаитсея без побрелм. Пичрионй эгото ялвятеся то, что мы чиатем не кдаужю бкуву по отдльенотси, а все солво цликеом
-
Это не так. CRC используется для проверки правильности декодирования кадра (пакета). Яркий пример - турбокоды: принятие решения об окончании итеративного процесса декодирования. Для HARQ - это только одно из использований. Более того, я встречал реализации, где CRC использовалось даже для снижения сложности демодулятора (но это уже экзотика).
-
Декодер свёрточного кода даст пакеты ошибок. Код RS с этим прекрасно справляется, так что лучше будет. У (133,171) низкий ЭВК при "жестком" декодировании, при этом низкая скорость кода. Если хотите получить приемлемый результат от свёрточного кода на "жестких" решениях, то надо увеличить K (ЕМНИП, до 14) и использовать списочное декодирование (анализировать набор наиболее вероятных путей с выбором по CRC). Однако, рост сложности ML-декодера с ростом K экспоненциальный, а это вычислительная мощность. Или использовать модификации Фано. IMHO, следует попробовать самый проростей вариант: RS с повторение части битов кадра. Если не получится, то тогда уже думать дальше. . Так же обратите внимание на замечание уважаемого des00 о видеокодеке, там тоже есть что подкрутить.
-
Попробуйте RS + CRC32 на пакет. Самое простое. Встречал реализации на свёрточном кодере с K > 11, где анализировался список наиболее вероятных путей с выбором по CRC. Эдакая реализация "мягкости" по выходу за счет большой величины веса путей. Поищите по форуму посты уважаемых des00, yes, petrov, работы П.В. Трифонова и В.Д. Милославской (есть лекции на youtube).