Implement a slowrx daemon

[sjlongland]

This pull request separates the SSTV decoder logic from the UI a little bit, allowing a separate command-line only SSTV daemon to be implemented.

This daemon could be started via means such as using systemd to make a headless SSTV receiver, optionally running a script that can perform actions on the received images.

• The core library now uses standard integer and booleans (stdint.h and stdbool.h)
• Rather than directly calling GTK routines, the core and UI communicate via shared global variables and callback functions (function pointers).
• FFTW3's fftw_complex becomes a typedef for double complex if complex.h is imported, so that has been done to further reduce the non-standard types.
• The daemon uses libgd to write the image file, simply because this is more likely to be available on a headless server than a GUI library like GDK.
• The GUI functions as it does before and uses the same libraries for rendering output images.

The code is a little rough, but seems to be working.

[sjlongland]

For those interested … https://static.vk4msl.com/sstv/ is a demonstration of this branch.

Long term goal is to set this up on a bicycle-mobile radio station, so it can capture transmissions for me to respond to when I pull over, transmitting the responses as I move along.

[windytan]

Hi, big props for your work! I honestly haven't touched this codebase in a decade and can hardly recognize it. :) I promise to take a look at it at some point.

I actually have a 'competing' command-line tool (complete rewrite in C++) in my desk drawer but wasn't sure if there was a user base for it. I may end up publishing the code in the future, but it's up-in-the-air whether it will be called slowrx or something else.

[sjlongland]

Ahh, there's life in the old project yet. That said, feel free to push what you have, despite SSTV being a fundamentally "visual" mode, this does not mean a totally CLI implementation is useless.

I've seen SSTV signal generators on the CLI, and my thinking is to combine these, a CLI receiver, a SVG renderer and a web UI into something that can run "headless" on a Raspberry Pi or similar single-board computer, and either act as a pure receiver, or allow for bi-directional SSTV communication.

My use case is using SSTV whilst mobile. So the computer hooked to a transceiver using a tablet or smartphone as a UI. It receives, queues what was seen in the UI. If I wish to respond to something, I can pick one or more transmissions to respond to, it uses the SVG renderer to render a template with those images into a bitmap of the right size, maybe do some final editing on the UI device to insert comments (if you've got a stylus, they can be hand-written)… then the result sent back for transmission when there's a clear break (which the station can take care of independently of the operator).

In that way, a single operator could queue up some CQ SSTV images to transmit… start moving as they transmit… responses are collected… and at some point convenient to the operator, they can pull over and respond, maybe take some pictures and send those as SSTV.

I'm no expert in the GLIB/GTK+ ecosystem, so there are probably lots of things that could be done in this daemon. I'm more a Qt person myself, but really, the underlying infrastructure doesn't matter much so long as it works. :-)

I was tossing up either pulling apart slowrx to create slowrxd, or the other option was to pick apart qsstv. The code in this package looked "simple" enough, so I started with that, and it seems to be doing quite well.

I hope I've not changed the code formatting much… my habit is usually tab indentation (I find two spaces gets hard to read) and left-aligned asterisks on pointers and tried to keep to this style but may have slipped up in places. I'm tempted to try set up clang-format to replicate the project style and clean up any slip-ups.

Anyway, as I say it seems to be working… not fully debugged, but good enough to be actively used. :-)

[formtapez]

@sjlongland i just tested your daemon. Works great - thanks for that! I will use it in a few days to hopefully collect some pictures from the upcoming ISS SSTV experiment.

It would be cool to be able to bypass the ALSA system and directly read the audio from a pipe from stdin via rtl_fm or similar SDR tools.

[sjlongland]

@formtapez Glad it's working for you… yeah removing ALSA as a hard dependency for audio throughput could be a good next step. Issue #3 more or less requests this, and it could be very handy for SDRs and all kinds of set-ups to be honest.

[sjlongland]

One thing I just noticed today… selection of left vs right channel doesn't quite work as expected. I'm observing this particularly with my own set-up where I have one sound interface monitoring two different radios via different channels.

One slowrxd instance is supposed to be listening on the left channel (VHF; tuned to 145800kHz FM) and the other on the right (HF; managed via hamlib).

So I may need to re-visit this, but for single-radio set-ups, this is not a show-stopper.