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 https://github.com/swharden/WsprSharp/blob/78fbbcc09630a3ff3dae6361db3b3a6fc6910832/src/WsprSharp/Encode.cs#L84-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

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:

https://github.com/swharden/WsprSharp/blob/2edfd65a1439403468b2477bb242b1a0f7ed6473/src/WsprSharp/Encode.cs#L76-L101

I added tests to confirm it performs as expected. Are there any additional test cases you think I should add here? https://github.com/swharden/WsprSharp/blob/2edfd65a1439403468b2477bb242b1a0f7ed6473/src/WsprSharpTests/CallsignTests.cs#L9-L15

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)