bg7yoz
commented
10 months ago hi，@Nimesis89
这是一个非常巧合的哈希值冲突的问题，SP9VRY的哈希值与OE8OK的哈希值相同。
我们来分析一下这个问题的成因：
1.当个FT8消息带有非标准呼号时，在FT8有限的77位消息中无法表示全部的信息。关于呼号，很有可能会用哈希值来表示。当消息中的呼号是哈希值时，按照FT8协议，应用程序应当从历史记录中寻找哈希值与呼号的映射，如果有找这个哈希值映射的呼号，则显示呼号，用<呼号>表示，如果没有找到映射的呼号，用<...>表示。
2.您使用的呼号时UB3BAE/3，在FT8协议中，这个呼号属于非标准呼号。对于消息UB3BAE/3 <OE8OK> RR73，是SP9VRY呼叫您的消息。在消息中，您的呼号（UB3BAE/3）占用了58位信息，呼叫方SP9VRY只能使用12位的哈希值表示，SP9VRY的12位哈希值是0x38C。
3.当FT8CN接收到消息UB3BAE/3 <OE8OK> RR73时，它实际上是接收到的是您的呼号名+哈希值+RR73，FT8CN会从历史接收到的呼号哈希表中查找，如果找到，就使用该呼号。SP9VRY的哈希值是0x38C，而OE8OK的哈希值也是0x38C！
4.在您打开FT8CN后，接收过的消息中应该是有呼号OE8OK出现过，FT8CN已经把这个呼号的哈希值记录下来了。当UB3BAE/3 <OE8OK> RR73出现时，FT8CN在查找哈希值与呼号映射时，找到的是OE8OK，而不是SP9VRY。
5.如果您打开了“Save Decoded”，您可以查询一下SWL Messages，看是否有OE8OK出现过。
以上，FT8CN还有需要改进的地方：当呼号哈希值冲突时，应当保存最新的呼号与哈希值映射。
这个回答希望对您又帮助。
BG7YOZ
The call sign was transformed during the operation of the program.
I didn't work with the call sign OE8OK. This call sign did not appear on the air at all.