Из Workspace константы использую в модели непосредственно по их именам.
Запись массива в Workspace через блок To Workspace.
Чтение/запись многоканальных временных рядов из/в .wav файлы через блоки From Multimedia File/To Multimedia File.
И в 2021 то же самое. Вообще в этом отношении только деградация от версии к версии, верхнее меню всё испоганили в очередной раз, GUI тормозит, памяти требует гигантское количество, выкидывают какие-то невинные функции, нарушая совместимость моделей между версиями и т. д. и т. п.
Экспроприируем серпом и молотом!
Там прекрасно знают про такое использование, и им выгодно, чтобы люди использовали их инструмент, а если заработал с помощью него большие деньги, так почему бы и не купить.
Я двумя руками за свободный софт, но Octave немного не то, не обладает такой наглядностью как Simulink.
Да, сделали такое дурацкое изменение, решения не нашёл, вытаскиваю наружу.
Ещё можно маркеры включить, точки будет видно, но график в наглядности сильно теряет.
des00
А разве база тройка даст эвк по 1е-6 больше 5дб?
Понятно, что это так себе. Не всегда людям очевидно, что можно увеличить энергию на бит вообще ничего не делая. Можно сделать базу двойка, дальше БЧХ по-проще с Чейзом.
Каждый бит передавать тремя символами с интерливингом, на приёме соответственно простое суммирование мягких значений до принятия решения, коды выкинуть. (:
_sda
Вы имеете ввиду модели в симулинке? А о каких задержках речь?
Я пишу программную реализацию, здесь в отличие от FPGA латентность отсутствует.
Ну вот в картинках из журнала вижу задержки, они не зависят от реализации. Разработка алгоритма и перенос его на язык - разные задачи, если совмещать, то происходит самозапутывание.
_sda
Подскажите, знающие люди, почему так может происходить?
В коде быстро теряется обозримость, элементарная ошибка в индексации массивов и всё поехало, ведь даже в статье картинки для чего-то, а не кусок кода на C. Вы же уже делали всё это в виде блок схемы, где все задержки в явном виде.
GrishaRezn
Вы хотите сказать, что при неравномерном распределении ОСШ по поднесущим, допустим BCJR, требующий знания ОСШЭ будет функционировать неверно, если мы в каждый подканал поставим АРУ?
Разумеется ничего хорошего, подавать на вход декодера кода усиленный шум вместо правильных мягких решений. Ещё проще можно продемонстрировать для жёстких решений, в наихудшем случае сколько будет спектральных нулей при максимальной задержке между лучами в длительность циклического префикса, с какой огромной избыточностью потребуется БЧХ код для исправления, сравнить с избыточностью БЧХ для исправления стираний, когда мы оцениваем, где спектральные нули стёрли передаваемые биты. Конечная цель не АРУ, а данные принять наилучшим образом.
GrishaRezn
Остается задача
Основная задача данные принять, как можно более правдоподобно, эквалайзер сам по себе никому не нужен. В наихудшем случае, при котором OFDM должна работать(а иначе она и не нужна), в поднесущих спектральные нули, сигнала нет, нужно ли шум усиливать? В OFDM важна совместная работа с кодом корректирующим ошибки, важно ли для кода, что отношение сигнал/шум в поднесущих разное?
soldat_shveyk
Или не подводит.)) Да, дальше там есть про отбеливающий.
Возможно, начать с DFE - хорошая идея.
Можно использовать линейную часть DFE как этот самый отбеливающий-согласованный, а коэффициенты в обратной части DFE как оценку канала для алгоритма Витерби.
