Krys

А сдвиговые регистры вообще не нуждаются в сбросе )) Они и так выплюнут всю грязь со временем.

В потоке должны быть заложены "резиновые" отсчёты, которые можно убирать или вставлять в необходимом количестве при "проскальзывании" тактовых. При этом они должны быть как-то выделены, что они "резиновые". Например, в Xilinx есть корка Aurora, где сигнал принимается на тактовой передатчика (в другом, незасинхронизированном устройстве), а затем перекладывается в домен локальной тактовой. Естественно, иногда бывают "проскальзывания". Проскальзывания компенсируются "резиновыми" отсчётами, на время которых снимается сигнал валидности в выходном потоке корки. Условно говоря, при равенстве частот всегда передаются 3 "резиновых" отсчёта. При разбеге - либо больше, либо меньше.

И Вам спасибо. Гляну, как будет время. Ох, и много времени чтение книжек отнимает )) В вузе надо было учиться )))

Спасибо!

Ну хоть просто для моего просвещения подскажите, пожалуйста, эквивалентны будут эти задержки, которые я описал в предыдущем сообщении?

Нам же необходима была задержка. Мы её можем получить, выбрав другую фазу (например, 3-ю от начала). А можем просто на 3 такта задержать сигнал по высокой частоте, до децимации. Разве задержка не будет эквивалентной? Вы говорите "очевидно". Мне почему-то нет )) Вы могли бы чуть больше объяснить? Как работает полифазный фильтр - представляю, реализовывал в ПЛИС.

Ну я предыдущий вопрос видимо про это спрашивал. А можете по-простому, на пальцах в двух словах объяснить, как эта схема слежения за фазой работает? Мне интересно, что она с чем сравнивает, как обнаруживает уход. Т.е. уход какой частоты от какой?

Вот так бы сразу и сказали, а то пасть порву, пасть порву надо читать больше книг, надо быть умнее... Я вот встречался с устройствами, засинхронизированными по опоре. Но не через ФАПЧ, а просто запитанных от одного генератора через делитель мощности )) У них перенос ровно в ноль делался )) А если в аналоге мы демодулировали не когерентно, то в цифре имеется небольшое смещение по частоте, фаза начинает набегать. Какими методами в цифре что с чем сравнивают, чтобы понять, какую сделать коррекцию частоты (дополнительный перенос спектра), чтобы компенсировать то смещение в аналоге? (не пытаюсь Вас вывести на незнание предмета, а то Вы что-то агрессивно реагируете, как будто именно это я делаю)

А это не является вытягиванием себя за волосы? Я не уверен, но навскидку мне показалось, что выбор фазы при децимации даст ту же задержку, что и просто линия задержки на нужное число тактов сигнала до децимации. Ведь линия задержки проще и понятнее.

Вы занимаетесь крючкотворством, зацепляетесь за мелкие формальные нестыковки, чтобы показать, какой я мол дартаньян, а остальные все... В рамках физической реализуемости можно говорить "ровно в ноль" при применении синхронизации колебаний несущей модулятора и демодулятора. Ах, ну извините, что со своими холопскими мнениями посмел встрять в обсуждение с человеком с высшим интеллектом и неоспоримым авторитетом (а также завышенным самомнением). Конечно, ведь главное что-то принять, а нужно ли такое "гэ" дальше или нет - нас не волнует. А, как я писал, убегающая фаза в некоторых применениях недопустима.

Не надо утрировать и сводить всё к идеальным условиям, конечно они недостижимы. От осознания наличия шумов не должны опускаться руки с полным отказом от синхронизации. Не засинхронизируешься - будет фаза набегать. Для некоторых методов последующей обработки это критично.

С удовольствием ) какая-либо гармоника в бэйсбэнде (т.е. до модуляции) на частоте w (омега) имеет такую частоту относительно нуля. После модуляции она имеет такую частоту относительно несущей. После демодуляции хотелось бы, чтобы было опять относительно нуля. Вот это я и назвал "ровно в ноль".

дак если ровно в ноль хочется перенести, то синхронизация всё же нужна.

А что значит "вычисляю"? Если уже получилась только целая часть, то откуда из неё получится дробная?

куда делся ТС? Мы уже тут со скуки похоливарить успели, а его всё нет )))

Я извиняюсь, запутался. Действительно, здесь надо влево. БПФ усилил, но, чтобы влезть в разрядность сдвинул вправо с потерей младших битов. А чтобы получить число в его реальном масштабе, нужно обратно сдвинуть влево.

- Подчёркнутое утверждение неверно. Вращающиеся вектора - неправильное объяснение. И что же неправильно во вращающихся векторах? Приведите пожалуйста пример, где модуль выхода БПФ больше максимально возможного размаха его квадратур. Для векторов, вращающихся вокруг единичной окружности это невозможно. Я привёл условия типа "если каждую квадратуру выхода БПФ считать пронормированным к 1". Я согласен, что это для частного случая. Но для него я не сделал ошибку. Согласен, если рассматривать иностранную цитату непогрешимой, то моё утверждение неверно. Но если считать, что цитата не является неоспоримой аксиомой, то ошибся не я, а цитата и Вы вместе с ней. Жирным с подчёркиванием я выделил места под вопросом. "Всегда" - ошибка. Именно про это был мой "вопрос на засыпку", и засыпка произошла. "Saturate the result to 1.15" - в рамках предыдущего "всегда" сатурация не требуется, там просто нечего сатурировать. "after left-shift correction" - мне непонятно, почему влево. Вот пример: Есть переменная 8 битов с форматом 4.4, её нужно вместить с потерей дробной части в 4-битную переменную 4.0. Что мы делаем: исходная переменная, физическая разрядность (не так, которую мы подразумеваем форматом 4.4): 7 6 5 4 3 2 1 0 Надо вместить в переменную: 3 2 1 0 Если просто скопировать биты 3..0 в биты 3..0 - сохранится младшая часть Тогда исходную переменную надо сдвинуть вправо: 0 0 0 0 7 6 5 4 А затем просто скопировать биты 3..0 в биты 3..0: Исходная переменная: 0 0 0 0 7 6 5 4 Копируем: | | | | Конечная переменная: 7 6 5 4 Сдвиг-то вправо. Ещё как корректен, просто это нужно прощупать "на своей шкуре". Очевидно, но первое, что очевидно, оказывается неверным. Вопрос на засыпку был "почему при умножении двух 16-разрядных знаковых чисел в допкоде результат получается 32-разрядным, когда по казалось бы очевидной логике должен быть 31 разряд"? Очевидно это 31 разряд, а не 32. Потому что при умножении полезные данные сосредоточены в младших 15 битах операндов, следовательно 15 * 15 получаем 30 и 1 бит знака. 31 разряд в результате. Откуда 32? Согласен, тут я сделал свой вывод только для своего сигнала. Он был реальный, но с сильным преобладанием несущей, на фоне которой нужно было обнаружить отражения с допплером. А Вы уверены, что смогли охватить этот самый общий случай? Он бесконечен. Все случаи учесть невозможно. Так-то хорошо все утверждения парировать, что это не годится, в общем случае работать не обязано. Универсальный козырь.

Хотел ещё уточнить, что ув. masics был прав, но и обозначенная мной проблема в первом сообщении тоже имеет место. А именно: когда меняем условие на 1'bx в ветке, куда симулятор никогда не зайдёт, поведение становится неправильным. А когда в этой ветке что-то определённое - то поведение предсказуемое и адекватное.

что-то ТС пропал... у Вас всё заработало?

И всё же, пришлось отказаться как от функций, так и от тасков по причине необходимости описывать все переменные в списке чувствительности. Если одну забудешь описать - черевато ошибками, т.к. в блок не будет заходить при её изменении. Перешёл на макросы, так и код один раз вставляется, и список чувствительности по звёздочке автоматически полный. И овцы целы и волки сыты, как говорится.

И всё же ув. masics был прав. Когда переделал в функцию всё вроде бы заработало как надо. Но спустя время выяснилось, что всё равно работает не так, как хотелось. Вспомнил его подсказку, добавил список чувствительности, всё заработало.

)))))))) но я бы её назвал согласно этой аналогии всё же именно псевдофиксированная )

А для комплексного сигнала частоты +F и -F - это 2 разных человека, их некорректно просто усреднять, они независимы, и каждый вносит свою лепту. Вы же не усредняете частоты 0 и 50Гц например.

Ну теперь-то мы уже путём длительного холивара разобрались )))

для вещественного сигнала?