проект WSJT-X: моды JT65,JT9,WSPR,JT4,JTMS,MSHV - работа с тестовым софтом

[RA3QH]

Правильно, давайте "забаним" друг друга и у кого менее 2Мвт на выходе, а то только Р140 на выходе- это не серьезно!

причем тут мощность....зовут...даешь оценку ему 00-05 к примеру...а он продолжает не рапорт давать а вызывать и так по 10-15 раз...было не один раз такое...

[RX3ASP]

причем тут мощность....зовут...даешь оценку ему 00-05 к примеру...а он продолжает не рапорт давать а вызывать и так по 10-15 раз...было не один раз такое...

Много чего бывает - программы сырые, обросшие запутанными функционалами, пользователи не все компьютерно-грамотные, помеховая обстановка, опять же разная.
Вот у меня полчаса назад ни с того ни с сего, после перехода на приём в ответе на CQ, перестали декодироваться нечетные интервалы. Только после перезапуска JTDX-77 заработала. Звал меня корреспондент или нет, неизвестно. Может ядра старые, может наводка, может ГуглХром влияет. И что, банить надо сразу?

[UA3DJY]

Много чего бывает - программы сырые, обросшие запутанными функционалами, пользователи не все компьютерно-грамотные, помеховая обстановка, опять же разная.
Вот у меня полчаса назад ни с того ни с сего, после перехода на приём в ответе на CQ, перестали декодироваться нечетные интервалы. Только после перезапуска JTDX-77 заработала. Звал меня корреспондент или нет, неизвестно. Может ядра старые, может наводка, может ГуглХром влияет. И что, банить надо сразу?

просто при таком сбое надо отключить передачу сообщений

[RA3QH]

Много чего бывает - программы сырые, обросшие запутанными функционалами, пользователи не все компьютерно-грамотные, помеховая обстановка, опять же разная.
Вот у меня полчаса назад ни с того ни с сего, после перехода на приём в ответе на CQ, перестали декодироваться нечетные интервалы. Только после перезапуска JTDX-77 заработала. Звал меня корреспондент или нет, неизвестно. Может ядра старые, может наводка, может ГуглХром влияет. И что, банить надо сразу?

так речь идет не о постоянном бане...на текущий момент банить...

[UA3DJY]

Измененный функционал:
- обновлен файл ALLCALL.TXT, в файле 55505 позывных
- добавлено распознавание частоты в декодере для свободных сообщений FT8, отсутствие этого функционала приводило к сбоям в работе фильтра блокировки вывода на экран свободных сообщений и возможным сбоям AutoSeq при обработке свободных сообщений
- свободное сообщение содержащее позывной оператора должно показываться на экране при включенном фильтре блокировки свободных сообщений
- патч устраняющий сбой в определении 'владельца' частоты при смене интервала при передаче сообщения CQ
- патч обработки нестандартных сообщений 73 в AutoSeq
- устранен сбой неправильного использования уведомления красным маркером для сообщения содержащего позывной оператора
- выполнен функционал черного списка, используется в работе AutoSeq

Подробное описание функционала черного списка в приложенном файле.

собранный софт (Windows) https://cloud.mail.ru/public/A95e/5MwAhJ7q2
кодовая сумма JTDX-18.1.0.78-win32.exe
SHA-256: 27D016435066A8636545A404A0FEE38EF8B530CCD33121AC0648DD3417C5975B

исходный код https://cloud.mail.ru/public/D8R7/dmsczQANF
кодовая сумма src18.1.0.78.zip
SHA-256: FAB49F8A2F39B21171B47E303476F1A71601D5C18FC53CB2F6E90F26E7684FBC

Структура файла JTDX.INI такая же как у JTDX v18.1.0.77.

[R0JF]

18.1.0.78 Linux version (compiled in Ubuntu 16.04LTS) from original sources files by UA3DJY

->Скрытый текст<-

Binary only: https://cloud.mail.ru/public/FMLo/ve5wx8cPt
SHA-256: a0bd43c4795d0821d6044b8bcca3972ca719c747fd784d58532bd5df13deaa63

64-bit deb-package: https://cloud.mail.ru/public/EZVe/ahUnsaMvY
SHA-256: 09b57ad5b255385c36d4a148cbfdd13eb76d9c0b67541adf248d86d5cab52363

32-bit deb-package: https://cloud.mail.ru/public/1L9M/XHhu3qbHm
SHA-256: 3702f681ecdfd65bb227165fcf793e183b1b42f93a96a48d3bbea68c8b93e3dd

[RW9WT]

Прошу подсказать, как захватывать дробные позывные целиком.
Связь не получилась:

->Скрытый текст<-

[UA3DJY]

Прошу подсказать, как захватывать дробные позывные целиком.

софт сам обрабатывает дробные позывные - дополнительных действий не требуется, при использовании свободного сообщения учитывайте ограничение протокола в 13 символов

[RK1AT]

Подробное описание функционала черного списка в приложенном файле.

и многократно передает одно и то же сообщение

Для контент-мэсэджей такая передача через механизм свободных сообщений есть норма, через макрос CALL/IMAGE передаётся множество различного контента, функционал автоСQ при этом не используется.

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

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

[UA3DJY]

перевод

->Скрытый текст<-

Всех приветствую,

Привожу выдержки из результатов прошедшего общего тестирования режима DX экспедиции FT8:

- подавляющее большинство участников в режиме 'гончей' работали как ожидалось и согласно инструкции. Я декодировал 190 уникальных позывных во время первого часа работы (2300 UTC, когда я работал в режиме 'лисы' на диапазоне 20м) и 330 уникальных позывных на протяжении 4 часов тестирования. Полагаю что в тестировании приняли участие 400-500 операторов, может больше.

- многосигнальный функционал 'лисы' на тестируемых значениях (количество слотов 3, 4 и 5) работал очень хорошо. Это основная опция функционала и я не вижу препятствий для использования одновременно 5 сигналов, особенно если 'лиса' использует большую мощность.

- за 4 часа тестирования количество внесенных в лог QSO на диапазонах 20, 30, 40 и 80м составило 320, 189, 454 и 351 соответственно. Однако к сожалению дефект в программе не позволял удалять позывные 'гончих' из 'QSO в процессе' списка 'лисы' после внесения QSO в лог.
в результате было передано много повторных сообщений RR73 и много QSO было занесено в лог повторно, и список 'QSO в процессе' продолжал расти. Вследствие этого заняло примерно до 20 минут чтобы завершить некоторые QSO, а также были 'гончие' кто передал рапорт но не получил подтверждающего QSO сообщения RR73.

- AA7A сработал 120 уникальных позывных в час диапазона 40м, другие 'лисы' отработали немного меньшее количество. После исправления дефекта в программе должно быть достижимо 300...400 QSO в час.

- конечно, некоторые 'гончие' не работали как подразумевалось. Несколько операторов пытались получить ответ от 'лисы' передавая сигнал ниже частоты 1000Гц (Большинство из них были из стран не говорящих на английском. Вероятно нам необходимы переводы инструкции по использованию режима DXpedition). Небольшое количество звавших использовали версию программы отличную от 1.9-rc2 и звали 'лису' 'вслепую' на первой последовательности. Несколько 'гончих' пытались использовать дробные позывные, что не поддерживается и должно быть четко сказано в инструкции на использование режима DXpedition.

- почти каждый оператор заметил XE1GK дающего общий вызов внизу диапазона частот 'лисы' и работающего с корреспондентами.
Пожалуйста не вините Ignacio, ясно что он не понял что должно было происходить и как работать во время этих тестов. Он прислал мне свои извинения. В любом случае его сигнал позволил нам оценить насколько хорошо режим DXpedition устойчив к обычным и цифровым помехам.

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

Перечисляю здесь список незначительных дефектов и другие аспекты всплывшие во время тестирования:

- хаотичные предупреждения 'позывной не соответсвует' появлялись на экране у оператора 'лиса'

- окно внесенных в лог QSO у 'лисы' должно автоматически проворачиваться вниз либо должно показывать последние 10 внесенных в лог QSO

- я не уверен правильно ли работал параметр "Max Calls" (максимальное количество вызовов) у 'лисы'

- иногда 'лиса' передавала сообщение RR73 той же станции одновременно в нескольких слотах в одном интервале

- у некоторых операторов 'заклинило' кнопку Decode в состоянии идущего декодирования

- 'гончие' иногда передавали низкий рапорт 'лисе', несмотря на сильный сигнал лисы

- если 'гончая' жмет "Enter" при пустом окне DX Call то в эфир может передаваться пустое сообщение

- если случайная станция (не 'лиса') вызывает 'гончую' это может спровоцировать передачу сообщения 'гончей' как в случае если ее вызвала 'лиса'

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

В итоге позвольте мне привести список нового функционала который мы можем добавить в WSJT-X.

- По крайней мере для диагностики и возможно как опция, окно показывающее оператору 'лиса' содержимое всех активных очередей.

- Ограничить максимальное одновременное количество QSO значением не превышающим количество слотов передачи.

- Опция отключения показа времени интервала на водопаде.

- Сделать обязательным передачу сообщения CQ лисой в одном из слотов по крайней мере каждые одну..две минуты.

- Сделать случайный выбор частоты для Tx3 сообщения 'гончей' при каждом его повторе?

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


-- 73, Joe, K1JT

оригинальное сообщение(английский язык)

->Скрытый текст<-

[wsjt-devel] DXpedition Mode Test Results
From: Joe Taylor <joe@pr...> - 2018-03-07 20:29:31

Hi all,

Here are a few highlights of results from last night's public test of
FT8 DXpedition Mode:

- The overwhelming majority of participating Hounds operated as
intended, and according to instructions. I copied 190 unique Hound
callsigns during the 2300 hour (when I was acting as Fox on 20m) and 330
unique callsigns during the whole four hours. I suppose that we had at
least 400-500 participants, maybe more.

- Fox's multi-signal capability worked very well at the tested values,
NSlots = 3, 4, and 5. This feature is surely a "keeper", and I see no
reason not to use NSlots = 5 -- especially if Fox is running power.

- In the four test hours the number of "QSOs" logged by Foxes on 20,
30, 40, and 80m was 320, 189, 454, and 351. However, a regrettable
program bug was preventing deletion of Hound callsigns from Fox's
"QSO-in-Progress" list after a QSO had been logged. As a result, many
repeated "RR73" messages were sent, many dupe QSOs were logged, and the
QSO-in-Progress list kept growing. As another consequence, some QSOs
took up to ~20 min to complete, and a number of Hounds who had been sent
a report never received their QSO-confirming "RR73".

- AA7A actually worked 120 unique calls in the 40m hour, and the other
Foxes worked comparable slightly lower numbers. When this program bug
is corrected, hourly QSO in the 300-400 range should certainly be
achievable.

- Of course, some Hounds did not operate as intended. Several kept
trying to raise Fox by calling below 1000 Hz. (Most of these that I
noticed were from non-English speaking countries. We will probably need
translations of the FT8 DXpedition Mode User Guide.) A few would-be
Hounds were not obviously not using v1.9.0-rc2, and were calling Fox
"blind" in 1st sequence. A few Hounds tried using compound callsigns,
which is not supported -- and which needs to be made more clear in the
instructions.

- Nearly everybody noticed the XE1GK calling CQ on the low-end Fox
frequency and working people these. Please don't be too hard on
Ignacio: he obviously misunderstood what was supposed to be happening,
and how to operate in the test run. He sent me an abject apology.
Anyway, his signal helped us to evaluate how well we can cope with QRM
and DQRM.

Two operating hints that should be used as needed, but in general were not:

- Hounds should manually reset their Tx frequency as needed to evade QRM.

- Fox may decide to use the randomizing feature to vary his own Tx
frequency.


I list here some relatively minor bugs and other things that came to
light during the test run:

- Spurious "Callsign mismatch" warning messages were displayed to the
Fox operator.

- Fox's log window should automatically scroll to the bottom. Or
maybe it should simply show the most recent ~10 QSOs logged.

- I'm not sure that Fox's "Max Calls" parameter worked as designed.

- Sometimes Fox sent RR73 to the same station in more that one slot,
in the same transmission.

- The dreaded "Blue Decode" button was seen by some.

- Hounds sometimes send a spuriously low signal report to Fox, even
when Fox is loud.

- If Hound hits "Enter" with the DX Call box empty, a blank message
can be transmitted.

- It a random station (not Fox) calls a Hound, it can trigger a Hound
transmission just as if Fox had called.

- Previously decoded Hound calls can sometimes reappear in Fox's left
window, when they should not.


Finally, let me outline a few new features we may decide to implement.

- At least for debugging, and possibly as an option, offer a display
window that shows the Fox operator the contents of all active queues.

- Limit the number of QSOs in progress to no more than NSlots.

- Option to suppress display of the waterfall timestamp.

- Have Fox call CQ in one slot at least once every few (1 or 2?) minutes.

- Should Hound's Tx3 frequency be re-randomized for each repeat try?

I'm sure there is more to be said, but that will do for now. Depending
on programming progress and on my own travel schedule, we may schedule
another public test within a few weeks.

-- 73, Joe, K1JT

[UA3DJY]

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

пользователь определяет самостоятельно и вручную, черный список используется только в работе AutoSeq при автоматическом выборе и автоматической последовательности проведения QSO

[RW9UU]

что-то в крайней версии (78). стал коряво работать переход на передачу т.е. при переходе на на передачу трансивер переходит на передачу, по сигнал не идет. Мощность по показометру НОЛЬ!!. Есть еще у кого такие проблемы?

[RW9UU]

Ну вот опять позвал DL1MAJ - передача не прошла. Выключил всё и ушел смотреть телевизор

[UR4UM]

при переходе на на передачу трансивер переходит на передачу, по сигнал не идет. Мощность по показометру НОЛЬ!!. Есть еще у кого такие проблемы?

Пару раз вчера имел такое-же, хотя и работал мало. Подумалось про 2 секунды, задержки ТХ при переключениях...
Выключил/включил (Enable/Halt) - пошла передача, но секунды утеряны... будет ли декод?

[RW6APC]

что-то в крайней версии (78). стал коряво работать переход на передачу т.е. при переходе на на передачу трансивер переходит на передачу, по сигнал не идет. Мощность по показометру НОЛЬ!!. Есть еще у кого такие проблемы?

Аналогичная ситуация...