Possibility lost callsign information if both calls use non-standard callsign

[d3m3vilurr]

from #62.

I found a problematic part from FT8Package.java

https://github.com/N0BOY/FT8CN/blob/40d3e95e/ft8cn/app/src/main/java/com/bg7yoz/ft8cn/ft8signal/FT8Package.java#L119-L122

        //当双方都是复合呼号或非标准呼号时（带/的呼号），我的呼号变成标准呼号
        if ((toCall.contains("/")) && fromCall.contains("/")) {
            fromCall = fromCall.substring(0, fromCall.indexOf("/"));
        }

I think here is if both call is non-standard, transform fromCall to std call.

btw, when you trip to another country, local bureau allows temporary callsign such as HL1/BG7YOZ (you can't use BG7YOZ directly in South Korea)

so, if two trip operators communicate each others, HL1/BG7YOZ and HL5/N0BOY, fromCall is only remained HL1.

we have to detect correct callsign pattern, then extract it using regex or specific rules. some weeks ago, I saw similar issues in qlog logger project;

• https://github.com/foldynl/QLog/pull/227
• https://github.com/foldynl/QLog/commit/12dd9f91c9

[bg7yoz]

hi,@d3m3vilurr

关于是否为标准呼号的问题：在FT8CN中所指的非标准呼号，与传统意义上的定义并非一致，在FT8定义的标准呼号，主要是用于标准消息（i3=1），在标准消息中，呼号c28字段用于表示呼号，它只有28位，能表示的呼号数量有限，所以，FT8协议中定义的标准呼号为：一个或两个字符的前缀，其中至少一个必须是字母，后面跟一个十进制数字和最多三个细目的后缀。这些呼号的最大数量为37361027272727=262,177,560个（27和37是因为前三个位置和后三个位置可能缺少字符、字母或数字）。28位数字=268,435,456，剩下的6,257,896个数值用于传输其它信息。比如：CQ（包括CQ修饰符）、QRZ、DE。其余类型的呼号，FT8都定义为非标准呼号，带有"/"的复合呼号（/P和/R后缀例外）也一律定义为非标准呼号。

FT8中非标准呼号与现实中的标准呼号并不冲突，仅仅是表示方式的不同。c28表示不下那么多呼号，当FT8所定义的非标准呼号出现时，FT8协议要用c58字段表示呼号，c58用了58位的数据，您可以看到，如果双方都用58位表示呼号，就超出了FT8的74位的信息长度，只能使用非标准消息（i3=4），非标准消息的格式是：h12 c58 h1 r2 c1，也就是其中一个呼号用12位的哈希值，一个用58位的呼号值。非标准消息，实际上是损失了一些信息的，对方的呼号（只有哈希值，这个要用上下文来推断），没有网格位置信息。HL5/N0BOY消息在FT8中的消息只能表示为: CQ HL5/N0BOY，后面没有网格。

FT8中称呼的标准呼号与非标准呼号，仅仅是用于不同格式的消息，请不要与现实中的定义混淆。这个只是在程序内部的称呼，在实际的GUI上并没有做区分。（但是消息的格式在FT8CN中是标注出来的，而JTDX并没有）。

以上，在FT8协议中有说明。

在FT8CN中，识别是不是FT8意义上的标准呼号，我是使用了正则表达做判断。

您提到的问题，对于带有“/”的复合呼号，会有N0BOY/QRP 也会有HL5/N0BOY，FT8CN只是简单地取“/”前面的部分，这确实不是很合理，我会尝试改为用正则表达式做识别。

谢谢！

BG7YOZ

[d3m3vilurr]

@bg7yoz yes. a payload size of ft8 message is really too tiny & limited to send all traditional callsign patterns and to send complex free text messages. so, sometimes, I want verification method to compare between encoding/decoding message before actual transmit.

and also yes. detecting callsign is required regex pattern. :)

thank you for your supporting!

73 DE DS1UFX

[d3m3vilurr]

recently, my Korean POTA friends are reported operating problem with /P suffix. he explained case is, if on opponent operators use JDTX, an app removed /P mark from callsign when answering the CQ . in this case, if CQ caller uses JDTX & WSJT-X, programs can communicate like this

CQ POTA DS1ABC/P PM37 (6)
DS1ABC DS1CBA PM37    (1)
DS1CBA DS1ABC/P -02   (2)
DS1ABC DS1CBA -10     (3)
DS1CBA DS1ABC/P RR73  (4)

btw, ft8cn consider it as calling with different callsign, it wouldn't answer the message of 1. I'll recheck it with my computer.

[bg7yoz]

hi, @d3m3vilurr 在FT8协议中，在标准呼号后面带有/P和/R后缀，是用专有的标志位来标注的，在CQ呼叫时使用的消息类型是i3=1或i3=2，这个与非标准呼号不同（i3=4）。所以，带有/P和/R后缀的呼号可以视作一个特殊的标准呼号来处理。

与JTDX、WSJT-X不同，FT8CN没有把/P和/R后缀移除，而是成为呼号的一部分，且保存到日志中的呼号也是以带后缀的。

DE BG7YOZ GL 73!

[d3m3vilurr]

@bg7yoz hello

personally I made a patch but not tested it yet. but couple of days ago, I monitered the actual case of japan friends on the air. (I wouldn't remember the app; maybe wsjt-x)

the problem seems to occur when both operators use /P (personally i use the ft8cn without any postfix marker and I never have the trouble to communicate with /P stations)

IDK a reason (maybe buffer size issue), when both operators use the /P, application(might be jtdx) change one of callsign to std call (removed /P postfix)

CQ POTA DS1ABC/P PM37 (6)
DS1ABC DS1CBA/P PM37    (1)
DS1CBA DS1ABC/P -02   (2)
DS1ABC DS1CBA/P -10     (3)
DS1CBA DS1ABC/P RR73  (4)

app will store a log with target callsign, so it wouldn't related actual communication.

at least, some of kor operators use a laptop to avoid this problem. in the world, wsjt-x and jtdx seems defacto standard, so sadly ft8cn should resolve of this problem to same way. I'll try to monitor another actual case and test in my local when i have time. (but... idk how to dump actual ft8 listen data from the wsjt-x)

[bg7yoz]

hi, @d3m3vilurr 带有/P和/R后缀的呼号确实是一个有趣的问题。在ft8协议中，对于/P和/R后缀的呼号，不是使用i3=4类型的消息（NonStd Call）。而是使用i3=1（对于/R后缀），和i3=2（对于/P后缀）的消息类型。当双方都是用/R后缀，或其中一方是标准呼号，另一方是/R呼号时，使用i3=1是没有任何问题的。同理，对于/P后缀的呼叫也是同样的，只是使用了i3=2类型的消息。 在双方都是用/P或/R后缀的呼叫，如： DS1ABC/P DS1CBA/P PM37 DS1CBA/P DS1ABC/P -02 DS1CBA/P DS1ABC/P RR73

DS1ABC/R DS1CBA/R PM37 DS1CBA/R DS1ABC/R -02 DS1CBA/R DS1ABC/R RR73

在JTDX和WSJT-X中是完全可以解码的，是合理的。不存在缓冲区的问题，因为在i3=1和i3=2的消息类型中，有专门的标志位用于表示/P和/R后缀。

在双方都是/P或/R的时候，FT8CN当前采用的方案是：不对呼号做改动，后缀保留。

通过您的提醒，我发现一个问题：当其中一个呼号有/P后缀，同时另一个呼号带/R后缀，这种情况在FT8CN中产生了混乱，因为没有这样的消息类型：同时拥有/R（r1）和/P（p1）标志位，二者只能选其一，这在设计FT8CN时是没有考虑的，这个问题会在即将发布的0.92版中解决。

对于JTDX与WSJT-X是行业标准的问题，FT8CN会向这两个优秀的软件看齐，尽量按照这两个软件的操作逻辑设计，同时，我也认为，FT8也是在不断发展的，只要是在规则之内有些许不同，也是可以理解的。

如果有时间，您可以使用这个非正式版本测试：

FT8CN_0.92_alpha7_20240110.apk.zip

这个版本可以解码全部类型的FT8消息。

谢谢！ BG7YOZ

[d3m3vilurr]

@bg7yoz thank you a lot! I'll share this patch to KOR pota friends!

[bg7yoz]

@bg7yoz thank you a lot! I'll share this patch to KOR pota friends!

刚刚发现了一个bug（个别设备会因为字符串没有初始化会造成随机闪退），修复了。 请使用这个版本（alpha7）的： FT8CN_0.92_alpha7_20240110.apk.zip

73！ BG7YOZ