Menu
Finest Hacking and HAM
  • Home
  • About me
  • Links
  • Imprint
    • Privacy Statement (EU)
    • Cookie Policy (EU)
    • Disclaimer
Finest Hacking and HAM

FT8 – Grid Locators and “Special Calls”

Posted on 30. August 202130. August 2021

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:

Bit Fields

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.

3 thoughts on “FT8 – Grid Locators and “Special Calls””

  1. Medan Egman says:
    9. March 2023 at 3:43

    This is a very interesting article. Thank you for it.

    And it talks about a problem that I have also noticed: How to operate FT8 from abroad (or alternatively: from Home QTH, but remotely) and give a working callsign PLUS locator? – Impossible?

    Scenario:
    Suppose I have a German callsign (DO1XYZ). My prefix “DO” means that I have a licence class that may not use e.g. 20m band! But when I am abroad (or remotely transmitting from abroad) I am allowed (depending on the country and CEPT agreement) to transmit with this class e.g. on 20m, too.

    Example:
    My locator is “JO44”, i.e. a locator that exists in Germany and also in Denmark. I am not allowed to transmit on 20m in Germany, but in Denmark. So I transmit from Denmark from an area with e.g. the locator “JO45” – no need to travel far then.

    What should my callsign look like now? OZ/DO1XYZ? or DO1XYZ/R?

    Problems:

    1) If I choose OZ/DO1XYZ, my locator is not sent on FT8, e.g. CQ OZ/DO1XYZ JO45 becomes: CQ OZ/DO1XYZ, WITHOUT locator!

    2) If I select CQ DO1XYZ JO45 and transmit on 20m, it looks like I am transmitting with my licence class on a not allowed band!

    So should I use CQ DO1XYZ/R JO45?

    It’s a pity that this weakness exists on WSJT-X and JTDX….

    Greetings from Germany

    Reply
    1. Medan Egman says:
      9. March 2023 at 3:49

      “Greetings from Germany”, haha… Just noticed this is a German site. 🙂

      Reply
    2. Avatar photo Alex says:
      25. March 2023 at 14:30

      You must use the prefix if you are in another country. So in OZ, OZ/ is correct. In Germany DO1XYZ/R will work. Sadly if using OZ/ the grid locator won’t work anymore. That was the exact same issue I was investigating when working the bands in LY.

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

(c) 2021-2024 - Alexander Pick - DO1ALX/K2API
Manage Cookie Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage {vendor_count} vendors Read more about these purposes
View preferences
{title} {title} {title}