Implement Wraase SC-2 60

[sjlongland]

I implemented this myself in libsstvenc, got it more or less decoding correctly in QSSTV, then used those timings for slowrx.

A reference file and demonstration of the decode is provided below.

wraase-sc2-60.mp4

[windytan]

Hi, thanks for the contribution. As I don't have the time to maintain slowrx any more I'll be archiving this repository soon. Would you like me to add a link in the readme to point users to your fork instead? There are also other forks I'm thinking of linking to.

[sjlongland]

I've been giving this some thought… I don't get a lot of spare time myself but I recognise that I've been quietly chipping away at this project and keeping it alive. It's not a big priority from my end. It works, gets the job done. Maybe not 100% optimal, the FFT-based approach is showing some limitations in terms of synchronisation which leads to "slant" issues but it got things working "good enough" for my use case.

I'd like to take it further but I'll have to revise my DSP knowledge to make a big impact, so it takes a back seat for now. As it is now, it's a great little SSTV receiver.

Looks like @parabirb has taken the fork even further. So there's plenty to pick from.

I think it's worth shopping around and see if one of the other maintainers might have the resources to be more active, and I contribute my improvements there, but I leave the ultimate decision to your judgement. :-)

[parabirb]

I've been giving this some thought… I don't get a lot of spare time myself but I recognise that I've been quietly chipping away at this project and keeping it alive. It's not a big priority from my end. It works, gets the job done. Maybe not 100% optimal, the FFT-based approach is showing some limitations in terms of synchronisation which leads to "slant" issues but it got things working "good enough" for my use case.

I'd like to take it further but I'll have to revise my DSP knowledge to make a big impact, so it takes a back seat for now. As it is now, it's a great little SSTV receiver.

Looks like @parabirb has taken the fork even further. So there's plenty to pick from.

I think it's worth shopping around and see if one of the other maintainers might have the resources to be more active, and I contribute my improvements there, but I leave the ultimate decision to your judgement. :-)

i mostly just have that fork (which is a fork of @ke5gdb's fork) because the robot 24 implementation wasn't working; that's all i fixed. i haven't written my own C in a while, so

[ke5gdb]

I nominate @sjlongland. I've been using your daemon version for an SSTV skimmer and discord bot, and it has been working great.

[sjlongland]

Sounds like I should round up the various forks and see if we can merge them into a new release.

Some things I'd like to probably move forward with:

• further separate the decoder functions by moving those into a shared library (.so / .dll / .dylib) with an API that programs can build against
• abstract the audio interface so we can support audio I/O interfaces other than ALSA (which will help address issue pipe input? #3 and issue Running on FreeBSD #9, particularly if the OS doesn't support libalsa)
• add support for more SSTV modes (e.g. MP narrow band modes)
• investigate the feasibility of a DPLL-based detector instead of using FFT
• might see if I can get some sort of common OS packaging going for armhf, aarch64 and x86_64 platforms

I'm open to others' ideas, as I'm sure some of you have been doing SSTV longer than I've been alive.