As I was traveling to LY recently I asked myself – why won’t JTDX add the location prefix to my calls on FT8? It just shows “CQ LY/DO1ALX”. I looked into the code and it looked promising on the first glace. After a few changes I tried to send a CQ with locator but it failed. Time to dig a little bit deeper.
To solve this question I fully read the FT8 spec and spoke to Arvo, one of the main developers of JTDX to get the answer to my question. Curious why you cannot have a grid locator along with a country prefix or event call? Here is the answer:
Encoding Basics
Ok, first we need to look at some basics. A FT8 message has 77 Bit of useable message body. A free text message can take up to 13 chars (71 Bit) max which fits into these 77Bit. But how can a message like “CQ DX DO1ALX JT58” be sent, it has clearly more than 13 chars.
The answer is simple and complex at the same time. FT8 has multiple message types. Some of them are able to use compressed (hashed) callsigns. This drastically decreases the needed space for a callsign to 28 Bit for these types. Using this method leaves 49 Bits in the message body for other things. Even a second (compressed) callsign and a report.
The drawback of this method is that a message has to have a fixed structure so this can work. Callsigns must follow a pattern so that they can be hashed.
To get a better understanding of the protocol look at the table from the spec article below:
You can see that many message types exist which can hold much more chars by using smart encoding. But each type has a own way of bit use.
If you look at type 4 you can see the encoding of a message with a “special call”. This is essentially what we are using if we use FT8 from other countries. A callsign using a country prefix is a “special call” here as it does not follow the default pattern for callsigns which can be compressed.
Bit Magic
Now let’s see how these nonstd calls are transmitted. The encoding for nonstd call messages reads as following h12 c58 h1 r2 c1 , but what does this mean? You can find the answer for it on the next page in the article:
h12 = hashed callsign (not special)
c58 = special callsign (freetext)
h1 = Hashed callsign is the second callsign (this is a flag)
r2 = RRR, RR73, 73, or blank (predefined messages)
c1 = First callsign is CQ, if so h12 is ignored
The number is the number of bits used by this message part, i.e. c58 means that the special call uses 58 Bits (of the available 77 Bits). If you math it all up you will notice that this message type will use 74 of 77 possible Bits. A grid locator wouldn’t fit in here anymore as it would take at least 15 Bits.
Takeaways
The FT8 protocol is fairly interesting. Joe Taylor did an amazing job with the protocol. But reading through the spec I personally think that there is still some room for improvements related to real world operations. One interesting cache while reading things up was at least a guess why /R callsigns often show up as false decodes on FT8.
This article is just a little primer. If the technical details are interesting to you, make sure to read the specs yourself.