stuck at sending RR73 if not received any reply

[Luca6605]

Hello everyone, contrary to what was stated in the new release, the problem identified as

Fixed QSO sequence sometimes stuck at sending RR73 if not received any reply

in my case it appeared, while with the previous release 0.88 patch2 I didn't have it.

[bg7yoz]

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

[Luca6605]

Hello, I reloaded the 0.89 to show you what happens. If Yo4dg gives me rr73 why don't I close and still try to transmit r-4?73 Luca -------- Messaggio originale --------Da: bg7yoz @.>Data: dom 13 ago 2023, 13:07A: N0BOY/FT8CN @.>Cc: Luca6605 @.>, Author @.>Oggetto: Re: [N0BOY/FT8CN] stuck at sending RR73 if not received any reply (Issue #62) hi, Luca6605 在通联时卡在RR73是一个比较有意思的问题。 按照Joe Taylor定义的FT8协议，标准的通联过程共6步： Tx6: CQ K1JT FN20 Tx:1: 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

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[bg7yoz]

您可以尝试如下设置：

[d3m3vilurr]

@bg7yoz https://github.com/N0BOY/FT8CN/issues/42#issuecomment-1682540374 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. https://github.com/kgoba/ft8_lib/issues/24

[bg7yoz]

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

[d3m3vilurr]

@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

[bg7yoz]

@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

[d3m3vilurr]

@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