Incorrect padding of short callsigns

[dj1yfk]

The code generator at https://swharden.com/software/wspr-code-generator/ produces wrong results for many call signs.

It simply pads spaces in front of the callsign until we have 6 characters:
https://github.com/swharden/WsprSharp/blob/main/src/WsprSharp/Encode.cs#L85

The encoding however demands that the third character is always a number, and only the first and the last three characters can be spaces/padding:
https://github.com/swharden/WsprSharp/blob/main/src/WsprSharp/Encode.cs#L36 ff

Therefore the padding only works correctly for 2x3 callsigns (AA0AAA - no padding needed) or 1x3 callsigns (A0AAA - single space padding in front bringing the number to position 3).

For all other callsigns, it pads incorrectly. Real life example described here https://www.qrpforum.de/forum/index.php?thread/14781-wspr-code-generator-gel%C3%B6st/ (DL3PB encoded as " DL3PB" which is not encodable, and the resulting bit pattern happens to be another valid callsign, "F0UPB")

[swharden]

Hi @dj1yfk, thank you for reporting this!

The current (incorrect) behavior left-pads the callsign with spaces to achieve 6 characters

WsprSharp/src/WsprSharp/Encode.cs

Lines 84 to 85 in 78fbbcc

	while (callsign.Length < 6)
	callsign = " " + callsign;

The encoding however demands that the third character is always a number, and only the first and the last three characters can be spaces/padding

Re-stating the correct behavior, the call sign must always contain:

• 2 characters (left-padded space)
• 1 number
• 3 characters (right-padded with space)

Is this description accurate?

[swharden]

Hi @dj1yfk, this is the new callsign preparation logic:

WsprSharp/src/WsprSharp/Encode.cs

Lines 76 to 101 in 2edfd65

	public static string SanitizeCallsign(string callsign)
	{
	if (callsign is null)
	throw new ArgumentException("callsign can not be null");
	// trim preceeding and trailing whitespace
	callsign = callsign.Trim().ToUpper();
	// If the 2nd character is a digit pad with a space
	if (char.IsNumber(callsign[1]))
	callsign = " " + callsign;
	// The third character must now be a number
	if (!char.IsNumber(callsign[2]))
	throw new ArgumentException("the callsign's second or third character must be a number");
	// Trim long callsigns to 6 characters
	if (callsign.Length > 6)
	callsign = callsign.Substring(0, 6);
	// Right-pad short callsigns with whitespace
	while (callsign.Length < 6)
	callsign += " ";
	return callsign;
	}

I added tests to confirm it performs as expected. Are there any additional test cases you think I should add here?

WsprSharp/src/WsprSharpTests/CallsignTests.cs

Lines 9 to 15 in 2edfd65

	public void Test_Callsign_Formatting()
	{
	Encode.SanitizeCallsign("ab0xyz").Should().BeEquivalentTo("AB0XYZ");
	Encode.SanitizeCallsign("a0xyz").Should().BeEquivalentTo(" A0XYZ");
	Encode.SanitizeCallsign("a0xy").Should().BeEquivalentTo(" A0XY ");
	}
	}

I'll look for screenshots of spectrograms for WSPR transmissions of short callsigns to ensure the encoded message is the same visually, and if I can confirm this is the case then I will redeploy the app and website

[swharden]

I found a short callsign (AJ8S) from this image https://swharden.com/software/FSKview/grabber.png

I then used the updated code to test the web interface with the following info

I used the grid square I found on QRZ and tried different power levels until I found one that made the trace appear correct

I think this is enough indication things are working that I can consider this issue solved and I'll deploy an updated web page and app, but if you have a better example please let me know

Thanks again for your input!

[swharden]

@dj1yfk you can test the latest version of the web interface here https://swharden.github.io/WsprSharp/

[dj1yfk]

Wow, that was fast! :-)
The updated version (at https://swharden.github.io/WsprSharp/) works fine and I think the tests cover the relevant cases.

Thanks & 73
Fabian, DJ5CW (ex dj1yfk)