Feature Request - WSPR spot upload to pskreporter

[dc7ds]

Hi Pavel,

i lately built up a WSPR decoder based on your marvelous software on a Red Pitaya 122-16. It does a great job, only one thing i miss is uploading the spots in parallel to pskreporter.info. WSJT-X does this and pskreporter is a great platform to get info and statistics about all sort of digimode activity, so this would be a great addition. Also, you already did the heavy lifting (IPFIX...) in your upload-to-pskreporter.c, so imho just other mode and colums selections would be needed.

BR
Stefan

[waterwin]

I am debugging the changes I did for this question.
I am stuck though.
Sending the same ipfix wrapped data to the pskreporter test port at 14739 does not give any insight in what is going wrong. Although it reports for the right ip address the package count is always 0

My approach:
change the ipfix wrapper line in upload-to-pskreporter.c for callsign and grid, as these are different for the ft8 decodes and the wspr decodes, one uses fixed columns the other a space between the data. This simple change did not result in wspr spots being uploaded to pskreporter.

&& sscanf(src, "%13s %4s", call, grid); >> && sscanf(src, "%s %s", call, grid);

For debugging I tried the test port at report.pskreporter.info 14739 instead of the normal port 4739. Package count is 0.
Then I tried the same test port in the working ft8 uploader. Still the package count is 0.
Other changes like setting a different soft parameter can be seen when posting ft8 to pskreporter so the process of changing the .c file and compiling is ok.

Either the test port is not working for this kind of direct from memory upload (memcpy).
Or it is not working at all.
Also same result when trying a command line approach

Other differences from ft8 to wspr
-no separate upload.sh > should not be relevant
-different filename (no timestamp) for the file that feeds the wrapper program > I do not suspect this to be relevant
-not adhering to the >= 5 minute period for uploading to pskreporter > this might be relevant but should not interfere for the first upload to the test port. If this is important than I need to separate decode.sh/upload.sh like for the ft8 implementation and cron the upload every 6th minute.

Any suggestions appreciated

Erwin

[waterwin]

Upon further study I see I interpreted the C-code wrong.
memcpy() is creating the buffer with the ipfix data
sendto() is used to copy the buffer to pskreporter at ip:port

Which makes this line in the previous comment incorrect :
Either the test port is not working for this kind of direct from memory upload (memcpy).

[waterwin]

Moving slowly, the 2 data files are different in more fields. Time and Freq differences are critical.

  | FT8 | WSPR
time | 131000 | 1448
dt | 0.23 | 0.2
freq | 10137692 | 10.140171
grid | @column | after space

time needs seconds
freq needs to be integer

sed -i 's/\.//2' wspr_spots.txt
sed -i 's/ /00 /' wspr_spots.txt

First SED replaced by
cut -c1-29,31-34,36- $RESULT as frequency in ALL_WSPR.TXT had a resolution of 10 mHz, and the result was a factor 10 too high

[waterwin]

Solution works, needed some finetuning so as to not miss spots when the decoder is still working and the uploader starts. Done.