Background WSPR decoding not working, from Manual Installation

[cjritola]

Describe the bug Background WSPR decoding does not appear to be working.

To Reproduce Ran separate radio w/ WSJT-X, tuned to 40m, no spot uploading, watch spot list. Openwebrx settings: enable background services, enable WSPR background decoding, spot uploading enabled, valid callsign, keep device running at all times, static schedule set up to switch bands hourly when inactive (probably not relevant but who knows), restart systemd unit. Loaded openwebrx in browser, switched to 40m, random mode/spot on dial. Wait 1 hr. List of spots on WSJT-X with separate radio No spots uploaded by openwebrx. ...same issue if openwebrx is closed and left overnight, no spots uploaded.

Control Variable Again, ran separate radio w/ WSJT-X, tuned to 40m, disable spot uploading to avoid dupes going to server, watch spot list. Manually tune openwebrx to same WSPR frequency, enable WSPR mode.

Both spot lists now populate similarly. WSPRnet lists the spots from openwebrx.

Expected behavior Expected at least one spot to have been uploaded by background decoder without having to manually tune and set mode.

Installation method Manual installation, December 20, 2021

Versions WSJT-X version 1.1.0

Log messages

Dec 21 10:59:00 host openwebrx.py[19588]: 2021-12-21 10:59:00,001 - owrx.service.schedule - DEBUG - source seems to be idle, selecting profile for background services
Dec 21 10:59:00 host openwebrx.py[19588]: 2021-12-21 10:59:00,003 - owrx.service.schedule - DEBUG - schedule did not return a current profile. checking next (future) entry...
Dec 21 11:00:00 host openwebrx.py[19588]: 2021-12-21 11:00:00,001 - owrx.service.schedule - DEBUG - source seems to be idle, selecting profile for background services
Dec 21 11:00:00 host openwebrx.py[19588]: 2021-12-21 11:00:00,002 - owrx.service.schedule - DEBUG - selected profile 212f2201-1b1a-4b8a-a311-1afcdac2b606 until 2021-12-21 16:59:00
Dec 21 11:00:00 host openwebrx.py[19588]: 2021-12-21 11:00:00,003 - owrx.source - DEBUG - activating profile 212f2201-1b1a-4b8a-a311-1afcdac2b606 for rtlsdr
Dec 21 11:00:00 host openwebrx.py[19588]: 2021-12-21 11:00:00,007 - owrx.source.connector - DEBUG - sending property change over control socket: center_freq changed to 28900000
Dec 21 11:00:10 host openwebrx.py[19588]: 2021-12-21 11:00:10,010 - owrx.service - DEBUG - re-scheduling services due to sdr changes
Dec 21 11:00:10 host openwebrx.py[19588]: 2021-12-21 11:00:10,011 - owrx.service.schedule - DEBUG - source seems to be idle, selecting profile for background services
Dec 21 11:00:10 host openwebrx.py[19588]: 2021-12-21 11:00:10,014 - owrx.service.schedule - DEBUG - selected profile 212f2201-1b1a-4b8a-a311-1afcdac2b606 until 2021-12-21 16:59:00
Dec 21 11:00:10 host openwebrx.py[19588]: 2021-12-21 11:00:10,015 - owrx.service - DEBUG - no services available
Dec 21 11:00:10 host openwebrx.py[19588]: 2021-12-21 11:00:10,017 - owrx.source - DEBUG - activating profile 212f2201-1b1a-4b8a-a311-1afcdac2b606 for rtlsdr

Additional context

[jketterl]

Log messages indicate that no services available. Please check your bands.json, in particular if the WSPR frequencies are set up correctly. You can refer to the one provided with OpenWebRX for examples. Please also make sure to check for other copies of the file that may interfere with your setup, the bands.json in your checkout has a higher priority than /etc/openwebrx/bands.json.

[cjritola]

The bands.json from my checkout is unchanged. It looks fine for the most part.

In the 80m section it specifies WSPR to be on 3592600 but WSJT-X 2.5.2 specifies it as 3568600 Could it have been moved since, or perhaps a regional difference? All other entries check out. 630m and 2.2km bands are missing WSPR but no big deal. JS8Call on 11m. Well that's news to me. (-:

I have no /etc/openwebrx/bands.json This was a fresh build. No manual editing of files.

Programmatically, what is the cause of'no services available'? Services were obviously specified in the configuration. Does it mean that for the given profile's frequency range it was unable to find a service which could be applied to said range?

[jketterl]

no services available means that after evaluating both the selected modes and the available frequencies for the frequency range of the current profile, no background services were found to be started. If there is services available, you should see log messages about them being started. If the frequencies are correctly set up and all requirements are met, the corresponding green (!) bookmarks should show up in your receiver, and clicking them should immediately start decoding.

The WSPR frequency for 80m has been recently updated (see #281). I was not aware of that change, even though I am subscribed to the wsjt-devel mailing list, so it will only be in the next release.

[jketterl]

Also, when testing, please monitor the receiver map for spots. The WSPRnet reporting API has its own set of problems, and often spots get lost on their way there.

[cjritola]

Cause: When a program is launched from systemd its working directory is generally not the directory in which the program resides unless the service file specifies it. When openwebrx launched it did not find /etc/openwebrx/bands.json because it didn't exist, and could not find bands.json in the checkout because it is not part of systemd's working directory.

Solution: If no /etc/openwebrx/bands.json is present, create one or create a symbolic link from bands.json in the checkout to /etc/openwebrx/bands.json.

This fixed the issue and now not only does WSPR work but a lot of new frequency markers showed up in the UI. The map is working well.

There were also errors in the times set in the schedule, particularly AM/PM which created conflicts. Also, a few profiles at the MF end had bandwidths wider than the frequency itself allowed.