Background decoding

OpenWebRX is capable of decoding many digital signal protocols making it useful as an automatic reporting station application.

Services

Right of the bench, OpenWebRX can decode all WSJT-X modes, JS8Call, as well as Packet, but will only do so when a user is connected and actively listening to one of these modes. Decoded station locations will be pushed to the built-in map. Colored squares indicate Maidenhead locators. Pins or symbols indicate stations beaconing a location via APRS or YSF.

The first step towards automatic monitoring is enabling "services". Services are decoders that will run automatically in the background, as soon as they detect that their frequencies are available on any of the SDR devices. For example, if you enable the service for FT8, and you have a user select the 40m band, the service will automatically start decoding FT8 on 7.074 MHz, while the user can listen to any other frequency or mode on the band.

As soon as the user disconnects, the SDR will shut down, and the background decoder will stop decoding. If you wish to keep your receivers busy, you can set up a schedule for each one of them, that will not only make sure that the background decoders have something to do, they also allow you to specify which frequency range should be available to decoding during specific hours of the day.

The background decoders and schedulers are designed not to interfere with user interaction of the service. A user requesting a specific profile will always take precedence over the scheduler selection. The decoders themselves use low scheduling priority, so that the user demodulation should still be possible, even if the CPU is saturated.

Enabling services

config_webrx.py holds background service settings (these are the default settings):

services_enabled = False
services_decoders = ["ft8", "ft4", "wspr", "packet"]

services_enabled controls whether or not background services are running. True (uppercase T required) to run.

services_decoder controls decode modes when their frequencies are in the passband. Valid values: ft8, ft4, wspr, jt65, jt9, packet.

Scheduler

Static

Schedules to listen on specific passbands allowing automated processing.

The example below illustrate tuning the

80m profile from 9pm to 4am
20m profile from 9am to 3pm
40m profile on the remaining slots between (all times are in UTC)

Start and end times must be 4-digits each separated by - (hhmm-hhmm). You can not set days, weekdays, or seconds. Any schedule may be set including SDR idle times - shut down unless a user is connected. Or, one profile may be scheduled all day long 0000-0000.

sdrs = {
    "airspy": {
        "name": "Airspy HF+",
        "type": "airspyhf",
        # ... other sdr options ...
        # ... removed for clarity ...
        "profiles": {
            "20m": {
                # ... removed for clarity ...
             },
             "40m": {
                # ... removed for clarity ...
             },
             "80m": {
                # ... removed for clarity ...
             },
        },
        # copy from here ...
        "scheduler": {
            "type": "static",
            "schedule": {
                "2100-0400": "80m",
                "0400-0900": "40m",
                "0900-1500": "20m",
                "1500-2100": "40m",
            },
        },
        # ... to here.
    },
}

Daylight

The "daylight" scheduler will calculate sunrise / sunset times and schedule your device for day / night operation respectively. You can optionally configure a "greyline" profile for the transition period (+/- 1 hour from sunset / sunrise).

sdrs = {
    "airspy": {
        # ... other sdr options ...
        # ... removed for clarity ...
        # copy from here ...
        "scheduler": {
            "type": "daylight",
            "schedule": {
                "night": "80m",
                "day": "20m",
                "greyline": "40m",
            },
        },
        # ... to here.
    },
}

Please Note: with the introduction of the daylight scheduler (January 2020), the config format has changed to allow for different scheduler types. The old config format is still supported for backwards compatibility, but at the same time deprecated. Please use the new format.

Reporting

Once your receiver is decoding any digital signals, you may as well share your spots with some networks so the transmitting station can find out about his range.

pskreporter

You can automatically upload your spots to pskreporter. Before you enable it, make sure you have set the receiver_gps to the correct latitude and longitude of the receiver's location. It is included in all the spots and will lead to irritating displays if it is not set up correctly.

pskreporter_enabled = False
pskreporter_callsign = "N0CALL"

pskreporter_enabled tells the system whether or not to send the sports to the network. Set this to True (uppercase T) to share your spots. pskreporter_callsign is the callsign of your station. This should be fairly straightforward if you're a ham, if you're not I suppose it's time to get creative. N0CALL is commonly used in such situations.

Please note that only decodes of the following modes are currently being sent to pskreporter: FT8, FT4, JT9 and JT65. This is just based on my personal perception of what's most appropriate, feel free to discuss.

APRS network

If your receiver is decoding any APRS signals, you can share them on the APRS-IS network. This is the default configuration:

aprs_callsign = "N0CALL"
aprs_igate_enabled = False
aprs_igate_server = "euro.aprs2.net"
aprs_igate_password = ""
# beacon uses the receiver_gps setting, so if you enable this, make sure the location is correct there
aprs_igate_beacon = False

aprs_callsign is the callsign you'd like your spots to be sent with. Differently than on pskreporter though, this callsign may be used by the network if your message is re-broadcast by other igate stations. Since this cannot be controlled by the reporting station, I suppose this is a feature only to be used by hams.

aprs_igate_enabled tells the system to start the decoder with the igate functionality enabled, which basically means that anything that's decoded gets fed back to the network.

aprs_igate_server is the server that you'd like to connect to. The default value is reasonable for pretty much anywhere of Europe, however, it is always recommended to check here APRS Tier 2 Network and Server Listing to find the server closest to your receiver.

aprs_igate_password is the password that, in combination with the callsign, identifies you on the network. Depending on the server software in use on the other side, this may or may not be optional. It can be generated here using valid Amateur Radio call signs.

aprs_igate_beacon tells the receiver to publish its own location on the network in intervals. Before enabling this, please make sure that the receiver_gps is set to the correct location of the receiver.

Please note: APRS data is forwarded to the network straight from the decoding software (direwolf).

WSPRnet

It is currently not possible to feed data back into WSPRnet due to the fact that the only API known to the author requires more information than the decoder is currently delivering.

The wsprd binary will write additional fields to a file called ALL_WSPR.TXT, which is also the same format that is required by the API. Due to the architecture of OpenWebRX, decoding will occur in parallel, and as such, I do consider that file to be corrupted by design. The output on STDOUT (which is parsed by OpenWebRX) is lacking some fields, and since the fields in the upload are only identified by their position, I would have to fake values for these fields, which I do not intend to do.

PA0ESH