Кубки РФ по р/связи на КВ 2019

**UA4LCH** · 02.02.2019, 19:35

Сообщение от R3KQ

Коллективки "отметились" две: UF4M и R8IZ. Передают одно... , а в лог пишут номера QSO "рядом"; посмотрел (UBNы) что у них в тот момент творилось... ну 4 QSO в минуту с двух рабочих мест (ран/подбор) ... ... во времена RM3Q мы и с большим темпом (и кол-вом рабочих мест) не путались ..

Потер я запись, а на колективку в лом тащиться.... В тот момент (связь 545) я работал на CQ - захват номера идет в TR4W автоматом - это была вторая связь в этом туре, предыдущая была 544 - то, о чем Вы говорите, просто невозможно. Комп не мог передать неправильно.
Номера не прерываются и все везде правильно и предыдущая и последующие. UF4M. Вы ошиблись при приеме.

**R3KQ** · 02.02.2019, 23:08

Сообщение от UA4LCH

- то, о чем Вы говорите, просто невозможно. Комп не мог передать неправильно.
Номера не прерываются и все везде правильно и предыдущая и последующие. UF4M. Вы ошиблись при приеме.

Да ну? И запись ошибается

Меняйте ...комп

UF4M.wav

Бывает ...

З.Ы. Чуть ошибся в оценке Вашей ситуации в тот момент. Судя по логу, было 3 QSO в первую минуту и два РАНа, на 160 и на 80.

**UA4LCH** · 03.02.2019, 05:40

Сообщение от R3KQ

Да ну? И запись ошибается

Меняйте ...комп

UF4M.wav

Бывает ...

З.Ы. Чуть ошибся в оценке Вашей ситуации в тот момент. Судя по логу, было 3 QSO в первую минуту и два РАНа, на 160 и на 80.

Чудеса. Не понимаю, как это возможно. Стоит задуматься о многочисленных ошибках подобного рода в UBN.... Плюс минус одно QSO то в логе правильны - так это что, получается комп раздал два одинаковых номера?

**RW9DX** · 03.02.2019, 07:04

Сообщение от UA4LCH

Чудеса. Не понимаю, как это возможно. Стоит задуматься о многочисленных ошибках подобного рода в UBN.... Плюс минус одно QSO то в логе правильны - так это что, получается комп раздал два одинаковых номера?

Машина она же "тупая", она не может ошибаться... человеческий фактор.

Алексей, ну здесь два варианта...
1. Если Вы уже ввели связь по ентер в лог и повторно через макросы передаете контрольный номер этому же корреспонденту, которого только что сработали, то этот номер будет на один больше, если в макросах не заведено "номер-1"(это в TR4W), допускаю такой вариант.
2. После того как все-таки связь провели, но не влазите в "резиновые" 2 минуты... номер "подгоняется под "правильное" время... и элементарно корректируется в логе в течение нескольких секунд, как-то так...

**UA4LCH** · 03.02.2019, 09:06

Сообщение от RW9DX

Машина она же "тупая", она не может ошибаться... человеческий фактор.

Алексей, ну здесь два варианта...
1. Если Вы уже ввели связь по ентер в лог и повторно через макросы передаете контрольный номер этому же корреспонденту, которого только что сработали, то этот номер будет на один больше, если в макросах не заведено "номер-1"(это в TR4W), допускаю такой вариант.
2. После того как все-таки связь провели, но не влазите в "резиновые" 2 минуты... номер "подгоняется под "правильное" время... и элементарно корректируется в логе в течение нескольких секунд, как-то так...

На записи слышно, что я оба раза передал один и тот же номер, также слышно, что я дал TU и позывной - при работе на CQ, связь заносится в журнал именно в этот момент. Так как все это происходило в течение первой минуты, то никакой необходимости подгонять что бы то ни было.
Все же я не понимаю, как комп ухитрился это сделать. Номер я повторял кнопкой, связь ввелась только после TU. 544 номер отдало первое место и связь подтвердилась и получается, что я тоже передал 544 - на записи же слышно... Но связь в логе под номером 545.... То есть прога каким то образом два раза повторила номер? И судя по тому, что такого в UBN полно - как то уже начинаешь сомневаться.... Ранее все дружно полагали, что это незахват номера на подборе - но тут то что получилось?
Какие ещё соображения? Эту ерунду надо бы прояснить.

**UA9PM** · 03.02.2019, 09:32

В TR4W такое случается часто ... смоделируйте эту ситуацию по новой и поймёте, в чём дело. У нас такое бывало, причину я ужу забыл. Но дело было не в "бобине".

**R3KQ** · 03.02.2019, 10:01

Сообщение от UA4LCH

Какие ещё соображения? Эту ерунду надо бы прояснить.

Всё дело в секундах, а может быть и в их долях

Может быть у Вас "длинная" сеть между компами? Типа :каждый со своим инетом (и провайдером

)?

**UA4LCH** · 03.02.2019, 10:13

Сообщение от R3KQ

Всё дело в секундах, а может быть и в их долях

Может быть у Вас "длинная" сеть между компами? Типа :каждый со своим инетом (и провайдером

)?

Не знаю. Обычная локалка, компы рядом. Ерунда какая то. Не замечал подобного ранее. Впрочем и не проверял..... ((
Одновременно один номер захватили? Четкая координация движений.... Ладно бы на поиск, там понятно, а так - нет....
Но факт фактом...

**UA4LCH** · 03.02.2019, 10:16

Сообщение от UA9PM

В TR4W такое случается часто ... смоделируйте эту ситуацию по новой и поймёте, в чём дело. У нас такое бывало, причину я ужу забыл. Но дело было не в "бобине".

Часто это случалось и случается когда подбор забывает застолбить номер.

**UA0DM** · 03.02.2019, 10:25

Сообщение от UA4LCH

На записи слышно, что я оба раза передал один и тот же номер, также слышно, что я дал TU и позывной - при работе на CQ, связь заносится в журнал именно в этот момент. Так как все это происходило в течение первой минуты, то никакой необходимости подгонять что бы то ни было.
Все же я не понимаю, как комп ухитрился это сделать. Номер я повторял кнопкой, связь ввелась только после TU. 544 номер отдало первое место и связь подтвердилась и получается, что я тоже передал 544 - на записи же слышно... Но связь в логе под номером 545.... То есть прога каким то образом два раза повторила номер? И судя по тому, что такого в UBN полно - как то уже начинаешь сомневаться.... Ранее все дружно полагали, что это незахват номера на подборе - но тут то что получилось?
Какие ещё соображения? Эту ерунду надо бы прояснить.

Нет захвата номера. Настройка с захватом должна быть на всех компах, а не только на сервере

**UA0DM** · 03.02.2019, 10:27

У меня обратная ситуация получилась. Отдал номер нормально, но корр попросил повторить в это время проведено QSO со подбора и по F2 вылетел номер на единицу больше перебивал вручную, но корреспондент так и не исправил

**UA9PM** · 03.02.2019, 10:29

Сообщение от UA4LCH

Не знаю. Обычная локалка, компы рядом. Ерунда какая то. Не замечал подобного ранее. Впрочем и не проверял..... ((
Одновременно один номер захватили? Четкая координация движений.... Ладно бы на поиск, там понятно, а так - нет....
Но факт фактом...

Обмен идёт через сервер. Задержка есть. Особенно когда идёт обновление "карты диапазонов" и передача информации во внешнюю сеть.

**RW9DX** · 03.02.2019, 10:35

Сообщение от UA4LCH

Часто это случалось и случается когда подбор забывает застолбить номер.

Алексей,
Михаил Иванович уже сказал, что это проблема TR4W и человеческий фактор... ведь в телефонном кубке у Вас таких ошибок практически нет (вернее всего 2).
Попробуйте передать повторно номер станции, которая уже заведена в лог посредством записанного макроса на функциональной клавише и посмотрите, что программа вам передаст. Я думаю, что где-то в этом направлении нужно искать причину. Кстати у многих такие ошибки есть и не только у коллективов...

**R3KQ** · 03.02.2019, 10:36

Сообщение от UA9PM

... Задержка есть. ...

Вот! А для того что бы контролировать эту факинмашину, нам дАдены глаза и уши (в моём варианте: одно ухо

).

**UA9OC** · 03.02.2019, 12:43

Сообщение от UA4LCH

Все же я не понимаю, как комп ухитрился это сделать. Номер я повторял кнопкой, связь ввелась только после TU. 544 номер отдало первое место и связь подтвердилась и получается, что я тоже передал 544 - на записи же слышно... Но связь в логе под номером 545.... То есть прога каким то образом два раза повторила номер?

Может. Там алгоритм заложен (Если в CtrlJ, #12="true")такой - если передаёшь номер по F3 при пустом поле позывного - передаётся номер предыдущей связи. Если в поле позывного есть знаки - будет передан порядковый номер, как бы всё логично. На записи связь с R3KQ у Вас нестандартная, что-то мешало ответить сразу, поработали даже навстречу. Скорее всего, поле позывного заполнялось потом, а при записи в лог "без звука" по Ctrl+ Enter идёт следующий номер... Послушайте Вашу запись, повспоминайте... Я как-то анализировал UBN по TR4W и заметил, что все ошибки "на единицу" на 99% связаны с запросами на повтор номера...