SunSDR: Remote - HELP!

[RL6M]

Как-то я обратился к форумчанам с просьбой дать свой адрес/порт на пробу. Откликнулись сразу несколько коллег. Попробовал, поработал ключом и через СОМ порт - в принципе все в порядке. Есть небольшие неровности, но, если придираться. Даже скиммер работает хорошо. И это при том, что у меня был деревенский 3G интернет. Снял кино, работал ключом.

Да, Юрий.
Вы правы, я забыл добавить. Когда я воткнул ключ в разъем Ecoder и передавал руками все было нормально (ну сносно как и у вас на видео) на том же компе....на тех же ресурсах...

Но здесь идет речь о программном ключевании CW c других программ (а не только 5M LOG)... разумеется я могу включить любой железный CW интерфейс и с того же компа включить его в E-coder, но решение будет похоже на "костыли" :-)

Тимофей

[UT4LW]

Подключайте PTT+CW к порту САТ. Там все работает.
Есть прикол - DTR RTS в настройках появляются только, когда есть подключение к серверу. ))

[R2AA]

Комп достаточно мощный.
Второе: мне показалось (???), что при включении манипулятора в E-coder при ямбическом режиме работы (галочка стоИт)
на удаленной стороне 100% все красиво.
Есть гипотеза, что в этом случае на удаленную сторону передается только ПРИЗНАК "точки" или "тире", а сами
телеграфные посылки также формируются на удаленной стороне, поэтому все и хорошо.

А в случае, когда переводим телеграф в обычный режим, вставляем в E-coder выход с телеграфного интерфейса и начинаем
логгером передавать - в этом случае на удаленную сторону передается уже как бы ГОТОВЫЙ пакет точек-тире, и он
по этой причине РВЕТСЯ...

Повторю, как мне кажется, ИЗНАЧАЛЬНО это не самый лучший вариант, заведомо наполовину "Обреченный".
Т.к. даже при условии, что все можно отрегулировать с компами и скоростью, пинги - дело не стабильное в
глобальной сети (не в локалке) и РВАТЬСЯ ВСЕ РАВНО БУДЕТ.

Поэтому, либо передавать код символа на удаленку и там формировать CW-посылку.
Либо отказываться от E-codera на стороне оператора и управлять аппаратом полноценно на удаленной стороне
через AnyDesk, RDP или TeamViewer, щелкая мышкой. (давно отработанный вариант, но не такой "модный").

Думали даже, а как бы "перенести" подключения E-codera по USB через интернет на удаленный комп...
Это тоже могло бы быть решением. Причем использовать тогда на удаленной стороне полноценную версию софта
eesdr.

- - - Добавлено - - -

Подключайте PTT+CW к порту САТ. Там все работает.
Есть прикол - DTR RTS в настройках появляются только, когда есть подключение к серверу. ))

Юрий, чуть подробнее, плиз....

[UT4LW]

Комп достаточно мощный.

Дело не в мощности компа, а в отсутствии проблем в нем. Устраните проблемы - будет все работать нормально. Следует заметить, что эти проблемы ломают телеграф не только для SunSDR2. Темы всех трансиверов имеют сообщения о пьяном матросе. И все находятся в одном месте - в нежелании навести порядок в компьютере.

что при включении манипулятора в E-coder при ямбическом режиме работы (галочка стоИт)
на удаленной стороне 100% все красиво.

Это говорит о том, что с трансляцией телеграфа на уровне программ SunSDR2 все в норме.

вставляем в E-coder выход с телеграфного интерфейса и начинаем
логгером передавать - в этом случае на удаленную сторону передается уже как бы ГОТОВЫЙ пакет точек-тире, и он
по этой причине РВЕТСЯ...

А вот это уже говорит о том, что проблема находится за пределами программ SunSDR2. Электронный ключ, который Вы подключили в гнездо панели уже имеет рваный телеграф.

Повторю, как мне кажется, ИЗНАЧАЛЬНО это не самый лучший вариант, заведомо наполовину "Обреченный".
Т.к. даже при условии, что все можно отрегулировать с компами и скоростью, пинги - дело не стабильное в
глобальной сети (не в локалке) и РВАТЬСЯ ВСЕ РАВНО БУДЕТ.

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

Подключение PTT+CW из лога:

[R2AA]

А вот это уже говорит о том, что проблема находится за пределами программ SunSDR2. Электронный ключ, который Вы подключили в гнездо панели уже имеет рваный телеграф.

Ни в коем случае! В этом месте как раз телеграф 100% корректный - проверял.

НО! Я обязательно воспользуюсь Вашими рекомендациями. Спасибо!
Правда, не совсем понимаю, что значит "навести порядок" в компьютере - он (комп) практически "читстый".
Удален весь ненужный виндусовый софт, почищен реестр, отключены браузеры (во время работы с программой).
Core i7 (5550), SSD 512, 8 gB RAM

[UA4NE]

И все находятся в одном месте - в нежелании навести порядок в компьютере.

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

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

[UT4LW]

он (комп) практически "читстый".

Это не показатель. Надо настраивать компьютер на предмет устранения "тормозов", если они есть, конечно.
Видеокарту - на максимальную производительность. Не помогло - отключаем всякие переключения и тормоза в схеме питания. Сетевая карта может провоцировать серьезные задержки во всей системе.
Мне везет - я всегда только видеокарту настраиваю.

и в нежелании задействовать потенциальные преимущества TCI

Согласен на все 100%. Ихних программеров надо закрыть на пару-тройку дней да мужика в зипуне, приветливо машущего дубиной (С), на выходе, пока не наведут порядок.
Но, на сегодня, как ни крути - SunSDR2 едва ли не единственный трансивер, который умеет передавать ключ и СОМ порт через удаленку. Только надо немного поработать самому.
Попроситесь к коллегам, которые это давно сделали, поработайте на их удаленках и примите решение: ждать, пока разродится ЕЕ, или использовать то, что есть уже сегодня.

[R2AA]

С видеокартой понял, спасибо. НО дело в том, что комп- "кирпичик", можно подключить только внешнюю USB-карту, но будет ли она такой
быстрой? Или надо ставить DESKTOP и сажать карту на PCI (express) ?

TO: UA4NE
Какие "чемоданные" технологии? На станции есть просто трансиверы, представляете К которым подключается разъем от CW-интерфейса.
И по TCI подключали, кстати... Такой же точно эффект.

[UT4LW]

но будет ли она такой быстрой?

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

Такой: https://www.asus.com/ru/Laptops-Acce...thernet_Cable/

[UA4NE]

Какие "чемоданные" технологии?

Евгений, а вот Юра сразу понял, что я имел в виду -)) Теперь дело за разработчиками, проблема решаемая.

[R2AA]

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

Попрошусь... Подскажите, плиз, (можно в личку) к кому попроситься?
Спрашивал Василия - "кто еще работает c SSdr remote и задает много вопросов? " - он навскидку не ответил...

[RL6M]

Спрашивал Василия - "кто еще работает c SSdr remote и задает много вопросов? " - он навскидку не ответил...

Ага... :-)

Для начала можно сюда список радиолюбителей, кто работает Remote SunSDR2 и не задает вопросов. :-)

Потом когда, Евгений, найдет такого человека, нужно спросить, КАКОЙ у него Sunsdr2 и как давно выпущен?

Например, модели с малыми серийными номерами (у меня такой) вообще не работают с последними версиями ExpertRS (сервера удаленки). Василий это кстати подтвердил.


Так что не исключено, что в современных моделях Sunsdr2 или даже SunSDRdx эта проблема рваного CW устранена или вообще не возникает.


Тимофей

[ZL1TM]

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

По-моему Вы с R2AA говорите о разных вещах. Вы про то что R2AA описал как "где галочка стоИт". А он про нажатие обычного ключа что эквивалентно программе формирующей точки и тире. Вы нажали на ключ (ну или на букву на клавиатуре и программа эмулирует нажатие ключа) и программа (любая) сразу должна передать факт нажатия а не пытаться его измерить. И во все время его (ключа) нажатия программа должна периодически посылать сигналы что ключ все еще нажат. И как только его отпустили программа должна перестать эти сигналы посылать. Допустим вы нажали на "E". Программе нужно передать точку то есть "нажать на ключ". Я не знаю какой период "оцифрования" этого нажатия в программе (это уж как программист решил). Допустим 10 миллисекунд. То есть для посылки "точки" в 100 миллисекунд программа пошлет 10 сигналов о том что ключ нажат в течении этих 100 миллисекунд. Допустим у вас пинг показывает постоянно (ключевое слово) 10 миллисекунд или 20 или 100 то проблем нет, просто в последнем случае трансивер начнет передавать с задержкой в 50 миллисекунд и перестанет с такой же задержкой. Проблема возникает тогда когда пинг показывает переменные величины, то есть существует "jitter" (packet delay variation). И если нет буфера или буфер не оптимальный (в совокупности с выбранным период "оцифрования") то и получается рваная манипуляция. Кроме того возможны потери пакетов в сети. Но это дело программиста выбрать период "оцифрования" нажатия ключа и величину буфера на стороне трансивера. Вообще это ничем не отличается от цифровой телефонии и методы борьбы с jitter и packet loss полностью применимы и здесь. В режиме элекронного ключа этой проблемы практически нет так как точки и тире программе формировать не нужно а нужно передать факт нажатия или точки или тире.

[UT4LW]

По-моему Вы с R2AA говорите о разных вещах.

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

[R2AA]

Джентльмены, я только не понимаю, неужели ВПЕРВЫЕ эта тема поднялась?
Или никто особо не использует SSdr в режиме remote?

Мне казалось, что столько веток на форумах, все давным-давно известно и решено,
а по факту получается, что нет...

Ну ОК, будем копать дальше + веорятно парни из Эксперт Электроникс помогут...