Вещаю 3589 LSB.

TEST вызывает WORLD.

Попробуй еще, я только сейчас заметил что QRG 3589.
Следует по конкретнее определиться с частотой.

Сегодня будем тестировать?
Я мониторю на 3.731,5 mHz LSB

ra1amw

Ща запущу. Только диапазон чистый ;) Наверное еще рановато для 80ки.

Вещаю.

Из Норвегии пришло письмо в почту, что получают меня.

у меня GUHOR.
Но диапазон чистый

Rulez Reloaded

То же вижу, но уровень оччень слабый.

ra1amw
SergUA6

Ну чтож, жаль.

А пакеты никто из наших не видит?

Я на 3,731,500 LSB

RN3ZF

И?

Во, это кто был?

Chat packet: kuku

нет, у меня ни какой активности не наблюдается.

ra1amw

Значит мертвяк между нами...

Из монитора пакетов нельзя копировать в буфер!Плохо...

И кто меня видел?

Я Змея слышал.Позовите меня что ли в SSB или BPSK я на 3,731,500.

"kuku" - это мое было ;)

В общем, попробовали с Rulez Reloaded поработать, слышно его неважно у меня, пакеты не все сразу проходили. Он мне залил даже файлик 442 байта длиной, принялся довольно быстро, но почему-то его сторона напорно продолжала передавать, хотя у меня уже файл был. Может быть не мог добиться от меня подтверждаемого пакета или глюк просто?



Автору:
Монитор пакетом конечно корявый...
Хотелось бы такого плана:

WASIA>PETIA Chat packet: ку-ку
PETIA>WASIA Status packet (типа подтверждаю)

И т.д. Тоесть, чтобы было конкретно, кто с кем работает!

И еще: можно ли сделать передачу "широковещательного" пакета, ну для маяка, чтобы не маячить вызовом , а как положенно маяком.

А то было так: Rulez Reloaded был под позывным TEST и давал "бесконечный" Connect к WORLD. А если несколько WORLD-ов будет на частоте - это же каша получится. Нужен какой-то широковещательный пакет чтобы скажем было:

WASIA>ALL : "Маяк Васи Пупкина"

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

Что выдумаете по этому поводу?

Я в конце свой позывной забил - RN3ZF. Ушел на 3,589,000 LSB.Там чисто.

Автору:

Ну, что поработали мы с RN3ZF...

Вроде бы работает, но конечно нужно еще бы поработать с протоколом...

Я так понял, что он передает сразу по очень много пакетов за один раз. Но прохождение в эфире такое, что синхронизация срывается часто - в пустую "дуется" по минуте и более... Хорошо бы, если программа сама будет регулировать кол-во кадров за один пакет, в зависимости от кондиции прохождения. Скорость в основном была 500, иногда 1000 и раз видел 2000, но не долго. Думаю, стоит еще ввести начальную скорось в 200 или 300, и динамическое изменение кол-ва фреймов на пакет - очень желательно.

И еще по просьбе Andy - сделайте в начале каждой передачи коротенькую "преамбулу" в виде среднего тона, скажем 200-250мсек - будет полезно для более простой визуальной настройки и для того, чтобы успевало в трансиверах отработать переключение полностью + АРУ на приемной стороне ( если оно медленное).

Пока все. Ждем новых версий ;)

Все описанное выше поддерживаю!
Как правильно выставить уровень по приему. Где эта полоска за которой дальше ни-ни?
Можно было бы добавить отладочный лог по работе проги.
Что бы разработчик увидел как и в каких условиях тестируется прога.
Мы бы его скидывали в копилку или куда нибуть еще.
Удачи!

Всем БОЛЬШУЩЕЕ спасибо ;) !
Ко всем вопросам прислушался, буду думать.
Не некоторые отвечу чуть попозже.
Версию с предваряющим тоном скоро выложу.

Добавил тон в начале каждого блока - чистая несущая длиной 0,3 сек.
Кроме того, был переработан звуковой "движок" - на радость владельцам карточек
с максимальной частотой 44100 (см. закладку Preferences->Hardware)
Брать тут - http://slil.ru/23429398

Теперь некоторые пояснения по некоторым вопросам :)

1.

Монитор пакетом конечно корявый...
Хотелось бы такого плана:

WASIA>PETIA Chat packet: ку-ку
PETIA>WASIA Status packet (типа подтверждаю)

И т.д. Тоесть, чтобы было конкретно, кто с кем работает!

Получилось так, что не во всех пакетах передаются позывные абонентов.
Конкретно, только в запросах на коннект и в некоторых потдверждениях.
А в основном позывные не передаются для экономии пропускной способности.
Поэтому если двое общаются в режиме чата, то третьему наблюдателю не получится увидеть,
кто с кем болтает, этого просто уже нет в эфире.
Так что тут два выхода: либо ставить дополнительную логику и запоминать
имена абонентов из отмониторенных пакетов коннекта,
либо менять формат пакетов (что хуже, ибо потеря обратной совместимости
и пропускной способности).

Кстати, в буфер обмена сообщения из монитора пакетов копируются,
просто этого нет в pop-up меню, но горячие клавиши-то работают...

2.
И еще: можно ли сделать передачу "широковещательного" пакета, ну для маяка, чтобы не маячить вызовом , а как положенно маяком.

А то было так: Rulez Reloaded был под позывным TEST и давал "бесконечный" Connect к WORLD. А если несколько WORLD-ов будет на частоте - это же каша получится. Нужен какой-то широковещательный пакет чтобы скажем было:

WASIA>ALL : "Маяк Васи Пупкина"

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

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

3.
Я так понял, что он передает сразу по очень много пакетов за один раз. Но прохождение в эфире такое, что синхронизация срывается часто - в пустую "дуется" по минуте и более... Хорошо бы, если программа сама будет регулировать кол-во кадров за один пакет, в зависимости от кондиции прохождения. Скорость в основном была 500, иногда 1000 и раз видел 2000, но не долго. Думаю, стоит еще ввести начальную скорось в 200 или 300, и динамическое изменение кол-ва фреймов на пакет - очень желательно.

Это уже посложнее, так сразу не сделаешь - есть некоторые проблемы :(
Модулятор-то на низкие скорости давно сделан,
но вот корректно все это увязать, да еще и в автомате... Буду думать.


4.
И еще по просьбе Andy - сделайте в начале каждой передачи коротенькую "преамбулу" в виде среднего тона, скажем 200-250мсек - будет полезно для более простой визуальной настройки и для того, чтобы успевало в трансиверах отработать переключение полностью + АРУ на приемной стороне ( если оно медленное).

Ну, это уже добавил ;)

5.
Как правильно выставить уровень по приему. Где эта полоска за которой дальше ни-ни?
Вообще-то, была мысль поставить индикатор уровня, но коллега отговорил - типа, "некрасива",
нарушает целостность дизайна. Но я еще подумаю и таки впендюрю его куды-нибудь
в окно "Tuning..." ;)!
А пока можно ориентироваться только по фазовой диаграмме, хотя, как я понял,
с таким качеством сигнала там хрен поориентируешься ;)

6.
Можно было бы добавить отладочный лог по работе проги.
Что бы разработчик увидел как и в каких условиях тестируется прога.
Мы бы его скидывали в копилку или куда нибуть еще.

Это мысль хорошая, подумаю, как прикрутить...

Ну, вроде все, гуд бай до следующего забега ;)

Упс...

Dmitry_D2D

Я вот что-то не понял с передачей сообщений и файлов.

Нельзя ли там как-то подсвечивать текст, который отправляется (например, посимвольное изменение цвета фона под текстом). И может быть еще как-то дополнительно обозначит текст, который был гарантированно получен (т.е. от оппонента получено подтверждение).

То же самое с файлами. Внизу есть какой-то статус-индикатор, но пока я отправлял файл, он всегда был 0%. Файл Zmej уже получил, но у меня всегда был ноль, а программа сделала еще 3 попытки передачи файла, и собиралась сделать еще, но я ее прервал.

Именно этот случай описал Zmej:

В общем, попробовали с Rulez Reloaded поработать, слышно его неважно у меня, пакеты не все сразу проходили. Он мне залил даже файлик 442 байта длиной, принялся довольно быстро, но почему-то его сторона напорно продолжала передавать, хотя у меня уже файл был. Может быть не мог добиться от меня подтверждаемого пакета или глюк просто?

Программа что-то делает, но что - не очень понятно. Живет своей жизнью, что-то передает (чат из буфера? какое именно сообщение, если их несколько? что уже "улететело" в эфир? чему еще предстоит? и т.д.).

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

На 100% каналах проблема, думаю, так остро не стоит, но на КВ при неустойчивом канале, абонент может получать сообщения с большой задержкой. Вчера при пробах, короткие сообщения в чате по радио проходили с задержками где-то в районе половины минуты по сравнению с ICQ ;)

Rulez Reloaded

Нельзя ли там как-то подсвечивать текст, который отправляется (например, посимвольное изменение цвета фона под текстом). И может быть еще как-то дополнительно обозначит текст, который был гарантированно получен (т.е. от оппонента получено подтверждение).

Тут труба, chat-пакеты отправляются и принимаются вообще без всяких подтверждений.
Я не считал этот режим важным, вот и не стал добавлять на него ARQ.
И, наверное, не добавлю ;)
А вот с обозначением того, какой текст уже был отправлен, а какой еще нет - мысль
дельная, стоит подумать...

То же самое с файлами. Внизу есть какой-то статус-индикатор, но пока я отправлял файл, он всегда был 0%. Файл Zmej уже получил, но у меня всегда был ноль, а программа сделала еще 3 попытки передачи файла, и собиралась сделать еще, но я ее прервал.

А вот тут, похоже, передающий не смог получить подтверждение на то, что передал.
Если бы подтверждение пришло, все бы было ОК - и индикатор, и остановилась бы сама.
А так будет делать 5 (или 10:) попыток, а только потом остановится.

Программа что-то делает, но что - не очень понятно. Живет своей жизнью, что-то передает (чат из буфера? какое именно сообщение, если их несколько? что уже "улететело" в эфир? чему еще предстоит? и т.д.).

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

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

Да я бы и сам этого хотел ;)

На 100% каналах проблема, думаю, так остро не стоит, но на КВ при неустойчивом канале, абонент может получать сообщения с большой задержкой. Вчера при пробах, короткие сообщения в чате по радио проходили с задержками где-то в районе половины минуты по сравнению с ICQ ;)

Вообще, в чат-режиме задержка не должна превышать 15 секунд,
в режиме передачи файлов - задержка на чат в среднем 1 минута ;)

P.S. А понять всю логику довольно просто, если соединить 2 модема напрямую, без эфира... ;)

Я опять зову всех своим позывным - RN3ZF. Ушел на 3,589,000 LSB.Там чисто. Приходите все кто может плиз.

Dmitry_D2D

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

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

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

Еще вопрос по "фазометру" или как он правильно называется, I/Q индикатору: когда шли данные , то на нем горело две снежинки по вертикали, но почему-то нижняя более тускло все время, а если вообще нет на нем точек, значит программа не засинхронизировалась на сигнал, верно? Но почему-то еще бывают такие положения, когда он просто хаотические точки высвенчивает, что это значит? Прокомментируйте пожалуйста...

Мониторю на 3.589