stuck at sending RR73 if not received any reply about ft8cn HOT 8 OPEN

hi, Luca6605

在通联时卡在RR73是一个比较有意思的问题。

按照Joe Taylor定义的FT8协议，标准的通联过程共6步：

Tx6: CQ K1JT FN20
Tx1: K1JT K9AN EN50
Tx2: K9AN K1JT -10
Tx3: K1JT K9AN R-12
Tx4: K9AN K1JT RR73
Tx5: K1JT K9AN 73

FT8CN运行的逻辑是当我发送完毕当前步骤后，应当能够收到对方回复的下一个步骤。

如果我发送的是Tx4（RR73）后，我在下一个周期中，应当能收到对方回复的Tx5（73）。如果没有收到对方回复Tx5，FT8CN认为对方可能是没有收到我的Tx4，它会持续发送Tx4，直到对方回复Tx5，或达到“无回复”（No response xx stopped）设定值，FT8CN才会退出循环。之所以这么做，是因为短波传输并不稳定，并非每一次QSO都是顺利的，有时会反复多次。您在通联时，卡在了RR73，应当是没有收到对方的回复，您需要在“设置”->“无回复”（No response xxx stopped）把阈值调小一些，比如：5次或更少。当无法收到对方的回复次数少于5次后，FT8CN会中断与对方的通联，转向下一个目标。

关于通联自动程序方面，FT8CN只是比较简单地实现，并不能做到像人一样思考。当没有收到对方回复时，它无法知道是传输质量下降还是对方终止了传输，它只能按照预定的路径继续呼叫。事实上，FT8CN还是做了一点点判断，当我是Tx4（RR73）时，下一个周期中有对方的消息而不是73，就判断为对方主动终止传输，这就是0.89版中做的修改。

73
BG7YOZ

from ft8cn.

from ft8cn.

您可以尝试如下设置：

from ft8cn.

@bg7yoz #42 (comment)
when an app transmit JG5VFK DS1UFX/QRP RR73, it actually send .... DS1UFX/QRP 73
is it generated the wrong signal?

it might be reelated ft8_lib issue. kgoba/ft8_lib#24

from ft8cn.

hi, d3m3vilurr

我测试了一下，确实存在JG5VFK DS1UFX/QRP RR73 被错误地发送JG5VFK DS1UFX/QRP 73了。

这个错误发生在FT8Package.java 第76行。
data[9] = (byte) (data[9] | 0x80);

应当改为：
data[9] = (byte) (data[9] | 0x00);
JG5VFK DS1UFX/QRP RR73 中的DS1UFX/QRP是非标准呼号，发送RR73必须是非标准呼叫（NonStd Call，i3=4）。
非标准呼叫的格式为：h12 c58 h1 r2 c1

其中，r2=1为RRR，r2=2为RR73，r2=3为73。
因为我是参照了Karlis Goba的代码，此部分可能在测试时没有发现，也许疏忽，把RR73与73的字段值混淆了。

这个问题将在0.91版本修正。

注：
JG5VFK与DS1UFX/QRP通联的标准过程如下：

TX6: CQ DS1UFX/QRP (非标准消息，i3=4，h12 c58 h1 r2 c1)
TX1: <DS1UFX/QRP> JG5VFK OL50 (标准消息，i3=1，c28 r1 c28 r1 R1 g15)
TX2: JG5VFK <DS1UFX/QRP> -05 (标准消息，i3=1，c28 r1 c28 r1 R1 g15)
TX3: <DS1UFX/QRP> JG5VFK R-13 (标准消息，i3=1，c28 r1 c28 r1 R1 g15)
TX4: DS1UFX/QRP RR73 (非标准消息，i3=4，h12 c58 h1 r2 c1）
TX5: <DS1UFX/QRP> JG5VFK 73 (标准消息，i3=1，c28 r1 c28 r1 R1 g15)

感谢！73！

bg7yoz

from ft8cn.

@bg7yoz thank you!

imo original ft8_lib has some missing callsign parts which wsjt-x is supported
(for example, ZA/K1ABC)
I also tested current master & update_to_0_2 of ft8_lib in local PC.
both versions has some buggy/missing feature parts :)

I shared this issue that we cannot use /P and extra non standard marker(such as /QRP until fixing)
to POTA hams of my country.
but near country friends, japan hams usually use /P & /1 suffixes.
I'm worried it is safe or not in FT8CN.

anyway FT8CN is really awesome & cool.
thank you & 73

DS1UFX

from ft8cn.

@d3m3vilurr

/P和/R是FT8协议中标准的呼号后缀，而/1不是。标准的后缀生成的消息是标准消息（i3=1)，而/1后缀的消息会是非标准消息（i3=4），我记得在ft8_lib中，好像没有支持非标准的消息（i=4），如果呼号为非标准呼号，它会直接输出自由文本（i3=0，n3=0)。FT8CN是支持非标准消息的（i3=4)，我是为此单独写了这部分代码（从ft8cn 0.63版开始），如果感兴趣，您可以参照FT8Package.java修改ft8_lib对应的代码。

FT8CN发送部分的代码是独立开发的，不会出现无法识别/1后缀的问题（带有非标准呼号的消息会根据情况生成为非标准消息，i3=4）。

在FT8CN的消息列表中，会标注出消息的类型，其目的就是防止把自由文本消息（i3=0，n3=0）的消息混淆成正常的消息。

73！

bg7yoz

from ft8cn.

@bg7yoz thank you for your explanation.
And sorry. I didn't read the source code carefully. so I thought it only uses ft8_lib and share the bug.
but it supports more! and it already resolved a lot of things. 👍

ty I'll read FT8Package.java :)

73 DS1UFX

from ft8cn.