A separate topic brought to light the fact that, with good signals, a surprisingly short transmission (either started late or ended early) can be decoded.

This raises an interesting question in my mind. Not that it would be a good regular operating practice, but is it even possible that a transmission could be started (say a final 73 message) and then at about 6.5 or 7 seconds in, a decode could be double-clicked to call that station, and BOTH messages would be decodable? Or is the minimum time required for a decodable transmission simply too long to allow for two? If length of text affects time required to transmit, then my short call might contribute to being theoretically able to combine two messages. My final 73 to a 4-character callsign would be just 12 characters, and a TX2 message would be just 13.

Randy, WS4C

This raises an interesting question in my mind. Not that it would be a good regular operating practice, but is it even possible that a transmission could be started (say a final 73 message) and then at about 6.5 or 7 seconds in, a decode could be double-clicked to call that station, and BOTH messages would be decodable? Or is the minimum time required for a decodable transmission simply too long to allow for two? If length of text affects time required to transmit, then my short call might contribute to being theoretically able to combine two messages. My final 73 to a 4-character callsign would be just 12 characters, and a TX2 message would be just 13.

Hi Randy,
To put this on the right rails may I refer to an excellent paper https://physics.princeton.edu/pulsar/k1jt/FT4_FT8_QEX.pdf
It describes how the messages are constructed and source coded. The most relevant issue about callsigns is that the number of characters as such is not the issue, but there are strict rules what a standard callsign can contain.
For you purpose there is already a message available in the Table 1.
0.1 DXpedition K1ABC RR73; W9XYZ <KH1/KH7Z> -08
It is used for DXpedition protocol. The use it for normal operation would set more strict rules for a QSO. E.g. in the example message K1ABC needs to be satisfied to the reception of the RR73 as the indication of the end of the QSO and no 73 should be used. Otherwise there is a high probability that the sender of that message would have two independent QSOs at the same time one with K1ABC and second with KH1/KH7Z. Well that would already happen, when K1ABC does not receive the RR73!
73, Reino OH3mA

The paper (which I had skimmed when it came out in QEX) does come close to answering my question; thanks for the link to it. The example you offer from Table 1, though, does not address my specific question. It shows an example of how a single transmission may contain two messages, but it does not answer the question of whether two separate transmissions might be completed and successfully decoded on the other ends within a single 15-second transmission window.

The practical difference between the two is this. Operating in standard FT8 mode (not DXpedition or Fox/Hound), I would not be able to manually construct a transmission like the entry from Table 1 quickly enough to be able to send it right in sequence. There maybe software to facilitate the construction of such a message type, but I'm envisioning just standard FT8 operating in the standard WSJT environment. The only way I would be able to send two messages in one period is to have one of them ready to go when the cycle begins and then switch to the other by a fast operation like double-clicking at the midpoint of the transmission period.

So I'll give another example of a real-life scenario such as I envision and wonder whether it is even possible. Suppose I CQ and get two calls. I work the first QSO and then call the second station. The second station does not reply, so I call another CQ. Back comes both a new call and, as a late decode, a reply from that station I had called previously. That late decode appears on my screen after my transmission has begun in which I give the new caller his report. If signals from both stations are strong enough to allow for correct reception of the data load on the first try, is it possible that I might be able to double-click that late decode and fit his RR73 into the same transmission period as my report to the new caller.

The only reason I raise this question at all is that the other thread that I mentioned indicates that the minimum length decodable transmission is much shorter than I was aware--getting down nearly to only half the length of a normal transmission period.

So in looking at the QEX paper more closely now, I see that Figure 9 presents curves showing the probability of successful decoding of messages started late, at SNR of -10dB. Without AP decoding enabled, the probability of decoding falls to 50% at a delay of about 5.5 seconds, which yields a transmission length of 6.5 seconds. Since the transmission window, as I understand it, is 12 seconds (but might it extend if the message is not completely sent after 12 seconds?), fitting in two 6.5-second messages would be impossible. With AP enabled, though, the decode probability curve is significantly better, with only about 4 seconds of transmission time required for a 50% probability of successful decode. I'd be really curious to know what these curves would look like at +10dB SNR.

At any rate, I think the probability of successful decoding for a half-length transmission is low enough to make my idea unreliable at best--especially since stations can't be depended upon to be using AP decoding. If, though, the probability improves with strong SNRs, and if stopping a transmission early is all the same as beginning it late, then it looks to me like 2 separate transmissions within one period are within the realm of possibility.

Thanks for the link to the paper, since it did contain information highly relevant to my question. Maybe I'll get on the air someday with a friend and play around with the idea to see whether my idea is even possible. I doubt that it will prove practical, but that doesn't make it any less interesting to explore what is possible.

For sure you will loose S/N. So why not FT4?
It's the Okkam's razor.

Pietro I2OIM

The paper (which I had skimmed when it came out in QEX) does come close to answering my question; thanks for the link to it. The example you offer from Table 1, though, does not address my specific question. It shows an example of how a single transmission may contain two messages, but it does not answer the question of whether two separate transmissions might be completed and successfully decoded on the other ends within a single 15-second transmission window.

Hi Randy,
I think that that a probability to decode two messages from a single shared message is so low that there is no practical opportunity to use it for any real working even at very high S/N situation. Also the timing for sharing should be nearly perfect within a few symbols.

The use of AP probably increases a bit the decoding probability of the 'RR73' message, but cannot make it 'perfect' for your purpose. In any case my guess is that there is less than 1% probability that both stations would decode the message correctly at the same time.

A decoding of two messages combined by that time division into a single message would be so rare or only theoretical case that it is useless for everyday working. Most probably you will have one unfinished and one not started QSO as a result. I have heard rumors that it has happened, but the situation was not perfectly clear as I don't have the related ALL.txt information available. Good luck, if you try to test it.

I took the DXpedition message only as an example how the 'two stations' problem could be built into the protocol. There is one derivate program that actually uses it outside the F/H protocol.

73, Reino OH3mA

Haven’t we almost come full circle to the “transmit two simultaneous audio streams to get multiple QSOs to run at once” paradigm?

73, Willie N1JBJ

Thanks for these additional replies. I'm not thinking of trying to maximize QSO rate on an ongoing basis (such as FT4 would allow, or simultaneous streams). I'm thinking primarily in the abstract about what is POSSIBLE (as opposed to USEFUL), and then secondarily, if it proves possible, whether it might in fact prove useful on relatively rare occasions within simple FT8 operating procedures.

I'm well satisfied with the input that has come back; all that remains to do is some testing under strong signal conditions and then, if in fact it works, work down a range of less optimal conditions to see what happens.

With other things going on in my life, I'm not sure when I'll actually manage to do this; the topic may well close out before then.

I imagine that Reino, OH3MA, will prove correct about this idea failing to exhibit any practical value.

Randy, WS4C

Randy, I have seen two different decodes from a single transmission just once, one was a 73 message the other a CQ. The operator must have clicked on CQ at just the right moment in the transmission. /Dave K1BZ

On Tue, Jul 19, 2022 at 10:21 AM, David Larrabee wrote:

I have seen two different decodes from a single transmission just once, one
was a 73 message the other a CQ.

Thanks! It looks like Reino and I might both be correct: I may be correct that it's possible, and he may be correct that it's not practically useful. Or maybe this op had experimented and perfected an art! :-)

users are probably using MSHV instead of wsjt...

Dave Garber
VE3WEJ / VE3IE

I did some experimenting this afternoon. Rather than trouble a friend over a project that might not interest him, I set myself up for a test contained within my station.

Not having a dummy load, I put my transmitter on on odd frequency on 10 meters and reduced power to around 1 watt. To listen to my transmitted audio, I connected a good-quality external mic to a second notebook computer with WSJT-X installed, and selected that mic as my audio input, then laid that mic next to the rig speaker. I was able to get decodes of my transmitted audio at a little over +20 SNR. Checking the quality of the audio over the mic, I listened to the FT8 frequency on 20m on both my main setup and on the second notebook with mic. The number of decodes on the two systems was always nearly identical. The two clocks on the computers were synchronized within a few tenths of a second.

Without going into the hairy details of what all I tried, I found that changing messages within about the first 7.5 seconds of the transmit period resulted in a decode of only the second message. Changing between about 7.5 and 9.5 seconds resulted in no decodes at all, and changing at about 9.5 seconds or later resulted in a decode of only the first message.

I found this interesting, because, with AP enabled, I could halt a transmission at about 8 seconds and still get a decode, and I could start a transmission as late as about 8 seconds and still get a decode. But changing messages at between 7.5 and 9.5 seconds never produced any decodes at all. I imagine the reason for this difference is perfectly obvious to someone who knows the program intimately on a nuts-and-bolts level, but that rather obviously ain't me. :-)

For my purposes, the case is closed, and Reino, OH3MA, turns out to be entirely correct, at least as far as my experiments today reveal. My thanks for the various inputs.

A point that I did not make clear in the description of my experiment is that I had AP decoding enabled for all the experimentation that I described. Without AP enabled, significantly longer transmissions were required for decoding. I don't know what percentage of ops choose not to enable AP decoding, but those who do not will not likely decode transmissions that are shortened by more than just a few seconds. I think this finding is consistent with the WSJT documentation and the QEX article that Reino linked to above.

This AP factor is something to consider for ops who use shortened transmissions for various reasons (such as wanting to get a brief look at the waterfall to see what your Tx frequency looks like): only stations with AP enabled will be able to decode your significantly shortened transmissions. So shortening a transmission is probably better suited to a CQ call than to a CQ response or an in-QSO exchange, where you might want to prioritize the likelihood of being decoded. Of course if you're thinking that you might suddenly have QRM on your Tx frequency in the middle of a QSO, it might still be worth risking a failed decode to take a look during part of your Tx period, since apparently your transmissions are failing at the moment anyway. So many subtleties!

Something else that I might play with a little is that once when I QSY'ed mid-transmission, I was surprised to see a good decode. Not sure whether that's because one side or the other of that transmission was long enough to decode or whether WSJT is actually slick enough to decode even with a QSY in the middle of the transmission. I suspect that the first of those alternatives is the correct one, or else, perhaps, a third one that comes to mind: the fact that my signal was the only one in the 3-KHz passband. If, though, WSJT really is smart enough to handle a mid-transmission QSY, that would a a good detail to know. A delayed transmission to check the waterfall could conceivably be followed, in a case where there's now QRM, by a QSY to a clear spot, resulting in a good decode on the receiving end.

Randy, WS4C

Oh, no. I think I may have gotten the AP detail wrong: I may have done most of my experimenting with it turned off rather than on. I didn't write that detail down, and now the old memory has gone fuzzy on me. Since I've gotten email from one station following this discussion, there may well be enough interest in this topic to warrant my checking this detail and reporting back. I expect to post again later this evening--depending on whether band conditions are good enough to make me want to operate rather than experiment. :-)

Here's the update on the AP question. Within my experimental setup described above, enabling AP or not made no difference. I suppose this is due to the fact that the signal was solid, with no gaps, so that the AP decoding routine was never invoked. I never saw the "ap" notation beside any of the decodes.

Then there's another update. I was not able to duplicate one observation that I mentioned above, about transmissions started as late as 8 seconds being successfully decoded. The latest I could start a transmission and have it successfully decoded was about 5 seconds. And the earliest I could halt a transmission and still have it decoded was about 7.5 seconds (the difference between this and the 8 seconds observed earlier is probably due to inexactness in my timings). So apparently in my first experiment I inadvertently recorded the 8-second timing for both kinds of transmissions (starting late and ending early). I'm prone to that kind of error, unfortunately. This correction, though, doesn't bear on the main point of this topic; I only report it in case someone else has reason to duplicate my experiments and wonders about a discrepancy between what they find and what I reported.

I also experimented with lower SNRs, down to about -20. Given the clean passband and steady signal I was working with, I guess it's not surprising that I observed no difference in the range of decodable timings between an SNR of +20db and one of -20db.

I think I'm finished on this topic. If I experiment with mid-transmission QSYing, I'll report those findings as a separate topic, after first exploring to see whether that question has already been discussed here.