Стандартизация протоколов устройств на МК для радиолюбителей [Архив]

NoName

14.06.2012, 20:39

Создается много разных конструкций на МК, в которых содержится определенный функционал. Объединить усилия авторов для работы над ними не всегда получается: инфраструктуры нет, амбиции авторов не позволяют, либо кому-то хочется испытать что-то свое, причин море. В общем есть некая самостийность.
Но есть другая безумная группа людей - у которой возникает безумная идея объединять их под одной крышей с мультиплексорами к LCD и синтезаторам, дабы съэкономить деньги и место, что есть бред.... Вот если бы каждый автор, сразу делал для своей поделки выход на USART или I2C с возможностью внешнего управления (такой небольшой API с доступом через терминальную прогу), то в конечном варианте можно было бы сделать внешний контроллер управления и отображения для нескольких устройств. Получился бы такой небольшой коллективный труд, кто-то делает свою железку, а кто-то их соединяет вместе. Тем более уже есть образцы воплощения данной концепции, надо только стандартизировать протоколы ну и доку создавать каждому на свой протокол... А уж любители объединить тоже найдутся. Если посмотреть сколько версий частотомеров и синтезаторов создано, то глаза разбегаются :)
Вот например:
1. У Сергея (transistor) http://www.cqham.ru/forum/showthread.php?t=209 53&p=655305&viewfull=1#post65530 5 в RF-Lab есть модуль частотoмера, который работает либо по USB с внешним миром либо по USART с контроллером управления, индикатора нет, только вывод данных на комп. Правда он свою разработку не публиковал, но я например давно мечтал иметь мощемер и частотомер в одном флаконе. Может опубликует....
2. NWT тоже пример устройства с которым можно общаться по USART, правда там родной протокол дибильный.
3. Я думаю и FCL метр найдется с внешним протоколом, ну либо кто нибудь из авторов допишет.

Сергей так же предлагал протокол обмена, далее цитата :)

"Мне давно приглянулся стандартный для всех профессиональных проиборов протокол,
который исторически развивался следующим образом:
HPIB - Hewlett Packard Interface Bus (середина 60-ых!);
GPIB - General Purpouse Instrument Bus ;
IEEE488 -> IEEE488-1/-2
IEEE1174 - вариант интерфейса IEEE488 адаптированный к последовательной RS232-линии (с применением USB-RS232 моста и к USB, естественно);
Примерное описание команд дистанционного управления.
1. Начинаются команды с <*>-для Общих команд или с <:> - для команд, относящихся к конкретному прибору.
2. Заканчиваются - <CR> и/или <LF> и/или <CR> <LF>.
3. Могут быть командные строки из набора команд, разделенных <;> (здесь при ограниченном быстродействии могут возникнуть проблемы).
4. Есть программный механизм управления потоками (flow control) - XON/XOFF.
В общем, можно взять за основу для своего протокола, на мой взгляд.
"
От себя могу добавить, можно добавить пару букв в команду для названия девайса и в путь.:smile:

UR4UDT

14.06.2012, 21:11

Вопросы стандартизации чрезвычайно актуальны.
Как бы не хотелось сделать "более правильно", но зачастую мы становимся заложниками уже того, что "де факто".
Пример тому протокол обмена NWT или CAT в любительской практике. Попытка поменять - наверняка фиаско.
Можно внедрить любой протокол, если он будет поддерживать "звездную" конструкцию. Допустим создается NewWinNWT который имеет массу новых возможностей, легкое дополнение новыми функциями и на первом этапе совместим с существующими конструкциями по базовым функциям (без изменения прошивок контроллера). Новые возможности - новая прошивка МК. И затем легкий переход на более "правильный" протокол.
Я делал такую попытку. Увы, вариант был на VB6 (по доброй памяти) и до конца не доведен, хотя частотомер, LC-мер и еще мелочевка работают.
Оставил эту затею.
Вынашиваю планы и мелкими шагами двигаюсь в сторону использования планшета для измерительных приборов (особенно на крыше).
Все в наших руках!

Хигэ

14.06.2012, 21:41

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

о, придумал как объяснить коротко и на пальцах, это как стандартизировать схемные решения радиолюбителей, во!

redd

14.06.2012, 22:37

Думаю что тут уже давно все изобретено, просто нужно переходить на контроллерные системы под управлением какой нибудь реал тайм ОС, написать стандартный модуль или несколько сразу (telnet, ssh, web морда например), и подключать к новым проектам ....

UR4UDT

14.06.2012, 22:57

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

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

В измерениях примерно то же.

Сначала нужно предложить новый протокол для измерительных приборов или выбрать из существующих и обсудить возможности использования в р/л практике.

redd

14.06.2012, 23:18

Вот например FreeRTOS, avr mega поддерживает, в случае чего можно на более мощный контроллер перекомпилить ....

RA9YTJ

15.06.2012, 04:52

Не стандартность протоколов высокого уровня (а именно об этом идет речь) микроконтроллерных устройств объясняется просто - малым вычислительным ресурсом распространенных чипов (до не давнего времени).
По этому в каждом конкретном случаи придумывается протокол минимизирующий затраты на его обработку. Например: САТ протокол Kenwood требует большего от процессора, чем YEASU, а его популярность объясняется гибкостью и хорошим восприятием человеком, а т.к. AVR PIC последних покалений уже легко справляются с ним, он становится дефакто в самодельных устройствах, да и поддерживается большинством программ.
Современные микроконтроллеры позволяют создавать протоколы уровня командной строки ОС без напряга. Думаю дело времени. Практика показывает, что на первом месте по важности стоят программы запускаемые на компьютере для работы с устройствами. и если они удобные и многофункциональные, то разработчики альтернативных устройств подстраиваются под протокол этих программ. Пример: PowerSDR, сколько синтезов пытаются работать с ней, даже делаются специальные контроллеры, которые "переваривают" посылки в LPT для схематически других синтезов и это не смотря на то, что PowerSDR открыта с исходниками.
Сейчас встает другая проблема, которая ложится поверх сабжевой и думаю сейчас более важная.
Это тип интерфейс подключения устройств. Известно, что СОМ и LPT практически отсутствуют на современных материнках, от них нужно отказываться в устройствах. Нужна замена и она есть - это USB.
Но тут встает проблема, в каком виде устройство должно "выглядеть" с точки зрения ОС и программы. есть 2 варианта: VirtualCOM и HID.
Рассмотрим сначала VirtualCOM, преимущество одно: простота работы с ним из программы и из контроллера (при использовании чипа USB-COM, т.к. UART есть во всех микроконтроллерах), дальше одни недостатки: нет стандартного драйвера, либо надо писать самому драйвер либо, если используется стандартный чип USB-COM, его драйвер, который не всегда обновляется и может иметь проблемы совместимости (сам сталкивался), да и обычно имеет ограничение по скорости. А необходимость установки чипа USB-COM ведет к усложнению устройства.
Рассмотрим HID, недостаток один: немного сложнее в программировании из программы (но это чисто по не знанию, реально там даже удобнее) и необходимость библиотеки HID для микроконтроллера (но они есть для всех USB содержащих чипов контроллеров).
Дальше достоенства: Самый главный - во всех современных ОС есть стандартный, а значит отлаженный и стабильно работающий драйвер. Скорость ограничена только самим USB. Подключается напрямую к микроконтроллеру.
Я за HID.

Леонид Иванович

15.06.2012, 12:17

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

Лично я последние 10 лет использую в своих устройствах протокол WAKE (если заказчик не просит чего-то иного). Работает как точка-точка, так и в сети (с транспортом, например, RS-485). Открытая спецификация, открытые исходники. Есть реализации на asm и C для 8051 и AVR, а также для PC в виде класса на C++, модуля на C или отдельной DLL, кому вообще лень возиться с протоколом. Есть клоны для nix-систем.

MIKHAEL

16.06.2012, 21:45

UB3TAF Андрей, незнаю кто и что мог бы собирать из законченых проэктов.
1. Конешно можно чтото подчеркнуть для себя в выложенном исходнике, причем наказуемо (это всё равно что помыться в бане под камерами центрального TV), от этого Вы вероятно и видите скампилированые *.hex-сы.
2. Для тех кто имет желание собирать, нужно хотя-бы освоить языки причом начиная с bascom C asm и т.д.
3. MK от MICROCHIP и ATMEL совершенно не похожи как с наружи (единого протокола здесь просто невозможно)
4. Да и вобще это глобальная проблема.

Пока формулировал как бы это без ихидства высказать. Прочитал пост Леонида Ивановича и понял, что мне по этому поводу уже сказать нечего, (всё сказано постом выше)

Добавлено через 14 минут(ы):

Хотя вполне возможно выводить линию TX к интерфейсу RS232, много места не надо, а за ним преобразователь логических уровней интерфейса+терминаль льный soft, короче огород.
Можно конешно и I2C.
For whom it is necessary?

khach

17.06.2012, 14:25

Если говорить про измерительную аппаратуру- то стандарт давно существует- SCPI http://en.wikipedia.org/wiki/Standard_Commands_fo r_Programmable_Instr uments Прекрасно реализуется для КОМ порта (в том числе и USB). Команды немного длинноваты, но допускают сокращение. Единственная проблема- больщие массивы данных в реальном времени, но и это обычно реализуется без проблем. Можно подсмотреть примеры реализации в том же "народном "осциллографе Rigol 1052. Немного хуже ситуация когда SCPI реализуется по чистому USB без виртуального КОМ порта- для драйверов протокола USBTMC (USB Test & Measurement) приходится ставить на комп огромную монструозную VISA, которая и триальная к тому же. Но можно найти в сети обрезанные версии VISA (2-3 мегабайта вместо 200-300 полной версии) и с ними прекрасно работать, да еще и сэкономить место, установив поддержку только USB (без GPIB VXI PXI и прочих изврашений для встроенных инструментов).

NoName

17.06.2012, 16:36

Если говорить про измерительную аппаратуру- то стандарт давно существует- SCPI http://en.wikipedia.org/wiki/Standar...le_Instrum ents
Ну вот и подходящий вариант нашелся...
- Если можно ссылочку на реализацию в "народном" осцилографе RIGOL 1052 ?

Кстати еще на вот это через WIKI вышел http://www.ivifoundation.or g/default.aspx, бум изучать....

khach

17.06.2012, 16:59

Ну вот и подходящий вариант нашелся...
- Если можно ссылочку на реализацию в "народном" осцилографе RIGOL 1052 ?

В гугле вбиваете "rigol DS1000E programming guide" и тяние первый попавшийся PDF. Раньше этот файл был доступен на сайте ригола, но теперь требуют регистрацию, что напрягает. К счастью файл разошелся по интернету. Только имейте ввиду- с версии софта 2.02 сменили VID-PID устройства, и если раньше требовался родной драйвер, то теперь оно автоопределяется через NI-VISA.
Кстати, надо иметь ввиду, что реализация SCPI съедает достаточно много места в памяти программ микроконтроллера- парсер длинных команд, подпрограммы печати десятичных чисел, оособенно с плавающей точкой. Ну и стек USB еще. Так что памяти мелких АВРок и ПИКов может и нехватить- для них потребуются более простые двоичные протоколы типа того же протокола от анализатора NWT. Зато под АРМом места во флеши хватает с запасом.
Зато одно из преимуществ SCPI- возможность подключить свой прибор к готовой измерительной системе от фирменного прибора. Например мы так цепляли самодельный генератор к софту от родешварцевского анализатора. Анализатор был без следящего генератора, зато софтна компе позволял мерять АЧХ, используя отдельный генератор от R&S в качестве источника сигнала . Достаточно было сэмулировать 3-4 команды SCPI и все начало работать с 50 баксовой самоделкой вместо 5000баксового фирменного прибора.

NoName

17.06.2012, 17:38

Но можно найти в сети обрезанные версии VISA (2-3 мегабайта вместо 200-300 полной версии)
А можно еще про это ссылочку..., а то на VISA знаете скоко ссылок в гугле будет :)

Леонид Иванович

17.06.2012, 19:21

Кстати, надо иметь ввиду, что реализация SCPI съедает достаточно много места в памяти программ микроконтроллера- парсер длинных команд, подпрограммы печати десятичных чисел

Вот в этом и трудность. Этот протокол не для любительских конструкций с маленькими процессорами. Совершенно невозможно представить, что сейчас все радиолюбители бросятся внедрять SCPI :)

Зато одно из преимуществ SCPI- возможность подключить свой прибор к готовой измерительной системе от фирменного прибора.

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

khach

17.06.2012, 19:41

А можно еще про это ссылочку..., а то на VISA знаете скоко ссылок в гугле будет :)
ftp://ftp.ni.com/support/softlib/visa/VISA Run-Time Engine/
И выбирать что то из версий 4.1-4.5. Обычно там достаточно функционала. При установке спросят про поддерживаемые модули- выбирать USB (для работы с Rigol). Одну из версий NI-VISA run time ригол поставляет вместе с софтом для скопа (там вообще все обрезано по самые помидоры, наверно перепахан инсталляционный пакет самими китайцами)- надо внимательно смотреть, чтобы не грызлись версии между собой. Хотя если хочется отлаживать работу приборов в ручном режиме и подсматривать протоколы работы чужих программ (использовать NI SPY) то придется разорится на траффик и качать полную версию пакета - там же в соседней директории ftp://ftp.ni.com/support/softlib/visa/NI-VISA/ при этом надо внимательно смотреть, какие версии имеют триальность 30 дней, а какие-нет. Так что не гонитесь за самыми новыми версиями.
Ps. наверно был неправ, предлагая смотреть программер гайд от риголовского скопа- намного информативнее и более продходит для радиоизмерительной аппаратуры "Programming Guide DSA1000 Series Spectrum Analyzer " (http://www.google.com/url?sa=t&rct=j&q=dsa1000 rigol programmer manual&source=web&cd=1&ved=0CGEQFjAA&url=http%3A%2F%2Fwww .ame-engineering.de%2Fpdf %2Fproducts%2Frigol% 2Fdsa1000_programmin g.pdf&ei=sgneT8SzK8re4QTW0 MDbCg&usg=AFQjCNFa7lHNn9n8 fSU1teMsv2zhamyIaQ&cad=rja)

Леонид Иванович

17.06.2012, 20:13

NoName

17.06.2012, 21:04

Мануал почитал. Минус: затраты на реализацию этого протокола куда больше, чем простого двоичного протокола. Плюс: совместимость с готовыми системами (но будет ли она хоть раз востребована?).
С моей точки зрения есть еще один плюс - ASCI код команд, поэтому отлаживать проще, т.к. подходит любая терминалка и команды просто бьются текстом. А раз проще отлаживать, значит быстрее разработка. Я ни чего не имею против WAKE, но он бинарный. А существующие мощности МК позволяют меньше думать о ресурсах, т.к. протокол по сути избыточный.

UR4UDT

17.06.2012, 22:29

Может не стоит сильно заморачиваться ?
Физический уровень: USB. Сначала композитное устройство для классов CDC и HID.
CDC для совместимости по железу с тем, что уже спаяно. Перегрузил софт в МК и дополнительные функции получи. Тот же NWT по свободным выводам контроллера имеет большие и интересные резервы.
HID для подключения к планшетам (драйверов для CDC там не будет никогда) и непринужденное использование с не-Wind-ОС.
Протокол повыше конечно же ASCII. Очевидно при отладке, удобно при написании софта, не сильно напрягает с объемом программы в МК.
Структура строки напрашивается следующая (широко распространена):
- адрес получателя/отправителя (важно при расширении системы, например по I2C);
- R/W;
- код команды;
- данные.
Для любительских целей этого будет достаточно еще на долго.

NoName

17.06.2012, 22:44

Протокол повыше конечно же ASCII. Очевидно при отладке, удобно при написании софта, не сильно напрягает с объемом программы в МК.
Структура строки напрашивается следующая (широко распространена):
- адрес получателя/отправителя (важно при расширении системы, например по I2C);
- R/W;
- код команды;
- данные.
Для любительских целей этого будет достаточно еще на долго.
Ну так SCPI так и делает и для USB есть тоже стандарт.

Леонид Иванович

17.06.2012, 22:45

Да, про простоту отладки для ASCII протоколов говорят часто. На caxapa.ru недавно на эту тема битва была. Кто победил - не очевидно. Лично я всегда использую двоичные протоколы, не только WAKE, еще и MODBUS RTU. Для двоичных протоколов достаточно иметь тестер протокола (WakeUp для WAKE, ModbusPoll для MODBUS RTU и т.д.). Он позволяет вводить и считывать данные, а в каком виде они в линии передачи бегают - совсем не важно. Плюс двоичных протоколов - меньшая избыточность. Но если кроме терминала ничего больше нет - тогда да.

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

Transistor

17.06.2012, 23:10

Полностью соглашаясь с Адреем UB3TAF по целям и задачам темы, хотел бы добавить свое видение.
Итерфейс IEEE488, как наследник GPIB, применяется в измерительных приборах с 60-ых годов и стал промышленным стандартом, де-факто. Грех не воспользоваться наработками мировой приборостроительной мысли.
Предлагаемый ув.khach SCPI является надстройкой более высокого уровня над IEEE488.2 и реализуется редко даже в профессиональных приборах нижней ценовой группы из-за сложности реализации лексического интерпретатора. Собственно это обстоятельство и подчеркивают многие участники дискуссии. С др. стороны, взять более простой IEEE488.2 в чистом виде нельзя, т.к. он рассчитан на аппаратный интерфейс GPIB - параллельный по сути, к тому же имеющий набор аппаратных линий-команд не возможных применительно к UART/COM - порту.
Существует вариант IEEE488.2 адаптированный под возможности последовательного COM-порта - это IEEE1174. Но полной версии его я не нашел. Краткий обзор можно посмотреть во вложении.
Собственно предлагаемые страндарты регламентируют набор общих команд и правил организации обмена. Разработка команд для каждого конкретного прибора отдается на откуп разработчику. Поэтому смысл настоящего обсуждения я вижу как раз в совместной выработке более простого по сравнению с SCPI универсального открытого набора команд для разработок "измерительной" направленности - генераторы, частотомеры, мощемеры(ВЧ-вольтметры), и ориентированного на USART, что автоматически делает Целевое Устройство не чувствительным к управляющей среде - контролер это или ПК (для USB необходим USB-COM мост, типа популярных FT232).
Что это дает?
Это позволит нарабатывать совместными усилиями парк оборудования, совместимого с набором различного компьютерного софта. Функции панорамного измерителя АЧХ или КСВ можно реализовать на стороне компьютерного софта, применяя различные генераторы и детекторы в зависимости от задачи и диапазона.

UR4UDT

17.06.2012, 23:35

Полность согласен.
О деталях нужно договариваться.

Transistor

17.06.2012, 23:39

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

Леонид Иванович

17.06.2012, 23:50

ориентированного на USART, что автоматически делает Целевое Устройство не чувствительным к управляющей среде - контролер это или ПК (для USB необходим USB-COM мост, типа популярных FT232)

Я тоже к этому пришел. Оказалось, что работать с мостами USB-COM через виртуальный COM-порт гораздо универсальней, чем напрямую.

Это позволит нарабатывать совместными усилиями парк оборудования, совместимого с набором различного компьютерного софта.

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

Создание универсального интерфейса-протокола как раз и призвано объединить усилия специалистов в разных областях и нарастить уровень сложности и качества "любительских" проектов.

Скептически отношусь к возможностям радиолюбителей работать в команде.

UR4UDT

17.06.2012, 23:51

Немцы публикуют и протоколы обмена и исходники. А нас что-то жаба душит.

Леонид Иванович

18.06.2012, 00:02

vadim_d

18.06.2012, 09:42

У нас не принято публиковать исходники. Но никто не может сказать, почему. Я вижу только одну причину: если я опубликовал какую-то конструкцию с исходниками, то кто угодно может внести изменения, и прошивка с глюками разойдется по миру. Зачем мне это надо?
Еще одна причина была озвучена :smile: :

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

UR4UDT

18.06.2012, 11:51

(это всё равно что помыться в бане под камерами центрального TV)
Не обольщайтесь и в баню ходят с мобильниками и на нудистские пляжи.

В теме просматривается неопределенность с физическим уровнем реализации протоколов. Я уже здесь излагал свое мнение, но видимо нужно убедительнее сказать про использование USB. Мосты COM-USB это порочная практика. Только, как выход из положения. В новых разработках устройств на контроллерах этого нужно избегать. Если использовать готовый софт под СОМ-порт, то всегда можно эмулировать CDC. В контроллере полтора ассемблерных килослова на энумерацию и пять-семь строк цикла на каждый обмен. Ни какой головной боли и масса преимуществ.
Наверное есть смысл обсудить это в отдельной теме и продуктивнее (уверен) станет разговор здесь.
Готов поделиться исходниками со всеми желающими.

Леонид Иванович

18.06.2012, 12:23

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

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

В теме просматривается неопределенность с физическим уровнем реализации протоколов

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

Мосты COM-USB это порочная практика

В измерительных устройствах должна быть гальваническая развязка с компьютером. Развязать сам USB - проблема. А вот развязать пару TTL-сигналов между мостом и процессором - очень просто. Поэтому мосты - лучшее решение, хоть и немного более дорогое.

UR4UDT

18.06.2012, 13:01

В измерительных устройствах должна быть гальваническая развязка с компьютером. Развязать сам USB - проблема. А вот развязать пару TTL-сигналов между мостом и процессором - очень просто. Поэтому мосты - лучшее решение, хоть и немного более дорогое.
ADuM3160 - гальваническая развязка USB. Это если очень уж нужно.
Сразу не вспомню тип ИМС, но можно развязаться и дальше по I2C.
Не уверен, что PC817 развяжет на скорости 56К. Вернее уверен, что не успеет. А про выше и не говорим.
Скурпулезно считал денежку для реализации одной хлебной темы. Трудно будет меня переубедить.

Добавлено через 12 минут(ы):

Физический уровень может быть любым. Логический протокол накладывает очень слабые ограничения на физический уровень.
Ну уж не скажите.
Все эти
, [;], [:], [#], [ESC] как раз и есть головная боль от RS232, 485 и т.д. Да и LPT не исключение.
В USB каждая транзакция исключает небходимость применения кривых разделителей. Иначе бывает очень редко.

Леонид Иванович

18.06.2012, 13:40

ADuM3160 - гальваническая развязка USB. Это если очень уж нужно.

Можно, как вариант. А развязка для измерительных приборов всегда нужна. Что касается оптронов, 4N35 тянет 115 кбод, но с трудом (приходится подбирать номиналы), 6N136 тянет легко. Ну или относительно дешевый ADuM1201. Есть еще от TI микросхемы емкостной развязки ISO7420 и другие, но я пока не пробовал.

Сразу не вспомню тип ИМС, но можно развязаться и дальше по I2C

Развязка для I2C существует. Но при чем тут I2C? В приборе может и не быть этой шины, а если и есть, то подключает лишь некоторые узлы.

Скурпулезно считал денежку для реализации одной хлебной темы. Трудно будет меня переубедить.

Вы совсем про другое. Там - да. Когда речь о коммерции, каждая копейка на счету. А мосты USB-UART очень дорогие. Но радиолюбительство имеет противоположные цели - не зарабатывать деньги, а тратить их.

Все эти
, [;], [:], [#], [ESC] как раз и есть головная боль от RS232, 485 и т.д. Да и LPT не исключение.
В USB каждая транзакция исключает небходимость применения кривых разделителей. Иначе бывает очень редко.

Привязываться к USB по-моему неправильно. Универсальнее привязываться к COM-порту. Тогда можно работать хоть через USB (для офисных применений), хоть через PCI-плату с RS-485 (для промышленных применений), хоть через настоящий RS-232, хоть по беспроводной сети через виртуальный COM. USB - это точка-точка. А если ориентироваться на COM, можно перейти к RS-485 и собрать сеть из измерительных приборов. И контроллер в качестве мастера гораздо проще подключается. Я свой WAKE применял и для радиоканала 433 МГц, и для проводных модемов V.23. Мы же здесь про универсальность, зачем зажимать себя в рамки USB?

UR4UDT

18.06.2012, 14:14

Со многим можно согласиться. Но жизнь диктует другое.
LPT канул в лета. Большая уже редкость.
COM в ноутбуках нет уже годиков 8-10.
Совершенно нет уверенности, что в очередной версии ОС останется поддержка СОМ.
В мобильных устройствах (ОС Андроид) о СОМ ни под каким соусом речь не идет вообще. А лет через пять планшетов и др.мобильных устройств будет, как грязи и ям на наших дорогах.
Конечно можно оставить для себя антикварный РС и наслаждаться прелестями LPT и COM.
Это уж дело личное.

ut1wpr

18.06.2012, 15:00

UR4UDT

18.06.2012, 16:16

Господа, ну что вы так к USB прицепились. Это же ТРАНСПОРТ. Стандартизация протокола должна быть в другом слое, этажом выше. Я не поддерживаю идею унификации вообще, но при чем тут USB? А сколько ему осталось жить, этому самому USB? Вы что, не видите его недостатков, как транспорта? А что будет с разработанным вами стандартом, появись совершенно иной транспортный слой? А он таки появится, ой чувствую... :)

Если вести речь о связи комьютеров, то все решено и развивается.
Если связь РС-МК, то ТРАНСПОРТ - архиважный момент.
Не нужно забывать, что обсуждается р/любительская тематика. Круг задач очерчивается измерениями (заявлено темой). Ресурсы МК ограничены.

О долголетии USB можно поговорить.
Одобрено USB-3. Началось производство чипов ведущими производителями. Разъемы под тему продают уже год. Устройства с питанием от шины - только USB. А эти устройства еще долго будут жить. Клавиатура и мышь это, как трусы и майка - сложно с альтернативой. Безпроводные варианты слабо приживаются. Зарядка моб.телефонов, фотоаппараты, внешние винчестеры. Индустрия серьезно заточена на USB. Если и попытаться предложить другое, то наверное не успеете до конца изложить свою идею.

Собственно и тема открыта, что бы обменяться мнениями. Кто сам пытается писать для МК что-то в области измерений сталкивается с поднятыми проблемами.

ut1wpr

18.06.2012, 17:33

To UR4UDT
Что-то ваш пост выглядит, как не терпящий пререканий. :) Так и только так!
Ведь я не порочу USB. И никто не спорит, что его будут и улучшать и развивать.
Но там, где замешана коммерция, трудно ожидать резких перемен. Попробуйте сейчас предложить альтернативу ДВС. А куда девать нефть?!
Так и с "заточкой индустрии на USB".
Излагать идеи не буду, их нет у меня.. :) Я про тех, кто думает и смотрит вперед.

Леонид Иванович

18.06.2012, 17:56

LPT канул в лета. Большая уже редкость. COM в ноутбуках нет уже годиков 8-10.

Так я не про аппаратный COM, а про виртуальные. Умирать они не думают. Всякие Блутузы имеют стек COM-порта, другие беспроводные адаптеры, куча серьезного промышленного оборудования работает по RS-485, которые в системе видны как COM. Ведь USB для промышленных условий не годится по причине низкой помехоустойчивости и малой длины линий. Про это в сети полно информации, да и сам лично столкнулся, когда пытался перевести на USB оборудование, работающее в цехах "Интеграла". USB - это настольный интерфейс. Где нужно что-то быстрее COM-а и RS-485, там Ethernet с питанием PoE.

Если связь РС-МК, то ТРАНСПОРТ - архиважный момент.

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

Хигэ

18.06.2012, 18:08

Совершенно нет уверенности, что в очередной версии ОС останется поддержка СОМ.
Совершенно нет уверенности, что очередная версия ОС появится на свет :-P
а в юниксподобных системах tty устройства ни куда не денутся

UR4UDT

18.06.2012, 19:07

Что-то ваш пост выглядит, как не терпящий пререканий. :) Так и только так!
.
Виктор, спасибо за комплемент.
Я совсем не причисляю себя к фанатам USB.
Так просто высказал свое видение.
В промышленных системах, если заказчик не настаивает, отдаю предпочтение CAN. Хорошая аппаратная поддержка (в PIC во всяком случае) и еще масса преимуществ. Каждый волен использовать, что ему нравится или за что платят.

Transistor

18.06.2012, 19:42

Добрый всем вечер!
Перечитал я ТО на недавно-купленный СА HMS3000 и обнаружил следующее. В меню можно выбрать три Интерфейса: USB, причем подчеркивается, что можно работать как с VCM, так и с чистым USB, Ethernet и GPIB (он же IEEE488-2). Но при этом
во всех случаях протоколом более высокого уровня остается SCPI ! Не вижу смысла ломать копья. Ни USB, ни WAKE не снимают проблему/вопрос разработки собственно команд для управления Измерительными модулями. Давайте совместно искать объединяющие моменты. По моему глубокому убеждению мир усложняется так, что найти единственное решение оптимальное со всех сторон и на все случаи жизни невозможно. А смысл стандартизации - сэкономить силы и время множества разработчиков, решающих одинаковые или схожие задачи. Где бы мы все были без стандартизации и унификации вообще? Поэтому согласен с ЛИ - без привязки к конкретным особенностям Интерфейса физического уровня протокол получается универсальнее и гибче.
Представляю на рассмотрение вариант Протокола командного уровня. Делал в спешке, прошу рассматривать как черновой - главным образом для иллюстрации Идеи - хотелось успеть пока тема горячая:smile:. В основе лежат SCPI команды генератора HAMEG HM8135 (стр.37 и далее по Мануалу).

Мануал на HM8135 слишком большой - не прицепился...

Спасибо Андрею UB3TAF за продуктивную идею использовать префикс из двух символов в качестве адресуемого устройства! До этого бился в пределах трех-символьных команд - ничего толкового не получалось; теряется одно из главных преимуществ ASCII - команд - наглядность.
Кстати похожее решение используется в протоколе NMEA-0183, он же IEC61162-1 - по этому протоколу передает данные большинство, если не все GPS-ы. А еще он является базовым для морских судов; физический уровень - RS422/RS485.

NoName

18.06.2012, 20:09

Делал в спешке, прошу рассматривать как черновой - главным образом для иллюстрации Идеи - хотелось успеть пока тема горячая.
Фигасе скорость... все бы так спешили... :) Я в общем тоже за SCPI, ну сложно сделать парсер, но сейчас контроллеры позволяют.
Тоже при беглом просмотре ПРИМЕРА...
1. Для генератора надо еще делать переключение на несколько выходов, можно и синтезаторов (хотя не важно и соответственно команады либо для каждого выхода либо для активного).
2. Свипирование надо делать как у нормального прибора. Центральная частота, шаг и количество точек. А то когда надо сдвинуть окно, две цифры приходится вбивать.
3. Ну и если делать, то делать полностью по стандарту:
- соотв. устройство это первый уровень иерархии
- после команды параметры через пробел и через запятую
тогда установка частоты :GR:FRQ ХХХХХХ и к разрядности параметра нельзя привязываться, а то в гигагерцы я уже один раз уперся. Вдруг кто захочет доли герца делать.

Есть еще вариант..., там ведь сокращения команд возможны, а запись идет в полном виде в разных регистрах для наглядности и тогда вот так:
:GENerator:FREQency XXXXXX

Ссылка на полную версию протокола (http://www.ivifoundation.or g/docs/scpi-99.pdf)

NoName

18.06.2012, 21:50

Читал про NI-VISA это вроде как только драйвера....
На сайте TI доступна только RunTime Engine для LabView (запуск готовых приложений LabView), а какая нибудь старая версия LabView есть в доступе? А то получается зачем биться за SCPI, смотреть все равно нечем кроме как LabView, а он платный... На форумах встречал что для Linux есть бесплатная старая версия 6.0.
Я так понимаю что еще можно смотреть софтом от какого нибудь прибора, но ведь хочется легальный способ получить...
Где я неправ? Или как-то еще можно смотреть результ?

Transistor

18.06.2012, 23:11

В основе лежат SCPI команды генератора HAMEG
Андрей, эта моя фраза очевидно вводит в заблуждение. На самом деле я против реализации SCPI из-за его громоздкости и сложности реализации на МК. Правильнее былобы сказать так: в основе Протокола лежат команды SCPI, редуцированные до
IEEE488-1 (фиксированная длина в три символа), но расширенные префиксом адресуемого устройства, что дает возможность МК целевого устройства работать с несколькими измерительными модулями. Это явно компромисный вариант, не отвечающий строго ни громоздкому SCPI, ни IEEE488-1, имеющему альтернативные средства достучаться до отдельных приборов, недоступные на уровне виртуального COM-порта.
Главная отличительная черта - команды двух типов:
- общие; начинаются с <*>, длина фиксированная - три символа;
- относящиеся к конкретному типу изм. модуля - начинаются с <:>, длина фиксированная - пять символов, структура фиксированная - два символа адресуемый модуль, три - команда;
- дальше параметры команды, как в IEEE488-1.
Это все по моему разумению должно сохранить и приемлемую сложностьт реализации на МК с ограниченными ресурсами, и наглядность команд.

Касательно LabView - мы на работе занимались немного, но все упирается в ломаный софт; открытого не нашли.
На мой взгляд, для наших измерительных задач особых наворотов математических не потребуется. Можно будет
обойтись и без LabView.

Добавлено через 16 минут(ы):

1. Для генератора надо еще делать переключение на несколько выходов, можно и синтезаторов (хотя не важно и соответственно команады либо для каждого выхода либо для активного).
2. Свипирование надо делать как у нормального прибора. Центральная частота, шаг и количество точек. А то когда надо сдвинуть окно, две цифры приходится вбивать.
3. Ну и если делать, то делать полностью по стандарту:
- соотв. устройство это первый уровень иерархии
- после команды параметры через пробел и через запятую
тогда установка частоты :GR:FRQ ХХХХХХ и к разрядности параметра нельзя привязываться, а то в гигагерцы я уже один раз уперся. Вдруг кто захочет доли герца делать.
1. Смутно понял, что имеется в виду. Например, есть в составе изм. комплекса два генератора - один ad9954, другой - adf4350; тогда надо активировать один из них и управлять им - так?
2. Так мне и самому больше нравиться, когда диапазон свипа задан через начало, шаг и количество точек. Команды допускают оба варианта, второй - дань WinNWT. Убрать команду - не вопрос.
3. На этот вопрос я частично ответил выше. Относительно разрядности параметра - какие будут предложения. Я вижу вариант с использованием
символов <K>-kHz и <M>-MHz, одновременно выполняющих роль десятичной запятой. Пойдет, или есть что получше?

Хигэ

18.06.2012, 23:25

как-то еще можно смотреть результ?
если выхлоп устройства текстовый, то отрисовать нет проблем
мне для отрисовывания треков gps (только треки, без карты) хватает grep для выбора нужных строк и gnuplot для отрисовки
просмотр вебмордой
не совсем реалтайм, но при скорости обновления раз в две секунды вполне нормально
и что самое приятное совсем бесплатно, огромное количество мануалов в сети
основное что может смущать виндовс пользователя, это отсутствие единой программы обработки, всё "размазано" по системе
если нужна реакция на события, можно посмотреть в сторону "питона"

Леонид Иванович

19.06.2012, 01:46

Ни USB, ни WAKE не снимают проблему/вопрос разработки собственно команд для управления Измерительными модулями

Удивлен Вашей продуктивности! Но разрабатывать систему команд управления измерительным модулем заранее и не нужно, ибо это абсурд. Если, конечно, не хотим топтаться на одном месте. На начальном этапе даже в голову не придет то, что потом будет реализовано в модуле. Я вот как раз сейчас проектирую ВЧ-генратор, так Ваш список команд не покрывает даже половины возможностей. Протокол и система команд - разные вещи. Стандартизировать нужно протокол: как передается код команды, как - параметры. А сами команды рождаются вместе с устройствами, только телепаты могут предсказать их заранее.

Как пример, присоединил заголовочный файл для DLL, которую предлагаю в комплекте со своим прибором. Пользователю вообще не нужно думать, что там за протокол. Функции DLL можно вызывать из программы на любом языке, да хоть из LabView.

NoName

19.06.2012, 06:28

1. Смутно понял, что имеется в виду. Например, есть в составе изм. комплекса два генератора - один ad9954, другой - adf4350; тогда надо активировать один из них и управлять им - так?
Да.

Так мне и самому больше нравиться, когда диапазон свипа задан через начало, шаг и количество точек.
Я говорил "Центральная частота, шаг и количество точек"

Я вижу вариант с использованием
символов <K>-kHz и <M>-MHz
Просто герцы без ограничения разрядности.

Transistor

19.06.2012, 12:38

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

Я вот как раз сейчас проектирую ВЧ-генратор, так Ваш список команд не покрывает даже половины возможностей.
Еще раз посмотрел стартовый топик темы про ВЧ-генератор, предложенный набор команд не позволяет выбрать только форму модулирующего сигнала. Остальное вреде как все можно выполнить. С другой стороны - никто ведь не запрещает развивать и дополнять набор команд. Я и не утверждал, что это законченный перечень, наоборот - подчеркивал, что это только начало.

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

Леонид Иванович

19.06.2012, 13:39

А почему заранее? Два опытных образца готовы и находятся на стадии отработки и шлифовки метрологических параметров.

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

P.S. Посмотрел на фото передней панели Вашего прибора. Есть несколько предложений:
- раз используется англоязычный интерфейс, то в качестве децимального разделителя логичнее использовать точку
- буква "мю" смотрится не очень хорошо, можно не делать левый хвостик наклонным, будет лучше
- букву "омега" зря Вы сделали высотой 8 точек, лучше сделать 7, подняв нижнюю часть и чуть сжав овал
- нет единства стиля, размерность во второй строке почему-то отбита пробелом от числа

Vitas56

19.06.2012, 18:28

читая эту ветку чтото совсем затупил.
Зачем изобретать велосипед? Все протоколы для связи с внешними устройствами уже стандартизированы. Используйте самый универсальный на сегодняшний день - USB и все вопросы закончатся. Большинство современных микроконтроллеров имеют в своем составе аппаратный USB. Всякие мосты типа USB-COM это динозавры вчерашнего дня. Зачем в новых разработках использовать устаревшие технические решения? Иначе обсуждение данной темы будет бесконечным и пустым.

Transistor

19.06.2012, 18:42

to Vitas56
USB, COM - это только часть вопроса - среда для передачи неких команд.
Командный уровень дистанционного управления прибором или даже измерительным комплексом - цель данной ветки.

Vitas56

19.06.2012, 19:05

Командный уровень дистанционного управления прибором или даже измерительным комплексом - цель данной ветки.
Командный уровень не может быть абсолютно универсальным для разного типа приборов - только для ограниченного числа однотипных конструкций например трансиверов. Да подобная универсальность и не нужна иначе она бы уже реализована. Зачем нужен протокол обмена холодильника со стиральной машиной?

Леонид Иванович

19.06.2012, 19:08

Зачем изобретать велосипед?

Вы делали хоть раз устройства, имеющие связь с компьютером? А то как-то непонятны Ваши вопросы...

Transistor

19.06.2012, 19:33

Просто герцы без ограничения разрядности.
предлагаю ввести <H> в качестве десятичной точки, а заодно она должна исключить разночтение с единицами измерения частоты. Количество разрядов при этом может быть любым как до запятой (Н), так и после нее.
Вопрос: распространить этот подход на все случаи где встречается частота или оставить фиксированный формат
для частот модуляции и девиации частоты ЧМ?

Я говорил "Центральная частота, шаг и количество точек"
- да, не досмотрел. С центральной частотой выглядит логичнее. Тогда выбрасываем команды GRSMA, GRSMI , а вместо них вводим GRSWF. Весь набор команд для управления свипом выглядит так:
GRSWF - центральная частота
GRSWS - шаг перестройки частоты
GRSWN - количество точек свипирования
GRSWT - задержка между переключениями частоты.

******************** *
Для выбора активного Генератора :
GRCHNab - Generator Channel Number, a-номер канала, b=0 - Off, b=1 - On, b=? - запрос текущего состояния.
Таким образом можно включить-выключить любой доступный Контроллеру Генератор (канал).

Добавлено через 7 минут(ы):

P.S. Посмотрел на фото передней панели Вашего прибора. Есть несколько предложений:
- букву мю мы уже исправили, фото несколько устарело. За остальные замечания спасибо, учтем!
Интересно было бы взглянуть на описание команд какого-нибудь Генератора, а то smc-5000 несколько далековат от темы.

Vitas56

19.06.2012, 19:48

Сама тема данного форума создает некую неопределенность, не совсем понятно что нужно стандартизировать и для чего. Так ведь можно и написанием "Гост" ов заняться. Ведь микроконтроллеры как и компьютеры имеют стандартные протоколы для связи с внешним миром. Если устройство(и программа) предназначено для работы в Windows оно не может работать в другой программной среде пусть даже протоколы и интерфейсы связи у них однотипные. Нужна другая версия программы? Или я что-то неправильно понимаю?

Леонид Иванович

19.06.2012, 20:51

Интересно было бы взглянуть на описание команд какого-нибудь Генератора

Для ВЧ-генератора я еще систему команд не составлял. Есть для двухканального НЧ-генератора:

UR4UDT

19.06.2012, 22:08

Не высказывая мнение про уже активно обсуждаемый протокол (систему команд), хочется узнать: что делать с ним после завершения дебатов и принятия мудрого решения?
Видимо, вопрос к Андрею (UB3TAF ).
Если уже пишется достойный софт (альтернатива WinNWT) и задержка за оптимальным протоколом это одно, а если нет – другое.
В пылу обсуждения деталей, мне кажется, упустили главное: не очерчен круг задач для решения. Нет концепции построения системы: «мост будем строить вдоль или поперёк реки?».
Если это сделать (обычно с этого и начинают), затем взять двух-трехкратный запас на последующие фантазии и потом выбрать из готового или изобретать свой протокол. Увы, этого нет. Потому вылили много воды попусту.
Просто гонять через порты панацею от всех проблем нет никакого смысла. Да и не приживется.
Жаль, если усилия будут направлены в мусорную корзину.
Может ещё подумаем ?

Vitas56

19.06.2012, 22:18

Вы делали хоть раз устройства, имеющие связь с компьютером? А то как-то непонятны Ваши вопросы...
Генератор ВЧ

114030

Его основные параметры:
Диапазон частот 1-180 мГц
Выходная мощность 100 мкВт
Ослабление аттенюатора -10 -127 дБ
Модуляция НГ АМ ЧМ ИМ (1кГц)
Шаг перестройки генератора 100Гц
Шаг ослабления аттенюатора 1дБ
Уровень гармоник -55дБ в диапазоне частот до180мГц
-70дБ в диапазоне до 80мГц
Lpt интерфейс для связи с ПК
Синтезатор на AD9951
Контроллер ATMEGA8
Аттенюатор на AT260
Изготовлен для измерения чувствительности радиостанций и трансиверов в рабочем диапазоне частот до уровня 0.1мкВ. Измерения избирательности приемников. Настройки ДПФ и кварцевых фильтров с помощью программы http://www.radioamatoriteam sviluppo.it/index.htm
С помощью внешнего направленного ответвителя - измерение SWR
Логарифмический детектор на AD8307. Необходимость в подобном приборе возникла из за того что я не смог купить за разумные деньги генератор для измерения чувствительности р.ст т.к все
они были "свистуны"

Леонид Иванович

20.06.2012, 10:04

В пылу обсуждения деталей, мне кажется, упустили главное: не очерчен круг задач для решения. Нет концепции построения системы: «мост будем строить вдоль или поперёк реки?»

Я сразу говорил, что тема пустая. Хотя небольшая польза, конечно, есть, хоть перечислены некоторые возможные протоколы. Никакой стандартизации никто следовать не будет, кто является разработчиком, тот и выбирает протокол. Я тоже планирую сделать к своему ВЧ-генератору софт по типу NWT, но какая сила может меня заставить использовать какой-то незнакомый протокол?

Генератор ВЧ

Супер! Я только мечтаю получить подобные параметры! Только нижнюю границу диапазона хочу получить от звуковых частот, 1 МГц - слишком много. Уже год продумываю конструкцию, но не хватает квалификации. И что, аттенюатор действительно обеспечивает ослабление -127 дБ на 180 МГц? Я тоже как-то применял каскадированные AT-260, но пролезание было очень сильным. Схема и конструкция Вашего генератора - секрет?

Настройки ДПФ и кварцевых фильтров с помощью программы

Раз Вы используете готовую программу, значит брали чужой протокол. Мы здесь обсуждаем протоколы собственные.

MIKHAEL

20.06.2012, 13:21

А за полоской, компания Джун-Липу с неперпением ждет нового совместимого протокола и исходников. Госпада поработайте на Джун-Липу&лузер. А всё дело случая, выписывает человек с китайского аукциона прибор. А это проэкт RU3GA первая версия, 311,4066,F84 вылаженая в полном комплекте, включая регулировку. Причом ни чего не меняя кроме заперев MК и поменяв буковки. Даже Украв наглым образом, они защитили себя от повторений. Конешно впечетляет конструктив на пром уровне.
А теперь посчитайте незнаю как у Вас.
1602-2$
F84-1$
4066-0.1$
311-0.15$ 3.25$ включая растормошку, транспортные, навар челноку(продовцу). Всё соответственно с того-же Китая.
Значит там это стоит ещё дешевли. Пасивную базу в расчёт можно не брать там она кинолентами запад посторался
в погоне за дешовым трудом.
А приборчик обошолся в 40$,это какой множетель??? всего две платы, даже без корпуса (правда почта бесплатная).
Давайте накормим голодающий китай с полна, выпустим и раскроем всё для человеко-роботов.
А как-же авторские права, девиденты от продукции.
На мой взгляд. Более как прошивки в 16к нечего не стоит выкладывать, пусть Джун-Липу поменяет буковки пекампилируют почешут репы приоткроют глазоньки пошире.
Заинтересующийся толковый человек сам выдет на Вас и попросит всё что ему будет необходимо.
Да ещё есть такая тема кусочники soft, плагиат, здесь её приоткрыли только слегка.

UR4UDT

20.06.2012, 13:39

... Никакой стандартизации никто следовать не будет, кто является разработчиком, тот и выбирает протокол. Я тоже планирую сделать к своему ВЧ-генератору софт по типу NWT, но какая сила может меня заставить использовать какой-то незнакомый протокол?
Я не фаталист, но видимо, нужно согласиться. Если судить по количеству участников обсуждения темы и накалу реплик, то вспоминается одно высказывание: "Мы все за колхоз, но не в нашей деревне!".

Леонид Иванович

20.06.2012, 23:45

Даже Украв наглым образом

Бесплатное нельзя украсть. Чем больше людей повторит мои проекты - тем я больше буду рад. Ну а если китайцы запустят в производство - буду просто горд и счастлив.

Я не фаталист, но видимо, нужно согласиться

Я за то, чтобы все применяли разные протоколы, пусть протоколов будет больше, всяких и разных. Но пусть радиолюбители хорошо документируют свои самодельные протоколы. Кому надо, тот напишет совместимый софт. Но в большинстве случаев этого не надо.

NoName

21.06.2012, 07:12

Бесплатное нельзя украсть. Чем больше людей повторит мои проекты - тем я больше буду рад. Ну а если китайцы запустят в производство - буду просто горд и счастлив.
А я вот например против, что бы на моих разработках деньги зарабатывали. Собирать для личного использования пожалуйста.
А Вам рекомендую хотя бы перевести весь код на GPL или LGPL лицензию. Ну что бы закрыть код нельзя было при модернизации, будет народным достоянием :). Но тут еще вопрос конечно, что в вашем коде присутствует :)

Леонид Иванович

21.06.2012, 09:25

А Вам рекомендую хотя бы перевести весь код на GPL

Я не понимаю, зачем нужна какая-то лицензия, если код открытый?

NoName

21.06.2012, 10:17

UR4UDT

21.06.2012, 10:50

Потому что кто нибудь может взять Ваш код и что-то дописать свое и свой код ни кому не показывать. А GPL например обязывает в этом случае открывать исходники для всех И добавленный код так же публиковать под лицензией GPL, т.к. она запрещает менять тип лицензии. Ну и много еще чего.

Андрей, ну ни кто и ни какая лицензия не сможет ОБЯЗАТЬ. Если реально смотреть на нашу действительность, то или опубликуй и спи спокойно, или не публикуй и то же.

NoName

21.06.2012, 11:01

Андрей, ну ни кто и ни какая лицензия не сможет ОБЯЗАТЬ. Если реально смотреть на нашу действительность, то или опубликуй и спи спокойно, или не публикуй и то же.
1. Для общего образования и по русски (http://licenseit.ru/wiki/index.php/Статья:Свободные_лиц ензии_на_ПО)
2. Если уж совсем лень бодаться - цитата "Фонд свободного программного обеспечения в целях упрощения правовой защиты произведений, опубликованных на условиях данной лицензии, рекомендует авторам передавать исключительные права Фонду или же передавать их в общественное достояние. "
На том же e-bay запросто прикроют, а так все от объемов зависит. Мне вот жалко если разработки ЛИ, какие-то чудаки на букву "м" своими объявят.

ut1wpr

21.06.2012, 11:52

1. Для общего образования и по русски (http://licenseit.ru/wiki/index.php/Статья:Свободные_лиц ензии_на_ПО)
2. Если уж совсем лень бодаться - цитата "Фонд свободного программного обеспечения в целях упрощения правовой защиты произведений, опубликованных на условиях данной лицензии, рекомендует авторам передавать исключительные права Фонду или же передавать их в общественное достояние. "
На том же e-bay запросто прикроют, а так все от объемов зависит. Мне вот жалко если разработки ЛИ, какие-то чудаки на букву "м" своими объявят." А GPL например обязывает в этом случае открывать исходники для всех И добавленный код так же публиковать под лицензией GPL, т.к. она запрещает менять тип лицензии." Фонд может обязывать и запрещать что угодно и как угодно. У Фонда нет механизма воздействия на нарушителей их рекомендаций, распоряжений и указов. Все положения Фонда суть декларативные.

NoName

21.06.2012, 12:00

У Фонда нет механизма воздействия на нарушителей их рекомендаций, распоряжений и указов. Все положения Фонда суть декларативные.
Давай вы возьмете Linux и сделаете свой закрытый fork, а я на вас стукану.... Заодно посмотрим какие у него есть механизмы.
Что вы перекладываете наш Русский/Украинский/Белорусский пофигизм на весь мир.

UR4UDT

21.06.2012, 12:14

to UB3TAF
Но Вы выкладываете .hex-ы без всех этих заморочек.
Средней руки программист и не ленивый раскрутит в ассемблер (конечно без комментариев).
Логика дебатов?

Transistor

21.06.2012, 12:55

На любой Закон всегда найдется определенное число нарушителей. И что - отказаться от законов вообще?
Да, кого то от нарушений сдерживает неотвратимость наказания и/или его суровость. Но лично я уверен,
что большинство все таки руководствуется совестью.
Прекрасно осознаю, что у многих упоминание совести вызовет ухмылку, ничего - переживу.
Моя позиция - использовать доступные инструменты, а относительно нарушителей - пусть у них голова
болит. ЖИЗНЬ найдет тысячи способов восстановить статус-кво!

ut1wpr

21.06.2012, 14:25

Давай вы возьмете Linux и сделаете свой закрытый fork, а я на вас стукану....А без стука?

Заодно посмотрим какие у него есть механизмы.Какие?

Что вы перекладываете наш Русский/Украинский/Белорусский пофигизм на весь мир.А что (кто) вам дал право делать подобные обобщения (заключения) ?
Ладно, треп ни о чем. Мир во всем мире одинаков. И люди в нем ну очень уж разные. Отсюда и выводы.

Transistor

21.06.2012, 15:18

Возьму на себя смелость подвести некоторый промежуточный итог, а заодно ответить на ЧАВО.
1. Мотивация к разработке унифицированного набора команд.
Современная радиоэлектроника развивается столь стремительно, что становится все труднее одному человеку
овладеть всеми стадиями процесса разработки изделия - от схемотехники, разработки и изготовления печатной
платы, до написания встроенного ПО микроконтроллера и терминального ПО для ПК.
С другой стороны, есть объективные стимулы завязать измерительные приборы с ПК. Например, панорамные
измерения АЧХ и КСВ существенно проще выполнить средствами ПК, чем корячиться на Контроллере при ограниченных
изобразительных возможностях доступных ЖКИ. Можно придумать и другие примеры: логгер для зарядного
устройства аккумулятора, наблюдение температурных профилей... Возможность дистанционного управления
может существенно снизить трудоемкость калибровки и выходной контроль параметров Прибора.
Унифицированного набора команд призван стать связующим мостиком между прогрммистами и "железячниками".
2. Объект рассмотрения - унифицированный Набор Команд (далее НК) для дистанционного управления отдельным
измерительным модулем (ИМ) или комплексной измерительной системой (КИС), состоящей из нескольких ИМ.
КИС может содержать как отдельные Контроллеры для каждого ИМ, так и общий Контроллер к которому подключены
ИМ, например по шинам I2C, SPI. По сути КИС - это младший брат промышленных ATE (Automatic Test Equipment).
Отличительные черты КИС:
- сильно ограниченный вычислительный ресурс (по сравнению с промышленными собратьями);
- существенно ограниченные возможности по тех. поддержке (над проектами трудятся один-два человека на
общественных началах, а не команда профессионалов в рабочее время).
3. НК должен быть максимально не зависимым от транспортного уровня управляющего интерфейса, которым может
служить, например, COM, USB, RS485.
Здесь уместно подчеркнуть, что выбор физического интерфейса не дает ответа на вопросы как сообщить Генератору -
установить такой-то урвень выхода, такую-то частоту, выбрать такой-то вход внешней модуляции, включить ЧМ и т.д.
Как заставить Мощемер измерить уровень сигнала, а частотомер - частоту с такой-то временной базой.
Для этого служит следующий - более высокий уровень управляющего Интерфейса, который и является объектом
рассмотрения в данной ветке.
4. Изначально внимание привлекли два полярных варианта НК.
Первый - это упрощенный до предела НК от Андреаса DL4JAL, широко известная программа WinNWT.
Недостатки НК от Андреаса:
- нет четкого признака окончания командной последовательности, что затрудняет обработку;
- нет наглядности/прозрначности команд, хоть они и ASCII-подобные;
- исходный НК сильно ограничен. Так для управления Генератором присутствует всего две команды:
“f” - "Установить F" VFO;
"r " включение аттенюатора;
- в случае линейного расширения этого НК недостатки будут еще больше усугубляться.
Второй - это наиболее совершенный на сегодня НК: SCPI - Специальные Команды для Программируемых Инструментов
(здесь - Приборов). SCPI предназначен для создания в том числе и сложных ATE и должен иметь возможность
реализовать ВСЕ возможности современных Измерительных Приборов (а как иначе?).
Вот три ключевых особенности современных Приборов, важных для рассматриваемой темы:
- невероятно богатый функционал и возможности, а значит и сложность Приборов;
- наличие встроенного одноплатного компьютера или аналогичной по вычислительной мощности управляющей*
подсистемы; поэтому обмен данными между таким Прибором и ПК правильнее классифицировать как обмен
"ПК-ПК", но никак не "ПК-Контроллер".
- над его разработкой трудятся целые коллективы, включающие по нескольку программистов разной специализации:
ембеддеры, занимающиеся разработкой Firmware, и системщики*, занимающиеся разработкой терминального
ПО - Software; плюс руководитель Группы программистов, координирующий работу всех программистов и плюс
руководитель проекта. Не вызывает сомнений, что у программистов по мере работы от прибора к прибору
нарабатыается личный и корпоративный опыт, закрепленный в виде соответствующий библиотек, например
лексических интерпретаторов. Вполне вероятно, что отдельная команда готовит специализированные драйверы для
каждого рибора.
Очевидно, что SCPI - является тем "велосипедом", об изобретении которого не раз говорилось в теме.
Но за 40 лет он превратился в средство управления автомобилем представительского класса - дорогого и с
кучей наворотов. А нам надо управлять мотоциклами, мопедами и даже велосипедами, иногда.
Вывод относительно SCPI - радиолюбителям, в силу организационных особенностей и ограниченности
вычислительных возможностей Контроллеров ИМ, его в оригинальном виде НЕ поднять.
5. Поиск оптимального варианта.
Но между двумя полярными вариантами существует множество промежуточных ступеней.
В теме фигурирует две: WAKE Леонида Ивановича и Протокол_для_Комплек са (пост №39).
WAKE лишен недостатков WinNWT, имеет открытую Спецификацию, блягодаря ЛИ, активно используется во многих
профессиональных и любительских проектах. К минусам протокола можно отнести, во-первых,
"бинарность", что делает его не наглядным, во-вторых, недостаточную проозрачность - содержание команды
скрыто за номером, регулируемый параметр - снова номер. При наращивании количества команд и управляемых
параметров приходится писать некую "шпаргалку" - что есть что (из личного опыта. Как оказалось после знакомства со
спецификацией WAKE, в прошлом году автору довелось участвовать в одном из проектов, где управляющий протокол,
с подачи иностранного партнера, был клоном WAKE). Кроме того, вопрос содержательного наполнения поля CMD
(Command) открыт, т.е. в каждом случае разработчик должен сам придумывать команды. Поэтому установка частоты
или выходной мощности, например, каждый раз у всех будет/может выглядеть совершенно по разному.
В авторском варианте НК (Протокол_для_Компле кса) сделана попытка взять лучшее из SCPI - наглядность и некоторые
правила генерации команд и параметров, но в тоже время значительно упростить его за счет устранения избыточности и
более жесткой регламентации формата командных последовательностей. Так заголовок команды является синтезом
подходов из NMEA0183 (два первых символа - кодовое обозначение адресуемого ИМ) и IEEE488.1 (три следующих
символа заголовка команды - собственно код команды). В итоге должна получиться наглядная, не очень сложная при
в обработке, способная к расширению Система команд. Проект этого НК находится в активной стадии разработки.
Приветствуются констриктивные предложения и критика.
Примеры различных ASCII-подобных НК:
$GPGLL,llll.ll,a,yyy yy.yy,a,hhmmss.ss,A, a*hh<CR><LF> - отчет GPS "Geographic position - latitude/longitude";
:RFSOURCE :FREQ :433920123<CR><LF> - установка частоты Генератора ВЧ согласно SCPI;
:GRFRQ 433920123H<CR> - установка частоты Генератора ВЧ согласно Протокол_для_Комплек са (пост №39).
- было бы здорово, если бы Леонид Иванович дополнил картину вариантом реализации аналогичной задачи
на WAKE.
Никто никого не может заставить использовать тот или иной протокол/НК, но и препятствовать выработке общих
подходов не вижу смысла. Для меня разработка НК - это актуальный рабочий момент. Уже готова терминальная
программа для Частотомера-Мощемера, но команды там "кривые" и требуют расширения. В планах - вкладка "Генератор ВЧ",
затем АЧХ-ометр подобно WinNWT. Верю, что и в области измерений возможно повторение ситуации с СДР - много
альтернативного софта, много альтернативного железа, и все это так или иначе между собой сопрягается.

СПАСИБО всем кто дочитал сей опус до конца!

Леонид Иванович

22.06.2012, 00:57

Потому что кто нибудь может взять Ваш код и что-то дописать свое и свой код ни кому не показывать.

Ну и ладно. Пусть не показывает. Что Вам от этого?

все труднее одному человеку овладеть всеми стадиями процесса разработки изделия

Это правда. Но правда еще и то, что рождается только та радиолюбительская конструкция, автор которой овладел всеми стадиями. Иначе это промышленная разработка.

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

Абсолютно верно. На PC гораздо проще отрабатывать алгоритмы, чем на микроконтроллере. А возможность графической визуализации данных так и вовсе порой является единственной возможностью решить задачу. Как пример: захотел сделать паяльную станцию. Отладить PID-регулятор, не видя переходной характеристики, почти нереально. В итоге паяльная станция получила интерфейс с протоколом WAKE, а на PC был написан софт специально для настройки паяльной станции:

114150

По сути КИС - это младший брат промышленных ATE (Automatic Test Equipment).

Занимался разработкой промышленных ATE (для ПО "Интеграл"). Конечно же, они используют протокол WAKE. И его бинарность оказалась весьма кстати, так как протокол не должен был сильно снижать скорость обмена.

К минусам протокола можно отнести, во-первых, "бинарность", что делает его не наглядным

Наглядность ASCII-протоколов проявляется при отладке устройств через терминал. Я против такой отладки. Как частью общей культуры, каждый электронщик должен обладать навыками программирования хотя бы на уровне написания отладочных тестов. Пусть большие программы с базами данных пишут профессиональные программисты. Но работа компьютера с железом - забота электронщика. Хотя я ни разу не программист, но работая над большими проектами всегда сам писал класс работы с оборудованием. Методы этого класса потом использовали профессиональные программисты в своих больших программах.

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

Никогда и нигде в программе нельзя применять номеров, т.е. чисел. Все константы должны быть именованы. Поэтому команды WAKE в исходном тексте нормально написанной программы имеют вид не 13, 11,18, а CMD_SET_MODE, CMD_GET_BIAS, CMD_SET_FREQUENCY. Так же и с параметрами. И заметьте, Вы можете давать командам сколь угодно длинные имена, но на трафике это никак не скажется, будет передаваться по-прежнему 1 байт.

вопрос содержательного наполнения поля CMD (Command) открыт, т.е. в каждом случае разработчик должен сам придумывать команды

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

:RFSOURCE :FREQ :433920123<CR><LF> - установка частоты Генератора ВЧ согласно SCPI;
:GRFRQ 433920123H<CR> - установка частоты Генератора ВЧ согласно Протокол_для_Комплек са (пост №39).
- было бы здорово, если бы Леонид Иванович дополнил картину вариантом реализации аналогичной задачи
на WAKE.

Не нужно опускаться так низко - как передается команда по проводам - никому знать не нужно. Главное, чтобы в исходнике программы было удобно работать с командами и данными. У меня сейчас формирование пакета делается следующим образом:

NewCmd(CMD_SET_FREQU ENCY);
AddDWord(433920123);
SendCmd();

NoName

22.06.2012, 08:58

Я бы все таки сделал как можно ближе к SCPI:
Вообще весь протокол SCPI парсить весьма нетрудно и даже удобно, единственно что из него надо выкинуть так это древовидную структуру, это реально трудно и не надо. Оставить два уровня УСТРОЙСТВО:КОМАНДА, а остальное взять один к одному, даже НАЗВАНИЯ КЛАССОВ И КОМАНД.
Естественно разделил бы имя устройства и команду символом ":", для парсинга токенов это еще лучше. Есть явный разделитель, он позволяет вообще не привязываться к длине команды (имени устройства). Зачем себя ограничивать 2 символа, 3 символа, хоть 1, хоть 5. Для каждой команды сравнивать только первые символы, которые обозначают значение токена, в SCPI это выглядит как FREQuency, где первые 4 символа есть обязательные символы токена, которые идентифицируют команду, а дальше по желанию. Код парсера это не раздувает, но позволяет делать команды более запоминаемыми и дружественными для человека.
Сделал бы опциональную возможность работы с Float На первом этапе Вас ни кто не заставляет оперировать с Float (это по желанию автора), но можно добавить. А можно на это команду добавить, что бы узнать - работает КИС, ИМ с float или нет. Например: *FLOAT? И все становится на свои места.
Убрал бы всякие префиксы H, K, M and other. Есть базовая единица измерения для параметра и все. Например только Герцы. Добавление размерностей усложнит парсер, который надо будет привязать к типу команды. Без префикса парсер будет единым для всех команд и выдавать цифровые параметры и имя функции.
Несколько параметров (для команды) парсить через запятую тоже нетрудно, т. к. есть разделитель “,” и конец команды “<CR>”. Но это вопрос для обсуждения. Команды с параметрами через запятую снизят в некоторых случаях избыточность передаваемых команд. И даже если устройство не будет поддерживать этот тип команд ни кто не запрещает добавить их в спецификацию протокола. Команды данного типа можно будет добавлять по мере развития устройства. Например сначала SWING можно сделать отдельными командами, а затем сделать еще специальную общую команду, если автор захочет.
Пример Итого:
1) :GEN:FREQ 433920123<CR> - установка частоты. Что эквивалентно :GENerator:FREQuency 433920123<CR>
2) SWING в двух вариантах
Вариант 1
:GEN:SWF 4500000<CR> - центральная частота
:GEN:SWS 1000<CR> - шаг перестройки частоты
:GEN:SWN 64<CR> - количество точек свипирования
:GEN:SWT 0<CR> - задержка между переключениями частоты;
:GEN SWR<CR> - запуск
Вариант 2
:GEN:SWIng 4500000, 1000, 64,0<CR> - при этом не надо делать команду запуска, т.к. все параметры уже набраны. Эту команду в спецификации можно обозначить как необязательную.
В данных примерах я не приводил названия команд из спецификации протокола, т. к. ее не было под рукой.

P.S. Это мы еще команды обсуждаем, а еще надо будет выходные данные обсуждать :).

Transistor

22.06.2012, 10:18

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

Естественно разделил бы имя устройства и команду символом ":", для парсинга токенов это еще лучше. Есть явный разделитель, он позволяет вообще не привязываться к длине команды (имени устройства). Зачем себя ограничивать 2 символа, 3 символа, хоть 1, хоть 5. Для каждой команды сравнивать только первые символы, которые обозначают значение токена, в SCPI это выглядит как FREQuency, где первые 4 символа есть обязательные символы токена, которые идентифицируют команду, а дальше по желанию. Код парсера это не раздувает, но позволяет делать команды более запоминаемыми и дружественными для человека.
- выглядит логично и убедительно.

Убрал бы всякие префиксы H, K, M and other. Есть базовая единица измерения для параметра и все. Например только Герцы. Добавление размерностей усложнит парсер, который надо будет привязать к типу команды. Без префикса парсер будет единым для всех команд и выдавать цифровые параметры и имя функции.
- к этом я тоже пришел, согласен.

Несколько параметров (для команды) парсить через запятую тоже нетрудно, т. к. есть разделитель “,” и конец команды “<CR>”. Но это вопрос для обсуждения. Команды с параметрами через запятую снизят в некоторых случаях избыточность передаваемых команд. И даже если устройство не будет поддерживать этот тип команд ни кто не запрещает добавить их в спецификацию протокола. Команды данного типа можно будет добавлять по мере развития устройства. Например сначала SWING можно сделать отдельными командами, а затем сделать еще специальную общую команду, если автор захочет.
- здесь надо подумать, проиграть разные варианты, хотя бы на бумаге. Не хочется пороть гарячку снова - беру таймаут.

NoName

22.06.2012, 11:17

Вообще весь протокол SCPI парсить весьма нетрудно и даже удобно, единственно что из него надо выкинуть так это древовидную структуру, это реально трудно и не надо.
Что то уже хочется просто сесть и написать пробный вариант, может и дерево парсить будет нетрудно.... Времени нету..., завтра опять дача :(

Transistor

22.06.2012, 12:05

Оставить два уровня УСТРОЙСТВО:КОМАНДА, а остальное взять один к одному, даже НАЗВАНИЯ КЛАССОВ И КОМАНД.
- как в один уровень для команды втиснуть все дерево Команд и при этом оставить Команды один к одному ?
По-моему, здесь либо дерево оставлять в том или ином виде, либо Команды сильно модифицировать...

NoName

22.06.2012, 12:12

По-моему, здесь либо дерево оставлять в том или ином виде, либо Команды сильно модифицировать...
Вот тоже сижу думаю, надо пробовать.

Transistor

22.06.2012, 14:20

У меня сейчас формирование пакета делается следующим образом:

Код:
NewCmd(CMD_SET_FREQU ENCY);
AddDWord(433920123);
SendCmd();

- именно этого я и хотел. Спасибо!

Vitas56

26.06.2012, 15:30

Супер! Я только мечтаю получить подобные параметры! Только нижнюю границу диапазона хочу получить от звуковых частот, 1 МГц - слишком много. Уже год продумываю конструкцию, но не хватает квалификации. И что, аттенюатор действительно обеспечивает ослабление -127 дБ на 180 МГц? Я тоже как-то применял каскадированные AT-260, но пролезание было очень сильным. Схема и конструкция Вашего генератора - секрет?
Извиняюсь что пропадал. отпуск-деревня. Насчет ослабления до -127дБм- Все вч узлы в отдельных экранированных ячейках. В том числе и аттенюатор разбивается на ячейки с затуханием 20 дБ. У меня 3 ячейки с фиксированным ослаблением по 20 дБ одна с 31дБ с шагом 1дБ. Остальное затухание с помощью регистра ASF DDS 9951. Все провода управления и питания являются потенциальными волноводами особенно на высоких частотах. Поэтому обязательны проходные конденсаторы небольшой емкости. Я например в поддоне сверлил отверстие 1мм вставлял походной контакт и с обеих сторон припаивал к нему безвыводные емкости на 200-1000пФ. Ячейки сначала запаял тонкой луженой сеткой а сверху дополнительно тонкой медной фольгой. Очень удобно проверять все пролазы ручной р.ст с "резиновой" антенной. По поводу схемы никаких секретов нет. Просто я не оформлял ее для публикации. Рисовал отдельными фрагментами. То-же и с конструкцией. DDS, аттенюаторы, управление делал на отдельных платках. Процессор вообще на макетке. DDS позволяет работать от "нулевых" частот и тем более от звуковых. Либо увеличиваете емкость конденсаторов на выходе DDS либо ставите на выход DDS дифференциальный усилитель например AD8009 c двуполярным питанием и небольшим смещением чтобы получить "0" постоянки на выходе. С усилителем коэффициент гармоник возрастет до -40 дб на частотах более 80 мГц. (см. даташит). Все остальное можно сделать (и нужно) программно. Самое ответственное калибровка аттенюатора. если есть серьезные приборы можно измерить погрешность и скомпенсировать с помощью того-же регистра ASF. Точность установки частоты напрямую зависит от стабильности опорного генератора. У меня стоит обычный снятый со старой материнской платы поэтому на частоте 100мГц уплывает на ~30Гц Отсюда и шаг перестройки 100Гц.