Трансивер SunSDR2, тема №6

[UN7RX]

Обсуждаем SunSDR2. Тем кто не имеет данного трансивера, категорически запрещено заниматься псевдооценками и прочим троллингом. В прошлой теме более 800 страниц. Чем лишать владельцев возможности в нормальной обстановке обсуждать имеющиеся трансиверы, гораздо гуманнее будет забанить желающих порезвиться за их счет. Не обижайтесь потом.

Желающие приобрести уточняют детали и параметры у ПРОИЗВОДИТЕЛЯ. Не в данной теме!

Отдельно обращаюсь к владельцам аппарата - не вступайте в бессмысленную полемику с флудерами и троллями всех мастей, вы САМИ топите свою тему в тоннах словесного мусора! Просто нажмите кнопку и сообщите модератору раздела.
Укажите в подписи наличие данного аппарата - так автоматом можно будет понять кто в теме, владелец, или "погулять зашел" и соответственно реагировать на посты.
Старая тема.

[R2MA]

Коллеги, уже поднимался вопрос по связке SS2 и JTDX.
Что при бете 8 и 9 при подключении через TCI, прога SS2 уходит в "ступор" ((((
Настройки вроде делаю правильные:

С 5М по TCI всё работает!!! Где "собака зарыта" ????
Возвращаюсь на ОмниРиг и вх-вых аудио, всё работает без проблем!!!!!
По TCI выход сигнала намного лучше выглядит!!!
Да, трансивер SunSDR2PRO

[R0JF]

Именно так все и будет. Единственный интерфейс с "внешним миром" у программы ExpertSDR3 это TCI.

Т.е. Вы предлагаете "простым" юзерам поскорее избавляться от Ваших трансиверов?

К сожалению, далеко не все программы поддерживают TCI - это раз!
Даже с TCI есть (пока) неразрешимые проблемы (SunSDR2QRP в среде Linux НЕ РАБОТАЕТ со звуком по TCI) - это два!
У пользователей есть необходимость и желание использовать и VAC и COM-порты - это три!

Спасибо за информацию, буду продавать, хотя очень жалко... :(

[VassiL]

Консультировался только что с программистом по выше обозначенным вопросам. Говорит, что разница между двумя способами передачи данных, с точки зрения загрузки ПК, будет стремиться к нулю. При этом TCI исключает целый паровоз из ненужных прослоек (драйвер аудио в ESDR2-прослойка аудиокабеля-драйвер аудио в JTDX). При этом пользователю необходимо настроить ряд параметров от которых зависит качество сигнала в эфире. В случае с TCI это две галки.
Как писал выше, в качестве переходного варианта была придумана утилита Клиент-TCI со всеми привычными входами/выходами. По факту ее готовности опубликуем на сайте.

Наличие TCI на борту трансивера или его отсутствие зависит от вычислительных ресурсов самого трансивера, а также от того, где заложена основная логика работы устройства. В данном случае вся логика заложена в самой программе. Трансивер лишь выполняет простую роль - передает и принимает радиосигналы сигналы, управляет периферией. Трансивер не решает, какой источник звука выбрать по приходу одного из 12ти типов PTT сигналов по двум приемникам, не разруливает блокировки между программными приемниками и пр. Как правило, эти вещи логичнее решить на стороне оператора и трансиверу отдать уже готовый результат. Особенно, когда трансивер находится на удаленной стороне. Какой смысл через интернет гонять потоки управления от логгера, программ цифровых видов связи и пр.?
В случае удаленного управления через интернет, есть идея внедрить TCI в сервер на удаленной стороне для управления периферийным оборудованием (усилители, ДПФ, антенны, поворотки и пр.), и это при наличии такого же сервера на стороне оператора в программе ExpertSDR3.

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

Т.е. Вы предлагаете "простым" юзерам поскорее избавляться от Ваших трансиверов?
....

Читайте, пожалуйста, внимательнее мои посты.
Скоро будет выпущена специальная программа-утилита, которая будет подключаться к ExpertSDR3 по TCI и "вытягивать" из программы все необходимые сигналы. При этом у утилиты на борту будут все привычные интерфейсы (IQ, НЧ входы/выходы через зв.карту, САТ через СОМ, CW через COM и пр.). Задача отсутствия всех этих устаревших интерфейсов на борту - убрать работу с драйверами этих устройств из основной программы для повышения стабильности ее работы. Если нужны эти интерфейсы - будете применять утилиту. Просто коллеги подняли вопрос о дополнительной нагрузке на ПК такого решения. Нагрузка будет +/- та же самая. При этом если драйверу СОМ-порта вздумается заглючить или Пользователь выдернет USB-кабель внешней звуковой карты из ПК на ходу, то нештатная ситуация возникнет в утилите, остальное радио продолжит свою работу штатно.

[ra6bx-alex]

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

Ну горячится так не надо.
CC2 отличная машина. и будет работать еще годы и годы, тем более ее последний релиз (итоговый) думаю не за горами.
А на СС3 пусть работают Сис.админы, контест-мены и т.д., полагаю только к следующему году что-то хорошее слепится.
Для обычных же пользователей СС2 это "находка" на долгие годы.
Нового выжать для DX работы врядли удастся - только сервисные функции ("сервер").
Единственный рывок для СС2 - это два раздельных приемных тракта. Вот тогда будет революция с далеко идущими выводами.
Но это уже будет другая машинка.

Так что наслаждайтесь СС2 !

[RX4HX]

вопрос по связке SS2 и JTDX.

С 5М по TCI всё работает

Потому что при работе с 5M TCI работает в режиме CAT, а с JTDX - и как CAT, и как виртуальная звуковая карта. И затык происходит именно при работе в качестве виртуальной звуковой карты.

TCI исключает

Василий, я не специалист в программировании звука, не могли бы Вы прояснить следующую не понятную мне ситуацию: "на бумаге" - "TCI исключает... и т.п." - одни преимущества и упрощения, а при внедрении TCI в JTDX возникли трудности, причем, как я понял, основная из них - большая нагрузка на комп. Мне вот этот момент не понятен.

[RJ7M]

Настройки вроде делаю правильные:

Активируйте как показано красным. Причём "Эмуляция на 1 VFO" - обязательно. Так правильнее... Если не получится - напишИте в личку.

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

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

Подтверждаю.
После появления TCI (и особенно после его внедрения в 5М) - забыл о существовании VAC и СОМ.
От окончательного удаления Сом0Сом и VAC с компьютера удерживают только НЕКОТОРЫЕ шероховатости при работе MSHV через TCI, альтернативу которой, при отдельных видах связи на УКВ, для себя пока не вижу.

[R0JF]

Читайте, пожалуйста, внимательнее мои посты.
Скоро будет выпущена специальная программа-утилита, которая будет подключаться к ExpertSDR3 по TCI и "вытягивать" из программы все необходимые сигналы.

Василий, хочу попросить Вас о том же - читайте внимательней посты пользователей!

Отказ от "классических" VAC-CAT однозначно похож на "до основания разрушим, а затем..." - сейчас и VAC и CAT хорошо работают в ESDR2, ЗАЧЕМ их выкидывать из новой программы? Код написан, обкатан.

Прикладных программ, которым достаточно TCI по пальцам перечесть, и вряд ли их список в ближайшие годы разительно увеличится. На JTDX, SDC, MSHV и LogHX свет клином не сошелся! Тем более, со звуком нерешенные проблемы. Зачем сознательно отбирать у пользователей возможность работать в отлаженных "связках"? А Вы очередной "костыль" предлагаете в виде новой утилиты. Чем это лучше?

Так что наслаждайтесь СС2 !

Я бы рад, да ESDR2 производитель уже "забросил", а ESDR3 - черезчур "радикально" изменена. При этом даже TCI-протокол в них разных версий.

[RX4HX]

Отказ от "классических" VAC-CAT однозначно похож на "до основания разрушим, а затем..." - сейчас и VAC и CAT хорошо работают в ESDR2, ЗАЧЕМ их выкидывать из новой программы? Код написан, обкатан.

Однозначно поддерживаю! Тем более для нормального существования фирмы ЭкспертЭлектроникс нужно закрепиться на "западном" рынке, а там свои программы, от которых в ближайшем будущем люди не готовы отказаться. И CAT по COM, и VAC должны присутствовать в самой программе, и никак уж не в отдельных утилитах, что явно не придаст скорости работы и стабильности.

При этом даже TCI-протокол в них разных версий.

Да это как раз не проблема - там просто новые команды добавлены. Это, как раз, не страшно)))

[RJ7M]

для нормального существования фирмы ЭкспертЭлектроникс нужно закрепиться на "западном" рынке

"Жаль, что все, кто знает как управлять государством, уже работают таксистами и кухарками" (С)

от которых в ближайшем будущем люди не готовы отказаться

ОНИ вам сами сказали или под пытками?
Или специалисты ЕЕ зря регулярно посещают различные профессиональные и радиолюбительские выставки. Там ведь не только "дефиле". Там ещё и общение с изучением и последующим анализом "общественного" мнения.

[UI3A]

работа с драйверами СОМ-портов и звуковых устройств является одним из дестабилизирующих факторов, приводящих к сбоям.

"есть ложь, а есть маркетинг" (с)

TCI это такой же "дестабилизирующ ий фактор", который так же может привести к сбоям, особенно если это не 127.0.0.1...
Применение TCI ну не приносит даже 10% увеличения стабильности.
Обычный софт, с обычными глюками и другими человеческими факторами.
Кстати, проблему сбрасывания передачи при коннекте нового клиента по TCI уже решили в новом единственном интерфейсе? (в старом так до сих пор не решили, больше года).

Можно настроить работу софта/железа через связки COM-VAC, которые будут даже более стабильнее TCI.
Я не против TCI - удобный протокол, сам использую в своих поделках, но я против огульного охаивания других стабильно работающих и драйверов и протоколов...