Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug in FT8 Telemetry mode and an easy fix. (Atmel tool chain and possibly others) #18

Open
SquirrelEng opened this issue Apr 9, 2019 · 3 comments

Comments

@SquirrelEng
Copy link

There is a bug in the FT8 telemetry mode code.

In JTEncode.cpp line 887 the line: snprintf(temp_msg, 19, "%*s", 18, c18); sets temp_msg to a zero length string. This causes the variable "message" further down in the code to have a zero 1st byte and corrupts the telemetry message.

Replace the snprintf call with the following: snprintf(temp_msg, 19, "%18s", c18);

I am running the code on an Arduno Pro Mini (Atmel chip) and it appears that the %*s formatter is not functioning correctly on this tool chain. Since the length is hard coded, the simpler %18s will work.

73s de KJ6FO

@NT7S
Copy link
Member

NT7S commented May 2, 2019

Thank you very much, I will check this soon and push the change when I can verify the fix.

@sajjsamm
Copy link

I have the same problem with Arduino and bluepill too. in decoding the message with WSJT-X the last char of message is getting truncated. the SquirrelEng solution didn't work for me.

@dl9sau
Copy link

dl9sau commented Aug 18, 2021

I had the same problem.

Plus another problem:
a normal message like "73 DL9SAU" is interpreted as hex telemetry.
The code checks for hex until blank. If blank is reached, or end of string, the function ends. It has detected at this stage "73" as hex string. -> 0x73..... (rest are fill characters) are transmitted.

Furthermore, there is much useless copying aroound array c18.

-> This fixes the issues:

--- a/src/JTEncode.cpp
+++ b/src/JTEncode.cpp
@@ -839,9 +839,9 @@ void JTEncode::ft8_bit_packing(char* message, uint8_t* codeword)
 	uint8_t n3 = 0;
 	uint8_t qa[10];
 	uint8_t qb[10];
-	char c18[19];
+	//char c18[19];
 	bool telem = false;
-	char temp_msg[19];
+	//char temp_msg[19];
 	memset(qa, 0, 10);
 	memset(qb, 0, 10);

@@ -852,10 +852,14 @@ void JTEncode::ft8_bit_packing(char* message, uint8_t* codeword)
 	// Has to be hex digits, can be no more than 18
 	for(i = 0; i < 19; ++i)
 	{
-		if(message[i] == 0 || message[i] == ' ')
+		//if(message[i] == 0 || message[i] == ' ')
+		if(message[i] == 0)
 		{
 			break;
 		}
+		// bugfix: "73     DL9SAU" was interpreted as hex message. Check further for non-hex-character
+		else if (message[i] == ' ')
+			continue;
 		else if(hex2int(message[i]) == -1)
 		{
 			telem = false;
@@ -863,7 +867,7 @@ void JTEncode::ft8_bit_packing(char* message, uint8_t* codeword)
 		}
 		else
 		{
-			c18[i] = message[i];
+			// c18[i] = message[i]; // not necessary. only if telemetry, it's used. First thing done below is, set c18 to 0.
 			telem = true;
 		}
 	}
@@ -882,6 +886,7 @@ void JTEncode::ft8_bit_packing(char* message, uint8_t* codeword)
 			}
 		}

+#ifdef notdef
 		memset(c18, 0, 19);
 		memmove(c18, message, i0 + 1);
 		snprintf(temp_msg, 19, "%*s", 18, c18);
@@ -895,7 +900,10 @@ void JTEncode::ft8_bit_packing(char* message, uint8_t* codeword)
 	      }
 	    }
 		strcpy(message, temp_msg);
-
+#else
+		for (char *p = message; *p; p++)
+			if (islower(*p)) *p = toupper(*p);
+#endif

 		uint8_t temp_int;
 		temp_int = message[0] == ' ' ? 0 : hex2int(message[0]);

dl9sau pushed a commit to dl9sau/JTEncode that referenced this issue Oct 10, 2021
This fixes problems with FT8 HEX messages, as described in
  etherkit#18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants