SLICER's minimum hardware requirements are a 4.77 MHz 8088 CPU and a CGA video adapter. A serial port or two wouldn't hurt either.
Note: The SLICER program and accompanying documentation may not be copied in whole or in part to any web site, CD-ROM, bulletin board, or network without the express written permission of the program author. All distribution rights are retained by the program author.
The SLICER program is for personal use only, and any copying for personal use is permitted and encouraged. Commercial use of the SLICER program is prohibited.
Connect your slicer to the PC's serial port and to a receiver (scanner, etc.) that is tuned to a continuous data stream (Motorola trunk data channel, G.E. EDACS data channel, fax data, Morse code, etc.) If a data stream is unavailable, tune the receiver to an empty frequency (one that produces just static when the squelch is turned down).
SLICER should be run from DOS (not from a Windows DOS session). If you are running Windows 3.x, exit Windows. If you are running Windows 95 or higher, select Shutdown / Restart in MS-DOS Mode.
Run SLICER. The program will indicate which serial ports are installed on your PC. Rerun the program with the appropriate port number (1 through 4) added to the command line (type one of: SLICER 1 / SLICER 2 / SLICER 3 or SLICER 4 at the DOS prompt). If the program lists more than one port and you aren't sure which one your slicer is connected to, just try them all in turn.
If you get the message
"Can't initialize COM port"
you've selected a non-existent port.
If you pass that hurdle, but the display shows
"Interrupt count: 0"
and
"0 interrupts per second"
possibilities include:
If you're powering the slicer from the serial port, you can try pressing 'R' to reverse the polarity of the +/-12 volts that is present on the DTR and RTS pins. If your slicer uses a bridge rectifier (four diodes) to route power, it should run fine with SLICER in Normal or Reversed power mode. Speaking of power, apparently, some newer PC's with serial ports on the motherboard don't provide enough power to run a slicer. Just something to consider.
If you have a voltmeter, you can check for correct voltages on the various op-amp pins. All voltages are relative to circuit ground:
+ power pin - +11V to +12V
- power pin - -11V to -12V
+ signal pin - 0V
- signal pin - 0V
Some older laptops provide +/- 5V on the DTR and RTS pins instead of the normal +/- 12V. The best thing to do in this situation is to wire the op-amp power pins directly to the DTR and RTS pins (+ pin to RTS, - pin to DTR), rather than through a bridge rectifier. If you go this route, be sure to connect a diode between the op-amp power pins such that if the voltages on DTR and RTS are reversed, the diode will conduct and protect the op-amp. The diode should be rated for 50 PIV or better. BTW, a slicer wired in this fashion may also be used on PC's that provide the standard +/- 12V levels.
If the slicer is generating interrupts, the program will indicate which pins on the serial port are active (sending data or noise to the PC). One or more of CTS, DSR, RI, or CD will show as active pin(s). The RI pin is not a good choice for getting slicer data into your PC. The other three pins are all equally suitable for the job, although some decoding programs require that the data be on a specific pin.
The program also shows the current state (high or low) of each of these four pins.
The interrupts per second counter is a good indicator of signal quality. The 3600 bps stream from a Motorola trunk should generate 1700 to 2000 interrupts per second. A 4800 bps MDT signal will run 2500 to 2600 IPS. 9600 bps EDACS data will get you 3500 to 3700 IPS. A channel with no signal (just static) should generate 3000 to 5000 IPS.
If the IPS count is lower than expected, the audio signal level reaching the op-amp is probably too low. Check for poor connections or adjust the design of your circuit.
A higher than expected IPS count indicates that the audio signal is dirty (excessive hiss, try adjusting antenna) or that the op-amp is getting too much signal (add resistance between the signal source and the op-amp) or perhaps that the DC power to the op-amp is unstable (needs 0.1 uF or better ceramic capacitors across op-amp power pins and circuit ground).
When the interrupt count reaches 8000, the program will generate a spectrum analysis display. Clean digital signals will produce a display with well defined spikes similar to this screen shot:
If your display looks like that, you're in fine shape. The number of spikes is dependent on the format of the data. A Morse signal should produce only one spike, since there is only one frequency present in the audio signal. Once you get a display that looks like the above, use SLICER's visual feedback to adjust your antenna position and orientation for maximum signal quality (narrow spikes with minimal spreading at the base). Adjusting the audio signal level to the slicer can also be used to clean up the display.
Dirty or overdriven signals will get you this sort of mess:
You're sure to get data errors from this type of signal. Adjust the antenna or reduce the signal level to the slicer to clean it up. You may also get this sort of degradation if you haven't conditioned the PC power feeding your slicer. You should have 0.1 uF or better ceramic decoupling capacitors connected directly from the + and - power pins of the op-amp to circuit ground. Don't connect these capacitors to the + and - signal pins...
Empty channels (just static) look like the following (due to the high frequency content):
But at least you know your slicer works!
| The spectrum display is redrawn after every 8000 interrupts or when you press one of the following keys: | ||
|---|---|---|
| F1: | scale = 1X; | display maximum spectrum |
| F2: | scale = 2X; | display top half of spectrum (default setting) |
| F3: | scale = 4X; | display top quarter of spectrum |
| F4: | scale = 8X; | display top eighth of spectrum (zoom in on high frequencies) |
| G: | display accumulated samples (don't wait for 8000 of 'em) | |
| The remaining keystroke commands are: | ||
| R: | reverse power polarity (as previously discussed) | |
| Esc: | exit program | |
You can get a pretty good idea of whether your PC will run decoders under Windows by running SLICER under your version of Windows. If the display still has well defined spikes with minimal splatter between them, you may be able to run decoders under Windows. If the display looks bad, decoders will likely have a rough time under Windows. You can try fiddling with the settings for a DOS session (priorities and such) to see if they clean up the displayed spikes.
If the signal looks good on the spectrum display, but your decoder application has problems, one of the following may be the problem.
Not enough horsepower. SLICER, as well as my own Moto/EDACS trunk tracking and MDT decoding software, require no more than a slow 8088, but some decoders require 486's or better.
Incorrect output pin. Some decoders require that the data be present on a particular pin, typically CTS or DSR. Some applications get upset if the data appears on both CTS and DSR (pins jumpered together). Check the appropriate documentation for output pin requirements.
Incorrect signal polarity. Most decoders have an INVERT switch to flip the polarity of the audio signal. The same effect can be achieved by rewiring the slicer with the + and - signal inputs of the op-amp swapped.
Incorrect power polarity. Most decoders raise RTS and lower DTR to provide the slicer with + and - 12 volts. If you have to run SLICER in the Reverse power mode to get a decent display, your applications will probably not run properly.
One last item - your decoding rate may improve if you eliminate as many resident programs (TSR's) as possible. This may include memory managers such as EMM386. Some TSR's disable interrupts for inordinate lengths of time (OK, a few ms or so), which degrades decoding accuracy. Start by eliminating all TSR's to see if they are the problem. Holding down a shift key, such as Ctrl or Alt, while running SLICER will indicate if the keyboard handling routines on your PC (TSR's and/or BIOS code) are disabling interrupts for excessive time periods. If they are, your decoder application may experience higher error rates while you are interacting with it via the keyboard.
End of Document (for now).