Bill and Joe, As a summary for readers I have identified that MANY false decodes being observed were observed ESPECIALLY using the “flipping” of the bits that results in a /R. Subsequently there has also been a bit of chatter re field days etc. and the use of non-standard suffixes even in the few hours that I have been sleeping.
The intent of prefixes and suffixes is to satisfy overseas “reciprocal” and “local” short-term operating rights primarily i.e VK1/K1JT (operating short-term in Australian Capital Territory) … though it is more difficult with some region specifiers now dropped internationally. Likewise there are “standard aceepted” suffixes recommended internationally to indicate operation away from nominated base that many regulators accept and require: with the main suffixes being /mobile, /portable, /aeronautical mobile and /maritime mobile (accepted as /m, /p, /am and /mm in the CW/Digital world). There are explosions of bastardisations of agreed callsign structures, callsign templates and “special calls” that create problems and issues generally (i.e. The VK F-call template). Additional suffixes such as /R that are RARELY used are NON STANDARD; in fact such suffixes may not be acceptable to regulators here in VK and in EU. AP Mode is a necessary fact of life for those of us in far-away places; many-many discussions on these forums refer to RR/73 loops. AP modes are a necessity to complete many transactions. It is more than highly annoying when you are following all recommended operational parameters - watch the automation pick out a false decode – and then to have to spring into action which does not necessarily look good to other operators observing your QSOs….. Unnecessary noise, chatter resultant QRM etc. In response to this issue and the recognition that the /R switch is being observed with MANY MANY false decodes, would it not be in order to apply mitigation strategies? I am seeing quite a number of posts re false decodes or potential bug reports before they head here as some have fear of how they will be received. I say to all POST as they need to know ! “The good, the bad and the ugly” must be reported ! I foresee that the “mitigation strategy” that would best suit the vast numbers of us that rely on AP modes to complete transactions – that would also fit logic and processing and performance requirements - would be to employ a hash table of acceptable “standard” suffixes . This hash table should loaded from the wsjtx.ini at load time and decodes checked against this. If it is not in the table its rejected by QSO-processing logic as being valid and therefore is not subject to the automated handling. For those that do use non-standard suffixes an option, not checked as default, may be in order to allow “non-standard suffixes” through the automated procedure. I’ll keep sending these false decodes through when observed as we know (and both of you have said to others in private messages) that false decodes of any form that can be reproduced are extremely valuable. 73, and keep up the amazing work ! Steve I VK3VM / VK3SIR
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
