Implement a slowrx daemon #12
Conversation
|
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. |
|
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. |
|
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 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 Anyway, as I say it seems to be working… not fully debugged, but good enough to be actively used. :-) |
sjlongland
force-pushed
the
slowrx-daemon
branch
from
4b9148f to
a20760a
Compare
There are a couple of exceptions to the even parity rule: - Robot 12 monochrome - Wraase SC-2 60 So use an 8th bit to encode that information in the table. This is in line with KB4YZ's VIS header reference.
This is reverse-engineered from QSSTV by first implementing an encoder for it that QSSTV's W260 decoder agreed with… *then* using the specifications determined to implement the decoder in `slowrx`. Aside from an occasional horizontal offset (which seems to be a common issue with all modes… might be related to "where" in the 1024-sample FFT frame the SSTV image is first seen), it seems to agree with QSSTV's decoding of the same reference audio sample.
These mean we can move different parts out to separate header files, and `gcc` will generate the dependencies so we don't have to keep them up-to-date in the `Makefile`. If something changes then, `make` knows exactly what to rebuild.
At some point, we'll make it possible for the user to rename output files or specify which ones to compile and install (e.g. for a headless daemon-only installation).
`gui.c` seems to reference `aboutdialog.ui`.
`gcc` is figuring this out for us now.
Tried playing with this to see if I could get a "better" looking FFT for waterfall generation purposes.
This allows us to implement audio dump hooks to dump recordings of the incoming audio.
This causes the recording of the SSTV image to be dumped to a file (Sun audio format, because it's dead simple to implement) for later replay.
Wrong variable, twit!
These waste a lot of space in the JSON output as most of the 2048 buckets are zeroes.
Some radio interfaces use a stereo input to support two mono receivers (e.g. NWDR UDRC-II and DRAWS both have this). This allows for selection of one channel over the other, or the option of mixing both channels together. The default is to use the left channel, as that matches what the audio subsystem did prior to this feature being added.
Copy of what's live on https://static.vk4msl.com/sstv/
W3C's own site code has a broken link, who knew?
The former doesn't reset the environment, meaning we can pass things like unix domain socket paths.
Robot72 is a simpler mode than Robot36 with a scan line that basically is unchanged in format for each row: - 1200 Hz for 9ms - 1500 Hz for 3ms - Y scan for 138ms - 1500 Hz for 4.5ms - 1900 Hz for 1.5ms - U scan for 69ms - 2300 Hz for 4.5ms - 1900 Hz for 1.5ms - V scan for 69ms This is in contrast to R24 and R36 which alternate between sending U and V on even and odd rows.
Y channel starts at 12ms (9ms SYNC + 3ms PORCH) U starts at 156ms (after Y scan + 6ms of separation pulses) V starts at 231ms (after U scan + 6ms of separation pulses)
sjlongland
force-pushed
the
slowrx-daemon
branch
from
89288ba to
50b438d
Compare
Not sure how this got lost, but it did!
|
@sjlongland i just tested your daemon. Works great - thanks for that! 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. |
|
@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. |
|
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 So I may need to re-visit this, but for single-radio set-ups, this is not a show-stopper. |
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
systemdto make a headless SSTV receiver, optionally running a script that can perform actions on the received images.stdint.handstdbool.h)fftw_complexbecomes atypedeffordouble complexifcomplex.his imported, so that has been done to further reduce the non-standard types.libgdto write the image file, simply because this is more likely to be available on a headless server than a GUI library like GDK.The code is a little rough, but seems to be working.