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

Цитата:

---

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

Ещё замечал, зову MSHV станцию, работает в два потока. Когда станция переходит в режим одного потока - мне рапорт прилетает со второго потока, которого уже нет :grin:
Но не всегда -26, бывают и лучше рапорта. И шанс поймать такой "рапорт" выше, когда нажата кнопочка AGCc. В моём трансивере увы АРУ нельзя отключить. Выкручиваю усиление до минимума.
И лучше бы сделать отключаемым этот "предсказатель". Везде он отключается, а в JTDX нет.

Арво, тестовая версия rc8-d3 отличается только лишь включенной записью в log debug информации? Есть другие отличия от разосланной rc8?

---

AGCc button has 2 meanings
1. AGC control ( when jtdx see that he is able to control agc gain ( button has gain number))
2. AGC compensation ( button not has numbers) now active button instruct decoder to try programmatically remove some gain changes what rigs agc has done.

have You try’d set QSO Rx freq sensitivity to low? At least for me it removes all -26 decodes. But sure also some sometimes valueable decodes for QSO.
Next is to try decrease overall sensitivity of decoder.

d2 and d3 versions have difference only in debug logging.

Арво, да, уменьшал чутье. Но это не особо помогло. Ложные декоды случались по прежнему.

Арво, в d3 версии JTDX я случайно обнаружил одну фичу - случайно на клавиатуре нажал какую-то комбинацию клавиш и на водопаде у курсора приема появилась шторка ограничения полосы пропускания по приему около 150гц как у программы MSHV и она привязана к курсору приема, очень удобно когда охота за DX, но как этот фильтр выключить так и не нашел! Убрал только переустановкой программы.

Цитата:

---

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

Арво, в d3 версии JTDX я случайно обнаружил одну фичу - случайно на клавиатуре нажал какую-то комбинацию клавиш и на водопаде у курсора приема появилась шторка ограничения полосы пропускания по приему около 150гц как у программы MSHV и она привязана к курсору приема, очень удобно когда охота за DX, но как этот фильтр выключить так и не нашел! Убрал только переустановкой программы.

---

Там где все кнопки большие, есть кнопка "Фильтр", под кнопкой SWL-режим. При нажатии происходит то, что Вы написали про шторку. Кстати, она при нажатии, вроде должна изменить свой цвет. Проверил. Да, зеленеет. И "шторка" по приему имеется. Выключается повторным нажатием.

Цитата:

---

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

...
General rule, -26 decodes should be rare if not to say very rare. It depends mainly of qrm situation in qth. 1. To try is set QSO Rx freq sensitivity to low. If remember correctly medium is default there. It is normal for good qth qrm cases. In city environment often needed to but low there. Vice versa I can use with TCI and sunsdr2dx high there, despite living in Tallinn. ( ok I have relative quiet environment here). With FT-847 I can’t use high, to much -25 -26 decodes, but can use medium. Same environment same antennas, so there many aspects. Everyone should find own solution. Also needed to find out best audio input level.
Everyone should find best decoder settings for own environment. There 2 aspects, computer power and qrm.
I agree that getting “wrong” decodes is wired, but always need to decide, which is better is to get sometimes wrong decode or not get decodes at all.
...

---

Hi Arvo. First thanks for supporting JTDX project. Below are a few notes about false decodes.

For years I have been using WSJT-X and JTDX programs and I myself and many users were observing this False decodes problem. I can see that WSJT-X developers were trying to solve it but it is still there.

The thing is WSJT-X and JTDX engines are used by many RBN Ops now to provide FT8/FT4 spots through RBN and there is no one (no operator) to reject false decoded messages. As a result false decodes (about 0.5% of all decoded messages) are spread via RBN to thousands of operators.

I think there is relatively simple and effective solution for this problem (false decoding). Being part of development team of N1MM Logger+ I spent some time trying to filter them out when decoded messages are coming from WSJTX/JTDX to N1MM Logger+ and it seems to work well. It works for me in my computers for at least one year now and I am very satisfied with it.

I tried to convince Alex Ranaldi W2AXR (the author of CWSL_DIGI that is using WSJT-X engine for decoding digital modes and sending decoded messages to spotting networks) and also Philip Gladstone (pskreporter.info) to use my algorithm for filtering false decoded messages but they both suggested doing it at the source of decoded information. And I agree with them a 100%.

I believe my methods of false decoding filtering are relatively simple and effective. The idea is to use these 2 simple methods described below. I implemented them in my special version of N1MM Logger+ and use it for about 1 year now.
1. Filter1: for messages like <xxx Callsign Grid> if the country of this caller does not match the Grid (actually the Field, i.e. the first 2 letters of the Grid) I reject this callsign for the first time only but store it in the memory. If it comes in again I will let it go through even though it has wrong Grid (it could be because of operator typo in his Grid). I made special file that has all possible Fields for every DXCC country that helps me quickly filter out false decodes. So in the worst case scenario (it is some new DX station not covered in my Country_to _Field.txt file) the first decoded call of this station will be delayed for one cycle only. The vast majority of fake Callsign + Grid combinations will be rejected by this filter.
Here is a sample of information in my Cty_Field.txt file (DXCC country -> 2 letters Fields) that is used for Filter1:
…
A7 LL
A9 LL
AP ML,MM
BY ON,OM,OL,NN,NM,PN,PM,PL,OK
BS7 OK
BV PL
BV9P OL
C2 OL
C3 JN
C5 IK
C6 FL
C9 KH,KG
CE FD,FE,FF,FG,FH
CE0Y DG
…
These are false decodes that will be blocked by filter1:

Вложение 369975

2. Filter2: for all other messages that do not have Callsign + Grid combination (for example if type 2 compound callsign in CQ messages is used) the message does not have the Grid in it and that does not allow me to use method 1. In this case I use the fact that many of those fake callsigns are unique. I check if this callsign is in the file of previously heard stations and if it is there I consider this decoded message valid. If the callsign is not there (was never heard before) I just add it to the file for the future. If this callsign shows up again in the next cycle(s) it will be found in the list of heard callsigns and this decoded message will be considered valid. The file with callsigns that were heard on the bands can be prepared ahead of program start and can be constantly updated with new callsigns received. Or (that is what I do) it can be started fresh when program starts. In this case all decoded messages with “suspicious” callsigns that were not validated by the first stage filter (Filter1,see description above) will be delayed by one cycle. I other words they will show up on the screen in 30 (FT8) or 15 (FT4) seconds if validated. I understand that for some users this delay maybe unacceptable so this filter can be made as optional.
To prevent holding up decoded messages with good known callsigns from delaying for one first cycle we could make a file with known good callssigns (including type 2 compound callsigns) in it. Perhaps we could use Philip’s data (pskreporter.info). The simple rule to keep some callsigns in that file will be – it should be reported to the PskReporter > 1 times for the period of last few days regardless of the band (FT8/4 modes only). The algorithm for sorting out PskReporter raw file will be: 1. remove all unique (most likely false) callsigns; 2. merge all duplicate callsigns in to one line.
As I mentioned before I am using these filters with my version of N1MM Logger+ for about 1 year now and it worked very well so far. I do not have the list of “good” calls for filter2 yet, I just delay every new callsign (not validated by filter1 and not stored in the computer memory yet) for one first cycle. It still works well for me but I could just collect those calls for a few last days into a file that can be automatically loaded upon logger start.
If these filters are implemented into WSJTX (may be as an option selectable by the user) I would think the decode algorithm could be adjusted to be even more sensitive without fear to get too many false decodes. That way we could get already excellent program even better.
This idea was discussed with Reino OH3MA about a year ago and he rejected this approach for solving false decoding problem. His argument was – this method may hide really weak signals that are decoded with errors and may look like false decodes. I think this can be true for UHF/VHF/EME bands but for HF my idea of filters described above should work well and finally remove ~90% of false decodes for many WSJT-X/JTDX users and all spots sent to RBN or PSKReporter.

If you think this can be implemented in JTDX (at least Filter1). I will be glad to share more details on it with you so you can decide to use it or not. Let me know if you are interested.

(SRI for English, если кого-то интересует перевод, дайте знать личным сообщением здесь на qrz.ru или на na3m{at}arrl.net)

Tnx Nic for info
JTDX does not have problem with wrong grid, jtdx has own method of checking call and grid.
1. for ap mask decodes filter check data against data from ALLCALL.TXT
2. additionally grid should belong to callsign dxcc list of grids.
problematic are only report messages or calling messages without grid.
False filtering is improving all the time.
As is also improving decoder all the time.
on 30.04 I got my new best decodes count:
https://dino2.ddns.net/jtdx/250430193138.png

Обнаружил в WSJT-X Improved 2.8 фичу: Если в фильтрах поставить птички на скрытие EU или AS, то он их не только скрывает, но и игнорирует вызовы с этих континентов!
Ванильный WSJT-X и JTDX всегда отвечают! За MSHV вот не скажу, использую MSHV в основном для MS QSO.



Вот так у меня настроено.

Цитата:

---

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

Обнаружил в WSJT-X Improved 2.8 фичу:

---

Аркадий поприветствую !
В настройках JTDX есть полезная фича.

Вложение 370011

А в WSJT-X возможен какой вариант ?

Только в Improved версии!

Цитата:

---

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

Только в Improved версии!

---

Тут как в телеграмме : Словам тесно, а мыслям просторно. (шатка !)
Если можно, то по подробнее; т.к. с этой прогой я не особо дружу.

Цитата:

---

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

Только в Improved версии!

---

Так и не работает 2.8 improved у меня. Что кандидаты, что релиз :s9: Видимо не дружит с Омнириг? От Омнириг не откажусь, уж очень хорошо связка Омнириг, 2.7 improved и лога работает. Что такого критичного в 2.8 сделали, что все сломалось?

wsjtx-2.8.0-win64_improved_PLUS_250524

https://l.sourceforge.net/f/a/f0WY6i...bgsNZSP7YKqw~~

Что за ссылка у Вас длинная? Вот прямая ссылка на загрузку файла: https://sourceforge.net/projects/wsj...4.exe/download

Впервые такой странный декод встречаю:

Вложение 370053

Это Z68YL так декодируется.

Цитата:

---

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

Впервые такой странный декод встречаю:

Вложение 370053

Это Z68YL так декодируется.

---

1. try newer jtdx.
2. try to record wav and send me by email.

this should be jtdx-s fault, but not sure it still there, since rc 3 a lot is changed.