stealth-coder

Отбрасываемые разряды тоже содержат информацию, при простом обрезании она теряется, при округлении - частично сохраняется. Формула корректная, но если пользоваться готовыми реализациями от Xilinx, например, то нельзя выставить произвольную разрядность, в таком случае экономия выходит боком. В теории - да, в жизни - если в ПЛИСе есть место, почему бы не добавить системе помехоустойчивости?

Из собственного опыта: 1. Везде использовать математическое округление, это сильно влияет на качество. 2. Наибольшее влияние на качество оказывает разрядность первых CIC-ов, чем ближе к выходу, тем менее критично. 3. Если есть возможность - делайте разрядность по максимуму, на выходе ставите окно нужного размера (обязательно с округлением) - получаете цифровое АРУ.

Быстро - это сколько? Озвучьте задачу с цифрами и бюджетом, шансы получить ответ вырастут... Современные ARM-ы за такт умножение делают. Типичная DSP - задача. Что-то не припомню контроллеры с MAC. Софт (Code Composer Studio), JTAG, тех. подддержка, плата, доп. элементы, коих там может быть довольно много, труд разработчиков в пересчете на довольно скромные тиражи, доставка, прибыль компании, прибыль реселлера. Тут копейка, да там копейка, вот и набегает. Себестоимость iPhone 220$, но в магазине он почему-то 1000$ стоит.

Излучайте не синусоиду, а, например, фазоманипулированный сигнал, модулирующую последовательность возьмите с хорошими корреляционными свойствами, например, последовательность Баркера, затем вычислите корреляцию: фаза вектора корреляции покажет дробную часть, а смещение по времени укажет на целое число периодов.

Ключевой вопрос - а зачем отказываться от использования алгебры или таблицы? Поставьте ПРОБЛЕМУ, тогда есть шанс услышать от кого-нибудь подходящее решение. Например: ресурсов вот столько, как вычислить фазу? Возможно, что Вы и сами не знаете в чем собственно ПРОБЛЕМА, поэтому и не можете найти решение.

2. Полиномы RCS для Wimax и DVB одинаковые, но перемежители разные. Это сделано по политическим причинам или это результат "улучшения" характеристик декодера в процессе разработки стандарта? Совершенно разные каналы генерируют совершенно разные ошибки (одиночные/пачки, длина пачки и т.д.), отсюда и разные перемежители, подобранные каждый под свои модели каналов. 3. В сверточных бинарных кодах, свойство tail-bitting используется при декодировании: В одной доке нашел что дополняют принятую последовательность вначале и в конце, затем декодируют по витерби и выкусывают нужное. В примере матлаба вообще составляют два фрейма, декодируют один за другим, потом из двух декодированных собирают один результат. Никакого намека на похожие операции в доках на турбокоды не нашел. Почему в алгоритмах SOVA/MAP/... для турбокодов это не делается? Вопрос в получаемом энергетическом выигрыше и цене, которую за это надо заплатить. В случае сверточных кодов tail-biting дает +0.3 дБ, а платой за это является требование увеличения вычислительной мощности устройства, на котором реализуется декодер. По всей видимости в случае турбокодов это нецелесообразно.

Делали разностно-дальномерный пеленгатор, а в качестве исходных данных брали корреляционные всплески. Для вычисления "до тысячных долей чипа" нужно либо адское отношение сигнал/шум либо усреднение на адском интервале. ИМХО реализуемо только в моделях.

Там есть страшная вещь - зависимость по данным, которая рушит конвейер, от нее не уйти и сходу просаживается производительность (в случае TigerSHARC) минимум в 2 раза, возможности SIMD при использовании плавающей точки ограничены, использование фиксированной точки для реализации приведенного алгоритма сомнительно, т.к., скорее всего, очень быстро накопится достаточно большая ошибка. Ну и в приведенной реализации нет операции деления Im / Re, что в случае DSP, как правило, делается каким-нибудь Ньютоном-Рафсоном, CORDIC же позволяет не выполнять деление.

По-моему проще Rapid IO поднять, 1 Гбайт/сек точно будет.

Насчет любых DSP не согласен. Недавно решали задачу, в которой нужно вычислять много арктангенсов, DSP TigerSHARC 101, CORDIC + SIMD дал результат лучше (в смысле вычислительных затрат) чем оптимизированный полиномиальный, хотя отдельно взятый CORDIC проигрывает. ТС: хочу обратить Ваше внимание, что в DDC с целью подавления спуров при генерации квадратурной гармоники используются некоторые хитрости, например, младшие разряды заменяются на соответствующий отрезок ПСП. Если не ошибаюсь, в Матлабе есть такая модель (или у Xilinx-а в генераторе корок, запамятовал уже).

Сравнить спектр исходного и восстановленного сигнала на интервале кодирования?

А зачем их нормировать? phi = atan2(im / re), если с делением напряг, то CORDIC в помощь.

К сожалению, способа, дающего нулевую вероятность ложной тревоги, в природе не существует. Сначала нужно определить допустимую вероятность ложной тревоги, а потом уже искать способ решения. Например, CRC 16 бит имеет вероятность ложной тревоги 0.02%, т.е. если на декодер CRC подать 5000 случайных пакетов, то на одном (в среднем, конечно, на выборке в несколько сотен тысяч пакетов) пакете CRC "сойдется". Существуют аналогичные оценки для различных ПУ кодов, копайте гугл. Либо моделируйте.

Вы хотите построить МОДЕЛЬ, в таком случае нужно точно определиться, какие характеристики являются существенными, а какие - нет, потому что сделать модель АЦП со всеми шумами, нелинейностями и пр. - задача очень серьезная. Если Вас интересует лишь модель из книжки, которая поясняет базовые принципы работы параллельного АЦП, тогда просто перерисуйте ее оттуда: параллельное АЦП есть набор резисторов-делителей напряжения и компараторов. Вот вам и "параллельный выход", и "шумы квантования".

Intel Integrated Performance Primitives

Для защиты от несанкционированного доступа к циркулирующей информации используют шифрование, другие средства не гарантируют хоть какую-то надежность в этом смысле ибо опираются на предположение об отсутствии у противника информации о способе формирования сигнала. Обеспечение скрытности - вопрос сложный и комплексный ибо в сущности своей противоречит связи (лучшая защита от СПИДа - никаких половых контактов): 1. Максимально короткие сеансы связи 2. Узконаправленные антенны 3. Вынесение пунктов связи в сторону от мест дислокации штабов, частей и т.д. Защита от подавления - повышение помехоустойчивости в обмен на скорость передачи (шумоподобные сигналы, помехоустойчивые коды, помехоустойчивые виды модуляции (BPSK против QAM1024) и самонаводящаяся ракета в створ антенны РЭБ противника. В любом случае вопросы скрытности, защиты и надежности комплексные и простого ответа (типа "FHSS") не существует, все есть система компромиссов.

Стандарт 802.11b использует DSSS на основе последовательности Баркера длиной 11 чипов (скорость 1 и 2 Мбит/с) или на основе последовательностей Уолша длиной 8 чипов (для скоростей 5.5 и 11 Мбит/с). Стандарт 802.11g/n использует классический OFDM.

Скажите, пожалуйста, Вы этим занимаетесь с целью получения навыков/знаний или чтобы сделать продукт? Если продукт, то не мучайтесь, возьмите готовый, у Xilinx точно есть (да, я знаю, что это за деньги, но если очень хочется.... ну Вы меня поняли).

Не холивара ради :))) На вкус и цвет фломастеры, конечно, разные, но сам по себе С++ предназначен для облегчения написания больших проектов благодаря ООП (вопрос, о котором уже много лет идет спор) и большому количеству библиотек (тут споров меньше). 1. Большой проект для DSP представить себе затрудняюсь (например, реализация базовой станции GSM/UMTS проект небольшой (по сути DSP и предназначены для таких задач) по сравнению с какими-нибудь СУБД (желающих реализовать ORACLE на DSP пока не встречал :). 2. Большинство библиотек для PC использовать на DSP невозможно в силу слабости компилятора, небольшого объема памяти и т.п., а практически все библиотеки, ориентированные на DSP, реализованы на С. Вот и получается, что в большинстве случаев использование C++ сводится к "С с классами", когда указатель на this передает не программист ручками, а компилятор. Более 10 лет пишу и на С, и на С++. Раньше был горячим сторонником С++ и ООП, а на С писал "потому что система так построена", но с опытом пришел к выводу, что за небольшой синтаксический сахар плачу разгребанием всякого геморроя типа исключений, который выбрасывают библиотеки, несовместимостью компиляторов и т.д. Сейчас большинство новых проектов сразу пишу на С. Разве что по STL иной раз взгрустну...

oversampling с последующей фильтрацией/децимацией позволяет уменьшить шум квантования. Условно говоря, двукратное увеличение частоты дискретизации с последующей децимацией/фильтрацией эквивалентно (в идеальном случае) увеличению разрядности АЦП на 1 бит. Физически это объясняется так (тезисно): 1. Шум квантования определяется разрядностью АЦП (чем больше "ступенька", тем больше ошибка, тем больше шум). 2. Шум квантования равномерно распределен в полосе оцифрованного сигнала. 3. Полоса оцифрованного сигнала равна половине частоты дискретизации. 4. Фильтрация с использованием более узкой полосы (далее можно уменьшить частоту дискретизации) позволяет удалить шум квантования вне полосы пропускания фильтра. Обратите внимание, что речь идет о шуме, который вносит само устройство ЦОС, а не о шуме исходного сигнала.

1. Запуском платформ не занимаюсь, работаю на прикладном уровне, но в директории, куда установлен Visual DSP, есть директория Examples, посмотрите там 2. С++ - это для embedded не гуд, в основном пишут на С (примеры, библиотеки и т.п. написаны на С), будете постоянно иметь проблемы с линковкой. Решаемо, но С++ здесь избыточен. ИМХО.

1. Стандартный подход в мобильных системах связи - замена потерянных пакетов на комфортный шум (silence frame), нигде не видел использования схем перезапросов (для речи, конечно), даже при потере половины фреймов (не куском, конечно, а более-менее "размазанная" по времени) речь разборчива. 2. Простое использование помехоустойчивого кодирования не поможет, т.к. очевидно, что не справляется кодирование самого WiFi, НО если у вас есть возможность получать от модема ВСЕ пакеты, в т.ч. и битые, тогда это имеет смысл; 3. Пом. уст. кодирование может помочь при использовании перемежителя (на интервале нескольких пакетов), тогда потерянные блоки могут быть восстановлены декодером, естественно, за это придётся заплатить задержкой; 4. Не знаю тонкостей решаемой задачи, но если возможно, то использовать вокодер, который "сожмёт" поток и тогда: 1) Можно передать несколько одинаковых пакетов за то же время; 2) Уменьшить скорость передачи и за счёт этого повысить помехоустойчивость (WiFi это умеет). При использовании вокодера задержка будет равна сумме длительности фрейма (обычно 20 мс) и времени кодирования/декодирования (в худшем случае, очевидно, не более длительности фрейма, иначе это перестанет быть системой реального времени).

Файл в wav формате. Что Вас смущает? В начале файла идёт стандартный RIFF-заголовок, в котором указаны частота дискретизации (1.125 MHz), stereo (т.е.I+Q), скорость потока 72000 kbps, т.е. разрядность 32 бита. Можете открыть в Cool Edit (Adobe Audition) и посмотреть на него. Как работать в Matlab - смотрите в help-е или в google.

Книг с описанием конкретных реализаций практически не существует из-за кучи нюансов и тонкостей, имеющих отношение к конкретным микросхемам и конкретным задачам. Зато все крупные производители микросхем (Analog Devices, Free Scale, Texas Instruments, Xilinx) выпускают пачками статьи по реализации тех или иных задач на их микросхемах с приведением исходных кодов, описанием алгоритмов и т.д. Если говорить о FPGA, то тот же Xilinx выпустил core-генератор, в котором помимо возможности генерации реализаций есть описание теории и особенностей решения задачи с помощью их микросхем. Резюме: если с теорией разобрались, то ищите тематические статьи на сайтах производителей чипов.

http://en.wikipedia.org/wiki/Undersampling