locked FT8 dit dit #EnhancementReqest


Kermit Lehman
 

I was on 15m CW yesterday afternoon getting ready for the CQ-WPX-CW. It occurred to me that FT modes need some kind of "dit dit" to indicate the end of a QSO. 

It would be a specially coded transmission (simple with much redundancy, very robust) that is more likely to get through bad QRM and bad QSB and be successfully decoded than other ending messages and could replace the current RR73, RRR and 73 messages. It would take the normal FT4 and FT8  transmission periods. 

It wouldn't need to contain call sign info or any other info. All it needs to do is trigger a canned message, which could be just RR73 or something similar. Call signs would be assumed by the QSO participants. They know who they have just worked and on what frequencies.  It's usefulness would be based on getting it when it's expected, just as it is used on CW. Both parties would send it.  We'd need to get used to using it, but FT is still a young culture, hopefully not yet set in its ways..

CQ AB1J FN42
AB1J 1X2Y AA11
1X2Y AB1J -08
AB1J 1X2Y R-10
RR73  
RR73

I have no idea of the feasibility of this. I know there are imitations on what can and cannot be sent on FT4 and FT8, but FT modes suffer from a serious QSO ending problem. It would useful to address this issue somehow.

73,Ken, AB1J


Joe Subich, W4TV
 

On 2022-05-28 1:32 PM, Kermit Lehman via groups.io wrote:
I was on 15m CW yesterday afternoon getting ready for the CQ-WPX-CW. It occurred to me that FT modes need some kind of "dit dit" to indicate the end of a QSO.
*NO!* You don't get an "I confirm that I got your confirmation that
you received my report" or a "QSO complete" message from the other
station in a DX pile up or Contest QSO on phone, CW or RTTY, why do
you expect one with FT4/FT8?

As far as your station is concerned, the QSO is complete when you
send either RR/RR73 or R-## - both stations have received and
acknowledged reports. If the other station does not receive your
R-## message he will repeat his message: "<your_call> -##" until
he hears your R-## message and then switch to RRR or RR73. If you
are sending RRR/RR73, you need send it only one time - the next
expected message is CQ or answer another caller (tail-ender). If
the other station repeats his R-## message (indicating he did not
copy RRR/RR73), you may chose to repeat the RRR/RR73 for the other
station's peace of mind although that is not strictly necessary
for a completed QSO.

If you do not hear R-## after sending RRR/RR73, you can assume the
QSO is complete and finished just as you would assume a CW QSO is
complete once you've sent your "599 TU" unless the other station
sends "AGN? AGN?".

Pile-up QSO:
CW FT8
Station 1: CQ TEST de DX1DX DX1DX CQ DX1DX AA00
Station 2: de KZ1ZZZ KZ1ZZZ DX1DX KZ1ZZZ FM20
Station 1: KZ1ZZZ 599 DX1DX KZ1ZZZ DX1DX -12
Station 2: TU 599 KZ1ZZZ DX1DX KZ1ZZZ R-10
Station 1: QRZ DX1DX KZ1ZZZ DX1DX RR73
=========== BOTH QSOs are complete ==========================

73,

... Joe, W4TV


On 2022-05-28 1:32 PM, Kermit Lehman via groups.io wrote:
I was on 15m CW yesterday afternoon getting ready for the CQ-WPX-CW. It occurred to me that FT modes need some kind of "dit dit" to indicate the end of a QSO.
It would be a specially coded transmission (simple with much redundancy, very robust) that is more likely to get through bad QRM and bad QSB and be successfully decoded than other ending messages and could replace the current RR73, RRR and 73 messages. It would take the normal FT4 and FT8  transmission periods.
It wouldn't need to contain call sign info or any other info. All it needs to do is trigger a canned message, which could be just RR73 or something similar. Call signs would be assumed by the QSO participants. They know who they have just worked and on what frequencies.  It's usefulness would be based on getting it when it's expected, just as it is used on CW. Both parties would send it.  We'd need to get used to using it, but FT is still a young culture, hopefully not yet set in its ways..
CQ AB1J FN42
AB1J 1X2Y AA11
1X2Y AB1J -08
AB1J 1X2Y R-10
RR73
RR73
I have no idea of the feasibility of this. I know there are imitations on what can and cannot be sent on FT4 and FT8, but FT modes suffer from a serious QSO ending problem. It would useful to address this issue somehow.
73,Ken, AB1J


Reino Talarmo
 

Hi Ken,

Current AP decoding does that almost perfectly already now for standard FT8 (see 12.1. AP Decoding and https://physics.princeton.edu/pulsar/k1jt/FT4_FT8_QEX.pdf).
It is less effective for combined Fox messages, but that message is already a compromise between decoding and QSO rate.

73, Reino OH3mA

-----Original Message-----
From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Kermit Lehman via groups.io
Sent: 28. toukokuutata 2022 20:33
To: rttydigital@groups.io; main@WSJTX.groups.io
Subject: [WSJTX] FT8 dit dit #EnhancementReqest

I was on 15m CW yesterday afternoon getting ready for the CQ-WPX-CW. It occurred to me that FT modes need some kind of "dit dit" to indicate the end of a QSO.

It would be a specially coded transmission (simple with much redundancy, very robust) that is more likely to get through bad QRM and bad QSB and be successfully decoded than other ending messages and could replace the current RR73, RRR and 73 messages. It would take the normal FT4 and FT8 transmission periods.

It wouldn't need to contain call sign info or any other info. All it needs to do is trigger a canned message, which could be just RR73 or something similar. Call signs would be assumed by the QSO participants. They know who they have just worked and on what frequencies. It's usefulness would be based on getting it when it's expected, just as it is used on CW. Both parties would send it. We'd need to get used to using it, but FT is still a young culture, hopefully not yet set in its ways..

CQ AB1J FN42
AB1J 1X2Y AA11
1X2Y AB1J -08
AB1J 1X2Y R-10
RR73
RR73

I have no idea of the feasibility of this. I know there are imitations on what can and cannot be sent on FT4 and FT8, but FT modes suffer from a serious QSO ending problem. It would useful to address this issue somehow.

73,Ken, AB1J