ADF4350

[GM]

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

Ага, вот это и есть частичный "парсинг на лету". Вы, ещё не приняв до конца пакет, отловили длину данных и используете её.

Да, и про заголовок. Заголовок в своём протоколе, я определил как два байта: 0x07 и 0xBB. Нет там места для "длины поля данных". Щательнее надо, товарисч.

[UA3ATQ]

Я ниже свой вариант давал - и под заголовком в данном случае я все что до поля данных (которое может быть нулевой длины) понимаю.

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

Парсинг содержащихся в поле данных команд "на лету" - дурной тон в данном случае. Пока не принято CRC - ничего не делаем с полем данных.

[khach]

Если на мачту идет линия RS485

А может подумать в сторону DISEQ с управлением по центральной жиле кабеля тоном 22 кГц - стандарт описан, библиотеки есть.  А для локального управления синтезатором оставить обычный RS232. При этом приемник DISEQ может быть другим процессором чем процессор управления синтезатором.
Только просьба большая есть - вывести наружу на разьем сигналы lock detect и muxout.
Ps. кто-нибудь ставил на втрую пару выходов АДФ простейший диодный удвоитель для диапазона 4.4-8.8 ггц? На парафазном сигнале удвоитель из 4 диодов прекрасно работает и цена ему 50 центов вместо десятка баксов за микросхему удвоителя. Вопрос только- если есть желание делать выход 4.4-8.8 через тот же разьем что и более низкие частоты, как комммутацию сделать? Обычные свичи wifi на таких частотах не работают. Диплексор что ли делать?

[UA3ATQ]

А может подумать в сторону DISEQ с управлением по центральной жиле кабеля тоном 22 кГц - стандарт описан, библиотеки есть.

Прикинул как будет выглядеть узел "отбора" управляющего сигнала с кабеля, по которому киловатт бегает... И аж заколдобился. Витая пара всяко дешевле и надежнее будет.

[khach]

Киловатт ВЧ или постоянки а по кабелю только ПЧ идет? Это как говорится две большие разницы. Ведь если синтезатор на антенне, то и усилитель мощноси там же. А киловатт по постянке это всего 55в 20А, нет особых проблем с инжекцией и приемом 22 кГц сигнала. Блоки ОДУ радиорелеек ведь так и устроены- по одному кабелю идут как питание, так и ПЧ вверх и вниз с разносом частот и сигналы управления НЧ модуляцией. Но это к синтезаторам как то мало относится.
Чтобы без оффтопика. Пытаюсь из ADF4351 построить синтезатор с малым шагом - десятки герц. Для этого использую внешнюю петлю ФАПЧ с делителем на ДДС AD9833. На китайских платах как то странно работает система обхода самокалибровки VCO ADF которую делал  по  CN0232 https://www.analog.com/en/design-center/reference-designs/hardware-reference-design/circuits-from-the-lab/cn0232.html
Может это связанно с перемаркировкой микросхем от IDT. Кто-нибудь в курсе, как на них производить автовыбор диапазона с последующим отключением самокалибровки?

[UA3TCF]

по которому киловатт бегает...

Для приема нормально использовать отдельный кабель.

[UA3ATQ]

Ведь если синтезатор на антенне, то и усилитель мощноси там же.

Ну мы же не будем делать отдельный протокол и отдельные изделия для 2 метров (где все кроме поворотки внизу) и микроволновых диапазонов (где вообще все вверху).

Для приема нормально использовать отдельный кабель.

В принципе согласен. Но вот например "резонаторный" МШУ от HB9BBD на 23 см можно запитывать только по кабелю и с жестокими ограничениями по току. Я не уверен, что не попрет мусор, если я ему попробую 22 кГц в "задницу" подавать.

И сейчас у меня зреет "мачтовый" модуль к которому будет подходить единственный кабель - от камер видеонаблюдения (75 ом тонкий коаксиал и две жилы питания 0.75 квадрата, по которым планируется пустить 48 вольт которые уже наверху будут преобразовываться в то, что надо. Наличие постоянки в коаксиале уже "задействуется" для управления передачей. Может тут и можно было бы DISEQ использовать.

Но как быть если на одной мачте 2-3 микроволновых диапазона и отдельные кабеля к каждому? Может сделаем сериальный протокол нормальный под RS485 а уже желающие шлюз из DISEQ в локальную шину этого протокола независимо "родят"? Только в протоколе надо тогда "закладки" сделать, для того чтобы шлюз мог подтвердить прием команды для удаленного устройства и запросить увеличение таймаута. А потом отдельно дослать пакет подтверждения уже от него.

[GM]

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

Ну что ж, буду последовательно защищать предложенный мной протокол от критики.

У меня создаётся впечатление, что обсуждаемый протокол предназначен не для управления отдельными устройствами любительской станции, а по крайней мере, дистанционным управлением из Москвы атомной станцией в Бушере :-). То есть по линии связи гоняются не 24 несчастных байта один-два раза за сеанс, а десятки-сотни мегабайт на скорости 100+ Мбит/с.

Поймите простую вещь: МК, управляющий синтезатором - это маленькая штучка с очень скромными размерами 5х5 мм, восемью выводами, памятью программ 1-2 байта, еепром 128 байт и озу 128 байт.

Ну обновите вы раз в полгода память программ за 10 с или за 20 с, ну кого это волнует? Задача в другом - дистанционно управлять синтезатором или другим устройством, потому что это удобно, потому что не надо лезть на крышу, пусть даже и шеда, снимать питание, открывать крышку синтезатора, переставлять перемычки, и тому подобное...

Фиксированная длина пакета радикально повышает надёжность алгоритма управления и упрощает собственно программу исполнительного МК.

Ну а квитанция отсылается после выполнения команды и хост может видеть результаты своей конкретной деятельности.

[GM]

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

Это хорошо, что вы цитируете модбас, но разрыв пакетов идёт не оттуда. Даже в RS232 есть разрыв - один стоп-байт, а раньше было полтора и два, да. Для того, например, чтобы дать время исполнительному механизму (телетайпу) отпечатать этот байт.

Вы говорите, что не надо делать разрыв, и тут же сами себе противоречите, "я бы вообще оговорил задержку не менее 4-5 байтовых интервалов...". Давайте уж, определитесь.

[GM]

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

Вы говорите "это видимо бред был?" Нет это был не бред, а пример с уартом. Читайте внимательнее. Ну и давайте вести себя покорректнее: критиковать предложенное, а не личность предложившего.

Передача от хоста по уарт может быть легко выполнена звездой, а как быть с приёмом? Например, если синтезаторы находятся в одном корпусе радиостанции - ставим ТТЛ УАРТ, всех делов. А на входе хоста ставим логический мультиплексер.

Зачем нам адрес отправителя и получателя, если в протоколе ясно сказано, "только хост начинает обмен"? Значит, заведомо известно, кто отправляет команды, значит, адрес отправителя не нужен.

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

[GM]

Я бы предложил следующее...
1) Два байта ЗАГОЛОВКА 0x??,0x?? - начало пакета - подобрать удобные для autobaud и чтобы пореже встречались в реальных данных

Ну зачем усложнять простой протокол? Зачем автоопределение скорости, куда его? Чем скорость 115200 бод плоха?

Какие вы предлагаете два стартовых байта в заголовке? Хотя бы посмотрите автокорреляционную функцию 0х07ВВ.

[GM]

2) Один байт АДРЕСА МК 0х01..0xFЕ - уникальный адрес ОТПРАВИТЕЛЯ в системе.
3) Один байт АДРЕСА МК 0х01..0xFF - уникальный адрес ПОЛУЧАТЕЛЯ в системе (0xFF - broadcast, получают все кто знает что с этой командой делать, не подтверждая)

Про адрес отправителя и получателя уже говорил - только хост начинает передачу, адрес отправителя не нужен.

broadcast - передача всем, всем, всем... Ну слушайте, это же не Декрет о мире :-). Какую общую информацию синтезатору и поворотному устройству вы хотите передать? Застрелиться, что ли :-)?

[GM]

4) Один байт КОМАНДЫ 0х01..0x7F - предписание МК, какую исполнить функцию, бит 7 у команды всегда 0, на подтверждении передается код подтверждаемой команды в битах 0-6 и 1 в бите 7 при успехе или 0 при неудаче.

Можно подумать как явно сделать разделение подтверждения и команды, например бит 7 оставить навсегда 0 для команды 1 для подтверждения, а ошибку как то в поле данных унести. Главное чтобы при необходимости вернуть в подтверждении полезные данные с ошибкой не "резалось"

Зачем усложнять/утяжелять протокол? Я допускаю, что здесь есть рациональное зерно, пока не понятно, надо перефразировать.

Ну вот, вроде бы ответил на критику.

Коллеги, не смущайтесь критиковать, всё, что будет сказано - может быть использовано не сейчас, так потом, а то, что не сказано - можно "пролететь", в смысле потом кричать на всех углах, что вот это забыли, это не учли ... и т.д., но будет поздно. Как говорится, too late to drink mineral water when your kidneys are shooted.

[UA3ATQ]

То есть по линии связи гоняются не 24 несчастных байта один-два раза за сеанс, а десятки-сотни мегабайт на скорости 100+ Мбит/с.

Это синтезатору раз за сеанс. А поворотке и доп. датчикам типа магнитометра при слежении за Луной - постоянно.

Поймите простую вещь: МК, управляющий синтезатором - это маленькая штучка с очень скромными размерами 5х5 мм, восемью выводами, памятью программ 1-2 байта, еепром 128 байт и озу 128 байт.

Это для управления синтезатором _может быть_ такой контроллер потянет. А для поворотки с "автономным слежением" как бы не 128к+ флеша понадобилось и 20к+ оперативки.

Фиксированная длина пакета радикально повышает надёжность алгоритма управления и упрощает собственно программу исполнительного МК.

Не вижу серьезного повышения надежности. Халявнее писать протокольный движок - это да.

Даже в RS232 есть разрыв - один стоп-байт, а раньше было полтора и два, да.

Прочтите что написали, и ужаснитесь. Не надо смешивать между собой разные уровни OSI модели.

Вы говорите "это видимо бред был?" Нет это был не бред, а пример с уартом.

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

Зачем нам адрес отправителя и получателя, если в протоколе ясно сказано, "только хост начинает обмен"? Значит, заведомо известно, кто отправляет команды, значит, адрес отправителя не нужен.

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

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

Вы делаете мне смешно (C). Как раз чип драйера RS485 это дешевый расходник. И нахрена класть multidrop шину если за ней вешать некий шлюз, который будет по каким то другим шинам что то куда то форвардить. И как это кореллирует с контроллером с мизером ресурсов?

Ну зачем усложнять простой протокол? Зачем автоопределение скорости, куда его? Чем скорость 115200 бод плоха?

Плоха она всем. Вы _НА ПРАКТИКЕ_ на какие расстояния RS485 в обстановке мощных помех клали? И каким кабелем?
 

Какие вы предлагаете два стартовых байта в заголовке?

Я их еще не предлагаю, я предлагаю посмотреть и сделать их не противоречащими алгоритмам autobaud у тех же stm32 кортексов. Даже если использоваться пока не будет.

Какую общую информацию синтезатору и поворотному устройству вы хотите передать? Застрелиться, что ли :-)?

Аварийный останов перемещения например. "Пульт рухнул, берегите антенну и не воткните ее в кровлю ребром".

Зачем усложнять/утяжелять протокол?

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

[R3KBF Петр]

Почти все (топология сети, протокол, адресация, программная и аппаратная реализация) касаемо RS485 уже нами было сделано и хорошо себя зарекомендовало в ПД-2017 http://rn3kk.blogspot.com/2018/04/remote-antenna-rorator.html, обсуждали здесь http://forum.vhfdx.ru/povorotnye-ustroystva/kontroller-povorotki-cherez-ethernet/msg337088/#msg337088. Поэтому некоторые вещи заново изобретать не надо, именно так мы поступили с протоколом для RS485 - взяли готовый от MikroE и заточили под наши задачи.