Люди!
Как вы думаете, есть ли смыл "западать" на компьютерный интерфейс (PC SB & PC RS-232 <> TRX) с гальванической развязкой (оптронной, трансформаторной)? Т.е. типа вот этого http://www.yl3bu.ardi.lv/Kenwood/PSK31_interface.html
Или от этой развязки никакой реальной пользы?
когда у меня был 570-й то был обычный кабель для подключения к компу, потом глянув в сервис мануал увидел, что разъем rs-232 подключен в трансивере к ЦП только через токоограничивающие резисторы, что очень непонравилось. Так как перепаять дохлый max232 это одно, а планарный ЦП совсем другое. В общем, заставил себя сделать оптронную развязку после этого. Вывод - от аппарата зависит.
>> когда у меня был 570-й то был обычный кабель для подключения к компу, потом глянув в сервис мануал увидел, что разъем rs-232 подключен в трансивере к ЦП только через токоограничивающие резисторы, что очень непонравилось. Так как перепаять дохлый max232 это одно, а планарный ЦП совсем другое. В общем, заставил себя сделать оптронную развязку после этого. Вывод - от аппарата зависит.
Спасибо за ценный ответ.
Хотя как я понимаю у компьютерных RS-232-портов тоже нет гальванической развяки, и ничего страшного с ними не происходит (до тех пор, пока не спалят порт "горячим" подключением/отключением устройства или иной глупой выходкой).
Т.е. нужна ли эта развязка, если я один раз все соединил и более ничего не трогаю? Или все равно есть смысл чего-то бояться (например, вездесущего статического электричества)?
Или все равно есть смысл чего-то бояться (например, вездесущего статического электричества)?
Дело ведь не столько в защите аппарата, сколько в снижении уровня фона и наводок, т.е. устранении выравнивающих токов на оплетке кабелей и тем самым повышении качества передаваемого и принимаемого сигнала. Кстати, неграмотный монтаж может свести на нет использование интерфейса.
Например: металлический корпус, разъёмы не изолированы.
Мелочь, про которую некоторые забывают :(
Такая конструкция уже не является гальванической развязкой, но... радиолюбитель доволен. Купил фирменный набор или повторил хорошо зарекомендовавшую себя схему и... живет себе припеваючи со схемой гальванической развязки, которая собственно таковой у него не является.
В общем моим побудительным мотивом было - "как бы чего не вышло". Помех по последовательному порту у меня не было. Просто прикинул что будет если сгорит порт в компе и в трансивере. В первом случае я просто куплю за 5 баксов старый исашный комбик и буду продолжать использовать мамку с горелым портом. В трансивере - попадаю минимум на замену проца. Стоит он недешево и перепаивать его - тот еще гемор. Просто решил перестраховаться чтобы снизить вероятность выхода из строя порта трансивера которая по моему и так довольно небольшая.Цитата:
Автор оригинала EIKA
[B
Спасибо за ценный ответ.
Хотя как я понимаю у компьютерных RS-232-портов тоже нет гальванической развяки, и ничего страшного с ними не происходит (до тех пор, пока не спалят порт "горячим" подключением/отключением устройства или иной глупой выходкой).
Т.е. нужна ли эта развязка, если я один раз все соединил и более ничего не трогаю? Или все равно есть смысл чего-то бояться (например, вездесущего статического электричества)? [/B]
Что же касается помех и наводок сигналу передаваемому по последовательному порту, то это решается просто уменьшением скорости передачи. Она не является очень критичной так как объем передаваемый данных совсем небольшой.
Реальная история. Дело было лет 5 назад.Цитата:
Автор оригинала EIKA
>> ... как я понимаю у компьютерных RS-232-портов тоже нет гальванической развяки, и ничего страшного с ними не происходит (до тех пор, пока не спалят порт "горячим" подключением/отключением устройства или иной глупой выходкой).
Т.е. нужна ли эта развязка, если я один раз все соединил и более ничего не трогаю? Или все равно есть смысл чего-то бояться (например, вездесущего статического электричества)?
Начали мы с ребятами на RK3AWB осваивать SSTV и PSK. Поставили нормальную "мамку", SB и подключили все это напрямую к FT-920. Первые пару минут все было ОК, а потом трансивер встал в постоянный ТХ и на переключается. Шнуры отключаешь - норма, подключаешь - "глюк". Перерыли всю программу, думали в ней проблема - ничего. Отключаем шнуры, проверяем РТТ (через RS-232) - "коза". Программу на передачу - "коза", на прием - она же. Позже поняли: КМОП ключи интерфейса спалили. Меняем "маму", делаем буферный каскад (без гальванической развязки!!!!) на 610 транзисторе. Включаем - норма.
Работаем. Только сила сигнапа на передачу в течении часа на ноль помножилась и комп не воспринимает на прием. Оказалось сгорел SB.
Меняем. Уравниваем потенциалы на корпусах компа и RTX. Норма, но с "грязью". Почесали затылок, поставити Т-фильтр против ВЧ (два дросселя последовательно и "кондёр" как шунт ВЧ). Чисто. Плата не сгорела даже через два года.
Мораль сей басни такова: Надо ВСЕ землить, уравнивать "корпусные" потенциалы и ставить буферные каскады. Тогда можно "выжить" и без развязки.
73!
Алексей
2 isartw
Спасибо за комментарии!
2 RW3DFQ
Полезная история... спасибо.
2 ALL
Теперь вопрос -- насколько качественно срабатывает перекючение TX/RX, если в качестве управляющего элемента используется транзисторный ключ, управляемый НЧ-сигналом с выхода SB (см. http://www.cqham.ru/images/acc2_123.gif)? Т.е. имеется ввиду насколько качественно по сравению с вариантом, когда управление TX/RX организовано черех COM-порт компьютера...
???
IMHO, COM-порт однозначно надежнее, проблема в том, что у разных типов трансиверов протоколы отличаются. Если используемый софт их поддерживает, то все класс.Цитата:
Автор оригинала EIKA
[B
Теперь вопрос -- насколько качественно срабатывает перекючение TX/RX, если в качестве управляющего элемента используется транзисторный ключ, управляемый НЧ-сигналом с выхода SB (см. http://www.cqham.ru/images/acc2_123.gif)? Т.е. имеется ввиду насколько качественно по сравению с вариантом, когда управление TX/RX организовано черех COM-порт компьютера...
??? [/B]
>> IMHO, COM-порт однозначно надежнее
Я тоже так думаю, что дискретные логические уровни будут надежней транзисторного ключа, управляемого недискретными сигналами.
>> проблема в том, что у разных типов трансиверов протоколы отличаются.
А как же -- конкуренция, мля.
>> Если используемый софт их поддерживает, то все класс.
Вы имеете ввиду, что может получиться так, что моя любимая PSK31 программа не сможет управлять моим трансивером, потому как с ним не "знакома" (это я абстактно спрашиваю -- без привизки к TS-570)???
Вот что еще — как вы думаете, можно ли сделать Y-шнур (т.е. рогатку с тремя COM-разъемами) и подключить тот конец, где один разъем к трансиверу, а там где два разъема — к компьютеру (один разъем «посадить» на COM 1, другой на COM 2).
Само собой нужно хитро распаять Y-шнур — так, чтобы у разъема COM 1 были распаяны только те пины, по которым передаются данные, а у разъема COM 2 распаять пины, которые отвечают за переключение RX/TX.
После этого настроить логгер (например, AAlog) на использование порта COM 1, а PSK31-программу — на использование порта COM 2.
Идея в чем — логгер через COM 1 работает с трансивером и пишет в журнал все, что положено (данные о частоте, диапазоне, виде модуляции и т.д.), а PSK31-программа через COM 2 управляет RX/TX
:)
Или эта идея реально не осуществима, например, по той причине, что некоторые провода, ВОЗМОЖНО, используются для передачи как данных (о частоте, диапазоне, виде модуляции и т.д.), так и для передачи команд управления RX/TX?
Что вы думаете насчет этой идеи?
Прочитал я сообщение Юрия (см. http://forum.qrz.ru/showthread.php?s...3796#post19551) и понял, что без подачи логического нуля на пин #9 разъема ACC 2 (т.е. без замыкания его на корпус), микрофонный вход на разъеме ACC 2 (пин #11) активироваться не будет.
Но это не проблема -- просто придется подавать управляющие сигналы RX/TX не на COM-порт трансивера, а на разъем ACC 2 трансивера.
Что скажете?
Да, именно такЦитата:
Автор оригинала EIKA
[BВы имеете ввиду, что может получиться так, что моя любимая PSK31 программа не сможет управлять моим трансивером, потому как с ним не "знакома" (это я абстактно спрашиваю -- без привизки к TS-570)??? [/B]
Это плохая идея, чтобы трансивер начал передавать ему тоже нужно дать команду, а не выставить потенциал на каком-то пине.Цитата:
Автор оригинала EIKA
Вот что еще — как вы думаете, можно ли сделать Y-шнур (т.е. рогатку с тремя COM-разъемами) и подключить тот конец, где один разъем к трансиверу, а там где два разъема — к компьютеру (один разъем «посадить» на COM 1, другой на COM 2).
Само собой нужно хитро распаять Y-шнур — так, чтобы у разъема COM 1 были распаяны только те пины, по которым передаются данные, а у разъема COM 2 распаять пины, которые отвечают за переключение RX/TX.
После этого настроить логгер (например, AAlog) на использование порта COM 1, а PSK31-программу — на использование порта COM 2.
Идея в чем — логгер через COM 1 работает с трансивером и пишет в журнал все, что положено (данные о частоте, диапазоне, виде модуляции и т.д.), а PSK31-программа через COM 2 управляет RX/TX
:)
Или эта идея реально не осуществима, например, по той причине, что некоторые провода, ВОЗМОЖНО, используются для передачи как данных (о частоте, диапазоне, виде модуляции и т.д.), так и для передачи команд управления RX/TX?
Что вы думаете насчет этой идеи?
Т.е. конкретно это решение не катит. Но в природе существуют свичи для последовательных портов, которые можно попробовать заюзать, хотя не факт что все программы с этим заработают.
Как вариант для винды, скачать DDK и сделать виртуальный драйвер для последовательных портов который бы выполнял функцию свича, т.е. мапил несколько виртуальных последовательных портов на один физический.
Или эта идея реально не осуществима, например, по той причине, что некоторые провода, ВОЗМОЖНО, используются для передачи как данных (о частоте, диапазоне, виде модуляции и т.д.), так и для передачи команд управления RX/TX?
В большинстве программ можно в меню выбирать способ переключения режимов прием/передача:
1. Специальным сигналом на последовательном порту (не сигналами RXD и TXD)
2. Командой САТ
3. Ничем .Tогда приходится либо вручную переключать, например педалью, либо задействовать VOX трансивера
Пользуйтесь MixW !
2 isartw
>> Это плохая идея, чтобы трансивер начал передавать ему тоже нужно дать команду, а не выставить потенциал на каком-то пине
Ну я просто не знаю, как Кенвуд переключается на передачу -- достаточно ему дать потенциал на каком-либо из пинов, или нужно послать ему команду в виде последовательности потенциалов, т.е. пакет.
Сейчас глядя на таблицу, в которой указаны назначения пинов, я понимаю, что трансиверу нужно посылать команду в виде пакета по проводу TXD.
Получается, что моя идея действительно не «канает», т.е. один и тот же провод нужен сразу двум портам (ACC 2 и COM-порту трансивера)
:(
>> Т.е. конкретно это решение не катит. Но в природе существуют свичи для последовательных портов, которые можно попробовать заюзать, хотя не факт что все программы с этим заработают.
Это уже огород получается…
>> Как вариант для винды, скачать DDK и сделать виртуальный драйвер для последовательных портов который бы выполнял функцию свича, т.е. мапил несколько виртуальных последовательных портов на один физический.
А это никак в этой ситуации не поможет — мне же нужно втыкать один и тот же провод в два разных разъема сразу (а это по понятным причинам не возможно — разве что найти аппаратный маршрутизатор для RS-232C :), т.к. при управлении PTT через COM-порт трансивера, микрофонный вход на ACC 2 не активируется! А мне нужен именно микрофонный вход в разъеме ACC 2, т.к. не отсоединять же микрофон каждый раз, когда хочется работать цифрой.