Коллеги,кто сталкивался с этой микросхемой? После загрузки регистра R0 на фильтре ФАПЧ появляется напряжение 1,3В , удерживается ~300мкс и плавно опускается до нуля. Очень похоже что не срабатывает калибровка. Дамп регистров при загрузке в TICS Pro ошибок не вызывает. Кто нибудь может подсказать что либо из опыта работы с ней? Всё таки в даташите есть непонятки. Например, как определяется параметр FRAC_ORDER, есть формула для расчёта VCO_AMPCAL , но неизвестно что делать с этим значением и т.д. В пристёжке дамп загрузки регистров.

Попробуйте в R20[10] прописать 0

Спасибо за неравнодушие!
Вы правы, это мой косяк. Но это я исправил давно и сейчас имею гетеродин с частотой настройки от 10МГц до 15ГГц. Это всё работает, а вот дальше начинаются чудеса. Теперь задача - добиться заявленной в DS скорости перестройки частоты 5мкс. В микросхеме 7 ГУН-ов, я пока работаю с первым (7,5ГГц...8,6ГГц). Если изменять частоту в этом диапазоне то на фильтре ФАПЧ вполне ожидаемо увидеть разные уровни напряжения для каждой частоты. В реальности я вижу на спектроанализаторе что выходная частота равна заданной, LOCK в единице, а вот напряжение на фильтре практически не изменяется Это если не использовать ассистентов. Если же прибегать к помощи ассистентов то можно добиться изменения напряжения на фильтре при изменении частоты, но с отрицательной крутизной(при увеличении частоты напряжение уменьшается). В DS на этот счёт ничего не сказано.
7584МГц - 0,7В
7616МГц - 0,63В
7664МГц - 0,25В

При частоте ГУН 7680МГц и выше наступает срыв захвата ФАПЧ т.к. напряжение на фильтре около нуля. А до озвученных 8,6ГГц ещё очень далеко...
Попробовал измерить крутизну ГУН - она оказалась в пять раз больше заявленной.
По прежнему не ясно что писать в R19 (параметр VCO_CAPCTRL). Не ясно куда писать вычисленное значение VCO_AMPCAL(интуитивно догадался что писать нужно в R17, но так или нет х.з.)
И даже в режиме работы с ассистентом для области частот где есть захват скорость перестройки остаётся недопустимо большой (500...1000мкс).
Через меня прошли десятки различных синтезаторов, но в такой ситуации я впервые

Диапазон каждого ГУНа разбит в свою очередь ещё на несколько пересекающихся поддиапазонов, выбираемых путём коммутации емкостей. Насколько я представляю себе механизм калибровки, то подбирается такой код емкости, чтобы управляющее напряжение составляло где-то половину от напряжения питания. При этом и частота ГУНа оказывается примерно в центре поддиапазона. Это обеспечивает удержание частоты при воздействии дестабилизирующих факторов.
Для наглядности посмотрите картинку из даташита на ADF4351 (Figure 20). Там 3 ГУНа, и каждый разбит на 16 полос.

По поводу скорострельности следует чуть подробней описать схему: какая опорная частота, полоса фильтра (ещё хорошо бы модель в PLLatinum Sim) и как измеряете время перестройки?

Спасибо огромное, очень ценная информация! Теперь хоть прояснился смысл калибровки. С ADF4351 мне приходилось работать, но они запускались с пол-пинка поэтому глубоко не копал. Но в DS на ADF4351 хоть прямым текстом говорят про разбиение на 16 полос, а в DS на LMX2594 так явно не разжёвано. Похоже для СВЧ-синтезаторов такая структура стала нормой,поэтому на ней и не заостряют внимание.

Опорная частота 40МГц+удвоитель. Итого частота сравнения 80МГц.
Время перестройки меряю по длительности просечки в сигнале LOCK.
Во вложенном файле нужно изменить расширение на sim.

_Anatoliy, вы используете PLLatinum sim от техасов? Просто я когда настраивал столкнулся с тем, что поддиапазоны VCO, указанные в даташите какие то странные, а то что выдаёт PLLatinum работает.

Насчёт FRAC_ORDER, насколько я помню, есть только ограничение на минимальное значение N делителя. При этом у меня нормально работает FRAC_ORDER 3 и выше, иначе спуры высокие.
Впрочем, тут уже много компромиссов с шириной петли и т.д.

Спасибо! Тоже ценная информация, я проверю.

А можно немного подробней о FRAC_ORDER? Я не нашёл в какой регистр его записывать. Как Вы его изменяете? Вы работали с этой микросхемой? Какая скорость перестройки получилась?
Может Вы прольёте свет на:

Меня сейчас интересует любая информация дополняющая DataSheet.

Проверил - поддиапазоны ГУНов в PLLatinum(v1.5.0.0) и даташите совпадают.

Так, значит возможно не совпадало у меня на LMX 2582. Но проверить не повредит. По крайней мере любое действие посмотреть в платинуме. И почтитать подсказки которые он выдаёт.

Насчёт FRAC_ORDER, порядок сигма-дельта модулятора, он у них там называется MASH_ORDER почему то во второй половине даташита. Если я ничего не попутал. Регистр 44.

По времени перестройки для 2594 ничего не скажу, работал с ней мало. в 2582 время автоматической калибровки было +- километр, в зависимости от частоты. Такое ощущение что VCO перестраивается с верху вниз пока не встанет на нужную частоту. При "ручной" калибровке всё по даташиту.

Как они задолбали, один и тот же сигнал называют в разных местах по разному. И не только этот сигнал.

Вот что они пишут о калибровке:


А меня очень смущает R19. Смотрите что я делаю. С интервалом 1Сек загружаю синтезатор то на 10ГГц, то на 12ГГц и смотрю переходной процесс.
Флажки такие - VCO_DACISET_FORCE = 1, VCO_SEL_FORCE = 1, VCO_CAPCTRL_FORCE = 0. При таких значениях флажков синтезатор перестраивается, LOCK после перестройки высокий, время перестройки примерно 500мкс. Но стоит мне только включить VCO_CAPCTRL_FORCE = 1 и всё тухнет, напряжение на фильтре около нуля, LOCK низкий. Методом перебора удаётся подобрать константу для R19(VCO_CAPCTRL), появляется LOCK но только для частоты 12ГГц. Причём +-2 для константы и всё тухнет. Для частоты 10ГГц подобрать так и не удалось. Ну не должно такого быть, если VCO_CAPCTRL так влияет на захват то должно вычисляться его значение для записи.
Глянул сейчас описание для LMX2582, различия таки есть. Но посмотрите,плз, какое значение Вы загружали в VCO_CAPCTRL (для LMX2582 это R22)? В datasheet на эту микросхему тоже не приводят зачение, только допустимый диапазон значений(0...183).

По ходу ещё один вопрос. R0 я загружаю последним(требование производителя).Логично было бы предположить что все изменённые параметры применились бы тоже при записи в R0. Однако видно что LOCK начинает падать сразу после загрузки коэффициентов деления(N,NUM,DENUM,NVCO). Итого у меня сейчас LOCK падает на 700мкс, а после записи R0 устанавливается высоким через 60мкс. Есть какой-то механизм обхода сего явления?

Ну вроде всё верно, вы выбираете вручную ядро VCO, вы говорите также что вручную будете задавать подключаемую ёмкость в контуре, далее если вы выбираете ёмкость такую которая выводит диапазон перестройки VCO за пределы установленной частоты, то усё, оно не работает.
Для предельно низкого времени перестройки для каждой своей частоты надо знать и ядро VCO и ёмкость. Если ёмкость оставить автоматике, то экономия времени будет за счёт выбора ядра только. Но это уже неплохо. Лучше чтобы рабочая частота была ближе к средине диапазона перестройки, логично предположить.
Я так понимаю и про ширину петли не надо забывать, к примеру при широкой петле перепрошивка на соседнюю ёмкость не приведёт к расстройке pll, а с узкой приведёт, у меня если частоту перестраивать маленькими шажками на автоматической калибровке в пределах одного VCO, lock detect вообще не падал.

В том то и вопрос состоит - как задавать подключаемую ёмкость в контуре?
2. Calculate the VCO CapCode as follows
VCO_CAPCTRL_STRT = round (CCoreMin – (CCoreMin – CCoreMax) * (fVCO – fCoreMin) / (fCoreMax - fCoreMin));
Так я вычисляю значение, записываемое VCO_CAPCTRL_STRT (R78), а вот какое значение нужно прописать в VCO_CAPCTRL (R19) - остаётся загадкой.
TICS для этого регистра формирует какой-то код для загрузки, но как он это делает неясно.

Попробуйте в режиме автокалибровки пройтись по нужным частотам и одновременно считывать R111[7:0] - вот эти значения затем и вписывайте в VCO_CAPCTRL (R19) при работе в ручном режиме.

Спасибо, конечно попробую. Только мне это совсем не подходит, так как я заранее не знаю на каких частотах будет работать синтезатор в изделии, значения частот будут вычисляться и в принципе могут быть любыми.

Вообще то меня вполне устраивает время перестройки и без флага VCO_CAPCTRL_FORCE(~60мкс). Единственная проблема осталась:

Писал в поддержку TI - в ответ тишина. Сейчас я вижу только один путь - повышение частоты клока SPI до максимума. Но не могли же они пойти на этот косяк ради экономии нескольких регистров для буферизации?
Кстати, это наблюдается не всегда. Например если скакать на низких выходных частотах(100МГц в 200МГц и обратно) - LOCK честно падает после загрузки R0. А если задать частоты 10ГГц и 10,5ГГЦ (третий ГУН) - эффект есть, LOCK падает уже после загрузки NUM.

Ещё хотел бы добавить по поводу быстродействия: в приводимой Вами модели опорный генератор обладает весьма посредственными характеристиками по фазовому шуму, из-за этого полоса фильтра вычисляется слишком узкой, что увеличивает время захвата.

Не понял. Полоса в Платинуме вроде не вычисляется, а задаётся. У меня была задана полоса 100КГц, т.е. время захвата должно быть порядка 40мкс. Сейчас пересчитал фильтр на полосу 500КГц.

Даже когда Вы задаёте полосу вручную (нет галки "Auto"), программа сообщает, что фактическая полоса ~ 45 кГц. И это как-раз по причине неадекватности фазового шума опорного генератора шумам микросхемы.

То есть советую взять опорник получше, например вот такой сразу на 80 МГц.

Ясно, спасибо!
У этого генератора действительно шумовые параметры получше, но неприемлемо большая нестабильность +-18ppm. У нас на порядок меньше.
Мне кажется что вклад ширины полосы в общее время перестройки очень незначителен по сравнению с проблемой описанной мной выше в посте № 14, чтобы заострять на нём внимание. С другой стороны - раз нет других соображений по этому вопросу, видимо придётся уповать только на повышение до максимума тактовой частоты SPI. Но это мне пока проверить не на чем.