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. :-)