Erik VK4AES Explains his development of the software.
Some time ago I became interested in a new digital mode, then called "High Definition SSTV". It was the brilliant work
of Barry Sanderson, KB9VAK. At that stage, the HDSSTV programs were for LINUX only, and stayed that way for some
years. Recently, these programs were ported to Windows, so I could not resist the challenge to see if I could make up an
easy to use GUI with these DOS executables. To use these routines "as is" was not for the faint hearted. I soon had a
working program, and was delighted with the results. After a computer crash, when I lost all my source code, I made a
fresh start and decided to make an all mode program, combining the usual analog and digital. Thus SSTV-PAL Multi
Mode was born.
JE3HHT and the digital was handled by the DOS executables from Barry. There were many problems getting all the
functions to work together. The C++ DLL and DOS executables were all having a fight with Visual Basic. It took many
hours and cups of coffee to make the program stable. On the other hand it has also given me many hours of enjoyment.
I hope this was also the case with the tireless team of beta testers. Thank you, thank you !! Receiving exact copies of the
transmitted data, whether it be pictures or any other type of file, has opened up many new exciting possibilities.
The characteristic of slow digital decoding of the received picture can be a draw back for slow computers. I think
this may be excused when it is realized just what the decoding entails. The file to be transmitted is encoded with a
"Reed Solomon" redundancy routine. You might say that if the redundancy is set to 20%, then 20% of the file can be
destroyed by band conditions, but can be repaired. These codes are particularly suited for radio as they perform
well for "burst errors" where small segments are completely destroyed such as in a static burst.
The "Reed Solomon" codes are already used in your HDD and CD drives. That is why a scratched CD might still work.
The same system is used in many telemetry signals from satellites.
This encoded file is then converted to a wav file, where the data is reordered by a "Fast Fourier Transform" to be
frequency sorted. The bandwidth of this data is restricted so that the data can be sent 8 times (eight carriers in the waterfall
display), each holding its own data, but with different frequency offsets. The bandwidth now nearly equals a normal SSB signal.
Successful decoding only needs some of these carriers to survive fading, QRM etc. Even then, these best of the bunch
carriers can contain some errors.
Now, Imagine the work the computer has to do to decode this received audio mixture. Actually, the decoding is
quite fast, the majority of the time is taken by conditioning the received file first. The slightest mistuning, drifting
transceiver or soundcard mistiming will change the audio pitch, and make decoding a failure. The program can
compensate considerably, so looks at the leader and changes the audio offset to bring it on tune. This gets everything on
frequency at the start, but what if the sound card timing is different at both ends. In this case the trailer will have
moved in frequency.
So by comparing the leader and trailer, sound card differences can be compensated for. The actual file is sent in "blocks"
and each individual block has to be treated separately. This requires many passes through the file, so takes time. Now the
decoding is started, faster if there are no errors. How the errors are corrected needs a University degree to understand;
thanks Barry. These corrections may need thousands of comparisons for every byte of corrupted data, and there are eight sets.
I can feel the CPU getting hot.
My explanations are only a tiny part of what really goes on, and by presenting it so simply,
there are many
omissions and probable technical inaccuracies and approximations.
Further development is taking place, so new things will always be coming up.
73's de Erik VK4AES.
|
