I think I am on its way to track down the weirdness with Type 2 messages.
It seems they only show up if I am also running a receiver with the same call sign and suffix.

I if  run a TX sending SM7PNV/7 and a RX with call sign SM7PNV the TX messages don't show up until I change my RX call sign to SM7PNV/7
The Type 2 message don't contain a locator so it is taken from the RX instead of leaving blank.
This a slight problem as well.

So if I send type    1 message as SM7PNV with locator AA00
followed by a type 2 message as SM7PNV/7

the first message will have locator AA00 but the second message will not.
It will have the locator of my receiving station inserted

OK at least know I know how it works, not super useful in my applications.
I was thinking to use it for trackers that could have used the Type 2 message to differentiate between several trackers running at the same time
E.g several balloons or sea buoys operating with the same Call sign but with different suffixes

73
//Harry 

 

Harry

I am not sure exactly what is not right in your case, but I have checked the spots that Rob's scraper takes from wsprnet.org for the last ten days and there are many examples of transmit callsigns with prefixes and suffixes. For example:

DF4PV/M, DJ2WW/P, EA8/OK2SAM, G0SZI/A, GM4SJB/2, HR9/WA4DT, MM/M0VIK, SM7PNV/2, TA4/G8SCU, W5/VK2ARH, W6LVP/V, W7GDK/7, ZS3D/N

including, I see, your own call as SM7PNV/2.

In your email you wrote "SM7PNV/p", was the lower case p a typo? 
Your example "OZ1/SM7PNV" is exactly the same character count and distribution either side of the / as EA8/OK2SAM which is in the database.

So, I do not think there is a general problem, but I cannot see what you are missing in generating your own Type 2 messages. Sorry.

73
Gwyn G3ZIL

On Fri, May 14, 2021 at 10:27 AM, Harry Zachrisson - SM7PNV wrote:

SM7PNV

I think there are limits on the number of character+ digits in the type 1 and type 2 message fields in WSPR packets which your callsign/extension may exceed.
There is a good explanation of the WSPR packet format at https://dxplorer.net/wspr/msgtypes.html#:~:text=The%20normal%20WSPR%20message%20%22Type,of%20up%20to%20six%20characters.

For users registered with wsprnet.org, it seems that they use your registered tx/rx 6 character maidenhead location when recording your type 1 messages which contain only the 4 character locator.

The wsprdaemon.org clone of the wsprnet.org spot database makes no modifications of the spots delivered by the wsprnet.org API.  If anyone sees they don't match, then there is a bug I am not aware of.

I have been generating Type 2 messages but I can't see the prefix or suffix in the data on wsprnet.org.(e.g transmitted SM7PNV/p or OZ1/SM7PNV is shown as SM/PNV) 
I am guessing it is not reported from the WSJT-X client to WSPRnet.
They seem to be intact in pskreporter though.

Anyone that has information around this?
It just seems strange that WSPR has support for it in both the transmit and receive side but it does not show up in the database, or did I miss something?

73
//Harry - SM7PNV