ASN
Свой-
Постов
483 -
Зарегистрирован
-
Посещение
Весь контент ASN
-
Вы хорошо знаете ФЗ-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).
-
Сделать несложно и то и другое: если на ЯВУ (пример, C) - то не более недели. Уважаемый des00 правильно указал, что самое первое - сделать модель системы в Matlab, где есть уже готовые модули. Но, повторюсь, я бы исходил , в первую очередь, из доступной вычислительной мощности: объема памяти и MIPS. При наличие достаточных ресурсов и на "жестких" решениях можно получить неплохой результат (в целом). Оптимизация системы под конкретную задачу даст больший эффект, чем оптимизация отдельных частей (например, помехоустойчивое кодирование). Поэтому и вопрос про задержку, обратный канал и вычислительную мощность.
-
Как я понял, для Вас коды с мягким декодированием не подойдут, т.к. передатчик цифровой. Тогда самое эффективное, наверное, алгебраические (RS, БЧХ). Классические сверхточные коды (алгоритм Витерби и Турбо-колы), а так же LDPC будут уступать. Хотя, для более-менее полезного ответа на вопрос, IMHO, мало данных: надо знать допустимую задержку трафика, наличие обратного канала и вычислительную мощность МПС на приеме.
-
Выбор канального кодека
ASN ответил Dobermann тема в Алгоритмы ЦОС (DSP)
Вот тут, IMHO, варианты есть. Но следует учесть, что у Вас - не радиоканал. -
Выбор канального кодека
ASN ответил Dobermann тема в Алгоритмы ЦОС (DSP)
Это не так: все упирается в ограничения: требуемая вероятность (качество), скорость, задержка и, обязательно, вычислительная мощность. Следует определится с этими параметры, тогда можно предложить какие-то пути решения. То есть, какая задача системы, такая и оптимизация структуры (СКК) под нее. Универсального решения не существует. Уважаемый stealth-coder хорошо описал зависимость вероятности от размера пакета. -
Выбор канального кодека
ASN ответил Dobermann тема в Алгоритмы ЦОС (DSP)
Это канальный байтовый протокол нижнего уровня (вроде UART "удлинителя")? Тогда обеспечение надежности передачи должны обеспечивать протоколы верхнего уровня. Зная из структуру можно туда "заглядывать". И использовать для детектирования ошибок пакетов. IMHO, если просто вообще ничего не знать о характере трафика (пакетах хотя бы 10-20 байт), то короткий БЧХ или Голей. -
Выбор канального кодека
ASN ответил Dobermann тема в Алгоритмы ЦОС (DSP)
А каким способом детектируются ошибки? То есть, как приемник определяет, что кадр (пакет) содержит недостоверные данные? Какова вероятность верно принять разные сформированные кодером источника последовательности? Если, как указал уважаемый petrov, "на выходе кодека хорошо отделяются друг от друга", то варианты есть. Отсюда и вопрос про вычислительные мощности. -
Выбор канального кодека
ASN ответил Dobermann тема в Алгоритмы ЦОС (DSP)
Конечно, уважаемый petrol, несомненно прав. Но указал на Вашу проблему применения кодов и OFDM для не АГШВ каналов (как в Вашем случае). Я имею в виду немного другое: что является критерием адекватности? IMHO, не стоить ориентироваться только на процент канальных ошибок. Предложенный уважаемым stealth-coder код может дать неплохие результаты при условии наличия критерия правильности принятия последовательности декодером источника. -
Выбор канального кодека
ASN ответил Dobermann тема в Алгоритмы ЦОС (DSP)
Решение, IMHO, должно лежать не в плоскости исправления канальных искажений, а в плоскости приемлемого качества всей результирующие системы. Этот критерий достаточно гибкий, и, IMHO, лежит для данной задачи, больше в области кодирования источника, а не канала. То есть, критерием качества принятой последовательности (кода канала) служит качество восстановленной последовательности кодера источника. Отсюда и вопрос про вычислительные мощности и задержку. -
Выбор канального кодека
ASN ответил Dobermann тема в Алгоритмы ЦОС (DSP)
Какие вычислительные ресурсы в наличии? Какие требуемые задержки? -
Ну и какое это отношение имеет к теме? Жалобы про высокую себестоимость мелкой серии чипов - это не ко мне. Не можешь производить - уйди с рынка. Все просто. Так есть 2Мх16 или нет?