Jump to content

    

Grizzly

Свой
  • Content Count

    896
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Grizzly

  • Rank
    Знающий

Recent Profile Visitors

6762 profile views
  1. Спасибо. Интересно, поищу информацию и почитаю. В первую очередь любопытно, что за мат. аппарат используется и как применяется ЦОС.
  2. С этим согласен. Для высоконадежных применений плохо всё, что тоньше 250 нм. Мне кажется, что в авиации, автомобильной промышленности, медицине, где дело касается непосредственно безопасности, должна быть более строгая сертификация изделия в целом. Как мне кажется, ТС хочет купить обычную платку и написать на ней некий софт. Писаться он будет в стиле Arduino, поэтому ни о каком удовлетворении стандартам типа MISRA не может быть и речи. Это настораживает. То, что ATmega является хорошим контроллером, у меня не вызывает сомнения. Я про подход к разработке изделий, в которых ATmega является лишь частью.
  3. FEC LDPC

    @des00 недавно обновилась версия статьи по полярным кодам в 5G: https://arxiv.org/abs/1804.04389 В ней рассматривается согласование скоростей. Если интересно, то прочитайте. На рис. 11 схема кругового буфера. Обман продолжается :)
  4. Отвечу сам себе ответом с форума Arduino. Из документов Atmel (https://forum.arduino.cc/index.php?topic=238289.0): Products are not designed for and will not be used in connection with any applications where the failure of such Products would reasonably be expected to result in significant personal injury or death ("Safety-Critical Applications") without an Atmel officer's specific written consent. Safety-Critical Applications include, without limitation, life support devices and systems, equipment or systems for the operation of nuclear facilities and weapons systems. Buyer will fully defend (at Atmel's option), indemnify and hold Atmel harmless from and against any cost, loss, liability, or expense arising out of or related to use of Products in Safety-Critical Application.
  5. В общем случае это не обязательно. Существуют алгоритмы БПФ и для других размерностей.
  6. То есть эти устройства не должны быть critical safe и проходить соответствующие сертификации? Мне казалось, что сама элементная база, что написание кода в стиле Arduino не соответствуют данным требованиям.
  7. Только забудьте, пожалуйста, о медицине. Не хотелось бы, чтобы кому-нибудь при лечении или обучении досталось подобное поделие, создаваемое с таким подходом. Обалдеть, терапия будет работать на устройстве с Arduino... Уже :) Ну, правда, стремно же, когда вместо прибора, прошедшего все сертификации, используют что-то купленное на Али и без знания предметной области.
  8. FEC LDPC

    Спасибо! Сильно невнимательно про это прочитал. Теперь всё встало на свои места.
  9. FEC LDPC

    В декодере да. Так и делается. Согласен. Мне показалось из описания процедуры кодирования, что кодер не принимает первые 2Z информационных бит. Этому сильно удивился. В таком случае происходит отображение в совершенно другое кодовое слово, а исходное невозможно восстановить. Видимо, не так понял. Кодировать надо все информационные биты, а уж что выкалывать, дело вкуса :)
  10. FEC LDPC

    @des00 Что-то все равно обман где-то кроется) Если 2Zc бит не передавать на вход декодера, то будет совершенно иное кодовое слово на выходе. В этом случае мы не сможем безошибочно декодировать исходный полный информационный блок. За latency тоже идёт борьба, поэтому в повторных передачах никто не заинтересован. В RV2, получается, не эти ли 2Z битов передаются?
  11. FEC LDPC

    Интересно, что они подразумевают под этим? Удобство получения разных скоростей, простота кругового буфера для разных ретрансмитов RV0...RV3, что-то еще?
  12. FEC LDPC

    А с этим мне тоже непонятно...
  13. FEC LDPC

    Здесь довольно хорошо описано про схемы согласования, но про 2Z нет подробностей: https://ieeexplore.ieee.org/abstract/document/8417496 Посмотрел более подробно zip от 3GPP. Насколько я понимаю, 2Z битов не передаются в случае RV0. Для других схем повторной передачи, например, RV2, они могут быть переданы. Видимо, это сделано для удобства реализации кругового буфера и получения различных вариантов передачи систематических/проверочных битов. В своем первом сообщении я как раз имел в виду тот факт, что помехоустойчивый код должен справляться с ошибками, когда какие-то биты не передавались. Естественно, надо только на приемнике знать структуру кодека, чтобы вставить в нужные места нули или ещё как-то скомбинировать из переданного, чтобы на вход декодера поступал честный полный кодовый блок.
  14. FEC LDPC

    В LTE существует 4 различных варианта ретрансмитов. Обычно при первой отправке данных выкалывают только проверочные биты (но если нужная высокая скорость, то приходится выкалывать и информационные (систематические)). На приемной стороне эти позиции заполнятся нулями. Если декодировали, то всё OK. Если CRC не сошлась, то приемник делает перезапрос. В результате будет отправлен новый блок (либо такой же, либо прочитанный, начиная с другой позиции кругового буфера). А дальше уже в зависимости от того, как был осуществлен ретрансмит, на приемной стороне происходит комбинирование битов (ну или сложение "мягких" решений). Таких ретрансмитов может быть несколько. Вроде бы 8-ю обычно ограничивают, но это не точно :) Вот тут про турбокоды хорошо описано в части II A. Systematic Bit Puncturing, почему лучше выкалывать систематические, а не только проверочные: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.667.268&rep=rep1&type=pdf P.S. Про LDPC в 15-м релизе я пока не прочитал :) UPD. Вот здесь есть некое описание от 3GPP: https://list.etsi.org/scripts/wa.exe?A3=ind1701C&L=3GPP_TSG_RAN_WG1_NR&E=base64&P=67179646&B=--%3D_mixed+006452C7882580AD_%3D&T=application%2Fzip; name="R1-1701473.zip"&N=R1-1701473.zip&attachment=q&XSS=3 Не факт, что это именно принятый вариант, но что-то похоже. Нужно еще почитать и подумать. С LTE я работал, а в схемы кодирования для 5G глубоко не вдавался.
  15. FEC LDPC

    Тогда только единственный выход - смотреть на параметры сигнала (пилоты, преамбулы, длительность фреймов и т.д.) и искать похожие стандарты. Один только поток вряд ли чем-то поможет. Нужно читать внимательно исходники и разбираться, что же всё-таки за система. Желательно с автором, чтобы процесс шел быстрее. И всё равно странно. Как вы, не зная стандарта, так смело можете утверждать о числе информационных битов - 1500. Может быть, это вообще какой-то мусор на выходе декодера. Непонятно.