@UA3DJY
Тоже экспериментировали с Игорем на 80ке. Он звал OH2DB вместо RC3C. Видимо хэш совпадает с моим.
оригинал https://www.youtube.com/watch?v=j5NIReQdu3I
@UA3DJY
Тоже экспериментировали с Игорем на 80ке. Он звал OH2DB вместо RC3C. Видимо хэш совпадает с моим.
оригинал https://www.youtube.com/watch?v=j5NIReQdu3I
UA3DJY , Игорь, добрый день ! Хочу вас поблагодарить за ваш труд по разработке и совершенствовании программы JTDX. Я очень доволен работой вашей программы JTDX- во всех отношениях и по комфорту, быстродействию, удобству работы , качеству декодирования и многим другим показателям. Давно пользуюсь вашей программой ( использую среднего качества ноутбук- четырехядерный процессор с частотой 2,42 ГГц и оперативки всего 2 ГВ). Сейчас у меня последняя версия rc 128- работает как часики - нареканий никаких нет. Работаю ею как на КВ так и на УКВ (144,432, 1296). При работе FT8 и JT65 она превосходит по многим параметрам и удобству в работе WSJTx и MSHV. Единственное неудобство-иногда на 144 МГц и 432 МГЦ приходиться работать модами JT65B ,JT65C , а в JTDX таких мод нет и приходиться переходить на WSJTx или MSHV. А можно ли в последующих версиях ввести возможность работать этими модами или это сложно и не нужно поскольку основная масса радиолюбителей ( я думаю процентов 90) использует ее на КВ. С уважением Анатолий.
Работа с хэш таблицей встроена в модуль упаковки/распаковки сообщений протокола FT8 v2. До тех пор пока команда WSJT не выпустит новую версию WSJT-X, где при использовании хэш таблицы будет учитываться содержимое окна DX Call, пользователи будут иногда видеть ассоциированные из хэш таблицы чужие позывные как в декодированных так и в передаваемых сообщениях во время проведения QSO. JTDX поправим сразу как появится решение этой проблемы в WSJT-X.
Оказались от поддержки JT65B JT65C в JTDX из-за того что для EME УКВ связи используется другой алгоритм автоподстройки частоты по сравнению с JT65 на КВ, используя КВ алгоритм получается посредственный результат в декодировании, а добавлять поддержку второго алгоритма автоподстройки не работая на УКВ и имея ограниченные ресурсы мы не видели смысла. В результате JT65B и JT65C полностью убрали из кода JTDX.
Вот как показывает страну GM4SQM rc123:
Возможно Вы используете свою версию файла cty.dat в папке с логом JTDX? Тогда просто удалите файл cty.dat и rc123 для этого позывного будет показывать правильное название страны.
UA3DJY, Игорь , понятно. Спасибо. Удачи вам.
Новые символы с учетом LoTW: JTDX Russian - JTDX v2.0.1-rc124 (12.01.2019)
Здесь управление списком позывных LoTW: JTDX Russian - JTDX v2.0.1-rc123 (08.01.2019)
UA3DJY, Игорь, в меню частот для jt65a указана частота 3570.0, правильно же 3576.0?
Не смогу:
Вложение 227879
Так что делать-то прикажете: обрабатывать этот байт, или игнорировать? JTDX в нем хоть что-то осмысленное передает?
Доброго вечера всем! Вопрос только к специалистам или с большим практическим опытом. Программа MSHV, настройки звука.
На что и как влияют изменения указанных параметров(каждый в отдельности) в большую или меньшую сторону. Как правильно подобрать оптимальные параметры? В JTDX таких настроек, кроме задержки, вроде нет, нужны ли такие настройки в JTDX, будут ли они полезны?
WSJT-X и JTDX на передачу не используют DirectSound https://ru.wikipedia.org/wiki/DirectSound , размер буфера звукового потока идущего на передачу определяет время затрачиваемое на смену сообщения во время передачи и снижает вероятность прерывания этого потока при высокой загрузке CPU, этот и параметры обработки входящего звукового потока если их настройка не оговорена в хелпе программы лучше не трогать.
Скорость измерителя уровня может определять количество выборок в интервале времени, тоже следует искать в хелпе программы.
PS настройка 'Задержка звука' расположена в блоке настроек RX звукового потока, возможно что эта настройка не имеет ничего общего с задержкой подачи звука на передачу используемой для защиты контактов реле.
Ну, и где здесь описание этих двух байтов? Хотя бы номер строчки скажите...Код:void MainWindow::postDecode (bool is_new, QString const& message)
{
auto const& decode = message.trimmed ();
auto const& parts = decode.left (22).split (' ', QString::SkipEmptyParts);
if (parts.size () >= 5) {
auto has_seconds = parts[0].size () > 4;
m_messageClient->decode (is_new
, QTime::fromString (parts[0], has_seconds ? "hhmmss" : "hhmm")
, parts[1].toInt ()
, parts[2].toFloat (), parts[3].toUInt (), parts[4]
, decode.mid (has_seconds ? 23 : 21, 21)
, QChar {'*'} == decode.mid (has_seconds ? 23 + 22 : 21 + 22, 1)
, m_diskData);
}
}
Это неправда. Чтобы ответить на этот вопрос, не надо пытаться "проникнуть в мои замыслы". Достаточно просто сказать - знаете ли Вы назначение этих двух байтов? Допускаю, что НЕ знаете. Вы не отчаивайтесь, это не фатально... ну, не знаете... подумаешь! :-) Может быть, Вы этот код не только не писали, но и не читали...