I suspect the world would be better if that percentage were even greater.
An impractical classic SSTV decoder…
A few days ago, I posted a .WAV file for a classic 8s SSTV image and asked if anyone could decode it. Nobody replied (I wasn’t surprised) so I set about writing my own demodulator.
Since I’m inherently lazy, here was my idea: generate the complex signal using my previously debugged Hilbert transform code. Then, for every adjacent pair of complex numbers, determine the angle between the adjacent samples by normalizing the numbers (so they have unit length) and then computing the dot product between the two. If you’ve done as much raytracing as I have, you know that the dot product of two vectors is product of their lengths and the cosine of the angle between them. So, you take the dot product, pass that through the acos function, and you’ll get an angle between 0 and $latex \frac{\pi}{2}$. You can then multiply that by the sample rate (and divide through by $latex 2\pi), and you can recover the frequency.
So, that’s what I did. If the frequency was in the band between 1500 and 2300 hz, I mapped that into a grayscale value. For values which were below 1500, I set the pixels to black. For values > 2300, I set the pixels to white. I generated one output pixel for every input sample. That means the image is too wide, but that’s no big deal: I resized it to 120 columns wide using some of the netpbm utilities (command line graphics programs).
And, here’s the image:
That’s a bit teeny, so let’s blow it up to 512×512:
Not too bad for a first try. Some thoughts: the sync pulses seem really wide to me. The spec says the sync pulses should be 5ms wide, which means they are about 7.5% as the line length. That’s a lot of the image to leave behind. I’ll have to work on that. I’m not currently doing anything to detect the vertical or horizontal sync pulses, but I’ve done that before with my NOAA weather satellite code, so I don’t anticipate any real problems. All in all, not a bad first try.
Addendum: The large image shows some JPEG compression artifacts since I expanded it from the small JPEG image without trying to save it at high quality. I can do better.
Addendum2: I decreased the overall filter size to length 11. It didn’t work very well, because the original file was at 22050, which pushes makes the portion of the spectrum we are interested in down into the region of the filter reponse which isn’t very uniform. But if we resample the sound file down to 8Khz, we filter works just fine with just 11 taps. Check it out:
The image is slightly skewed because the line length is no longer an integer number of samples, and the accumulated error causes the sync to drift slightly. A real implementation would track this accurately.
Comments
Comment from Ken Paulson
Time 9/29/2011 at 6:47 am
Alas, I also sent a file to your arrl address, but I wonder if the service blocks attachments. Oh Well.
Ken
N0HRL
Comment from Jani Sakki
Time 1/2/2014 at 10:21 pm
Hey, I tried implementing the process you used to calculate the frequencies. But range get is form 190-19000. could I get an example how the you calculate inputs?
Comment from Steve Anderson
Time 10/11/2015 at 12:18 am
I’m not sure if you’re still working on this, but I have demodulated and displayed the image. Not being a member of the ARRL I cannot send a message except via this method – and no attachments it seems.
Comment from Eric Baker
Time 9/29/2011 at 5:16 am
Mark,
Check your mail. I sent you a decode of the audio 2 days ago to your ARRL address. Perhaps it got stuck in there somewhere.
Anyhow, here is a link to my image: http://satilla.com/wy/mark.bmp
I used MMSSTV software which does the 8 second BW mode.
73
Eric / WY7A