Wednesday, 19 July 2017

WSJT-X and FT8 - you have to be quick

This is not a criticism. I like FT8. This is just what I found by trying to use it on the busy bands.

After a night using FT8 on 40 metres, I have to say that it is very efficient. It proves, however, that I am not as efficient as I might like to be.

It all comes down to managing the 15 second time segments.

In a nutshell, the transmitted signals have to start right at the beginning of the tx segment (of course), but this is very difficult to achieve if you are waiting to see a decoded signal from the other end. So human intervention, which may not be well timed, was tending to slow everything down.

Lets us suppose that I decide to call CQ, just like the 40m calls last night.

EDIT I have corrected typos in the timing, but the point remains the same.

I might do this during segment 1, at 0 minutes and 15 seconds.

1. 0m 15s CQ GM4FVM

Unless I was fairly careful or had set this on the earlier receiving segment, it is very unlikely to start at exactly the right point. Much more likely it will start after the beginning of the segment and therefore not be a signal which can be decoded by anyone else. Thus the next segment, my receive one, will be silent.

1. 0m 15s CQ GM4FVM
2. 0m 30s Silence

Set up as it is to auto repeat, it will call CQ again next time.

1. 0m 15s CQ GM4FVM
2. 0m 30s Silence
3. 0m 45s CQ GM4FVM

Anyone likely to reply to me will have to wait to see the decode of my signal (duh!). From what I have seen, not many people with normal reactions can click on my callsign in their software before the next tx segment has begun. With only 2 seconds available for decode, reaction and processing that is hardly surprising. The rapidly ageing demographic of amateurs (including me) only makes this less likely to happen.

So at some point during the next segment I get to see a reply, but it is never going to decode.

1. 0m 15s CQ GM4FVM
2. 0m 30s Silence
3. 0m 45s CQ GM4FVM
4. 1m 00s Trace seen but no decode

There is no time for me to put up "QRZ?" either, as I have to wait to see whether that trace decoded or not. So I just send CQ again. There is nothing for the other station to do either, other than transmit again, but this time I will decode it as it started automatically at the correct time. It turns out that it is A1DX, a (non-existent but) very desirable station to work.

1. 0m 15s CQ GM4FVM
2. 0m 30s Silence
3. 0m 45s CQ GM4FVM
4. 1m 00s Trace seen but no decode of call from A1DX
5. 1m 15s CQ GM4FVM
6. 1m 30s GM4FVM A1DX KM33

Great, A1DX, a rare station in a fairly unusual square! I have to wait to see the decode, by which time even though I click on A1DX's callsign it is too late to get the full message transmitted and she only gets two fragments which she cannot decode. However, it shows at my end as having gone (along with the record of another CQ which it interrupted, showing up as two tx lines on the panel).

1. 0m 15s CQ GM4FVM
2. 0m 30s Silence
3. 0m 45s CQ GM4FVM
4. 1m 00s Trace seen but no decode of call from A1DX
5. 1m 15s CQ GM4FVM
6. 1m 30s GM4FVM A1DX KM33
7. 1m 45s CQ GM4FVM/A1DX GM4FVM +03

At this stage A1DX will see that I have replied but get no decode, so she just sends her call again. We all need to be patient here.

1. 0m 15s CQ GM4FVM
2. 0m 30s Silence
3. 0m 45s CQ GM4FVM
4. 1m 00s Trace seen but no decode of call from A1DX
5. 1m 15s CQ GM4FVM
6. 1m 30s GM4FVM A1DX KM33
7. 1m 45s CQ GM4FVM/A1DX GM4FVM +03
8. 2m 00s GM4FVM A1DX KM33

At this point automation takes over and the rest of the QSO proceeds very quickly without further intervention by either of us (just as well given the speed of our reactions). The path shown next will be followed providing that A1DX has the "Auto Seq" box ticked, but it turns out that she has. Otherwise it will take forever to do this.

1. 0m 15s CQ GM4FVM
2. 0m 30s Silence
3. 0m 45s CQ GM4FVM
4. 1m 00s Trace seen but no decode of call from A1DX
5. 1m 15s CQ GM4FVM
6. 1m 30s GM4FVM A1DX KM33
7. 1m 45s CQ GM4FVM/A1DX GM4FVM +03
8. 2m 00s GM4FVM A1DX KM33
9. 2m 15s A1DX GM4FVM +03
10. 2m 30s GM4FVM A1DX R-16
11. 2m 45s A1DX GM4FVM RRR
12. 3m 00s GM4FVM A1DX 73

OK she might send 88s, as we do go back a long way.

But anyway, now a further issue arises. If I have by now altered my WSJT-X panel to send the next CQ, I will not know if A1DX sent 73 until it is decoded. She might have not received my RRR and then she would send R-16 again, which would mean me changing everything again and wasting time. So I am almost obliged to leave everything in auto until I see the decode of 73, by which time it is too late to stop me sending 73 myself. If I do intervene by changing this to CQ it gets me nowhere because the resultant changed message is not able to be decoded by anyone. So I end up with this ...

1. 0m 15s CQ GM4FVM
2. 0m 30s Silence
3. 0m 45s CQ GM4FVM
4. 1m 00s Trace seen but no decode of call from A1DX
5. 1m 15s CQ GM4FVM
6. 1m 30s GM4FVM A1DX KM33
7. 1m 45s CQ GM4FVM/A1DX GM4FVM +03
8. 2m 00s GM4FVM A1DX KM33
9. 2m15s A1DX GM4FVM +03
10. 2m 30s GM4FVM A1DX R-16
11. 2m 45s A1DX GM4FVM RRR
12. 3m 00s GM4FVM A1DX 73
13. 3m 15s A1DX GM4FVM 73
14. 3m 30s Silence
15. 3m 45s CQ GM4FVM

Thus, in theory a 6 segment cycle (as it often is on JT65) becomes a 14 segment cycle. The FT8 segments are only a quarter of the length of the JT65 ones of course.

If it goes round again, the correct start time of segment 15 reduces subsequent iterations to 13 segments. Instead of calling CQ after 6 cycles on JT65, I ended up calling CQ after 12 cycles on FT8. This produces twice as many QSOs on FT8 compared with the same time on JT65, not four times as I might have expected before actually trying it.

It is quicker if you are the one answering the CQ of course. It takes longer if you are the one calling CQ as you have the dead rx periods.

I recognise that there might be some failings on my part due to my slow reaction times. The other stations seemed to be doing the same. I tried to sharpen up at my end, for instance by being ready to double click on the other station's callsign as soon as it appeared on my panel (you have to do it on the "RxFrequency" side as it moves up the screen on the other side, plus it will move up a line as soon as you start to tx, so I aimed for the second line up). This usually saved two segments, but I had to be lightening quick.

Nobody at the other end seemed to be moving any more quickly than I was, and all the QSOs were like the one above. I had to call CQ twice before I got a decode of the other end's callsign, even though after the first CQ I could see something on the waterfall. It was never decoded the first time. They were not getting as quick as I was.

With careful timing it is possible to reduce this process, but nobody was doing it last night. My lack of ability to avoid sending a second redundant 73 at the end of the cycle really annoyed me, but I just did not have the time to get it right and change over to CQ as soon as I had received 73. That is my standard procedure on JT65. Maybe I just need to loosen up and accept that as the whole process is better then the odd missed segment is OK.

This all seems simpler on MSK144. The modes are not technically comparable, but MSK144 also has 15 second segments. There is enough time to work out what to do next on MSK because timing is not important on meteor scatter - and on 60 second JT65 there is plenty of time even though you still need to concentrate. I pondered a bit on whether the same FT8 protocol with 30 second segments (with the extra 15 seconds devoted simply to deciding what to do next) would actually take the same time to complete a QSO. The answer with some of the real-life contacts was "yes".

Of course the built-in automation takes a lot of the problems out of all this. It works 100% fine. It is only when cranky old humans get involved that it all goes awry. Well not "awry" as it still works, but it diverges from the ideal. Put simply, my desire to complete "a QSO", meaning all the stuff done right, is part of the delay. I am the one deciding not to go straight on to CQ without seeing 73, but then that seems pretty logical to me. Let me put it this way - I do it on all the other modes.

Further automation, like automatically replying to the next signal or the weakest signal, is on the way for FT8. The snag with this, despite the attraction for others, is that I don't want to do it. I really want to know who I am replying to to before I reply. The UK does not have a "banned list" but some DXCCs do. In general I just do not want to be able to work everyone who might just call me.

Automatically going to CQ once 73 is received would be a good option for me though.

This is a fine balance to strike. At what point does speeding up the QSO get too fast for the operator to keep up with?

In the early 1980s I was taking a post graduate course at Queen's University of Belfast. I took an option in Ergonomics, which examined what was then called "man/machine interface". You know, aircraft cockpit dials all reading the same way, and how to design a control panel for a nuclear reactor. Great stuff and very useful in later life. Well ...

At one point we were trooped (!) into the university "Drill Hall" where a line of personal computers was arranged. I had never used a personal computer before, as the only computers I had used were the size of small buildings. We had to compare the interfaces on Microsoft and Macintosh machines. Microsoft was DOS, the Macs had ... windows. I wrote a long essay (my essays are still long) to say that windows were a much more accessible human/machine interface than obscure keystrokes. Speeding up the process using windows still left the operator with enough time to decide what to do next at their own pace, having been provided with timely visual clues. Did Microsoft read that? I don't know, but that is my qualification to blether on this topic now. I studied ergonomics you know.

I might have just got a bad night on 40m, with everybody new to the mode. However, it looked a bit like we might have got near to the limit as to how far we can shorten the reaction time available to operators and still expect them to sort things out in time. We can react more easily to messages that can be decoded as they arrive - like CW - where the message is gradually building up during the QSO. With data modes however, you get nothing until you are presented with a fully decoded message or still just nothing. What you do then is limited in all sort of ways. Further automation is possible but do we really want it?

Here is an FT8 QSO today on 6m ...
50MHz FT8 at GM4FVM on 19 July 2017. Click image to enlarge if necessary
This is better than the 40m ones last night. There is the same jittery start. Did he not hear me the first times I called, or did he click to reply during a segment and I did not decode the partial message? There was QSB. Once we got into automatic mode everything went well until two 73s and even an extra one from me which I cancelled part way through. It is not really comparable with last night, as on 6m DX everybody is keyed up and concentrating, while on 40m around Europe it is ... different.

Let us get this straight. Most of the QSOs I had would never have taken place on JT65, and no other mode either. Whilst FT8 might not be working for me at four times the speed of JT65, it is certainly getting through the QSOs at twice the rate, which means half of the 40m ones would never have happened in any other mode. As for the 6m contact, well -17dB is a pretty weak signal, so FT8 won the day technically. Once he actually heard me and started his reply the QSO was complete in another 45 seconds. With JT65 the QSB would have got him before the end anyway. I am a fan of FT8.

FT8 works. The high pace makes me feel fraught and unlike JT65 there is not much time for logging and feeding the cat between overs. I can cope with that (can Katy?). However, it is a bit ... wearing ... keeping up with it. Worth the effort though.

The protocol works very well, the operator is in need of a software upgrade.

If you ever need your nuclear reactor control suite updated, you know the person to call. I will put in some delay time to allow for second thoughts before pressing "go" - you cannot get people to react fast enough and still see the consequences of their actions. Other people! Eh? Who needs them?

I wonder did windows ever catch on in computing?

73

Jim

GM4FVM



No comments:

Post a Comment