Hi Niklas,

As Bill wrote, the the 'std_call_to_c28.f90' example function is over simplified.  As posted, it provides correct results only for 6-character standard callsigns.  To make it work for any standard callsign you could do the following:

1. Remove the statement on lione 18, "call_std=adjustr(call_std)"
2. When running the compiled program, enter the callsign enclosed in quotes and with a leading blank if the call has a single-letter prefix.

  -- 73, Joe, K1JT

Hi Bill, 
thank you very much for the clarifications!
I understand it now. 

Best Regards
Niklas 

Hi Bill,
thank you very much for your fast answer!
Sorry about the other post, I am rather new to groups.io and made this one via email and the other one via the website, because I wasn't sure if I did this one correctly, I tried to delete the other post in time, but I was too late.

With your tip I was able to successfully decode the first callsign, thank you very much!
I must have overlooked the paragraph regarding the i3 position.
I used an online Fortran compiler and used the code from 'std_call_to_c28.f90', which was mentioned in the QEX paper, to translate the first 28 bits to the callsign and it worked!

But now I got another question regarding 5-character callsigns.
I translated my callsign "DH0MN" to a decimal integer and got: 8796639
But If I translate for example "DZ0MN", I also get: 8796639.

I think its because the third(second for 5-character-callsigns) character gets looked up in array a3. Array a3 is '0123456789', so if you look up letter in this array the index-function always returns -1.

Obviously this problem does not exist in WSTJ-X so I think the code in 'std_call_to_c28.f90' is just deprecated?
Are 5-character callsigns maybe actually left adjusted instead of right adjusted like in the fortran code('call_std=adjustr(call_std)')?

Thanks!
Niklas

Hi Niklas,

the 'std_call_to_c28.f90' example function is sightly over simplified. You should note that both the 'a1' and 'a4' maps can decode a space character. The correct interpretation is that the callsign is aligned so that the suffix letters of which there can be 0, 1, 2, or 3 letters are decoded using 'a4'. Where there are no letters (always trailing positions, and maybe the first position) there will be spaces. So in your examples the alignment is:

1  2  3  4  5  6
D  M  0  M  N  Sp
a1 a2 a3 a4 a4 a4

where the top row is the notional character position, the middle the callsign, and the lower the map used to decode it. For my call the alignment is as follows:

1  2  3  4  5  6
Sp G  4  W  J  S
a1 a2 a3 a4 a4 a4

As you are decoding the alignment can be ignored, just use the correct maps as you divide with remainders the 5 times necessary then trim spaces afterwards.

73
Bill
G4WJS.

Hi Bill,
thank you very much for your fast answer!
Sorry about the other post, I am rather new to groups.io and made this one via email and the other one via the website, because I wasn't sure if I did this one correctly, I tried to delete the other post in time, but I was too late.

With your tip I was able to successfully decode the first callsign, thank you very much!
I must have overlooked the paragraph regarding the i3 position.
I used an online Fortran compiler and used the code from 'std_call_to_c28.f90', which was mentioned in the QEX paper, to translate the first 28 bits to the callsign and it worked!

But now I got another question regarding 5-character callsigns.
I translated my callsign "DH0MN" to a decimal integer and got: 8796639
But If I translate for example "DZ0MN", I also get: 8796639.

I think its because the third(second for 5-character-callsigns) character gets looked up in array a3. Array a3 is '0123456789', so if you look up letter in this array the index-function always returns -1.

Obviously this problem does not exist in WSTJ-X so I think the code in 'std_call_to_c28.f90' is just deprecated?
Are 5-character callsigns maybe actually left adjusted instead of right adjusted like in the fortran code('call_std=adjustr(call_std)')?

Thanks!
Niklas

On 22/10/2021 19:15, Niklas Aust via groups.io wrote:

Hello,
i was trying to understand the FT8 protocol and maybe try to make my own basic decoder.
I was looking at an FT8 signal from the samples provided with wsjtx (210703_133430.wav) and tried to get a better understanding by looking at the spectrum.
I attached the spectrum(Figure_1), that i got by calculating the fft. The FFT size was selected to be 1920 that should yield 6.25Hz per bin for the sample rate of 12kHz.
In the next step I selected the bin that yields the frequency with the most power for every of the 79 symbol locations. I also changed the offset a little bit to get the correct Costas arrays. Figure-2 shows the spectrum after these processing steps. The Costas arrays are clearly visible at start/middle/end with 3,1,4,0,6,5,2. I decoded the next symbols with the gray code explained in "https://physics.princeton.edu/pulsar/k1jt/FT4_FT8_QEX.pdf".
I did not do any error correction (neither CRC ord LDPC).
From what I read there is no interleaving happening and i think its an systematic code.
So the first 77 bits should be information bits, right?
So Codeword should be (Message bits + CRC bits + LDPC bits) in that order.
Please correct me if I misunderstood something.
The reason I am asking is because the first symbol after the first costas array is a 7 equaling to 1-1-1, you can see this in Figure-2. The first three bits are the message type and if I understood correctly the message type (i3) can only be between 0 and 5. So do I already have an error in the first symbol or do I have misonception somewhere?
I decoded the message with WSJT-X and the message should be "WM3PEN EA6VQ -09".
Therefore I guess i3 (message type) should be 001 meaning "Standard Message".
Thank you in advance!

Hi Niklas,

you are making good progress. The missing information is that the 'i3' field is in position 77 of the information bits, i.e. the last symbol before the CRC. In the QEX paper it is noted in Appendix A page 16, col 1, para 3.

73
Bill
G4WJS.