最近在关注FT8这类数字模式，发现了一个小问题。例如A台与B台进行通联时，A台向B台发送了RR73。此时B台是否要向A台回复73，使得A台可以确认QSO呢？事实上，根据WSJT-X的User Guide（用户手册）（网址：https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-2.6.0.html#_standard_exchange）的Standard Exchange部分，A台在向B台发送RR73时，双方即可确认QSO了。同时，在网页中下方注明：「The RR73 message should be used only if you are reasonably confident that no repetitions will be required.」意思是：RR73只有在你确信不会收到回复的时候才使用。也就是说，如果B台在收到A台的RR73后，不向A台回复73，转向与其他友台通联也是合理的。此时，A台也无需因为没有收到B台的73而反复发送RR73，从而浪费一个15s的时间。由此，我倡议双方在通联通联过程中，收到RR73（或RRR）消息即可确认QSO。同时，避免对于RR73消息不必要的回复。如需获得对方的73，建议使用RRR进行回复。欢迎各位友台交流讨论！

不过有时候要发73才会记录通联所以还是会有rr73之后还看到73的回复

对于双方自动日志记录，只有73/RR73或者包含73的自由文本才会触发

@"YofoaStudio"#p588 所以说事实上只要看到RR73就可以记录通联了，对方发出RR73也可以记录通联了。再发回73不是必要的。

@"BI1NEI"#p595 触发记录的条件好像是主动发送RR73或者73的小心，或者接收到带有73的内容，所以如果不是F/H模式，你收到了对方的RR73，只是触发了自己的日志记录，但是你不发送73，对方是不会触发日志记录的。所以基于这个特点，有的时候可以利用一下。比如你发送了回复R-10后对方一直没发RR73给你，但是其实双方已经交换了信号报告，也可以认为是完成了QSO，这时候如果迫切需要这个DXCC，可以试试直接发送73过去，“强制”那边触发记录。然后就是有时候如果通联中，突然出现稀有dxcc，为了快速结束当前QSO，可以连续发送RR73和73过去，快速结束QSO，当然这其实挺不礼貌的。

还在想为啥有的用RRR有的用RR73，学习了！

两种方式，第一种，你只是记录一下日志，对方长时间不给你回RR73，可以手动点击通联日志，记录通联日志，后期上传到qrz再看通联确认情况第二种你发射的R XX信号报告对方一直不回复（或者传播下去了），可以手动发射RR73（其实我们按流程是接收RR73发送73的）多发几次，如果对方收到触发登记日志最好，如果对方已经QSY或者QRT了，那就看天了，对方有没有按第一种方式操作，我试过直接回73，软件只是自动回复一次，所以这种情况建议回复RR73 至少能多发射几次

你的倡议需要和做自动化脚本的人沟通。。

结束联通是RRR与RR73二选一，都由软件自动完成。

@"Bi4KKF"#p22893 这玩意不是自动的么

@"BI4IVE"#p23054 自动也有规则

Regarding RR73 and RRR's proposals for FT8

BI1NEI

I've recently been looking into FT8-like digital modes and have noticed a small issue.
For example, when Station A communicates with Station B, Station A sends RR73. At this point, should Station B reply to Station A with 73, allowing Station A to confirm the QSO?

In fact, according to the WSJT-X User Guide (available at: [URL])https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-2.6.0.html#_standard_exchange) The Standard Exchange portion, where one station sends RR73 to another, allows both stations to confirm a QSO.

Additionally, please include the following statement at the bottom of the webpage: "The RR73 message should only be used if you are reasonably confident that it will not need to be repeated."
This means that RR73 should only be used when you are certain that you will not receive a response.
That is, if B receives RR73 from A and does not reply with 73 to A, then switching to communicate with other friendly devices is reasonable. At this point, A also doesn't need to repeatedly send RR73 because it hasn't received 73 from B, which would waste a 15-second period.

Therefore, I propose that both parties confirm a QSO (communication) as soon as they receive an RR73 (or RRR) message during the communication. Additionally, avoid unnecessary replies to RR73 messages. If you need to respond with "73," it is recommended to use RRR for this purpose.

Welcome to this discussion among our partner stations!

YofoaStudio

However, sometimes it's necessary to send a 73 message in order for the connection to be recorded.
Therefore, there will still be replies to "RR73" even after it has been mentioned.

BI1NEI

YofoaStudio Therefore, in fact, as long as you see an RR73, you can record the communication. You can also record the communication if the other party sends out an RR73. Sending it back is not necessary.

BI1NIZ

For both automatic logging scenarios, only entries containing "73/RR73" or free-text entries containing "73" will be triggered.

BI1NIZ

BI1NEI It seems that the condition for triggering the log is either actively sending an RR73 or receiving one containing "73", so if you're not in F/H mode, and you receive your opponent's RR73, it will trigger your own log recording, but if you don't send 73, your opponent won't trigger the log. Therefore, this characteristic can sometimes be exploited. For example, if you send a reply to R-10 and your opponent never sends an RR73 back, but in reality, both parties have exchanged signal reports, which can also be considered as completing a QSO, then if you urgently need this DXCC, you can try sending 73 directly to "force" the log recording. Another situation is when communicating, a rare DXCC suddenly appears. To quickly end the current QSO, you can send RR73 and 73 consecutively to quickly end the QSO. Of course, this is quite impolite.

BG5VLI

I understand now why some people use RRR while others use RR73!

Bi4KKF

There are two ways. The first way is to simply record the logs, and if the other party doesn't respond with RR73 for a long time, you can manually click on the communication log and record it, then upload it to qrz later to check the communication status.
The second scenario is when you transmit the R XX signal and the recipient doesn't respond (or if it has been relayed), you can manually transmit RR73 (which, according to our procedure, we should receive RR73 and then send 73). Try sending it multiple times. If the recipient receives the trigger and logs it, that's ideal. However, if they have already QSY or QRTed, then it depends on whether they followed the first method of operation.
I tried replying directly to 73, but the software only automatically replied once. Therefore, I recommend replying to RR73 at least so that it can be launched multiple times.

BI4IVE

Bi4KKF Isn't this supposed to be automatic?

BG2EFX

Your proposal requires communication with those who create and maintain automation scripts.

BG7DKN

The "End Connection" function is either RRR or RR73, and both are automatically completed by software.

Bi4KKF

BI4IVE There are also rules for automation.

闽ICP备2021006864号-7

闽公网安备35020602002794号互联网举报中心

用户协议隐私政策社区规范积分规则中继规则转载须知
更新日志联系我们常见问题友情链接运营报告赞助

浩奇科技（厦门）有限公司

是无线电，把我们联系在一起