a features request

[d9394]

The system create a new thread in the background, that will be an automatic decoder with WSPR/FT8/APRS(select by the configure file) and upload decode result to the wsprnet/spot/aprs.fi.

[jketterl]

There's already a feature in there that does (almost) what you requested. It's called services, and once enabled, it will scan the bands.json for any usable frequencies and start decoding. You can tell it which modes you want it to decode. By default, it will only run as long as a user is connected, however you can set up a scheduler per SDR device that will then tell it what profiles to run when no user is connected.

The services feature should be pretty straight-forward in the config, I'll see that I commit a scheduler example, too, since it has to follow a specific scheme.

[jketterl]

The spotting is currently implemented for pskreporter.info, only. I wanted to do wsprnet, but their API is pretty much "upload the ALL_WSPR.TXT file". Unfortunately, the way the decoding works in openwebrx, that file potentially gets corrupted, since it is accessed by more than one process at the same time. Unfortunately, there's some fields that the wspr decoder only writes to that file, so I cannot "fake" that upload.

[jketterl]

Almost forgot: aprs.fi works, too, thanks to direwolf. Just needs some config, too.

[d9394]

Roger, let me see. but why it must need a user connected, I hope the service is always run in the background after the system startup. don't let the mechanism be free , :relaxed:

[jketterl]

as i said, the scheduler takes care of that, it will tell your receiver what to listen on when there's no user. i just don't have an example at hand right now, i need to get onto my development machine first ;)

[d9394]

I think this way: let the receiver stay on the latest listener band or automatic change to the first define in bands.json ? :wink:

[jketterl]

Well, there's plenty of room for new strategies that might work for different scenarios. At first I wanted to implement a way to check the LUF / MUF and set up the shortwave receiver accordingly, unfortunately I couldn't find any reliable source for that kind of information. That's what brought me to the scheduler.

Selecting the "first" of anything has brought up unreproducable results for me, at least on some hosts. It seems that certain python versions do not really care about the sequence of arrays. You can still set up the scheduler to run on a specific profile for the whole day, that way you should get pretty much the same result.

[jketterl]

Here's an example of an sdr config with different profiles (I have stripped the actual profile value for clarity):

sdrs = {
    "sdrplay": {
        "name": "SDRPlay RSP2Duo",
        "type": "sdrplay",
        "profiles": {
            "80m": {
                ...
            },
            "40m": {
                ...
            },
            "20m": {
                ...
            },
        },
        "schedule":{
            "1800-0400": "80m",
            "0400-0800": "40m",
            "0800-1600": "20m",
            "1600-1800": "40m"
        }
    },
}

This is what the scheduler config would look like if you want it to run on one specific profile when idle (this would be the typical config if you'd like to run it as an APRS iGate):

sdrs = {
    "sdrplay": {
        "name": "SDRPlay RSP2Duo",
        "type": "sdrplay",
        "profiles": {
            "2m": {
                "name": "2m komplett",
                "center_freq": 145000000,
                "rf_gain": 3,
                "samp_rate": 2400000,
                "start_freq": 145725000,
                "start_mod": "nfm",
            },
        },
        "schedule":{
            "0000-0000": "2m",
        }
    },
}

You can also go crazy on your CPU and set up profiles spanning multiple bands (for example, with the 10MHz of an SDRPlay you can cover 160m, 80m, 60m, 40m and 30m at the same time). I am running that myself, but the higher the bandwidth, the more processing power you'll need. If you intend to do that, you should also increase the wsjt_queue_length, since you will probably receive more than 10 decoding jobs in bursts, which will probably lead to job overflows. I am currently running wjst_queue_length = 25 on my high-end machine.

Users can connect at any time and switch to whatever profile they want; The services will follow suit.

[d9394]

Roger, I have tested the schedule function, and I can see the decoded results in /tmp/decode.txt, that's so good. but how can I specified the aprs frequency ?

[jketterl]

You should also see lots of grid squares popping up on the map.

APRS frequency is configured in bands.json, its called "packet" there (which is not really accurate. I will need to get some better structures going). It is set to 144.8 by default, which is the default for all of Europe, as far as i know, so you'll have to edit it if that doesn't match your local situation.

I am aware that band allocations are variing across the world, so there may be the need to deliver multiple bandplans to chose from in the in the future, or maybe a way to edit it to your needs. Maybe there's even some API that I could pull the data from. But for now, it needs to be edited in bands.json :smile:

[d9394]

OK, I edit it for my location APRS service decode.