Jump to:


Background

The purpose of this software is to enable binary data files to be transferred reliably, via a relatively poor audio channel. An example of such a channel is that used between Australia and the United States in 20 meter Single Side Band amateur radio transmissions.

Software for both the transmit side operations and the receive side operations is provided. The transmit side software requires the name of a file to be transferred and a choice of one of four levels of redundancy to be supplied to it. The result of the transmit side software is a wav file that represents the contents of the file to be transfered, at the chosen level of redundancy. Playing this wav file generates the audio signal that is to be transmitted to those who wish to have a copy of the file being transfered.

The receive side software requires the name of a wav file as its input. This wav file should be one recorded from a transmission of a wav file produced by the transmit side software. The receive side software, which is a program named "WAV2BIN", demodulates and decodes the information. If all the errors are corrected by the "WAV2BIN" program, then it will have stored a copy of the original file on the hard disk of the computer on which it ran (i.e. the file will have been successfully transfered).

This version of the software is a 'Win32 Console Application'. It must be run by the DOS_Prompt program with the processor in 32 bit mode. It will not work if the processor is in 16 bit mode.


Installation

To install this software, the distribution file must be unzipped into an appropriate directory on a hard disk drive. Whatever program you normally use to unzip ZIP files can be used to unzip the WEXE20D.ZIP file. There are two basic ways of installing this DOS_Prompt version of the software.

First Method

The first way is to have all of the executable programs (those whose extensions are "EXE" or "BAT") and the ancillary data files (those whose extensions are "FLT") in the a directory which is not listed in your PATH environment variable. The consequences of this choice are that you will need to have this directory be your current directory when running the software, and that the data files needed by the software have to be in this same directory. The data files are those you wish to send, and those you have recorded.

To see the directories listed in your PATH environment variable, execute the "PATH" command at the prompt of the DOS_Prompt program (i.e. start the DOS_Prompt program and type "PATH", without the quote characters, followed by a carriage return).

If you wanted to install the DOS_Prompt version of this software in a directory named "HDSSTV" in the root directory of your C: drive, you could create that directory with the following DOS_Prompt commands.

  CD C:\
  MKDIR HDSSTV
  

Of course this directory could also be created without using the DOS_Prompt program. You can choose any name for the directory that your system will let you create; the name does not have to be "HDSSTV".

Unzipping the distribution file into the directory of your choice completes this first method of installation.

Second Method

The second way is to have all of the executable programs (those whose extensions are "EXE" or "BAT") in a directory that is listed in your PATH environment variable and to modify the included HD-T.BAT file to reflect actual directory containing the ancillary data files (those whose extensions are "FLT"). Modification of the HD-T.BAT file is needed because the DOS_Prompt program does not support the "APPEND" command. The consequences of this choice are that any directory can be your current directory when running the HDSSTV software.

To see the directories listed in your PATH environment variable, execute the "PATH" command at the prompt of the DOS_Prompt program (i.e. start the DOS_Prompt program and type "PATH", without the quote characters, followed by a carriage return).

Unzipping the distribution file into a directory listed in your PATH environment variable will put all of the executable programs and the ancillary data files into that directory.

You can also put the HDSSTV software into a new directory that you create, and add this new directory to those already stored in your PATH environment variable. This accomplishes the same thing as putting the HDSSTV software into an existing directory already listed in your PATH environment variable.

Modification of the HD-T.BAT file

One line of the supplied HD-T.BAT file needs to be modified in this second method of installing the software. The original contents of the line to be modified are reproduced just below.


COPY /B 2TONE-03.FLT /B +CHIRP3B.FLT /B +MOD_OUT.FLT f2w_in.flt

  

The modification consists of adding parent directory information to the 2TONE-03.FLT and CHIRP3B.FLT file specifications, resulting in absolute path names for these two files. If you put these two files in a sub-directory called HDSSTV in the root directory of your C: drive, then the line in the HD-T.BAT file should be changed to the one listed just below.


COPY /B C:\HDSSTV\2TONE-03.FLT /B +C:\HDSSTV\CHIRP3B.FLT /B +MOD_OUT.FLT f2w_in.flt

  

You don't have to use a sub-directory named HDSSTV in the root directory of your C: drive. You just have to have the correct (for where you put them) absolute path names for the 2TONE-03.FLT and CHIRP3B.FLT files in the line of the HD-T.BAT file that refers to them.

Testing the Installation

From the directory containing the supplied DEMO.BAT script, execute this script as a DOS_Prompt command. When this script finishes, check that the files "MODE_DEF.H" and "B2S_IN.SAV" are the same.


Program Usage

Two batch files are provided. One, HD-T.BAT, for use on the transmit side, generates a wav file corresponding to the binary file to be transfered. This generated wav file provides the audio to be transmitted, in order to transfer the corresponding binary file.

The other batch file, HD-R.BAT, is for use on the receive side. It operates on a wav file and produces the corresponding binary file.

WARNINGS

The behavior of this software reflects the research environment in which it was developed. In some respects it behaves differently than you would likely expect. These differences in behavior are listed below.

Sampling Parameters

The short coming I expect to cause the most problems is the failure to check the sample rate and number of bits per sample in the .wav file header that is input to the "WAV2BIN program". None of the ".wav" recording programs I am aware of default to the 11,025 Hz, 16-bits per sample required by my program. Even I didn't always remember to select the correct recording mode, before making recordings of HDSSTV transmissions.

The good news is that other sample rates and bit depths can be converted to 11,025 Hz and 16 bits, and that recordings made at 22,050 Hz with only 8 bits per sample have decoded just as well as those made at 11,025 Hz and 16 bits per sample. The bad news is that my program will fail, without telling you why, if it is given a .wav file that is not 11,025 Hz with 16 bits per sample.

Overwriting files of the same name, without warning, is not very nice behavior, but BE WARNED, that is the way these programs work.

Audio Recording Program

If you use an audio recording program that creates a wav file corresponding to just the audio between the point at which you push the button to start recording and the point at which you push the button to stop recoding, then you should not have to do any editing of the wav file before operating on it with the WAV2BIN program.

If you use an audio recording program that creates a wav file containing data for only a portion of the signal you intended to record, then the WAV2BIN program will not be able to recover the original file. WAV2BIN must find the "leader" portion of the signal in the first half of the wav file and the "trailer" portion of the signal in the last half of the wav file before it will attempt to demodulate and decode the information. For example, if you wanted to record a signal that lasted for 70 seconds, and the wav file produced by the recording program you were using only had 60 seconds of data, the information conveyed by the missing 10 seconds of data can't be recovered by the WAV2BIN program.

If you use an audio recording program that creates a wav file containing not only the audio signal you wanted, but also whatever happened to be left over in some larger buffer, then you may need to edit this wav file to better isolate what you intended to record, before trying to use the WAV2BIN program on it. If the correct "leader" portion of the signal will be that first encountered, when searching the wav file from the front to the middle of the file, and the correct "trailer" portion of the signal will be that first encountered, when searching from the end to the middle of the file, then you may expect WAV2BIN to be able to operate on the wav file as it is. Otherwise, the wav file will need to be edited so that those conditions are met; the left over buffer contents included in the file, but which were not part of the signal just recorded, will need to be removed from the file to be operated on by the WAV2BIN program.

Transmit Side Disk Space Usage

The "MODPM" program uses a significant amount of disk space for temporary storage. The amount depends on the size of the file being transfered and the amount of redundancy used. The table below lists a factor which can be multiplied by the size of the file being transfered to yield an estimate of the peak amount of disk space that will be needed.

     amount of redundancy    factor for est. of disk space
     --------------------    -----------------------------
            10 %                     9200
            20 %                    10400
            40 %		    13600
            70 %                    26000
  

The above table is for files about 2000 bytes in length. The factor decreases slightly with increasing file size. An example of the use of the above table is: for a file size of 3000 bytes and 20 % redundancy, the estimated amount of temporary disk storage needed is 3000 * 10400 bytes. This is 31,200,000 bytes.

Receive Side Memory Usage

The "WAV2BIN" program dynamically allocates a significant amount of memory. To estimate how much extra memory will be needed, you can multiply the size of the "wav" file being operated on by 35. This factor increases with increasing file size. For a "wav" file of 500,000 bytes the factor is about 30. For a "wav" file of 2,600,000 bytes the factor is about 35; for this case the estimate of extra memory needed is 91,000,000 bytes.

In order for the "WAV2BIN" program to operate correctly, the sum of physical memory available to the program, after it is loaded, and the amount of swap space available must be greater than the amount of dynamically allocated memory needed by the program.

If you want to operate on large "wav" files, you may need to increase the amount of swap space available.

Transmit Side Batch File

The supplied "HD-T.BAT" puts both of the ancillary data files in front of the phase modulated signal representing the file being transferred. One reason for including the ancillary data files is to provide the person at the receiving end time enough to "push the record button". Having both ancillary data files in front of the phase modulated signal provides about 3.31 seconds of sound that is not used by the "WAV2BIN" program.

Before running the "HD-T.BAT" script, you can set whether, or not, you want the ancillary data files to come before the phase modulated signal. The instructions for doing this are in the "HD-T.BAT" file.

The "HD-T.BAT" script requires three parameters. The first parameter is the name of the file to be transferred. The second parameter is one of: 10, 20, 40, or 70. This second parameter specifies the percentage of outer code symbols that are redundant. The third parameter is the name of the wav file to be generated.

Executing HD-T without any parameters displays instructions for its use and then exits.

For example, the following command line:


HD-T  FILE.XYZ 20 file.wav

produces a file named "file.wav". Playing this wav file produces the audio signal to be transmitted in order to transfer "FILE.XYZ", with 20% of the outer code symbols being redundant, to those who are recording what they receive.

Receive Side Batch File

The "HD-R.BAT" script requires two parameters. The first parameter is the name of the wav file to demodulate and decode. The second parameter is the name of the file in which the information written to stdout by the WAV2BIN program is placed. The value of 12, in the HD-R.BAT script, may be changed to another value, if you desire. This number controls the amount of information written to stdout as the demodulation and decoding process proceeds. Comments near the top of the WAV2BIN.C file list the various values of this parameter that the program tests for.

The syntax normally used is:


HD-R recorded.wav recorded.txt

where "recorded.wav" is the name of the recorded wav file to be decoded and demodulated.

The "WAV2BIN" program writes information about the demodulation and decoding process to stdout. The last of this information is the name of the file in which the decoded results were placed and the number of bad blocks detected in the final result. If all of the errors were corrected, the number of bad blocks will be 0.

Redirecting stdout to a file with the same root name as the recorded ".wav" file, to which it pertains, is an easy way to keep track of this information.

Executing HD-R without any parameters displays instructions for its use and then exits.

If you want the stdout of WAV2BIN to be displayed in the DOS_Prompt window, rather than being saved in a file, you can execute WAV2BIN directly. WAV2BIN requires only one parameter, which is the name of the wav file it is to operate on.