Автор Тема: ADF4350  (Прочитано 161594 раз)

0 Пользователей и 7 Гостей просматривают эту тему.

Оффлайн GM

  • Старожил
  • ****
  • Сообщений: 201
  • Репутация: +45/-9
  • QRA: KO85SK
Re: ADF4350
« Ответ #300 : 26 Июнь 2019, 19:24:01 »
Кстати, Андрей, поскольку у вас всего две частоты, вам не нужны переключатели с ТХ на RХ и обратно. Попробуйте подключить выход RFOUTA к ТХ, а выход RFOUTВ к RХ.

В четвертом регистре есть включение/выключение как выхода RFOUTA, так и выхода RFOUTВ. Ну, туда к ним подключить фильтры на приём/передачу и ву-а-ля, дело в шляпе! Я сам не пробовал, но по описанию вполне может вам подойти. Затухание до -40 дБм.


Делать надо сразу хорошо, а плохо - само получится.

Оффлайн UR8IP Андрей

  • Ветеран
  • *****
  • Сообщений: 1239
  • Репутация: +291/-38
  • QRA: kn87sc
Re: ADF4350
« Ответ #301 : 26 Июнь 2019, 19:30:40 »
В четвертом регистре есть включение/выключение как выхода RFOUTA, так и выхода RFOUTВ. Ну, туда к ним подключить фильтры на приём/передачу и ву-а-ля, дело в шляпе! Я сам не пробовал, но по описанию вполне может вам подойти. Затухание до -40 дБм.
Это интересно. Но нужна схема, хоть на бумаге, готов опробовать.
73! Андрей

Оффлайн GM

  • Старожил
  • ****
  • Сообщений: 201
  • Репутация: +45/-9
  • QRA: KO85SK
Re: ADF4350
« Ответ #302 : 26 Июнь 2019, 19:59:26 »
Там всё просто. К выходу A через фильтр подключаете приёмник, а к выходу Б через фильтр - передатчик.
Делать надо сразу хорошо, а плохо - само получится.

Оффлайн GM

  • Старожил
  • ****
  • Сообщений: 201
  • Репутация: +45/-9
  • QRA: KO85SK
Re: ADF4350
« Ответ #303 : 26 Июнь 2019, 19:59:48 »
Кто-нибудь лазил к расширенным регистрам 8V97051 чтобы это проверить?

Похоже, чип IDT_8V97051 получше будет, чем ADF4351.
Что удалось заметить при чтении по диагонали.

1) Фазовый шум плл существенно ниже.

2) Регистры синтезатора можно читать (всего регистров восемь)

3) FRAC и MOD могут быть в пределах 2..65535. Это означает, что при частоте сравнения 5 МГц можно получить дискрет перестройки 100 Гц при прочих равных условиях. Можно строить ГСС.

4) INT от 8 до 65535.

5) Выходная мощность от -4 дБм до +12 дБм. В выключенном состоянии менее -80 дБм.
« Последнее редактирование: 26 Июнь 2019, 20:08:24 от GM »
Делать надо сразу хорошо, а плохо - само получится.

Оффлайн UR8IP Андрей

  • Ветеран
  • *****
  • Сообщений: 1239
  • Репутация: +291/-38
  • QRA: kn87sc
Re: ADF4350
« Ответ #304 : 26 Июнь 2019, 20:17:16 »
Похоже, чип IDT_8V97051 получше будет, чем ADF4351.
Может тогда перейти на боле доступные SI5344,SI5340 ?
73! Андрей

Оффлайн GM

  • Старожил
  • ****
  • Сообщений: 201
  • Репутация: +45/-9
  • QRA: KO85SK
Re: ADF4350
« Ответ #305 : 26 Июнь 2019, 21:11:32 »
В чипдипе они дороже (=1550 руб), чем даже ADF4351 (=410 руб) и диапазон у них уже.
« Последнее редактирование: 26 Июнь 2019, 21:29:53 от GM »
Делать надо сразу хорошо, а плохо - само получится.

Оффлайн GM

  • Старожил
  • ****
  • Сообщений: 201
  • Репутация: +45/-9
  • QRA: KO85SK
Re: ADF4350
« Ответ #306 : 26 Июнь 2019, 21:12:33 »
Коллеги, хотелось бы поговорить о дистанционном управлении синтезатором с прмощью МК. Имеется в виду, как изменение частоты синтезатора, или запись новой частоты в МК, так и смена программы.

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

Ну вот, предлагаю простой протокол обмена центрального компьютера (хост) и микроконтроллеров (МК), выполняющих функции связи и управления.

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

Пакет от хоста к МК состоит из 14 байт.

1) Два байта ЗАГОЛОВКА 0x07,0xBB - начало пакета.
2) Один байт АДРЕСА МК 0х01..0xFF - уникальный адрес в системе.
3) Один байт КОМАНДЫ 0х01..0xFF - предписание МК, какую исполнить функцию.
4) Восемь байт ДАННЫХ - зависит от адреса и от команды.
5) Два байта циклической контрольной СУММЫ CRC - для определённости возьмём CCITT-16.

Пакет от МК к хосту также состоит из 14 байт. Заголовок, адрес и команда остаются теми же, а вот данные и CRC могут быть другие.

Если заголовок или контрольная сумма не совпадают, или нет такого адреса или команды - пакет игнорируется. Точно также и при разрыве пакета.

Пример.

Есть устройство на МК ATtiny25, которое управляет синтезатором.
Адрес 0х01. Обмен по УАРТ на скорости 115200 бод. Передатчик подключен ко всем МК звездой, возможно через буферные элементы. Приемник подключается к МК с помощью мультиплексера.

Список команд
0х01 - записать в синтезатор код частоты под номером 1 (байт1=0х01), расположенным в еепром.
0х01 - записать в синтезатор код частоты под номером 2 (байт1=0х02), расположенным в еепром.
. . . . . . . . . .
0х01 - записать в синтезатор код частоты под номером 5 (байт1=0х05), расположенным в еепром.
0х02 - записать в синтезатор код частоты под номером 6 (байт1=0х06), расположенным во флеши.
. . . . . . . . . .
0х02 - записать в синтезатор код частоты под номером 60 (байт1=0х3С),
0х03 - записать в еепром код частоты под номером 2 (байт1=0х02, байт2-байт5 - код).
0х04 - записать во флеш код частоты под номером 10 (байт1=0х0A, байт2-байт5 - код).
0х05 - записать во флеш машинный код инструкции (байт1-байт2=адрес в памяти, байт3-байт4 - код инструкции или, возможно, две инструкции).

Протокол может быть применен для любого устройства в системе связи, например, в опорно-поворотном устройстве.

Прошу высказать конструктивную критику, а также ваши пожелания и предложения.
« Последнее редактирование: 26 Июнь 2019, 21:27:57 от GM »
Делать надо сразу хорошо, а плохо - само получится.

Оффлайн UA3ATQ

  • Ветеран
  • *****
  • Сообщений: 2016
  • Репутация: +201/-21
  • QRA: KO85QV
Re: ADF4350
« Ответ #307 : 26 Июнь 2019, 22:17:39 »
Критиковать сейчас сил особых нет. Но попробую вкратце.

1. Не надо делать фиксированную длину. Может понадобиться гораздо большая длина данных (хоть бы для того же обновления прошивки - гонять больше 50% оверхеда это не есть хорошо). И гонять полный размер только для того, чтобы подтвердить прием - тоже слишком избыточно.

2. НЕ НАДО делать по принципу MODBUS RTU окончание пакета по разрыву между байтами. Просто - не надо, поверьте на слово. У контроллеров которые в UART не имеют прерывания по освобождению сдвигового регистра передатчика это такой геморрой ловить окончание фактической передачи и управлять трансивером RS485 в жестком цейтноте, чтобы не подрезать ответ...... Я бы вообще оговорил задержку не менее 4-5 байтовых интервалов до начала передачи после окончания приема последнего байта.

3. Если на мачту идет линия RS485 (про мультиплексер - это видимо бред был?) то на ней может работать более одного мастера (пульт управления антеннами вдобавок, например). Так что адреса отправителя и получателя были бы не лишними, чтобы было понятно кому и какую команду подтверждают. Также должно быть оговорено негативное подтверждение - например невалидная команда, с возможностью передачи кода ошибки или вообще текстом ответ на ошибку.

Я бы предложил следующее...

1) Два байта ЗАГОЛОВКА 0x??,0x?? - начало пакета - подобрать удобные для autobaud и чтобы пореже встречались в реальных данных.
2) Один байт АДРЕСА МК 0х01..0xFЕ - уникальный адрес ОТПРАВИТЕЛЯ в системе.
3) Один байт АДРЕСА МК 0х01..0xFF - уникальный адрес ПОЛУЧАТЕЛЯ в системе (0xFF - broadcast, получают все кто знает что с этой командой делать, не подтверждая).
4) Один байт КОМАНДЫ 0х01..0x7F - предписание МК, какую исполнить функцию, бит 7 у команды всегда 0, на подтверждении передается код подтверждаемой команды в битах 0-6 и 1 в бите 7 при успехе или 0 при неудаче.
5) Длина блока данных, в байтах
6) Блок ДАННЫХ - зависит от адреса и от команды, длина явно указана выше.
7) Два байта циклической контрольной СУММЫ CRC - CCITT-16 будет годно.

Можно подумать как явно сделать разделение подтверждения и команды, например бит 7 оставить навсегда 0 для команды 1 для подтверждения, а ошибку как то в поле данных унести. Главное чтобы при необходимости вернуть в подтверждении полезные данные с ошибкой не "резалось".
« Последнее редактирование: 26 Июнь 2019, 22:21:23 от UA3ATQ »

Оффлайн khach

  • Старожил
  • ****
  • Сообщений: 484
  • Репутация: +64/-8
Re: ADF4350
« Ответ #308 : 26 Июнь 2019, 22:38:22 »
Поскольку тема про ADF4350-4351. Существуют такие китайские модуля, типа анализатора спектра.
Содержат STM32F103 и две ADF4351, смеситель на IAM-81028  и логарифмический детектор AD8307 .
По интерфейсу прикидываются  NWT4400.
Так к вот этим модулям нашелся оригинал китайских исходников.
https://github.com/joseluu/D6_firmware/releases/tag/0.0 файл main.c
Компилится Кейлом с включением необходимых библиотек RTL.
Может кому пригодится.
Обсуждения одной из версий этой конструкции тут http://alloza.eu/david/WordPress3/?p=542
« Последнее редактирование: 26 Июнь 2019, 22:41:51 от khach »
Александр

Оффлайн UA3ATQ

  • Ветеран
  • *****
  • Сообщений: 2016
  • Репутация: +201/-21
  • QRA: KO85QV
Re: ADF4350
« Ответ #309 : 26 Июнь 2019, 23:59:28 »
Вдогонку - возможный вариант с разделением команд и подтверждений.

0 в старшем бите поля команды - команда от мастера к слейву
1 в старшем бите поля команды - ответ на команду от слейва мастеру. Если длина поля данных 0 - просто положительное подтверждение, если 1 и более - первый байт - статус, 0 - нет ошибок, 1-255 - коды ошибки. Последующие данные в поле данных - доп. данные об ошибке если ошибка или запрошенные данные (если команда - запрос неких данных).

Оффлайн GM

  • Старожил
  • ****
  • Сообщений: 201
  • Репутация: +45/-9
  • QRA: KO85SK
Re: ADF4350
« Ответ #310 : 27 Июнь 2019, 22:07:58 »
Не надо делать фиксированную длину
Как тогда узнать, где кончается пакет?
Делать надо сразу хорошо, а плохо - само получится.

Оффлайн UA3ATQ

  • Ветеран
  • *****
  • Сообщений: 2016
  • Репутация: +201/-21
  • QRA: KO85QV
Re: ADF4350
« Ответ #311 : 27 Июнь 2019, 22:20:03 »
Как тогда узнать, где кончается пакет?

В заголовке явно указана длина поля данных. Принимаем по ней и проверяем CRC в конце. Про парсинг на лету лучше забыть сразу.


Оффлайн GM

  • Старожил
  • ****
  • Сообщений: 201
  • Репутация: +45/-9
  • QRA: KO85SK
Re: ADF4350
« Ответ #312 : 27 Июнь 2019, 23:47:54 »
Предположим, что в длине поля данных N есть ошибка, для определённости Nпринятого > Nпереданного. Тогда байты принимаемого CRC должны быть расположены дальше, чем в реале. Но хост передал заданное количество байт и ждёт ответа, а МК ждёт дополнительных байт, которых никогда не будет. В общем ситуация, как с Буридановым ослом. И это только один из возможных сценариев.
Делать надо сразу хорошо, а плохо - само получится.

Оффлайн UA3ATQ

  • Ветеран
  • *****
  • Сообщений: 2016
  • Репутация: +201/-21
  • QRA: KO85QV
Re: ADF4350
« Ответ #313 : 27 Июнь 2019, 23:53:02 »
Таймаут в таком случае, по любому. Оговаривается максимальная задержка между байтами в пакете и максимальное время ожидания подтверждения.

Та же история если сбой в адресе и такого слейва нет на шине.
« Последнее редактирование: 27 Июнь 2019, 23:56:11 от UA3ATQ »

Оффлайн GM

  • Старожил
  • ****
  • Сообщений: 201
  • Репутация: +45/-9
  • QRA: KO85SK
Re: ADF4350
« Ответ #314 : 28 Июнь 2019, 02:32:10 »
Ну и зачем нам тогда длина поля данных в теле пакета? Как говорится, Моня, зачем нам эти шутки :-)?

Без длины поля данных спокойно можно обойтись! Задержки на длину передачи байта достаточно! А байты передаются без разрыва. Так всё и описано в моём протоколе.

И не забудьте, протокол должен быть простым, как веник, чтобы он мог быть реализован даже на восьминожках типа ATtiny25-ATtiny45-ATtiny85.
Делать надо сразу хорошо, а плохо - само получится.