Since Tx5 is can be used for "Free Text", adding any sort of 'callsign check' would be hard to implement as anything can, and often is entered into that message box. The logic would need to be able to distinguish between a valid callsign, and something that LOOKS like a valid callsign but isn't.
Frankly, thread is getting out of hand. The issue that occurred only happens if someone does not use the program properly, which usually means they did not take the time to read the User Guide and the sections that cover this 7.2, and 10.5. https://physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.2.2.html Neil, KN3ILZ On 8/19/2020 7:27 AM, Frode Igland wrote:
Steve, My apologies that I hadn't noticed that Reino had already explained the invalid call sign. I should have read all the messages this morning before I responded to your e-mail. I guess that we may wish that the WSJT-X algorithm for identifying the DXCC entity should have had a checkpoint that the call sign is at all valid (involving at least the prefix and number), prior to identifying the DXCC entity (I guess the current method is to look at the first 2-3 characters after "CQ " from Tx6 or "CQ DX " from Tx5). As this was a case from Tx5, we know the message after "CQ DX " must conform to the special standards required to allow more than 13 characters, or it will be considered free text and truncated beyond 13 characters. As Tx5 obviously did not accept 5CT as a call sign, there must already be some sort of "valid call sign check", at least in that message, otherwise it would have been sent as an ordinary CQ DX message from Tx5 with an untruncated locator. I have no idea whether a general "valid call sign check" to avoid DXCC entity identification of invalid call signs is a simple matter to include, or if it may slow down decoding or have other undesirable effects in WSJT-X. Nor do I know whether a "valid call sign check" is needed, as identifying call signs not conforming to call sign format standards may be something that should be left to the operator's attention and consideration, not the computer's logic. We don't have to automate everything just because it may be possible to do it. I guess Bill, Joe et al. will look into the matter and decide whether this issue makes it to the priority list. 73 Frode LA6VQ ons. 19. aug. 2020 kl. 10:25 skrev Stephen VK3SIR <vk3...@hotmail.com <mailto:vk3...@hotmail.com>>: Frode and The Community-at-large, Yes its invalid – the discussion has clearly identified that and I suspected that at the first post. The community has done a great job in clarifying this not only just for me but also lots of others. No more discussion needed on that subject of the callsign validity forever as it is repetitive and it has been most clearly identified …. WSJT-X has correctly prevented Tx response to the station…. Good Job J But… There is a point that many of you are missing here and that I am trying to get across … So I’ll place this in a container for clarity: -------------------------------------------------------------------------------------------------------------------------- Why has the stream been decoded (good) and the logic allowed it to be identified – displayed - as coming from Morocco (bad)? The station should not display that it has come from Morocco in the first place as the call violates the rules of callsign structures for that DXCC entity. That is the real point I am making here ! -------------------------------------------------------------------------------------------------------------------------- There are many ways that this could be adjusted when the codebase for r2.2.2 is examined with some methods having greater impact than others to the codebase – If this behaviour has not been addressed already with other tweaks that may have entered the codebase > r2.2.2 (which we know is awaiting the Hamlib go). There is no point posting changes to the codebase as it is closed … what I could post may upset something else unknown to me. So therefore we have to post “anomalies identified” and rely on the intelligence of our core development team to consider, rate and implement changes if necessary. Many many many posts of mine have been about refactoring logic to prevent and eliminate false decodes and user confusion. This is a false lead issue reported here created a user confusion issue in a number of stations at the time that contacted me (Remember many of us hunt DX in packs !). I could validate the confusion issue when it presented itself. Therefore I have a responsibility to report the matter to the community !!! Almost all my posts are around improving utility especially for the “learner” and decreasing end-user confusion J 73 Steve I VK3VM / VK3SIR _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
