| Автор |
Сообщение |
|
|
Дата: 13 Дек 2007 20:10:36
#
RU2FVничего лучше мт63 не работает.
Попробуйте OLIVIA и JT65, последней вообще работают через Луну :) Но, я еще раз говорю, что сравнивать режимы предназначенные для ручной или QSO-работы с режимами для передачи данных есть совсем некорректно.
может кто-нибудь провести подобное испытание ?? Надо пару компов с динамиками и микрофонами.
Я этим баловался лет 5 назад, среди видов для передачи данных, в частности простой пакет и Q15x25, то Q15 выигрывал имено в таком "динамико-микрофонном тесте", а вот в реальном эфире - не всегда почему-то.
В любом случае, на данный момент времени, для передачи данных через звуковую рулит именно RFSM!
Dmitry_D2DНеужели вы думаете, что в RFSM нет FEC??? )))
Есть, но ведь наверно не во всех комбинациях скорости и не всегда равное количество повторяемых фрагментов?
Дмитрий, как вы думаете, возможен ли еще какой-то подрежим в RFSM, который был бы поуже (и ессно медленее), но чтобы позволил работать при еще более низких соотношениях СШ?
|
|
|
Дата: 14 Дек 2007 06:55:14
#
Zmej
Есть, но ведь наверно не во всех комбинациях скорости и не всегда равное количество повторяемых фрагментов?
В скоростях до 3200/2666 применяется стандартный несистематический последовательный FEC 1/2, далее применяется он же, но с выкалыванием.
Дмитрий, как вы думаете, возможен ли еще какой-то подрежим в RFSM, который был бы поуже (и ессно медленее), но чтобы позволил работать при еще более низких соотношениях СШ?
Возможен, его мы уже разработали, но еще не встроили в основную программу.
Правда, полоса бужет не уже существующей, а точно такая же.
Режим основан на последовательностях Уолша, и по проведенным тестам обеспечивает устойчивую работу на ОСШ до -5 дБ.
Скорость режима 300 бит/сек.
Думаю, в ближайших версиях мы его прикрутим к основной программе.
|
Реклама
Google
|
|
|
|
Дата: 14 Дек 2007 10:27:07
#
to zmej
сравнивать режимы предназначенные для ручной или QSO-работы с режимами для передачи данных есть совсем некорректно.
Важен результат (кол-во пер инфо в единицу времени при одинаковых условиях), и тут МТ на высоте. Я вообще-то говорю только о качестве работы протокола.
Я этим баловался лет 5 назад, среди видов для передачи данных, в частности простой пакет и Q15x25
А вы попробуйте в комнате, стены которой отражают звуки, накладывая их на основной сигн (типичная ситуация при скачковом распространении КВ, сигнал "размазан". У меня при этих усл МТ не сбавляет, остальные теряются, я уж не говорю о скорости).
В любом случае, на данный момент времени, для передачи данных через звуковую рулит именно RFSM!
Он великолепен тем, что передает ВСЕ, что подсунеш. А вот по устойчивости уступает МТ (при моих сложных условиях экспер.)
to Dmitry
если еще не надоел Вам своими тестами, неск замечаний:
- слишком длинная пауза при отсутствии квитанции от принимающей стороны. По моему инициировать запрос на повторение кадра должна ПЕРЕДАЮЩАЯ сторона, и через время, немного превышающее время предполагаемой квитанции;
- при коннекте надо сразу выдавать список почты для этого позывного и названия файлов, недокачанных в предыдущем сеансе;
- в режиме чата, если помеха забивает несколько кадров, то информация строки ТЕРЯЕТСЯ. Это очень неудобно;
- необходима докачка файлов;
- если потеря синхронизации происходит в начале болльшого кадра, то остальной прием игнорируется (судя по умершему индикатору приема). Тут логичней продолжать попытки синхронизации и складывать принятые куски, затем запрашивать недостающие из этого кадра.
- при соотношении SN меньшем 10 прием неустойчивый, но система продолжает гнать инфо на скорости 3200-2400. На мой взгляд, начиная с 9 необходимо переходить на 1200-600, скорость в итоге выше.
Условия моего теста тяжелые, но нам ведь надо оценить работу в сложных условиях, "на грани", иначе зачем ?
Дмитрий, прошу не судить строго мои замечания, RFSM отличная пр. и надеюсь станет еще лучше.
|
|
|
Дата: 14 Дек 2007 10:38:58
#
RU2FV
Ок, спасибо за замечания, будем смотреть, проверять, исправлять...
|
|
|
Дата: 14 Дек 2007 10:55:14 · Поправил: RU2FV (14 Дек 2007 10:56:46)
#
to Dmitry
Судя по умному маяку, система может отслеживать занятость в канале. Но при перекачке файлов случаются запросы навстречу, почему ? Нужно сл за занятостью кан все время.
Можно еще предусмотреть передачу сигнала и дисконнекте третьему корр, пытающемуся присоединиться в паузах основного трафика, чтобы не мешал.
|
|
|
Дата: 14 Дек 2007 11:04:34
#
RU2FV
Судя по умному маяку, система может отслеживать занятость в канале. Но при перекачке файлов случаются запросы навстречу, почему ? Нужно сл за занятостью кан все время.
Это просто сбои, такого не должно быть...
Можно попобробнее описать такую ситуацию?
|
|
|
Дата: 14 Дек 2007 11:19:04
#
Это просто сбои, такого не должно быть...
Можно попобробнее описать такую ситуацию?
Ситуация типичная, не принято окончание очередного кадра. После длинной паузы обе станции почти одновременно начинают работать навстречу, делают неск запросов, не принимая друг-друга. Думаю. что надо сделать РАЗНОЙ паузы от передающей и приемной сторон. Тогда передающ. будет опрашивать раньше, простой сократится.
Сегодня уточнил, в какой момент происходит потеря приема на одном из компов. Судя по звуку, прием идет до первой перезаписи на диск, дальше инд приема умирает до конца кадра. Комп вроде норм, пень-3, мозгов только 100, может не хватает ??
|
|
|
Дата: 14 Дек 2007 11:23:32
#
RU2FV
Немного прокомментирую предыдущий пост.
- слишком длинная пауза при отсутствии квитанции от принимающей стороны. По моему инициировать запрос на повторение кадра должна ПЕРЕДАЮЩАЯ сторона, и через время, немного превышающее время предполагаемой квитанции;
Пауза не длинная и не короткая, она именно такая, сколько нужно другой стороне, чтобы передать подтверждение (квитанцию). Если даже квитанция не опознана, она вре равно есть (другая сторона ее всегда передает), поэтому нужно дать ей на это время. Вот это время и выжидается, причем ровно столько (ну, или на 1-2 секунды больше), чем ушло бы времени на реальный прием квитанции.
- при коннекте надо сразу выдавать список почты для этого позывного и названия файлов, недокачанных в предыдущем сеансе;
Несогласен - а вдруг это НЕ нужно? Передача такого списка с гарантированной доставкой займет большое время, а с негарантированной - не нужна и вовсе. Уж лучше почту запросить самостоятельно, по крайней мере, тогда пользователь знает, что делает. Или он не может нажать одну кнопку? :)))
Вот кнопка для запроса списка недокачанных файлов - это разумно. Сейчас такие файлы можно посмотреть в каталоге Received, с расширениями .$$$.
- в режиме чата, если помеха забивает несколько кадров, то информация строки ТЕРЯЕТСЯ. Это очень неудобно;
Да, такая проблема есть. Чат передается с негарантированной доставкой.
Мы посчитали ненужным делать еще и гарантированную доставку чата, ведь для RFSM это не основной, а всего лишь вспомогательный режим.
- необходима докачка файлов;
Непонял, вроде она уже есть... :)))
- если потеря синхронизации происходит в начале болльшого кадра, то остальной прием игнорируется (судя по умершему индикатору приема). Тут логичней продолжать попытки синхронизации и складывать принятые куски, затем запрашивать недостающие из этого кадра.
Правильно подмечено, есть такая проблема. Мы над этим уже работаем...
при соотношении SN меньшем 10 прием неустойчивый, но система продолжает гнать инфо на скорости 3200-2400. На мой взгляд, начиная с 9 необходимо переходить на 1200-600, скорость в итоге выше.
Нужно поразбираться, возможно, скорректируем алгоритм понижения скорости...
Еще раз, спасибо за замечания.
С уважением, Дмитрий.
|
|
|
Дата: 14 Дек 2007 11:34:15
#
RU2FV
Собственно, какая у вас версия программы?
И, кстати, RU2FV - ваш позывной?
Если да, то вышлю бета-лицензию (для проверки всех возможностей).
|
|
|
Дата: 14 Дек 2007 11:51:55
#
Пауза не длинная и не короткая, она именно такая, сколько нужно другой стороне, чтобы передать подтверждение (квитанцию). Если даже квитанция не опознана, она вре равно есть (другая сторона ее всегда передает), поэтому нужно дать ей на это время.
Понятно.
при коннекте надо сразу выдавать список почты для этого позывного и названия файлов, недокачанных в предыдущем сеансе;
Несогласен - а вдруг это НЕ нужно?
А зачем тогда вообще соединятся ? ;))
- необходима докачка файлов;
Непонял, вроде она уже есть... :)))
Тогда sorry, не нашел, как ею пользоваться.
Собственно, какая у вас версия программы?
И, кстати, RU2FV - ваш позывной?
Если да, то вышлю бета-лицензию (для проверки всех возможностей).
Версия 052, RU2FV-позывной, за лицензию буду благодарен.
|
|
|
Дата: 14 Дек 2007 11:59:55
#
RU2FV
А зачем тогда вообще соединятся ? ;))
Ну, например, чтобы ОТОСЛАТЬ почту :))
Тогда sorry, не нашел, как ею пользоваться.
Если опция включена, то докачка действует автоматически...
Лицензию выслал на мыло.
|
|
|
Дата: 14 Дек 2007 12:51:24
#
А зачем тогда вообще соединятся ? ;))
Ну, например, чтобы ОТОСЛАТЬ почту :))
Логично.
Если опция включена, то докачка действует автоматически...
Я правильно понял, что при коннекте система сама предлагает докачать файл ?
У меня не получилось :((
Лицензию выслал на мыло
Спасибо, сейчас заберу.
|
|
|
Дата: 14 Дек 2007 14:06:19
#
RU2FV
Важен результат
Для меня он не важен до тех пор, пока в этих модах не появится возможность устанавливать линкованный канал. :)
Тесты я делал как и микрофонно-динамиковые в комнате, так и в реальном эфире. На то время MT63 был хорош, не спорю... У меня тогда был еще самодельный трансивер и ессно у него частота имела свойства подплывать - вот это и было смертью для MT63 - он тут же терял синхронизацию, а пока восстанавливал, то тералась довольно большая часть инфо. Позже появился режим Olivia который обладал не худшей устойчивостью, а еще и широким выбором скоростей и кол-ва тонов, кроме этого, была отличная AFC (АПЧ) которая легко захватывала уход частоты и я мог спокойно работать даже на своих дровах...
- если потеря синхронизации происходит в начале болльшого кадра, то остальной прием игнорируется (судя по умершему индикатору приема). Тут логичней продолжать попытки синхронизации и складывать принятые куски, затем запрашивать недостающие из этого кадра.
Dmitry_D2D
Я тут полностью согласен с товарищем из 2го района - нужно вводить так называемую MEMORY-ARQ, чтобы из нескольких битых кадров "склеивать" один хороший...
Режим основан на последовательностях Уолша, и по проведенным тестам обеспечивает устойчивую работу на ОСШ до -5 дБ.
Скорость режима 300 бит/сек.
Думаю, в ближайших версиях мы его прикрутим к основной программе.
ОК :)
|
|
|
Дата: 14 Дек 2007 14:44:53 · Поправил: RU2FV (14 Дек 2007 15:00:11)
#
to Dmitry
Спасибо за лицензию, получил.
Пауза не длинная и не короткая, она именно такая, сколько нужно другой стороне, чтобы передать подтверждение (квитанцию). Если даже квитанция не опознана, она вре равно есть (другая сторона ее всегда передает), поэтому нужно дать ей на это время. Вот это время и выжидается, причем ровно столько (ну, или на 1-2 секунды больше), чем ушло бы времени на реальный прием квитанции.
Это в теории, а на практике совсем др картина ;))
Специально засек время от ОКОНЧАНИЯ передачи квитанции (которое не принято на передающей стороне) и до повторныхъ попыток, оно сост примерно 35 секунд. Если сюда прибавить время передачи самой квитанции, которая в итоге не принята, то набегает 40 сек простоя, это слишком много :((
Или у меня что-то не так работает ?
Добавлю, что это происходит при передаче файла. В чате реагирует по другому.
|
|
|
Дата: 14 Дек 2007 17:04:05
#
Dmitry_D2D
Собственно, какая у вас версия программы?
И, кстати, RU2FV - ваш позывной?
Если да, то вышлю бета-лицензию (для проверки всех возможностей).
Версия 052, RU2FV-позывной, за лицензию буду благодарен.
Узбекистан возете в "тестеры"?
Два желающих - UK8ADI и UK8AKK ,версию взяли 052.
До этого скачивал предидущие версии ,только пробовать особо не с кем было ,а на днях уговорил знакомого ,попробовали - понравилось.
Виктор UK8AKK сейчас много работает разными цифр.режимами ,а меня привлекает все новое и интерестное.
Для того ,чтоб понять и попробовать.
Работал с модемами Packet-300HF,1200VHF ;PACTOR-I,II ;HALL CLOVER ;Mix-W все режимы ;PC-ALE , ну и по работе с CODAN модемами.
|
|
|
Дата: 14 Дек 2007 17:10:13 · Поправил: tigra (14 Дек 2007 17:13:16)
#
Пардон!
P.S.
Вчера пробовали на УКВ и на КВ на нижних диапазонах(3,5 и 7МГц) - очень даже "Гуд" !!!
Мощности на наших 706-ых были убраны в "1"(ватт пять,если не ошибаюсь) ,помеховая обстановка в городе сами знаете какая.
Я корреспондента еще слышал (ушами) а он меня нет - работало.Причем по ошибке я работал на высокочастотной антенне 14МГц :-).
|
|
|
Дата: 15 Дек 2007 12:48:40 · Поправил: Dmitry_D2D (15 Дек 2007 12:55:06)
#
RU2FV
Это в теории, а на практике совсем др картина ;))
Специально засек время от ОКОНЧАНИЯ передачи квитанции (которое не принято на передающей стороне) и до повторныхъ попыток, оно сост примерно 35 секунд. Если сюда прибавить время передачи самой квитанции, которая в итоге не принята, то набегает 40 сек простоя, это слишком много :((
Или у меня что-то не так работает ?
Похоже, действительно что-то не так.
ТАК точно не должно работать.
Пожалуйста, болшая просьба - подробно описать, как проводите тесты.
Интересует все - на каких компах (или на каком) все запущено,
как настроены Upload/Download каталоги (если запущено на одном компе, то это очень важно),
как запускаете передачу файла и какой длины (это важно), и подробно - как именно
имитируете пропадание квитанции.
Ну не должно там быть ТАКОЙ паузы - после теоретического окончания квитанции должно проходить ну не более 5 секунд.
Хотя, постойте... Есть один вариант...
Ситуация, описиваемая вами, теоретически может возникнуть в таком случае -
если для теста вы берете маленький файл, для передачи которого генерируется сигнал
с длиной, меньшей чем максимально возможная длина (ну, плюс этот же эффект возникает
при передаче последней порции файла, которая, естественно, то же меньше максимальной длины).
Если у вас именно эта ситуация, то модем ведет себя так, как нужно.
Там все дело в механизме выдерживания паузы. Это механизм по умолчанию рассчитан на передачу
максимальных порций. А также, он постоянно подстраивает паузу по принимаемым квитанциям.
А вот если квитанции не принято - то, естественно, выжидается максимальный тайминг.
Сделать так есть свои причины, подробнее долго объяснять.
Но, повторюсь еще раз, такая ситуация возникает ТОЛЬКО при пропадании квитанции во время передачи маленьких порций (это маленькие файлы и окончание файла). А поскольку модем рассчитан в первую очередь на передачу БОЛЬШИХ порций, то этот небольшой недостаток проявляется достаточно редко.
Ведь максимальная порция как раз и длится 45 - 50 секунд - как раз столько, сколько модем и выжидает.
Вы попробуйте убрать квитанцию в середине передачи достаточно большого (> 100 Kb) файла - описываемой паузы вы не увидите даже в случае пропадания квитанции.
И, как бы там ни было, даже при таком эффекте модемы НЕ ДОЛЖНЫ после этого начинать передачу ОДНОВРЕМЕННО, время паузы специально рассчитано на это.
Если же они все-таки начинают передачу одновременно, то это точно КОСЯК...
И если по вашим тестам найдем его - офигенное вам спасибо... :)))
tigra
Узбекистан возете в "тестеры"?
Два желающих - UK8ADI и UK8AKK ,версию взяли 052.
Возьму с удовольствием, но укажите мыло - куда лицензии выслать... :)))
|
|
|
Дата: 15 Дек 2007 12:55:38
#
uk8adi (dog) mail.ru
uk8akk (dog) yandex.ru
|
|
|
Дата: 15 Дек 2007 13:00:10
#
Виктор в данный момент работает на 14109!!!
|
|
|
Дата: 15 Дек 2007 13:03:51
#
tigra
Выслал на оба адреса, ловите... :)))
|
|
|
Дата: 15 Дек 2007 13:06:26
#
Увидел!
Сейчас возьму ,спасибо!
Я на работе ,а Виктор UK8Akk - 14,109 :
From 'UK8AKK' to 'RV9DH':
Channel status, S/N: 21 dB
Chat packet: тавим!
Info packet(s), mode 2666 long
|
|
|
Дата: 15 Дек 2007 13:09:43
#
Дмитрий ,а как со сканированием каналов?
Или я чего-то пропустил?
|
|
|
Дата: 15 Дек 2007 13:16:31
#
tigra
Дмитрий ,а как со сканированием каналов?
Или я чего-то пропустил?
А никак пока. RFSM не сканирует каналы - в нем нет возможности управлять частотой трансивера.
И, кстати, нужно ведь не просто сканирование, а проверка прохождения на канале и выбор оптимального.
Вы наверно это имели в виду? Незнаю, правда, где радиолюбители найдут столько доступных частот,
чтобы полноценно использовать этот механизм. Ну да ладно, это ведь не мои проблемы... :)))
В любом случае, это уже задумано, будет реализовано позднее.
|
|
|
Дата: 15 Дек 2007 13:17:12
#
На 14109 From UK8AKK слышу естественно без проблем (в одном городе) а вот RV9DH - нет :-( .
Аппаратура у меня под рукой ТК-80 + антенный тюнер SGC-239 + длинный провод(другой нет).
|
|
|
Дата: 15 Дек 2007 13:32:07
#
RFSM не сканирует каналы - в нем нет возможности управлять частотой трансивера.
Для управления передачей есть возможность использовать CAT команты через КОМ-порт ,значит возможность такая может появИться ?
И, кстати, нужно ведь не просто сканирование, а проверка прохождения на канале и выбор оптимального.
Механизм ALE ил CALM(Кодан) слепо копировать ,наверное не обязательно ,Пактор-2 тоже работает со сканированием каналов ,но как оно справляется с качеством линии в Пакторе - этого я не в курсе!
Незнаю, правда, где радиолюбители найдут столько доступных частот,
Ну ,если поискать ,то найти можно ,сети Пактор да и АЛЕ в любительском эфире встречаются часто!
|
|
|
Дата: 15 Дек 2007 14:07:40 · Поправил: tigra (15 Дек 2007 14:22:56)
#
Сканирование в варианте для любительских приложений ,может и не очень обязательно ,но для профи - обязательно и очень! (это мое личное мнение)
При наличии нескольких каналов в разных диапазонах (а это для КВ "производственная необходимость") вручную постоянно переключать с канала на канал - не эргономично ,рутинно.
Особенно в переходное время ,кодна на одном канале уже плохо ,а на другом еще плохо...
Для примера в программе PC-ALE предусмотрен список каналов и сканирование .
 |
|
|
Дата: 15 Дек 2007 14:20:56
#
tigra
Сканирование в варианте для любительских приложений ,может и не очень обязательно ,но для профи - обязательно и очень! (это мое личное мнение)
Так с этим никто и не спорит... :)))
|
|
|
Дата: 15 Дек 2007 14:27:56
#
Дк ,я не спорю!
Я так ,мысли вслух....
Спасибо за файлы ,ребята уже пробовали ,слышал...
Сам смогу только вечером сегодня и завтра днем ,может быть.
Если получится на работе днемна 14 МГЦ ,постараюсь!
|
|
|
Дата: 15 Дек 2007 14:59:50
#
Dmitry_D2DИ, кстати, нужно ведь не просто сканирование, а проверка прохождения на канале и выбор оптимального.
Не обязательно. На то мы и радиолюбители, чтобы знать где куда есть прохождение ;) Хочется чтобы просто серверный RFSM мог на прием работать в режиме сканирования на нескольких частотах (диапазонах), скажем, слушал по 30 секунд на каждом канале вызывающих, и если кто-то вызвал, то просто выключал сканирование и отвечал на конект того, кто вызывал. Когда абонет отсоединился, RFSM снова по кругу сканировал свои частоты в поисках новой "жертвы" ;) Не более.
|
|
|
Дата: 15 Дек 2007 19:51:24 · Поправил: Dmitry_D2D (15 Дек 2007 19:52:29)
#
Zmej
Не обязательно. На то мы и радиолюбители, чтобы знать где куда есть прохождение ;) Хочется чтобы просто серверный RFSM мог на прием работать в режиме сканирования на нескольких частотах (диапазонах), скажем, слушал по 30 секунд на каждом канале вызывающих, и если кто-то вызвал, то просто выключал сканирование и отвечал на конект того, кто вызывал. Когда абонет отсоединился, RFSM снова по кругу сканировал свои частоты в поисках новой "жертвы" ;) Не более.
Вот теперь я вас понял. Вы, оказывается, совсем не то сканирование имеете в виду. :)
То, что вы описываете - это будут функции модуля "Расписание."
В нем можно будет по времени или с заданной периодичностью выполнять определенные действия, например, переходить на другую частоту, переключаться на другую звуковую карту, и так далее - на сколько фантазии хватит. Такие просьбы к нам уже поступали, и мы их уже запланировали...
А я то имел в виду другое сканирование, настоящее, а именно функции, подобные ALE, CALM, и т.д. - то есть направленные на поиск оптимальной частоты для установления соединения.
Причем, естественно, такие действия сервер выполняет не самостоятельно, а в паре с тем, кто желает установить с ним линк...
Это совсем другая песня, но и такое уже запланировано... :)
|
Реклама
Google |
|
