-
Ответ #300
от GM 26 Июн, 2019 19:24
-
Кстати, Андрей, поскольку у вас всего две частоты, вам не нужны переключатели с ТХ на RХ и обратно. Попробуйте подключить выход RFOUTA к ТХ, а выход RFOUTВ к RХ.
В четвертом регистре есть включение/выключение как выхода RFOUTA, так и выхода RFOUTВ. Ну, туда к ним подключить фильтры на приём/передачу и ву-а-ля, дело в шляпе! Я сам не пробовал, но по описанию вполне может вам подойти. Затухание до -40 дБм.
-
Ответ #301
от UR8IP Андрей 26 Июн, 2019 19:30
-
В четвертом регистре есть включение/выключение как выхода RFOUTA, так и выхода RFOUTВ. Ну, туда к ним подключить фильтры на приём/передачу и ву-а-ля, дело в шляпе! Я сам не пробовал, но по описанию вполне может вам подойти. Затухание до -40 дБм.
Это интересно. Но нужна схема, хоть на бумаге, готов опробовать.
-
Ответ #302
от GM 26 Июн, 2019 19:59
-
Там всё просто. К выходу A через фильтр подключаете приёмник, а к выходу Б через фильтр - передатчик.
-
Ответ #303
от GM 26 Июн, 2019 19:59
-
Кто-нибудь лазил к расширенным регистрам 8V97051 чтобы это проверить?
Похоже, чип IDT_8V97051 получше будет, чем ADF4351.
Что удалось заметить при чтении по диагонали.
1) Фазовый шум плл существенно ниже.
2) Регистры синтезатора можно читать (всего регистров восемь)
3) FRAC и MOD могут быть в пределах 2..65535. Это означает, что при частоте сравнения 5 МГц можно получить дискрет перестройки 100 Гц при прочих равных условиях. Можно строить ГСС.
4) INT от 8 до 65535.
5) Выходная мощность от -4 дБм до +12 дБм. В выключенном состоянии менее -80 дБм.
-
Ответ #304
от UR8IP Андрей 26 Июн, 2019 20:17
-
Похоже, чип IDT_8V97051 получше будет, чем ADF4351.
Может тогда перейти на боле доступные SI5344,SI5340 ?
-
Ответ #305
от GM 26 Июн, 2019 21:11
-
В чипдипе они дороже (=1550 руб), чем даже ADF4351 (=410 руб) и диапазон у них уже.
-
Ответ #306
от GM 26 Июн, 2019 21:12
-
Коллеги, хотелось бы поговорить о дистанционном управлении синтезатором с прмощью МК. Имеется в виду, как изменение частоты синтезатора, или запись новой частоты в МК, так и смена программы.
Те программули, которые приводились мною выше, предполагают наличие кнопок и светодиодов в непосредственной близости от синтезатора. С другой стороны, если синтезатор на мачте или на крыше, то в пургу неохота туда лазить...
Ну вот, предлагаю простой протокол обмена центрального компьютера (хост) и микроконтроллеров (МК), выполняющих функции связи и управления.
Хост и МК обмениваются пакетами фиксированной длины. Обмен всегда начинает хост. МК обязательно отвечает квитанцией. Обмен может быть осуществлён с помощью любой полудуплексной линии связи. Все байты в пакете передаются без задержек между байтами. Каждый пакет заканчивается пустым интервалом, как при передаче одного байта.
Пакет от хоста к МК состоит из 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 - код инструкции или, возможно, две инструкции).
Протокол может быть применен для любого устройства в системе связи, например, в опорно-поворотном устройстве.
Прошу высказать конструктивную критику, а также ваши пожелания и предложения.
-
Ответ #307
от UA3ATQ 26 Июн, 2019 22:17
-
Критиковать сейчас сил особых нет. Но попробую вкратце.
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 для подтверждения, а ошибку как то в поле данных унести. Главное чтобы при необходимости вернуть в подтверждении полезные данные с ошибкой не "резалось".
-
Ответ #308
от khach 26 Июн, 2019 22:38
-
-
Ответ #309
от UA3ATQ 26 Июн, 2019 23:59
-
Вдогонку - возможный вариант с разделением команд и подтверждений.
0 в старшем бите поля команды - команда от мастера к слейву
1 в старшем бите поля команды - ответ на команду от слейва мастеру. Если длина поля данных 0 - просто положительное подтверждение, если 1 и более - первый байт - статус, 0 - нет ошибок, 1-255 - коды ошибки. Последующие данные в поле данных - доп. данные об ошибке если ошибка или запрошенные данные (если команда - запрос неких данных).
-
Ответ #310
от GM 27 Июн, 2019 22:07
-
Не надо делать фиксированную длину
Как тогда узнать, где кончается пакет?
-
Ответ #311
от UA3ATQ 27 Июн, 2019 22:20
-
Как тогда узнать, где кончается пакет?
В заголовке явно указана длина поля данных. Принимаем по ней и проверяем CRC в конце. Про парсинг на лету лучше забыть сразу.
-
Ответ #312
от GM 27 Июн, 2019 23:47
-
Предположим, что в длине поля данных N есть ошибка, для определённости Nпринятого > Nпереданного. Тогда байты принимаемого CRC должны быть расположены дальше, чем в реале. Но хост передал заданное количество байт и ждёт ответа, а МК ждёт дополнительных байт, которых никогда не будет. В общем ситуация, как с Буридановым ослом. И это только один из возможных сценариев.
-
Ответ #313
от UA3ATQ 27 Июн, 2019 23:53
-
Таймаут в таком случае, по любому. Оговаривается максимальная задержка между байтами в пакете и максимальное время ожидания подтверждения.
Та же история если сбой в адресе и такого слейва нет на шине.
-
Ответ #314
от GM 28 Июн, 2019 02:32
-
Ну и зачем нам тогда длина поля данных в теле пакета? Как говорится, Моня, зачем нам эти шутки :-)?
Без длины поля данных спокойно можно обойтись! Задержки на длину передачи байта достаточно! А байты передаются без разрыва. Так всё и описано в моём протоколе.
И не забудьте, протокол должен быть простым, как веник, чтобы он мог быть реализован даже на восьминожках типа ATtiny25-ATtiny45-ATtiny85.
SA1.jpg