A Computer Control for the Cirkit APT Receiver ---------------------------------------------- Last year I revived a long dormant interest in weather satellite reception, dating back to my schooldays, and built myself a Cirkit receiver kit. This is a fairly old design, which uses crystal control of the received channel frequency. Nevertheless, with the aid of a RIG Dartcom pre-amp, and 'tall, thin' QFH (home made from copper pipe) it still pulls in interesting pictures day and night. Since I am usually out (or asleep) when satellites pass by, I use the 'WAVSAT' software. This can automatically start and stop recording the receiver output based on satellite predictions. The signal is stored as a Windows .WAV file, and it can optionally be decoded to a .BMP picture format at the same time. This set-up allowed me to capture all the passes of a single satellite - say NOAA-14 - for as long as I chose to leave the PC running. WAVSAT can track up to six satellites at the same time, recording the output from each into separate files, in satellite-specific directories. The only missing feature was the ability to switch the receiver channel to match the satellite. Although this facility is not built into the program, I have now discovered that WAVSAT can act as a Windows DDE server. This means another Windows program can talk to it, and ask it for data, including the name of the next satellite due. This knowledge inspired me to design and build a computer-control interface for the Cirkit receiver, and to write some software to drive it. I now have a system which will operate completely unattended, capturing every pass from up to six satellites. This article describes the hardware and software I generated: you may be able to make immediate use of it, or if not, it may provide a source of ideas. Tuning the Cirkit Receiver -------------------------- The Cirkit receiver uses one crystal for each satellite channel. Up to six crystals can be fitted. The kit is supplied with a rotary switch for selecting between the crystals. A single oscillator circuit is used: one crystal is switched into this at a time, while the inactive crystals are disconnected. Instead of switching the RF signal directly with the rotary switch, p-i-n diodes are used as RF switching devices. These are operated by a DC current which is in turn controlled by the rotary switch. To select a crystal, a current of about 1mA must be sourced into its switching diode from the +12V supply. The aim of the design was to allow manual as well as computer control of channel. When the receiver is first switched on, the rotary switch controls the channel. Meanwhile, the computer interface waits for a command to arrive over an RS-232 interface. When a valid command arrives, the interface takes over the channel control, until a 'go to manual' command arrives, or the 'manual control' pushbutton is pressed. Since, in computer control, the switch position no longer indicates the active channel, I added an LED display which operates in both modes. Each command to the interface takes the form of a two-character text string, for example "f1". This command would select channel 1, which on my receiver is occupied by the crystal for 137.3MHz. Upper or lower case can be used, and there is no need for a terminating . To return to manual control, the command string is "F0". The serial interface operates at 1200 baud, 8 data bits, 1 stop bit, and no parity. The controlling software operates in a loop. Every 30 seconds, it attempts to retrieve the name of the current satellite from WAVSAT. If it gets a reply, and WAVSAT is tracking at the time, it looks up the satellite name in a (tiny) database, and sends the appropriate command to re-tune the receiver. It keeps its own record of the current satellite, only re-tuning when it changes. This allows manual overide if the channel number in the database is incorrect - the software won't keep on trying to switch to the wrong channel every 30 seconds. The circuit diagram for the interface is shown in Fig. 1. The prototype was built on a Veroboard 'collander ground plane' prototyping board. Construction technique is not critical, except that it is important to keep noise from the PC, or the interface itself, out of the receiver circuit. The interface is designed using 'slow' logic components and low clock frequencies to minimise the amount of noise it generates. The RS-232 interface is opto-isolated to reduce the risk of noise transmission (and of frying the PC in the event of a lightning strike!) Principles of Operation ----------------------- The Cirkit receiver, like many others, runs from a single +12V DC supply. To reduce costs, the interface runs from the same supply. This is regulated down to +10V by IC1, an LM317 3-terminal regulator. The +10V supply is used to power all devices except for IC8. IC8, which switches the channel control currents, runs directly from the +12V supply. The two supply voltages are close enough so that logic outputs from the rest of the circuit will drive IC8 correctly. The dual supply is necessary because IC3, the UART, will not operate safely from more than +10V. IC2 is the master clock generator for the interface. The 2.4576MHz output from crystal X1 is divided down to produce a clock output on pin 6 at a frequency of 19.2kHz. This is used to provide the baud rate clock to UART IC3, and to clock the character received flip-flop IC5-a. The clock frequency is kept as low as possible to minimise the risk of interference. This clock rate also sets the baud rate: 19.2kHz is sixteen times 1200 baud. This circuit does not use a microcontroller, but is all 'hard-wired' logic. Most UART chips are designed for use in microntroller systems, and require to be programmed by writing a series of commands before they will operate. the IM6402, on the other hand, is controlled by the logic levels on individual input pins for each operating parameter (number of bits, parity, etc.,) and so is more suitable for this type of circuit. It is wired to receive 8 bit data, with 1 stop bit, and no parity. The transmit side of the UART is not used. Serial data arrives at the DB-9 connector, and is converted from RS-232 signal levels to the internal 10V logic level by opto-isolator U1 and associated components. This circuit limits the maximum baud rate to about 1800 baud, but speed is not vital in this application. When IC3 receives a character, it places the received data on pins 5 to 12, and takes pin 19 high. Before it can receive another character, it requires an 'acknowledge' pulse on pin 18. IC5-a generates this pulse immediately each character arrives. The 'character received' pulse is one cycle of 19.2 kHz long (52.1 microseconds) and is used as a clock for the rest of the circuit. Everything that has to happen when a character arrives, must do so by the end of this pulse. IC4-a, IC4-b, and IC6 together decode the binary patterns representing the ASCII characters "f" and "F": namely 1100110 and 1000110. The eighth bit is ignored. If either of these patterns is present, IC6 pin 3 will go high. The end of the character received pulse is used to clock the data on this pin into IC5-b, the 'command character received' flip-flop. IC5-b pin 1 will be high if either of "f" or "F" - the valid command characters - have just been received. It will stay high until the end of the next 'character received' pulse. IC4-c and IC7 decode the bit patterns corresponding to the range of ASCII characters "0" to "6" (well, actually "0" to "?"). The output of the 'command character received' flip-flop is included as part of the decoding. If the previous character was a valid command, then the 4 least significant bits of the numeric character are stored in the latches of IC7. Conveniently, the ASCII codes for the numeric characters are arranged so that the binary equivalent of the number appears in the four least significant bits. Here we are only interested in numbers 0 to 6, so only 3 bits of the latch need be used. These 3 bits are taken to IC8, an analogue multiplexer, which is used to switch the p-i-n diode currents. R7 connects the common terminal of the multiplexer to the +12V supply, and sets the current at about 1mA. One of the eight outputs is connected to this terminal, as controlled by the the 3 bits from latch IC7. Outputs 1 to 6 each connect via an LED to one of the crystal switching diodes. The actual voltage at the active output is about 2V. Since the p-i-n diode switches are current-operated, this value is not critical. C6, R8, and D2 are used to generate a reset pulse when the circuit is switched on. This clears the two flip-flops and resets the UART, and also clears IC7's latches to 0000. This selects output 0 of IC8. Output 0 is connected to the wiper of the rotary switch, and so at reset the p-i-n diode current is fed to whichever channel is selected by the rotary switch. To return to manual control, either the "F0" command can be used to select output 0, or the 'manual control' pushbutton can be used to reset the circuit. A minor point is that I 'scrambled' the inputs and outputs to IC7 & IC8 to make wiring up the Veroboard easier. This does not affect the operation of the circuit, but only the naming of the output pins. All parts are widely available. The only things you might have difficulty with are the UART and possibly the opto-coupler. I used Farnell Components (+44 113 263 6311) who stock both. There are no adjustments or other setting up procedures needed. Operating Software ------------------ To drive the interface, all you need is a way to send characters to a serial port (and a spare serial port, of course!). The simplest way to do this is from the command prompt: echo F1 > com1: sets the channel to 1. Fully automated operation is a bit more complicated, and depends on the operating system. I use Windows NT version 4.0, to which I have added the MKS Toolkit of UNIX-derived utilities (see www.mks.com). As a result, the driving software is more like a UNIX script than a normal Windows program. MKS Toolkit includes the Korn Shell command and programming language, which I used to write the controlling script, as well as a 'dde' utility which can communicate with WAVSAT. The command: dde -s WAVSAT -t Sat -r SatName starts a conversation with the server (-s) WAVSAT, on the topic (-t) Sat, requesting the data item (-r) SatName. If the conversation succeeds, the result is printed to standard output: susato[510] $ dde -s WAVSAT -t Sat -r SatName METEOR 3-5 The script reads this into a variable called SATNAME, using the $(command) Korn Shell construct. If WAVSAT is not running, or not currently tracking a satellite, nothing is printed, and the exit status is non-zero. This is tested by the script, and used to set the interface to manual control. If the dde command succeeds, the value of SATNAME is compared with LASTSAT. If they are different, WAVSAT has switched satellites, and the new name is converted to the appropriate channel. The script prints an information message, giving a record of operation, as it changes channels: Auto Tune starting at Thu Dec 31 21:51:15 GMT 1998 WAVSAT not responding - switching to manual control WAVSAT started at Fri Jan 1 13:45:04 GMT 1999 WAVSAT not tracking - switching to manual control Tuning to 137.85 MHz for METEOR 3-5 at Sat Jan 2 11:32:31 GMT 1999 Tuning to 137.5 MHz for NOAA 15 at Sat Jan 2 11:33:02 GMT 1999 Tuning to 137.62 MHz for NOAA 14 at Sat Jan 2 11:39:33 GMT 1999 Tuning to 137.5 MHz for NOAA 12 at Sat Jan 2 13:09:29 GMT 1999 Tuning to 137.62 MHz for NOAA 14 at Sat Jan 2 14:22:45 GMT 1999 Tuning to 137.85 MHz for METEOR 3-5 at Sat Jan 2 14:35:49 GMT 1999 Tuning to 137.62 MHz for NOAA 14 at Sat Jan 2 14:36:19 GMT 1999 WAVSAT not responding - switching to manual control WAVSAT started at Sat Jan 2 19:59:11 GMT 1999 WAVSAT not tracking - switching to manual control Tuning to 137.4 MHz for SICH-1 at Sat Jan 2 19:59:41 GMT 1999 Tuning to 137.4 MHz for OKEAN 1-7 at Sat Jan 2 20:19:48 GMT 1999 Tuning to 137.4 MHz for SICH-1 at Sat Jan 2 21:34:05 GMT 1999 Tuning to 137.4 MHz for OKEAN 1-7 at Sat Jan 2 21:59:42 GMT 1999 Tuning to 137.85 MHz for METEOR 3-5 at Sat Jan 2 23:12:29 GMT 1999 The full script 'tunesat.ksh' is shown in Fig. 2. I have included it in the start-up menu of my system. Every time I log in, it will start and wait for WAVSAT to respond. Because it spends most of its time in the 'sleep 30' command, it places only a negligible load on the processor. There are probably very few other MKS Toolkit users among the readers of this magazine (if there are, I want to hear from you), but the operation of the script should be clear enough to allow it to be translated into another language, such as Visual BASIC, fairly easily. The only key requirement is a means of using DDE. As an alternative, it is possible to calculate the times of satellite passes in advance, and write a script or batch file to change channels at the appropriate time. In this case, all you need is a way of reading the computer clock - or a facility like the Windows NT 'at' command to run batch files at pre-programmed times. I leave the rest to your ingenuity! Max Hadley max@susato.demon.co.uk