To YT3MV de YT3MV 11.02.90 16:44 GMT 45985 Bytes dspsoftware.txt De YT3MV @ YT3A RADIO-AMATEUR DSP COMPUTER SOFTWARE =================================== 1. Introduction --------------- The previous three parts of the article about the DSP computer described its principles of operation and its construction. However, from the user's point of view one of the most important aspects is the available software and the ease of using it. Therefore this additional article is almost necessary and probably additional articles will be required in the future to describe new available software and/or important modifications to exsisting software. The software for the DSP computer includes the operating system stored in the EPROM and application software distributed on floppy disks. The operating system (actually V7.2) works with program and data files arranged in directories as on commercial computers. For simplicity there is just one directory for the files stored in the nonvolatile RAM and one file directory for each floppy disk. Application programs are supplied both as source files and as compiled executable files. Source files are provided for users that wish to modify programs or as an example for users that want to write their own programs. Source files can be compiled at any time into executable files using the high-level language compiler built into the operating system software (in the EPROM). Although executable files require about four times more memory space for storage than source files they are supplied too. Executable files actually contain the values of all the variables. The initialisation of some of these may be quite difficult for the beginner, like typing-in the orbital elements for a number of satellites or setting-up the parameters of a packet-radio program. As already mentioned in the previous articles, the operating system commands are described in a small manual available separately. This article describes the main actual applications software divided into four main groups: - satellite tracking software - APT/WEFAX picture receiving and processing software - demodulators and modems - packet-radio software Rather than describing the commands and functions in detail, this article includes a description of the internal operation of each program. Understanding the operation of a program, its commands become immediately self-evident. Besides the menus, all application programs also include a help message listing all available commands which is displayed immediately after a wrong command was issued. Finally, wherever possible a comparison will be made with commercially available software and/or hardware. 2. Satellite tracking software ------------------------------ Satellite tracking software is not really DSP software, it is however used together with many DSP demodulators and DSP communications programs. A satellite tracking program running on the described DSP computer may only require a very limited computer capacity: if tracking just a single satellite and with no graphics it is only using about 2% of the CPU time. In other words, the satellite tracking program can be executed as a background task while using the computer for another task (any DSP program) at the same time! Satellite tracking usually includes at least three different tasks for the computer: - compute the satellite's position and velocity from its orbital parameters at a given time (usually real time) - automatically steer the antenna rotators in the computed direction (and eventually set the correct frequencies of the receivers and/or transmitters to compensate for the doppler shifts) - display all interesting parameters in numerical form (elevation, azimuth...) and/or in graphical form (plot the acquisition circle on a world map) The first task, computing the satellite's position and velocity, is accomplished in real time by the program TRACK (See Fig. 1.1 and Fig. 1.2). The latter supplies all the information required to other programs (through a data file) and to the antenna rotator interface (through the RS-232 port). The satellite's position and velocity are obtained from the satellite's orbital elements by solving a set of equations. Which equations need to be solved to obtain sufficient accuracy? The basic orbit of a satellite around a planet is elliptic, but there are several perturbing effects. First, the planet is not a point mass nor a perfect sphere and its gravity field is not uniform. Second, there are other gravity forces due to other celestial bodies: in the case of an Earth satellite, these forces are mainly due to the Sun and the Moon. Finally, there are other forces acting on a satellite, like the atmospheric drag or the solar radiation pressure. Radio-amateur computer programs for satellite tracking usually include the basic elliptic orbit equations and the main perturbations: Earth's oblateness (ellipticity) and atmospheric drag. The effect of higher order Earth gravity field perturbations is at least three order of magnitude smaller and requires a complicated and time-consuming numerical integration if included. Luni-solar effects are not included for the same reason. Their effect can only be noted as a long-term variation of the altitude of perigee of high orbit satellites like AO-13. Finally, atmospheric drag depends on the solar activity and is thus unpredictable just like HF propagation. One of the first amateur tracking programs including the basic elliptic orbit, Earth's oblateness effects and a simple drag model was published by J. Miller, G3RUH in [1]. Most tracking programs are simply clones of the G3RUH program, maybe just with a fancier display. TRACK is also based on the original G3RUH program but includes many improvements. The most important improvement is that the satellite velocity vector is derived in a completely analytical way providing a much better accuracy required both for computing doppler shifts and/or APT picture gridding. The basic elliptic orbit is described by a set of orbital elements, usually Keplerian elements. Keplerian elements describe the shape and size of the ellipse (eccentricity and semi-major axis), its orientation with respect to an inertial coordinate system (inclination, right ascension of ascending node and argument of perigee) and the position of the satellite on this orbit (mean anomaly), all at a given time (epoch time). Published orbital elements include some additional data. Although the mean motion can be computed from the semi-major axis and vice-versa using the third Kepler's law, the mean motion is usually supplied for better accuracy. The atmospheric drag is usually described with a decay coefficient. To allow for ageing orbital data, the corresponding menu (Fig. 1.3) includes a clock correction variable for each satellite. The program stores sets of orbital data for 40 satellites. Thanks to the nonvolatile CMOS RAM this data remains stored even after the computer is switched off. In addition, the program containing the modified data can be recorded on a floppy disk. Unlike programs running on commercial computers it is therefore not necessary to worry about losing the updated data file. Other parameters, common to all satellites, can be updated using the appropriate menu (Fig. 1.4). In particular, there are a number of parameters associated with the antenna rotator interface. The elevation and azimuth counts should match the figures obtained from the interface A/D converter. Some parameters require an explanation about the tracking procedure. The software and interface were designed for a commercial azimuth/elevation rotator KR5600. Azimuth rotators have a limited rotation range, usually just slightly more than 360 degrees. In fact, an infinite azimuth rotation would require complex mechanical solutions, like rotary joints. Since regardless of the rotator installation there are always some satellite passes that cross the azimuth discontinuity point, the software has to provide a solution to avoid the discontinuity: about 2 minutes of loss of data due to the 360 degrees azimuth rotation! Most commercial software simply ignores this problem and the result is an unavoidable loss of contact for a few minutes during many satellite passes. The program TRACK provides two different solutions for the discontinuity problem. The first is called AZ OVERLAP and can be used for polar orbiters. The tracking software assumes that the rotation range of the azimuth rotator is slightly more than 360 degrees and that there is a slight overlap around the discontinuity point in the south direction. The second procedure is called RECIPROCAL. It uses 180 degrees elevation rotation and reciprocal values for azimuth and elevation when required: when it is necessary to move the discontinuity point from south to north. The antenna system and the rotators themselves have a considerable mechanical inertia. This problem is made even worse by the rotator control unit, which only allows the motors to be either turned on at full speed or off. Commercial software and related interfaces solve this problem by adding a large hysteresis in the control loop to avoid endless oscillations. Such a control system may be accurate enough to track a satellite on 145 MHz with a short yagi antenna, but is completely unsatisfactory to steer a mode-L high-gain uplink dish or receive HRPT pictures from a NOAA satellite. Of course microprocessors allow a much more accurate steering of the same mechanical and electrical hardware. To optimize the steering two damping coefficients have to be supplied for each feedback loop. These coefficients are then sent to the rotator interface microcomputer with a Z80 CPU. In this way a quick and accurate steering is obtained. In fact, once the system was calibrated it was not possible to steer a 1m dish better manually on S-band. During real time satellite tracking, TRACK generates a display like on Fig. 1.5. The latter includes the actual time, date, satellite position and velocity, azimuth and elevation, doppler shifts and antenna rotator data. As real-time tracking is started, the software will try to find the next satellite pass and decide the correct tracking procedure to avoid azimuth discontinuities. The decision is made according to the azimuth quadrant where the maximum elevation occurs. The quadrant can also be forced manually if the program was started in the middle of a satellite pass and there was no time to find the maximum elevation automatically. One of the most important commands are the time correction commands. Published satellite orbital elements are not always accurate and they are subjected to ageing. The quickest growing error is certainly mean anomaly or time. TRACK allows to correct the time for each satellite orbital data set separately and during real time tracking in either 1 second or 30 second steps. If the link performance is unsatisfactory and inaccurate tracking is suspected, the user simply has to shift the time back and forth for best results! This command was added as a result of practical experience with satellite tracking and is not available in commercial software written by hackers that never tracked a satellite in real time. From the tracking screen one can either call another program (see Fig. 1.6) or check for future or past satellite passes (Fig. 1.7). The orbital prediction routine can be set for any time or date, the default value (no input) is the current time and date. The default step is 3 minutes, a negative step will show past satellite passes. In the case of a wrong command the "On-line HELP" will appear as on Fig. 1.8. TRACK.SRC is about 21 kbytes long. When compiled into an executable file, it requires about 64 kbytes of memory. The data file is 138 bytes long and includes time, date, satellite name, position and velocity. Future additions to TRACK may include the tracking of celestial bodies with built-in ephemeris and automatic steering of transceivers for the correction of doppler shifts. The SATVIEW program can be called from TRACK. It represents the satellite data in a graphical form in a variety of map projections, as shown on Fig. 2.1. The first three options will display the acquisition circle on a world map in a projection similar to the Mercator map projection. Either the full world map (see Fig. 2.2), a selected part (Fig. 2.3) or an "auto-zoom" mode (fig. 2.4) can be selected. SATVIEW can also draw a view of the Earth as seen from the satellite. The latter can be drawn as a natural view form the satellite (Fig. 2.5 and Fig. 2.7) or mapped into a standard map projection (Fig. 2.6 and Fig. 2.8). Note that Fig. 2.5 and Fig. 2.6 (and similarly Fig. 2.7 and Fig. 2.8) cover exactly the same geographical area, only the projection is different. The natural views are useful to check the pictures from an imaging (weather) satellite while the map projections are useful to find the communications coverage. How does SATVIEW draw a map? Maps are stored as sets of points in space, each point being described with its three coordinates X, Y and Z. According to the desired projection, the required coordinate transformation is applied first. Then the points are connected with lines to form the drawing. At least one map file and the satellite position file should be available to make the program work. Up to two additional map files can be used too. Depending on the length of the map files SATVIEW requires between 1 and 4 seconds to update the picture on the screen. Any picture displayed can be printed: the command "*" will generate a hardcopy printer file that is understood by most standard printers. It may however happen that the Earth looks quite elliptic rather than round. In this case the circle factor needs to be adjusted. Experimenting with the hardware in the author's shack the circle factor had to be set to 1.60 for the TV monitor, to 1.68 for a small dot-matrix printer (Brother M-1109) and to 2.00 for a laser printer (Epson GQ-3500). Compared to commercial programs [2], SATVIEW runs considerably faster. If compared to GRAFTRAK running on an IBM clone equipped with the expensive math coprocessor, SATVIEW is between 30 and 100 times faster. Maybe this suggests why it still has sense to make a homebrew computer... Accordingly, it is not necessary to prepare any picture files for animation, for any map projection, since real-time computing is fast enough. In addition it allows a wider selection of projections. On the other hand, some commands have been omitted essentially to keep the user interface as simple as possible: it does have little sense to write a program that requires a thick operating manual no user will ever have the time to read! SATVIEW.SRC is about 16 kbytes long. When compiled into an executable file, it requires about 59 kbytes of memory. The map files COAST.MAP, BORDER.MAP and GRID.MAP require respectively 70 kbytes, 13 kbytes and 33 kbytes of memory. Future additions to SATVIEW may include additional geographic projections. A different map representation (land and sea of different shades) could be used as well, but the memory requirements grow quickly in the latter case! 3. APT/WEFAX picture receiving and processing software ------------------------------------------------------ As described in the introduction (theory) article, the DSP computer was first intended for the reception and processing of weather satellite pictures. The DSP computer video board was designed to generate the highest resolution picture that is still compatible with standard TV monitors: 256 lines of 512 pixels with 256 grey levels per pixel. After a few experimental programs to test different demodulation and synchronization DSP routines two final application programs were developed. The APT program was designed for the reception of pictures from polar orbiting satellites. It allows the recording of a single APT picture at full resolution and a comprehensive picture processing afterwards: zooming and grey-scale enhancements. The other program, WEFAX, was designed to receive sequences of pictures from geostationary satellites like Meteosat. To save memory space, WEFAX does not allow zooming after pictures have been recorded. It can however record sequences of up to 14 pictures (with 1Mbyte of memory) that can be displayed in a moving sequence. Both programs have in common a high performance DSP demodulator (with a lookup table), an automatic and very accurate gain / grey scale adjustment routine and reliable and accurate synchronization routines. Since pictures require by far the largest amount of memory, they are stored in separate files. Both programs include routines to create suitable picture files according to the available memory. The APT program includes 15 user defined picture formats as shown on the main menu on Fig. 3.1. It however works with a single picture file containing a single picture at a time. If a file with the specified file name does not exsist, the program will allow the user to create such a file. The length of the latter will of course be limited by the available memory. The length of the file is displayed as the number of bytes in hexadecimal format. The program uses one byte per pixel of the picture stored. The organization of pixels into lines however depends on the selected picture format. The structure of a (user-defined) picture format is shown on Fig. 3.2. A picture format essentially consists of two parts: the recording parameters and the display parameters. The recording and signal parameters should be set up before attempting to record a picture. Internally, the program is sampling the APT signal at a rate of 4800 pixels per second. For a 240 lines per minute APT signal this means that one line is 1200 pixels long and this information has to be provided to the computer! The computer should also know what is the sync burst frequency and duration to be able to synchronize the picture. The recording parameters define the resolution and the length of the picture stored in the file given a certain amount of memory. For instance, if 512 kbytes (80000H bytes) of memory are available and 1024 pixels per line are stored, the picture file will contain a picture of 512 lines. If the picture is to be recorded at reduced resolution, then the pixel and line sampling rates are to be set accordingly. The format allows for an offset of the start pixel to avoid recording the sync pulse at the edge of the picture. If the picture is recorded at reduced resolution, the program performs an automatic averaging to improve the signal-to-noise ratio. The display parameters define the processing of the stored picture for display. They can be edited like the recording parameters or modified interactively during picture display. The display parameters allow independent zooming in the two directions, moving the display window around the picture and grey scale enhancement. The program performs a check of all format parameters immediately after any parameter is modified. If some parameters are found out of bounds they will be modified to the nearest acceptable value. In particular, the internal line buffers are limited to 2700 pixels and the program can not accept picture formats slower than 120 lines per minute. Slower formats, used in the past (ITOS satellites, old Meteor-2 IR) are seldom used today: larger line buffers would only result in an unnecessary waste of memory. To record and/or display a picture, a picture file with the specified name must exsist and a picture format has to be selected. Selecting a picture format starts two independent tasks: a picture recording task and a picture display task. To start recording a picture a manual start command has to be issued. This will first start a synchronization routine as indicated in the annotation line below the picture. The synchronization is acheived by computing the cross-correlation between the defined sync pattern and the average of 8 successive lines. The synchronization routine may take a few seconds to find the best match. The recording will start afterwards at the write offset as displayed in the annotation line. Before issuing the start command, the write offset usually has to be reset first! The recording will stop automatically when the write offset reaches the end of the picture file: when there is no more memory space available. The picture display window includes 248 lines of 512 pixels each since the bottom 8 display lines are used for the annotation line (see Fig. 3.3 and 3.4). The display has two modes of operation. In the auto mode, the display window tracks the recording operation and the last recorded information is displayed. In the MAN mode, the display window can be moved in any direction along the picture. All other commands are available in both modes. As usual, in the case of a wrong command the "On-line HELP" message is displayed (Fig. 3.5). The display is updated between 1 and 5 times per second, depending on the computer loading. The effects of zooming and grey scale enhancement can therefore be noted immediately. The grey scale enhancement function requires two parameters: gain and offset. Offset specifies a value between 0 and 255 where the specified gain increase will occur. The program will then compute a transformation function such that no saturation occurs either below or above the point of the gain increase: of course the gain has to be decreased in these regions. The function itself is of the form Y=X/SQRT(X^2+1), which is shifted and stretched to match both end points and the required gain increase at the required offset at the same time. APT.SRC is about 16 kbytes long. When compiled into an executable file, it requires about 104 kbytes of memory. In addition, the APT program requires a picture file which may require much more memory. The size of the latter is user-defined depending on the available memory and resolution and/or recording length desired. Future additions to APT may include an automatic start feature for unattended operation and automatic APT picture gridding: using the data supplied from the TRACK program to superimpose grids and coastlines to APT pictures. Although the picture transmission standards and corresponding demodulation and data handling are similar, the overall operation of the WEFAX program is quite different. WEFAX is designed for a completely automatic, unattended operation and can even be programmed for an automatic autostart in the case of a power failure. WEFAX also allows 15 different picture formats (Fig. 4.1), however each picture format may have its own picture file. Each picture file may contain one or more pictures. More picture formats can be enabled and active at the same time. WEFAX starts its picture receiving task immediately. The pictures are then stored to different picture files according to the time schedules associated with each picture format (Fig. 4.2). The recording parameters have a similar meaning as in the APT program except that the user can only choose between two picture formats: "full" 512X248 pictures or "economy" 256X248 pictures. To save memory no zooming can be performed after the pictures have been recorded. There is however a grey-scale enhancement routine identical to that in the APT program. The time schedule includes the transmission times of the desired picture series. Up to 48 transmission times can be programmed. The transmission time tags only include hours and minutes: it is assumed that the broadcasting schedule repeats with a daily period (true for all present satellites). Since WEFAX pictures require at least 4 minutes for transmission, the program tolerates a picture start time that is up to 1 minute early or 2 minutes late from the scheduled time. Finally, if no times are specified in the schedule, the program will simply record all received pictures in that format. When creating a picture file the program will ask for the number of pictures desired indicating the available memory as well. The picture file will be initially filled with a 32-step grey scale. Pictures will then be stored in the file in the same sequence as they have been received. When the picture file is full of pictures, the oldest picture in the file will be overwritten by a new picture. Of course, to edit a picture format the latter has to be deactivated and disabled first! Similarly, the format has to be enabled afterwards to allow the automatic recording of pictures. Selecting a particular picture format from the main menu will show the recorded picture sequence (Fig. 4.3) if a picture file with the given name exsists. It is not necessary for the format to be enabled to display the picture sequence: for example, if it is not desired to write any new pictures to the file. On the other hand, the display operation does not influence the picture recording task either. When a new picture is overwriting an old one, the two pictures will be separated by a dotted line. The annotation line at the bottom will only be updated with the time and date of the new picture after the complete new picture was transferred to the file. In the picture display mode, the user can either manually scan the pictures contained in the picture file or set the scannig speed for automatic scanning. A grey scale enhancement routine identical to that in the APT program is provided as well. A wrong command calls the "On-line HELP" as on Fig. 4.4. WEFAX.SRC is about 18 kbytes long. When compiled into an executable file, it requires about 97 kbytes of memory. "Full" pictures take about 128 kbytes each while "economy" pictures only take about 64 kbytes of memory each. With 1 Mbyte of memory this means either 7 "full" pictures or 14 "economy" pictures or a combination of both. Unfortunately, with a single memory board (256k) there is only room for 1 "full" or 2 "economy" pictures, since the program must be present too. Future additions to WEFAX may include a similar picture handling as in the APT program, where zooming can be performed also after the pictures have been recorded. This however requires much more memory. A routine to automatically synchronize the computer real-time clock could be added easily: picture start times are usually accurate! Finally, there are many other picture transmission formats a DSP oriented computer could demodulate and display. LF and HF FAX transmissions and radio-amateur SSTV are particularly interesting. The FAX standard is used many times to transmit just black-and-white maps: a considerable saving of the required memory space could be made by storing just 1 bit per pixel. SSTV is just a derivative of the HF FAX standard: due to the low resolution of SSTV pictures available memory space would not be a problem either. The computer could easily transmit in any of the mentioned standards as well, so there are many possibilities for further developements. 4. Demodulators and modems -------------------------- Demodulators and modems are certainly the most common applications of DSP computers. Since packet-radio programs are covered under the next section, only two programs, RTTY and BPSK400 will be described here. RTTY is an universal AFSK demodulator/receiving program. As shown on Fig. 5.1 the RTTY transmission standard is fully user-defined, of course within certain limits. The tone frequencies can be set between approximately 800 Hz and 2400 Hz and the transmission speed can be set up to 1200 bauds. All lower transmission speeds are truncated to the nearest submultiple of 1200 because of the internal operation of the program: 45.45 becomes 46 bauds and 110 becomes 109 bauds. RTTY can demodulate both BAUDOT and ASCII transmissions. Of course the BAUDOT code is immediately converted to ASCII (upper-case letters) using a conversion table. Unfortunately some BAUDOT punctuation characters are not defined uniquely and the program may convert them to other ASCII codes! In the BAUDOT mode, the automatic unshift-on-space feature is available. This is an amateur addition to the BAUDOT standard and is very useful on noisy signals, but sometimes it has to be switched off to allow normal reception of numbers and figures (AO-13 telemetry for instance). In the ASCII mode, the number of bits can be selected together with the parity check bit. If the parity check is enabled, all the received characters failing the parity check will be replaced by the code 7FH (cursor character). The transmission standard parameters have to be entered as a series of numbers exactly in the same order as they are shown on the menu. Each transmission standard has associated a file name: if recording is enabled, a file with the specified name will be created and the received text will be stored in this file. The text to be stored is formatted: if no carriage- -returns are received, these will be inserted automatically according to the screen width. If the screen format is set to 64 characters per line, carriage-return/line-feed combinations will be inserted after every 63 printable characters. Correspondingly, a screen format of 85 columns will impose formatting the text to 84 printable characters. Reception is started by selecting the desired transmission standard. During reception a tuning indicator can be enabled (the two horizontal bars on top of Fig. 5.2) if desired. Commands to create a file and start recording, display recorded length or stop recording are provided too. They are all listed on a short HELP message which appears each time an inexsistent command is issued (not shown on Fig. 5.2). When the screen is filled-up with text, the content is scrolled-up after a carriage-return. The scroll operation is relatively slow and certainly not fast enough at the highest data rates (1200 bps). To solve this problem the program includes a 1000 character FIFO buffer for the display. In certain cases (text with many carriage-returns) even this buffer is not enough and part of the received text is simply skipped on the screen. However, no text is skipped in the recorded file, which always contains all received characters! The RTTY program is making use of the squelch (or DCD) input besides the analog input on the A/D. The squelch input has to be held high to enable reception (>5V). If the squelch input is held low or simply left open, reception is disabled! RTTY.SRC is about 10 kbytes long. When compiled into an executable file, it requires about 41 kbytes of memory. Additional memory is required to record any received text. Future additions will certainly include the possibility to transmit in any RTTY format. Such a program has already been tested and now it has to be put in a "user-friendly" format with menus and help messages... BPSK400 is a receiving program for the AMSAT Phase-3 series satellites' PSK transmissions. It includes a BPSK demodulator and a frame synchronizer to receive the 400 bps telemetry. The program (Fig. 6.1) allows two modes of operation: raw ASCII reception (Fig. 6.2) or raw binary reception (Fig. 6.3). Reception is started by selecting the desired mode. Besides accurately tuning the receiver it is also necessary to wait for several seconds for the sync pattern to appear at the beginning of a 512 byte block. The program does not perform any formatting according to the block structure and filler bytes between blocks are well visible (letters "P" on Fig. 6.2 or bytes 50H on Fig. 6.3). The ASCII text is however formatted to 63 columns. All received data can be recorded if desired: a file with the recorded data will be created. Just like the RTTY program, BPSK400 will issue a HELP message after a wrong command... BPSK400 includes a tuning indicator (not shown on Fig. 6.2 or Fig. 6.3) similar to the RTTY program. The tuning indicator shows the offset of the recovered carrier from the given center frequency, usually 1500 Hz for standard voice SSB receivers. The tuning indicator is intended for fine frequency adjustments (+/- 100 Hz). Due to the usually poor signal-to-noise ratio and deep fading the PLL in the program has a rather narrow loop and false locks are possible far away from the correct frequency! BPSK400.SRC is about 8 kbytes long. When compiled into an executable file, it requires about 26 kbytes of memory. Future upgrades certainly include a block-formatted reception of ASCII blocks, CRC check and Q-block (binary telemetry) decoding and display. Of course, RTTY and BPSK400 are not the only demodulator programs that could be built with the DSP computer. The only issue is whether it is worth to invest an amount of time to develop a modem program for a transmission standard that is rarely used, like AMTOR for example. On the other hand, there are interesting applications outside the narrow radio-amateur field, like decoding the transmissions of time/frequency standard broadcast transmitters. 5. Packet-radio software ------------------------ Packet-radio software includes complete communications programs. Each program includes a DSP modem, AX.25 protocol handling routines and a terminal program: everything required for packet-radio besides the (radio-frequency) transceiver. Packet-radio software actually includes three programs: AX25, PSK1200 and MAX25. AX25 has a BELL-202 modem (1200 bps, AFSK tones 1200 Hz and 2200 Hz) and is intended for terrestrial VHF packet-radio communications. PSK1200 has a PSK demodulator and a Manchester modulator suitable to communicate with store-and-foreward satellites like FUJI-OSCAR-12 or the Microsat satellite series (to be launched later this year). PSK1200 can also be used for terrestrial PSK packet radio with SSB transceivers. Finally, MAX25 is an experimental program with a Manchester 2400 bps modem to be used with standard amateur VHF FM transceivers. All packet-radio programs have similar user interfaces: main menu (Fig. 7.1, Fig. 8.1 and Fig. 9.1) and terminal program. The protocol part is similar too and the only major differences are in the different modems. Before describing the single programs in detail a brief description of the packet-radio communications protocol is necessary. In packet-radio communications the operation of the radio-frequency transceiver is completely under computer control. A computer decides when to switch from receive to transmit and vice-versa, how to establish a contact with the correspondent station, how to send information and when to repeat a message that was not acknowledged. All this operations must conform to a standardized set of rules, named the communications protocol, for two different stations to be able to communicate. Although the rules of the AX.25 protocol have been published many years ago [3], not all equipment manufacturers and software writers followed them completely. Instead of strictly following the published protocol, the packet-radio programs had to be written to be compatible with as much exsisting equipment as possible... Packet-radio communications with a simplex radio-frequency transceiver require three different delays to be set. The first is the header length. Before transmitting useful data a header of flags (synchronization characters) has to be transmitted to enable the correspndent's receiver to acheive synchronization. This delay is further necessary due to the finite RX/TX switchover time of the transmitting transceiver and the eventual squelch delay of the receiving station. In commercial equipment, this delay is called (rather confusing) TX delay. The second delay to be set is the real TX delay: the time packet-radio equipment waits for the channel to be clear before attempting a transmission. This delay has to be sufficiently long to enable other stations to use the channel! TX delay is set to 0 in the PSK1200 program, since the latter is used together with a duplex RF link (2m transmitter, 70cm receiver) to access the satellite. It has to be set to a nonzero value if PSK1200 is used with simplex SSB transceivers for terrestrial PSK packet radio. The third delay is the acknowledge delay: this is the time the equipment waits to receive an acknowledge for the information sent before attempting a retry. Of course it has to be set much larger than both the header length and TX delay together. All delay parameters on the menus are expressed in time units that correspond to one flag or one byte: at 1200 bps the time unit is 6.67ms. Commercial equipment usually has steps of 10ms for comparison. Two further protocol parameters are the maximum number of frames per packet (between 1 and 7) and the maximum number of data bytes per frame (up to 256). Of course, before using the program, the station callsign and the callsign of the correspondent have to be set together with eventual digipeaters. The callsigns of the latter have to be typed in the order they are used. The main menu of any packet program includes two file names: a receive file and a transmit file. A receive file will be created to record the text received if commanded to do so. The content of the transmit file can be transmitted either in the disconnected mode (as UI frames) or in the connected mode. There are two further parameters, not related to the packet-radio protocol: blinking and screen format. Blinking is simply a time constant for the blinking of the cursor, since the latter depends a lot on the CPU clock frequency and CPU loading. The screen format can be either 64 or 85 columns and all text is formatted accordingly. The 64 column format 7X7 character font is easily readable, however most packet-radio messages are formatted to 80 columns and the 85 column mode, with a 5X7 character font has to be used. All packet-radio programs have DSP demodulators that can work with a fairly wide amplitude range of input signals. All three programs detect the presence of a valid transmission by checking the CRCs of the received frames. Therefore there is no critical adjustment of the transceiver's squelch to be performed like with commercial TNC DCDs and no related delay either! On the other hand, it is always necessary to adjust the amplitude of the output signal to correctly modulate the transmitter: the parameter TX amplitude has to be set according to the transmitter used. PSK1200 and MAX25 have some additional parameters to be set. PSK1200 allows the PSK demodulator carrier frequency to be adjusted between approximately 1200 and 1800 Hz. MAX25 allows both receive and transmit bit rates to be set independently, of course within certain limits (to be discussed later). An example of using the AX25 program is shown on Fig. 7.2. In operation the packet-radio programs can be switched between two modes. In the command mode characters entered form the keyboard are decoded as commands. Any errors call an "On-line HELP" message as on Fig. 8.2. In the text mode all characters are considered as text to be transmitted. The switchover between the two modes is performed by the line-feed key (CTRL-J). The latter was chosen since it is seldom used: depressing carriage-return already generates a CR/LF on the screen. During information transfer in the connected state, the blinking cursor symbol is replaced by a blinking number. This number indicates the number of frames in the transmit queue that have not been acknowledged yet. After all frames have been acknowledged, the cursor is again replaced by its standard symbol. This feature allows an immediate check of the status of of the contact and/or channel loading: its function corresponds to the ACK LED on commercial TNCs. PSK1200 requires accurate tuning when used with SSB receivers (+/-200 Hz), therefore it includes a tuning indicator identical to the BPSK400 program. No accurate tuning is required with the other two programs, AX25 and MAX25, since they are usually used with FM transceivers. MAX25 is an experimental program and its demodulator works with just 4 signal samples per bit. The DSP routine is using interpolation between samples to acheive synchronization. The MAX25 demodulator is therefore very sensitive to the input signal filtering. The TP3040 input filter on the analog I/O board is not ideal for this application: it has a large differential group delay and severely distorts the signal. With the TP3040 filter MAX25 acheives acceptable results at 2400 bps. Replacing the filter MAX25 can be used for any speed up to 3200 bps. All three packet-radio program sources are each around 21 kbytes long. When compiled they require from 73 to 75 kbytes of memory each. Future developements include experiments with new modems. AX25 could be readily modified for 300 bps HF operation and equipped with the same tuning indicator as the RTTY program, since it uses the same DSP demodulator routine. However, the BELL-103 standard presently used on HF is not the best suited for the HF propagation medium and further experimentation will be necessary, including much more sophisticated DSP techniques before a reliable standard can be selected. On the other hand, 2400 bps is certainly not the highest speed that can be obtained in a voice bandwidth channel. A QPSK modem would probably work up to 4800 bps and other techniques could be used to go beyond this figure. Finally, a packet-radio program without a DSP modem, using the high-speed serial port should be developed for high-speed microwave packet communications. 6. Conclusion ------------- All the software described in this article was extensively tested and its operation is considered reliable. All the software was developed along the same guidelines: a wrong command displays a HELP message immediately and a carriage- -return causes an exit. In a few words, on a working hardware, users should never need to press the RESET button! All the software presented has similar hardware requirements: CPU board, video board, analog I/O and floppy drive. The floppy drive is only used to load programs, the latter could also be loaded from another similar computer through the RS-232 port thus eliminating the need for the floppy drive and related controller. All software can work with a single 256 kbyte memory board, although in this case the performance of weather satellite picture processing programs will be rather limited. The more memory the better but unfortunately due to the recent static RAM shortage and related speculation the prices are very high. All software is ready to work with the full addressing range of the microprocessor of 16 Mbytes (less the space taken by the operating system). No program is using the high speed serial port yet: the related components simply need not be installed yet. From the pubblication of the previous article an improved version of the operating system, V7.2 was developed. It is completely compatible with all previous software and includes only additions. It still fits on a 16 kbyte EPROM so it can be supplied on 27128, 27256 or 27C256 EPROMs. The operating system manual was not only updated but also enlarged: in particular it includes a much more detailed description of the high-level language compiler. Application software can be supplied on both 3.5" floppies (800k per floppy) or 5.25" floppies (400k per floppy). The floppy controller and operating system software can use both types of floppy drives with no modifications, but 3.5" floppy drives are recomended for obvious reasons. All radio-amateur DSP software (all the software described in this article) is intended to be "PUBLIC DOMAIN SOFTWARE". It can therefore be copied freely and is available both from the author and from the publishers for just the expense for the media (floppy), handling and postage. Modifications and additions to these programs are encouraged and further advice can be obtained from the author by either writing or calling to the given address / phone number: Address: Matjaz Vidmar, YT3MV S. Masere 21 YU-65000 Nova Gorica Yugoslavia Phone (home): (+ 38) 65 26 717 This article describes the presently available software. It already includes the description of probable additions and new developements in each software group. Other software is in developement too. When ready, it will be described in future articles and made available. 7. References ------------- [1] J. R. Miller, G3RUH: "OSCAR-10 POSITION CALCULATION PROGRAM", Oscar News 45, December 1983, pages 15 - 18, AMSAT-UK. [2] Silicon Solutions: "GRAFTRAK", set of tracking/display programs for IBM compatibles. [3] Terry L. Fox, WB4JFI: "AX.25 Amateur Packet-Radio Link-Layer Protocol, Version 2.0", October 1984, American Radio Relay League, Inc. , Newington, CT USA 06111. YT3A >