LaserScatter

System Requirements:

1. Software:
   • Java Runtime Environment (JRE) version 1.4 or later
   • 32-bit Windows OS (untested on Mac, 'Nix)
2. Hardware:
   • CPU-It runs on my W98/233/64Mb, but more would be better
     Untested on other platforms
   • Full-duplex sound capabilty (likely a problem on Linux systems)
   • Driver circuit for laser
   • Baseband AM laser receiver
   • Method of keeping CPU clock within 1sec of NIST (eg., GPS)

Installation:

java -jar laser.jar

This second method allow you to see any exceptions or program errors that get dumped to the console.

Principle of operation

Messages are sent using multi-tone FSK. Each character is assigned a unique audio frequency and is transmitted for 10 seconds. This is very similar to Barry Larkin's PUA43 protocol. This slower transmission speed allows for detection of extremely weak signals, orders of magnitude beneath what could be detected by ear.

The tones are placed in two ranges: 20-25Hz ("bottom") and 26-31Hz ("top"). In a normal situation, a station transmits on the opposite band from the one he is listening on. This should allow for full-duplex communication provided that one's back-scatter signals do not bleed into the passband. These frequencies were chosen to avoid any manmade interference from 50Hz or above while passing through the input capacitors of most soundcards. Click here for the table of characters and frequencies.

Trasmitting:

The program sends a square wave at 16x the transmission frequency from the soundcard output. The benefits are two-fold. Firstly, this allows the use of a divider (such as a 4060) to generate a 50% duty-cylce square wave at the fundamental, which can easily drive a transmitter. Secondly, this eliminates any interference through poor isolation between the inputs and outputs of the soundcard. I have been able to drive a 4060 by using a step-up audio transformer, though just barely. Click here for a block diagram. This circuit amounts to using an audio transformer to produce enough audio to replace the crystal in my super easy laser transmitter. A better solution might be to amplify the output and drive a Darlington pair to saturation to create a square wave at TTL voltages.

Receiving:

You will need to ensure that your soundcard is not saturated by audio from the receiver. If it is, the signal will be clipped and you will loose weak-signal sensitivity. Many audio programs provide a level input monitor to help you adjust this. I'll likely provide one once I figure out how to do it. Though it may seem counterintuitive, there is no need to filter out the strong interference from city lights provided that system does not clip the signal anywhere in the receive path-the FFT algorithm will sort it all out!

Operation:

• The program runs on an automatic timer, much like WSJT. Pressing the "auto" button will toggle it to on. Transmission will start when the CPU clock reaches the next integer multiple of 10 seconds. The program displays the character it is currently sending in the "TX now" box. You may turn off the automatic timer by pressing the "auto" button a second time. The TX and TX bands can be selected with the check-boxes. It is possible to transmit and receive on the same frequency band to allow for bench testing.

• The messages must contain uppercaseletters, numbers, spaces, or '/'. In addition, the lowercase 'o' is provided for the signal report, $ for "RO" , and lowercase 'r' for "roger". Given the weak-signal nature of tropospheric scatter EME practices seem appropriate.

• The program begins recording audio a moment after the start of the transmission. This data is saved to a .wav file in the program directory. (The filenames run in a loop between "0.wav" to "30.wav", so as not to eat all space on the harddrive over several hours). After each 10-second cycle the .wav file is analyzed and the data is displayed on the screen. The amplitudes of the characters' frequencies are represented by the yellow bars in the spectrum window. The strongest frequency in the range of characters is mapped to a character which is printed below the spectrum window. With relatively strong signals (though still at amplitudes that would be far from audible) this will produce readable text, much like very slow teletype.

• To decode even weaker signals, one can enable averaging by checking the box on the bottom right of the screen. Once must know the length of the message to do this. The averaging should produce ~1.5dB of S/N improvement for every doubling of the number of receive periods. The thin red bars in the spectrum window are the relative amplitudes of the character frequencies after averaging. The average message is printed in the top right textbox after each receive period.

• You may wish to create test files with an audio editor and open them here. (The program will only look at the first 8.2 seconds of the file.) One can open files from the File menu for analysis. You may select multiple files which will be read in alphabetial order. This is a quick way of testing the averaging algorithm.

• There are various FFT windows on the bottom left. These are provided for your experimentation. The rectangular window seems to be the best on the bench, but perhaps under certain conditions others will be better. Let me know what you find out.

• The "fudge" parameter is an adjustment of the computer's transmitter frequency, similar to an XIT. This is in place because two soundcards often do not agree on what the "correct frequency is". The frequency accuracy on many laptops is often no better than a few parts per thousand. The way to adjust this is to get both computers in the same room and exchange data with strong signals. The spectrum may be unbalanced, causing energy to spill over on one side of the correct tone, or possibly even be off by a character. The fudge factor is multiplied by the tone frequency, so this is only likely to move a few thousandths. Setting it to "1.000" means that the computer is transmitting and receiving in the same place, wherever it thinks that is. Presumably most soundcards use the same time source for both input and output, so if one computer has to fudge upward in frequency, the other probably has to fudge down.