DESIGN OF A WIRELESS KEYBOARD, AUDIO, VIDEO & MOUSE SWITCH

By

Richard Cantzler Grant Farrand

ECE 345, SENIOR DESIGN PROJECT FALL 2003

Grade: 20 / 20 (Technical)

TA: Han Seok Kim

09 December 2003

Project No. 5

ii

ABSTRACT We designed and created a semi-wireless keyboard, audio, video and mouse (KAVM) switch. The KAVM switch allows a centralized Base Station to interface with Remote Stations connected to individual computers. Although we were not able to transmit all of our data wirelessly, the design allows for easy integration with wireless digital transceivers. The device uses a quasi-TCP/IP protocol to transmit control data. The keyboard and mouse data are constantly sent from the Base Station to the currently enabled Remote Station. The audio and video are transmitted from the enabled Remote Station back to the Base Station. The Base Station is typically connected to a television, a stereo system, a keyboard and a mouse. The Remote Stations are typically connected to a computers video and audio outputs and to the keyboard and mouse inputs. Although our designs worked, there are still improvements that can be made by incorporating a better video encoding chip, using pseudo-random numbers for Remote Station identification, and implementing a wireless data routing network. The final cost of implementation was higher than we expected. There are many ways the cost of production could be reduced and are discussed in the conclusion.

iii

TABLE OF CONTENTS 1. INTRODUCTION.................................................................................................................... 1 1.1 Purpose............................................................................................................................... 1 1.2 Specifications......................................................................................................................1 1.3 Subprojects......................................................................................................................... 2 1.3.1 Power Supply Module............................................................................................... 2 1.3.2 Control Channel Processing Unit.............................................................................. 2 1.3.3 Audio Transmitter Module........................................................................................2 1.3.4 Audio Receiver Module............................................................................................ 2 1.3.5 Video Converter Module...........................................................................................3 1.3.6 Button and Switch Module........................................................................................3 1.3.7 Status LED Module................................................................................................... 3 1.3.8 Router Module...........................................................................................................4 DESIGN PROCEDURE........................................................................................................... 5 2.1 Power Supply Design......................................................................................................... 5 2.2 Data Transmitter and Receiver Design...............................................................................5 2.3 Audio Transmitter and Receiver Design............................................................................ 6 2.4 Button and Switch Design.................................................................................................. 8 DESIGN DETAILS.................................................................................................................. 9 3.1 Power Supply Module........................................................................................................ 9 3.2 Control Channel Processing Unit..................................................................................... 11 3.3 Audio Transmitter Module............................................................................................... 11 3.4 Audio Receiver Module....................................................................................................12 3.5 Video Converter Module.................................................................................................. 12 3.6 Button and Switch Module............................................................................................... 13 3.7 Status LED Module.......................................................................................................... 13 3.8 Router Module.................................................................................................................. 13 DESIGN VERIFICATION.....................................................................................................15 4.1 Testing.............................................................................................................................. 15 4.1.1 Power Supply.......................................................................................................... 15 4.1.2 Audio Transmission and Reception........................................................................ 15 4.1.3 Video Conversion....................................................................................................15 4.1.4 Button Debouncing..................................................................................................16 4.1.5 Data Routing............................................................................................................16 4.2 Conclusions.......................................................................................................................16 COST...................................................................................................................................... 18 5.1 Parts.................................................................................................................................. 18 iv

2.

3.

4.

5.

5.2 Labor.................................................................................................................................18 6. CONCLUSIONS.................................................................................................................... 19 REFERENCES....................................................................................................................... 20 APPENDIX A BLOCK DIAGRAMS............................................................................... A.1 APPENDIX B SCHEMATICS..........................................................................................A.2 APPENDIX C TEST DATA............................................................................................. A.7 APPENDIX D PICTURES.............................................................................................. A.11 APPENDIX E PARTS AND COST................................................................................ A.15

1. INTRODUCTION We designed and created a semi-wireless keyboard, audio, video and mouse (KAVM) switch. The KAVM switch allows a centralized Base Station to interface with Remote Stations connected to individual computers. Although we were not able to transmit all of our data wirelessly because of time constraints, the design allows for easy integration with wireless digital transceivers. The device uses a quasi-TCP/IP protocol to transmit control data. The keyboard and mouse data are constantly sent from the Base Station to the currently enabled Remote Station. The audio and video are transmitted from the enabled Remote Station back to the Base Station. The Base Station is typically connected to a television, a stereo system, a keyboard and a mouse. The Remote Stations are typically connected to a computers video out, audio out, keyboard in and mouse in. 1.1 Purpose The purpose of this project was to use our knowledge of communications, signal-processing, and digital system design, to engineer a product that would allow us to use our computers from a remote location. Since we both own keyboard, video, and mouse (KVM) switches, we spent some time thinking of things to improve upon. We decided that we wanted our design to improve upon commercial products by buffering the video input. The VGA signals were sent out so a monitor can still be attached to the Remote Stations computer. By providing multiple video output formats, we would improve the products usability. We would also eliminate long wire connections via wireless technology. Although most commercial KVM switches incorporate function keys that allow switching between the inputs via the keyboard, this usually implements a time delay between hitting the function keys and when the computer receives the input. We wanted our product to have as little latency as possible. 1.2 Specifications The project was split up into modules as seen in Diagrams A.1 and A.2 (All diagrams, figures, and tables appear in the appendices.). For individual module specifications, refer to section 1.3. The KAVM switch needs to transmit and receive data with minimal delay. We set an initial upper bound for the transmission delay based on the number of words per minute a skilled person can type. Based on data from The Guinness Book of World Records [1], the fastest typing speed is 212 wpm. We assumed the average number of characters per word to be five, yielding 142 bps. Using this estimate, Equation 1.1 demonstrates that the KAVM switch needs to transmit around 300 bps, requiring a latency of less than four milliseconds. Minimizing this latency is important so that data does not get visually lost in transmission. BPS [b/s] = WPM [w/m] 5 [c/w] 8 [b/c] 60 [m/s] 1 (1.1)

The switch also needs to transmit video at a fast enough rate so there is no flickering. Estimating that we should be able to transmit VGA at a resolution of 1024 horizontal by 768 vertical and a vertical frequency of 60 Hz, Equation 1.1 tells us the needed data rate is more than 1,132,462,080 bits per second for true color. If this data transmission were done with an analog channel, we would need to send 5 signals each having a bandwidth of about 5 MHz. If we were to send only the composite video signal, however, we would have a reduced image quality and only need one transceiver with a bandwidth of roughly 5 MHz. 1.3 Subprojects The design was broken into many modules, which each perform specific tasks. The modules we decided to implement were:

1.3.1 Power Supply Module The Power Supply Module needed to convert a 7-volt unregulated DC source to +5 V, +3.3 V, -5 V with respect to ground. The module also had to prevent large current spikes, more than one amp, from damaging the other modules.

1.3.2 Control Channel Processing Unit The Control Channel Processing Unit, or CCPU, needed to negotiate traffic on a network and be able to enable or disable transmission of all data signals. Although the code for the PIC in this module was designed for ECE 246, much time was spent determining which hardware should be used based on the format and frequency that the PIC could transmit data.

1.3.3 Audio Transmitter Module The Audio Transmitter Module needed to take an audio input signal from a computer, shape it, and route it to an analog transmitter. The transmitter/receiver pair needed to work within 100 ft, but no further.

1.3.4 Audio Receiver Module The Audio Receiver Module needed to receive an analog signal from the airwaves and route it to some kind of sound output system (speakers). The transmitter/receiver pair needed to work within 100 ft, but no further. 2

1.3.5 Video Converter Module The Video Converter Module needed to receive a video signal in VGA format, convert it to NTSC or PAL format for output, and provide a buffered VGA output.

1.3.6 Button and Switch Module The Button and Switch Module needed to allow reading of an eight bit unique binary number for use in identifying Remote Stations. This module also needed to have buttons to interface with the CCPU.

1.3.7 Status LED Module The Status LED Module needed to take inputs used for debugging purposes and light an LED if the signal was high. In the end, this module needed to indicate if the device has power, is transmitting or receiving control channel data, is enabled, or registered on the network.

1.3.8 Router Module The Router Module was meant to be a grouping of wireless transmitter/receiver pairs or transceivers. Since we had difficulty in sending clocked data, this module was adopted to allow easy integration with wireless transceivers in the future. This meant that the module needed a clock line with each control channel input and output. Matches up with the subprojects/blocks from Design Review Excellent.

2. DESIGN PROCEDURE 2.1 Power Supply Design The power supply was meant not only to convert voltage from an AC/DC 7 V unregulated power source to provide +5 V, +3.3 V, -5 V, and a ground terminal, but also to protect our other circuitry from dangerously high current levels. Although we could have used a commercial power supply, we wanted our power supply to be internal to the device and to offer the best protection we could. We started the design by using the LM317T, which is a current regulated feedback to control the amount of voltage being supplied. The benefit of this chip is that it allows for up to +37 V input, is short circuit current limiting, and has a thermal shutdown mode to protect the device as well as the load. We added a second regulator to the power supply after realizing that most of the digital transmitter/receiver pairs required +3.3 V. When testing the transmission of analog audio signals, we discovered that our op-amps were clipping the audio signal, so we added a charge pump to the +5 V line so we could provide a -5 V rail as well. We later added a one-amp fuse to the boards as a redundant layer of protection in case the current limiting on the LM317 fails. 2.2 Data Transmitter and Receiver Design The transmission and reception of clocked data was a great challenge. Initially, we set out to use the Linx LC series 315 MHz transmitter/receiver pair. After doing some research on clocked data transmission, we came across some information [2] explaining a method known as Manchester encoding. This solution looked very promising, as long as we could find a way to recover the clock from the encoded signal. According to an application note for the LC series [3], encoding chips could be obtained from Linx, Holtek, and Motorola. After searching Motorolas website and finding only obsolete Manchester encoding chips, and finding on Holteks website that Linx is the only North American distributor of their parts, we emailed Linx inquiring about encoders and decoders. We received an email notifying us that Linx does not carry any of the encoders or decoders. Linx did have the four-bit encoder chip but not the decoder. This led us to determine if we could implement Manchester encoding in software. Implementing Manchester encoding in software was easy as the scheme simply requires sending a 01 in place of a 0 and a 10 in place of a 1. The trouble appeared when trying to decode the data to retrieve a clock. The implementation would require a phased-lock-loop, which meant having the PIC interrupt on a pin. The problem with this is that the PIC can only interrupt on a pin on port B, which was being used by the LCD. We thought there was a possibility of creating an interrupt that would check the status of a pin, but we 5

were not sure if this would cause problems because of the main routine length. Our other fear was that we would only need to interrupt to receive data and that this might cause problems with our function that sends data. We decided to test the main routine cycle time by checking the nineteenth bit of a counter and flashing a pin. We used an oscilloscope to measure the time between pulses and estimated 8.4 seconds to count through 524,288 cycles, yielding a main routine cycle of 16 s. Since each instruction takes about 0.2 s to complete, and our initial decoding routine was 38 instructions, the interrupt would take 7.6 s to complete. We figured that this would pose a problem with the execution of the main routine, although it would provide us a data rate of 131,578 bps given by Equation 2.1. We decided that if we had time at the end, we would add in the Manchester encoding/decoding routines and try them. DATA RATE [b/s] = BITS [b] TIME [s] (2.1)

Since we determined that Manchester encoding and decoding was not going to be as easy as we initially thought, we quickly investigated using some digital wireless transceivers from Atmel. The transceivers, however, were too complex in implementation and too expensive for to buy preassembled. With no means of transmitting our control channel data, we turned to the development of a wire-line router. In hopes that we could get some data to transmit wirelessly we decided to concentrate our efforts on wireless audio transmission. After transmitting audio signals successfully, we began designing the wireline router. We began designing the router as a drop in replacement for a wireless transceiver. This was intuitive, yet very complicated. The Base Station needs to transmit data to both Remote Stations simultaneously. With the transmission gates in place, only one Remote Station can reply at a time without time-aliasing data from either channel. Luckily, this was planned out in the initial protocol so that multiple Remote Stations would not interfere with each other. While the Base Station must provide only the data and clock lines, each Remote Station must also provide a transmit-enable line. This is the signal that hooks a particular Remote Station into the Router Network. A major design question was whether to route the full VGA signal, which requires six to eight lines, or simply handle the composite video and S-Video outputs, which only requires three total. The benefit of transmitting the full VGA is that the Video Conversion Module could be included only on the Base Station, and allow the Base Station to also connect to a monitor. Although we could have done this, our main goal was to get video working on a television, so we decided to restrict our options in favor of a slightly simpler design. 2.3 Audio Transmitter and Receiver Design We initially felt that the transmission and reception of analog audio would not pose any challenges. After listening to severely muffled output, however, we took a closer look at our inputs and outputs. The analog audio signal coming from the computers had amplitude of roughly 1 Vp-p. Rather than 6

transmitting two audio signals, we decided to mix the right and left channels to make the system mono. We felt that we might need to scale the signal up or down so we added an adjustable amplifier with a gain from 0.1 to 10 and DC biased the signal to 1.5 V. For audio reception, we thought we might need another amplifier to boost the signal and to match the low impedance of the speakers. We implemented another amplifier with a gain from 0.1 to 10 using an op-amp. We connected the output of the receiver to an oscilloscope and adjusted the potentiometers to reach what ended up being approximately unity gain amplifiers. We also adjusted another potentiometer to get the offset of 1.5 VDC. We verified the audio signal levels by listening to the audio on the speakers. The output of the audio receiver was much clearer than the original attempt.

2.4 Button and Switch Design The design of the network protocol required each Remote Station to have a unique identification number. To implement this, we used a DIP switch with eight switches that were connected to an 74LS165 and current-sourced through resistors tied to the positive supply rail. The other end of each switch connects to ground. The PIC then interfaces with the parallel-in serial-out shift register and reads in all the data bits as the unique ID. The buttons on the board were designed to connect directly to the PIC and allow the user to control the menu. When we first attached the buttons to the PIC, we were unable to navigate the menu system because of the bounces the buttons produced. Since these were SPST buttons and not SPDT, we could not use the simple cross-feedback debouncing circuit we learned in ECE 110. We found debouncing ICs from Analog Devices, but the package sizes were too small for us to mount and we were skeptical as to their effectiveness, so we searched for other methods of debouncing signals. The first document [3] that had suggestions for debouncing a single signal offered a design using the 555 Timer. In implementing the 555 Timer circuit, we estimated a minimal response time of about 20 ms on the switches. This required us to use a 1 uF capacitor and a 20 k resistor in the circuit. In addition, we needed the ability to store the button input in case the PIC was busy transmitting or receiving, so we connected the output of each 555 Timer to the clock-line of a D flip-flop whose non-inverted output and clear line go to the PIC. When a high level from the output of D flip-flop is read, the PIC acts accordingly and then resets the flip-flops.

3. DESIGN DETAILS 3.1 Power Supply Module The Power Supply Module was designed so that we could put a power supply in each of the stations and power it with an unregulated AC/DC power converter that one would buy at a Radio-Shack. If the overall product was being prepped for the market, we would not have to go through the long and arduous task of UL approval. It costs a lot of money and time. Since these unregulated AC/DC power converters are already UL approved, we dont have to do it. This module uses 2 LM317Ts as its primary component. These are TO-220 package linear adjustable voltage regulators. The equation that governs the output voltage in terms of the control resistors and acquiescent current draw is shown in Equation 3.1.1. Vout = 1.25(1 + R2 / R1) + Iadj(R2) R2 = R2a + R2b (3.1.1a) (3.1.1b)

As seen in Figure B.1, the divider resistor is actually the combination of a fixed resistor R2b and a potentiometer R2a. This allows us to adjust the output voltage to exactly 5.00 volts above ground. The same analysis holds for the 3.3 volt supply as well. As seen in Figure B.1, there are 2 protection diodes in this circuit. D1 protects against a current dump from C4 and D2 protects against a current dump from C3. These diodes protect the LM317T in the event that power and ground are reversed at the input terminal J1. The next most critical part was the charge pump, U3 in Figure B.1. It takes a positive voltage input and converts it to the exact negative at the output. This negative supply rail was used in the video converter board and on the wireless transmitter and receiver boards. The video amplifiers in the video board needed a negative supply. The op-amps in the wireless transmitter and receiver boards also needed this same supply. These chips were only capable of sourcing 80 mA but that was more than enough to power the op-amps and video amps. Preg = V5v, reg * I1/2, cap Preg = V3.3v, reg * I1/2, cap (3.1.2) (3.1.3)

The power supply took an unregulated 7-volt DC signal as input. It used this signal to power the voltage regulators that took the voltage from 7 volts to 5.00 volts and 3.30 volts. Because of this voltage drop across the regulator, the power not sent to the output terminals was dissipated as heat through the regulator. At -capacity, the 5.00 volt regulator would have to dissipate 1 W of heat, per Equation 9

3.1.2. At the same capacity, the 3.3 volt regulator would have to dissipate 2 W of heat, per Equation 3.1.3. This meant that each of the regulators needed to have heat sinks attached to them to prevent them from over-heating.

10

3.2 Control Channel Processing Unit The CCPU did not require much design. Besides mapping all the pins to sequential blocks for each port, the only work went into controlling the backlight on the LCD. The final circuit, as seen in Figure B.4, utilizes an NPN transistor for amplification of the input current to drive the LCDs backlight. We initially used Equation 3.2 to calculate the value of R2 needed to provide about 100 mA of current. R2 [] = (5 - Vce,sat)[V] / 0.1 [A] (3.2)

The value of R2 that made the backlight first turn on, however, was around 25 . The current draw needed to operate the backlight was measured to be around 250 mA. Luckily, the 2N4401 is capable of sinking up to 600 mA of current.

3.3 Audio Transmitter Module The design of this module was fairly straightforward after consulting the application notes in the Linx HP-II series documentation. The input signal needed to have Peak-to-Peak amplitude of 3.0 volts and needed to be DC-biased to 1.5volts. Since there were right and left channels coming out of the computer and we only had one transmitter per channel, the decision was made to simply mix the stereo input to mono and amplify that. As seen in Figure B.2, the right and left channels get AC-coupled and fed through two 1.5 k resistors into the inverting input of a TL072 op-amp. The non-inverting input has a DC-bias voltage placed on it. The feedback loop of this amplifier has a 100 resistor in series with a 5 k potentiometer. This creates a circuit that will amplify or attenuate and add a DC-bias to the input signal. Both of these aspects are controlled by R5. Equation 3.3.2 relates the output voltage of this amplifier to its two inputs, VL and VR. Ra = R1 Rb = R5 + R4 Vout = -(Rb/Ra)*(VL + VR) + Vbias(1 + Rb/Ra) (3.3.1a) (3.3.1b) (3.3.2)

Equations 3.3.1a and 3.3.1b are simply definitions to clarify the result of Equation 3.3.2. Equation 3.3.2 was derived using the principle of superposition. It turns out that the output DC-bias depends on the magnitude gain of the amplifier (Rb/Ra). When adjusting this circuit, first the gain is adjusted for the correct signal amplification/attenuation. The DC-bias voltage, Vbias is adjusted to compensate for the gain of the circuit and to get the overall DC-bias to be 1.5 volts. The Linx HP-II series chip uses an FSK transmission scheme to send data over the airwaves. There was a very detailed talk about antenna design and placement given in the Linx documentation. However, for the short distances that we were planning on transmitting (less than 100 ft.) we could use almost any antenna we wanted to. In the end we ended up using a printed antenna on the bottom of our PC board. 11

It works well. Input pin 7 (Figure B.2) is connected to the Enable output pin of the corresponding Remote Station. When one Remote Station is enabled, we dont want the other station broadcasting its audio data into our receiver. Thus, when one Remote Station is enabled, the other must be disabled. The Base Station is responsible for making sure that only one Remote Station is active at a time.

3.4 Audio Receiver Module The design of the receiving circuit was much simpler than that of the transmitter. However, it is far more common that the reverse is true. The circuit used here was a simple inverting amplifier, as seen in Figure B.3. Here there is no DC-bias added to the output signal. The audio input was phase-shifted by 180 before being sent to the transmitter. In an effort to alleviate that effect, we add another 180 phase shift to the received signal. Ra = R1 Rb = R3 + R2 Vout = -(Rb/Ra)*(Vin) (3.4.1a) (3.4.1b) (3.4.2)

The output amplitude is controlled directly by R3 as can be seen in Equation 3.4.2. The user can set this so that he/she has a useable signal at the output for the speakers to broadcast. An op-amp based amplifier was used here because it has a very low output impedance that will match with that of the speakers. We want the impedance of the op-amp and the speakers to be matched for maximum power transfer. All the power output will then go to the speakers thus maximizing efficiency.

3.5 Video Converter Module The video converter module design was taken straight from the pages of the AD725AR application notes [6]. A schematic was drawn up that depicts all of the input and output pins as they relate to actual components (mainly VGA connectors). The AD725AR takes interlaced VGA data at a 60 Hz vertical scan rate. It uses the NTSC standard frequency (14.318180 MHz) as a system clock to convert this VGA data to NTSC. The chip can encode in either NTSC or PAL by setting an input low or high. As seen in Figure B.7, when D1 is forwardbiased, it acts as a switch that pulls C11 into parallel with C10. This creates a notch filter at the NTSC frequency. When D1 has no voltage drop across it, C11 is in series with C10, thus creating a notch filter at the PAL frequency.

12

3.6 Button and Switch Module This 555 Timer debouncing circuit works by setting an R-C time constant for the 555 Timers output pulse. When the 555 Timer receives a high signal, the output goes high for a time period given by the Equation 3.6. PERIOD [s] = R [] C [F] (3.6)

As seen in Figure B.5, resistor R2 and capacitor C3 determine this period. The 20 k resistor and 1 uF capacitor result in a debouncing period of 20 ms, which proved effective on two of our three boards. We later introduced software delays in our PIC program to fix the third board. TTL versions of the 555 Timers were used in the implementation. Each one of these chips draws about 15 mA of current. There are three of these chips on each board plus other discrete logic. The debouncing boards ended up drawing about 55 mA of current total. This is a huge number for a TTL circuit. The CMOS version of these chips draws about 1/10th the current at the same supply voltage. We would use these in our final design. 3.7 Status LED Module The LED Status Module was designed to help us debug the code and to look pretty. There are 5 LEDs (1 red, 2 yellow, 2 green). Each of these LEDs needs a current limiting resistor so we dont burn up the diode. Each LED also has a different voltage drop across it when it is on. The voltage drop depends on the color of the LED. For simplicity and flexibility, instead of calculating all the voltage drops and necessary resistances, we just put potentiometers in place of fixed pull-up resistors. We adjusted each potentiometer until we had about 10 mA of current flowing through each LED. Equation 3.7 shows the current-voltage relationship for the circuit in Figure B.6. Id = (Vcc Vd) / R (3.7)

Because the PIC itself is not capable of sourcing an enormous amount of current, we wanted an external device to provide power to the LEDs. In addition, we wanted positive logic control over them. A hexinverter chip lent itself very well to this application. Signals from the PIC were routed to the Hex inverter and each could be seen in the status of the corresponding LED (logic high = LED on, logic low = LED off).

3.8 Router Module This module was to be a drop-in wireless system. Due to time constraints, the wireless transmission system was abandoned in favor of a wire-line routing system. The Router Module contains 6 transmission gate chips that function as logic-controlled wires. When a logic-high is applied to the 13

control pin of the chip, the CMOS switch is closed, and data passes from the input to the output unaffected. When a logic-low is applied to the control pin, the CMOS switch opens, and the signal does not reach the output side. The chips were mainly used to transmit the digital signals of the keyboard and mouse. Those signals could be attached directly to the chips. However, when it came to transmitting the video signals, we had to consider DC-biasing the signal. Since the video signals have no DC components and the transmission gates have a +5V and ground supply, we had to get the operating voltage of the signal above ground. This was done using a resistive divider to pull the voltage up to 2.5 volts. Equation 3.8 shows the simple equation relating the bias voltage to the resistors used and the supply rail voltage. Vbias = (R2 /(R1 + R2))*(5 0) (3.8)

We wanted equal headroom on both sides of the AC signal so we set R1 = R2 and Vbias became 2.5 volts. The design of this board was very intuitive, however it proved to be a wiring nightmare.

14

4. DESIGN VERIFICATION The main test we wanted the devices to pass was not one involving quantified data. We wanted the Base Stations to successfully allow connections from two Remote Stations and to control them properly. When switching between Remote Stations, we wanted the audio output on the Base Station to change accordingly along with the video output. We also wanted to make sure our switches were not bouncy anymore. 4.1 Testing Besides testing how well all the modules work together, we wanted to make sure that all of our modules were independently operating to our satisfaction. The testing of each module is described in their respective locations below. 4.1.1 Power Supply We tested the power supply to make sure the output had low ripple, and to make sure our other modules were protected. Looking at the +5 V output of the Power Supply Module compared to ground, as seen in Figure C.1, the ripple has a maximum of 75 mV p-p. PERCENT REGULATION [%] = 1 - || ( VSL [V] - VLL [V] ) VLL [V] || (4.1)

Using the data from our power supply tests, seen in Tables C.1 and C.2, the voltage test showed percent regulation of 96.968% and the current test showed regulation of 96.324%. These are very good voltage regulation percentages for only an $18 power supply. We also tested the power supply to make sure it would not allow currents to damage the other modules. We did this by connecting our AC/DC 7 V unregulated power source to the input of the Power Supply Module and shorted the +5 V and ground connections on one of the other modules. This successfully resulted in blowing the one-amp fuse on the Power Supply Module, and did not harm any of the other modules. We were very happy with these results. 4.1.2 Audio Transmission and Reception We were concerned mostly with distance of reception here. We set up a transmitter module in the northwest corner of EL 246 and a receiver module in the southeast corner of EL 251. This distance was about 60 feet. The receiver had absolutely no trouble picking up the signal at this distance. 4.1.3 Video Conversion 15

Since we were seeing almost three complete images of the screen on the television, we decided to take a look at the NTSC composite video signal coming out of the AD 725, as seen in Figure B.7. We were able to identify the horizontal sync pulse as a -0.3 V pulse occurring at a frequency of 63.9 kHz. Although information [5] we found said there should be a quick burst of modulation after the horizontal sync known as a color burst, the signal from the AD725 does not appear to have this feature. This could have been the reason for the ghost images. We initially thought the three images were a result of improper horizontal sync signals, and analysis shows that the composite output signal has a horizontal sweep frequency much greater than we expected. We set the oscilloscopes horizontal time scale to one full period of the horizontal sync and triggered on the falling edge of the negative going pulse. We also displayed a black background, so the white mouse pointer would have significant contrast. The horizontal sync can be seen as the first, negative going pulse in Figure C.8. The vertical sync can be seen in Figure C.7. We measured a horizontal frequency of 64 kHz, where our research of the NTSC standard showed that we should see around 15 kHz. The large reading can be accounted for, however, since we were in a resolution mode of 1024x768 instead of the 800x600 the datasheet recommends. This difference in resolution modes results in a factor of 1.28 in the horizontal sync frequency. Accounting for this difference, we should have expected a 50 kHz horizontal sync signal in a resolution mode of 800x600. This is slightly more than three times what we would like, and explains why we saw three full images of the screen on the television. 4.1.4 Button Debouncing The button debouncing was an easy design, but was very difficult to find. As seen in Figure B.5, the debouncing circuit relies on a Timer 555 with an RC circuit. The Timer 555s output pulse has a period that is set by the RC time-constant. We estimated that the users will not need to hit the buttons very quickly, and since the buttons were very bouncy, we set the RC time-constant to be 20 ms by using a 20 k resistor and a 1 uF capacitor. The design works as seen by Figures C.5 and C.6. 4.1.5 Data Routing The data routing test was very easy. It amounted to putting data in and seeing if the same data was seen at the output. 4.2 Conclusions Overall, we were very pleased with our design as it passed our tests. Although initial tests of the power supply showed only 25 mVp-p of ripple, we were still happy with the level of the ripple under larger loads, which was 75 mVp-p. The power supply also saved us many times by blowing out the fuse 16

instead of our other modules when we inadvertently shorted the power lines, many times. Receiving audio signals at a distance of 60 ft was very exciting, as we originally were only able to transmit about 10 ft across the lab. In addition, the audio was being biased and amplified to correct values, creating a much cleaner sound than in the beginning. Although our video conversion did not work as well as we had hoped, we were still very happy that it worked as well as it did. Buffering the VGA back out to the monitor was a very nice feature, and made testing the devices much simpler. We had not originally planed on spending time debouncing buttons, but the circuit worked very effectively on two of the three boards. We were not able to determine why debouncing on the the third board was not working properly, so we implemented software debouncing to help. These tests helped us ensure that critical designs were performing to the specifications. Matches up with the Testing Plan from Design Review Excellent.

17

5. COST Since we had an initial market of about four people, we wanted the KAVM switch to be a finished product. In addition, since this product requires a Base Station and at least one Remote Station, the final cost of each module, station, and one Base Station with four Remote Stations and a router module will be analyzed. 5.1 Parts Although we could have purchased a regulated power supply for $40, the parts for the Power Supply Module ended up costing a total of $18 as seen in Table E.1, saving us nearly $22. The cost of each individual module can be seen in Tables E.1 through E.9. The Base Stations final cost was $165.76 as shown in Table E.10. Table E.11 shows the final cost of the Remote Station as $214.72. Table E.12 shows the final cost of a 2-Pack, which allows two Remote Stations to communicate with a Base Station. The final cost of this package was $705.47. These prices were overestimates based on minimal quantity purchases. 5.2 Labor We estimated our future salary at around $60 per hour. The amount of time spent researching and developing the KAVM switch turned out to be more than we expected. From out lab notebooks, we estimate around 132 hours this semester spent working together. Individually, we accumulated 66 hours of independent design time. Using the following formula for estimating cost, our 198 hours of work ended up costing $29,700+. Total Cost = Parts + (Ideal Hourly Salary (Hours Spent + Shop Hours) 2.5) (5.1) (2.1) According to Equation 5.1, we would need to sell 43 devices at twice our cost to recover the research and development costs. However, nobody would buy these at such an exorbitant price. Reducing the retail cost to just under one thousand dollars would require us to sell 85 devices.

18

6. CONCLUSIONS We were extremely pleased with how the project turned out. The KAVM switch was able to connect multiple Remote Stations to a single Base Station, and enable or disable the stations accordingly. The audio signals being received on the Base Station sounded good, with little noise and no clipping. The video output was discernable and simple modifications to the computers horizontal sync should have yielded a cleaner image. The device was also able to transmit more than 50 ft. There are a number of design parameters that should be changed in future designs of this product. Manchester encoding and decoding should be implemented in the software now that we know our PIC can handle high frequency interrupts. This would involve removing the clock lines and connecting the transmit and receive lines to a Linx transmitter and receiver respectively. The Audio Transmitter Module and Audio Receiver Module should be modified to handle stereo audio. This would require mixing the signals to separate frequencies and transmitting them on a common carrier. This would still only require the single transmitter/receiver pair. The Video Conversion Module could be removed from the Remote Stations and placed on the Base Station to allow the addition of monitor output as well as reduce cost. The module should also use a more flexible NTSC and PAL encoder. This would allow users to get larger resolutions at greater refresh rates. Mixing the six data lines up to separate frequencies and superimposing them on a carrier would allow them to be transmitted using a single transceiver. Some sort of scheme could also be devised to transmit the keyboard and mouse data using a single transceiver. This would not only cut costs, but also allow bidirectional communication with the mouse and keyboard so that advanced buttons such as the scroll wheel could work. Another alternative would be to add a pseudo-random number generator into the Remote Stations and have them generate their identification numbers rather than having them hardcoded. This would help fix errors where two sets of DIP switches were set to the same number, although similar problems could still occur. Although we have tested the functionality with two Remote Stations communicating with a Base Station, we are still uncertain as to how well the system will perform with more than two Remote Stations. Regarding the cost of the devices, there are many ways to reduce the numbers. In a finished product, we would not need most of the mounting hardware. By placing orders of larger quantities, we could cut the cost drastically. We could have also reduced the number of modules by combining them into a single board. Some of our more expensive components, such as the LCD and buttons, could have been purchased at a lower cost from different companies. 19

REFERENCES [1] N. McWhirter, The Guinness Book of World Records, 23rd ed. New York: Sterling Publishing Co., Inc., 1985. G. Fairhurst, Manchester Encoding, [Online Document], 1 Jan 2001, [cited 14 Sept 2003], Available HTTP: http://www.erg.abdn.ac.uk/users/gorry/course/phy-pages/man.html Linx Technologies, Application Note AN-00232: General Considerations for Sending Data With The LC Series, [Online Document], [cited 14 Sept 2003], Available HTTP: http://www.linxtechnologies.com/ldocs/pdfs/AN00232.pdf T. van Roon, Timer 555/Oscillator Tutorial, [Online Document], 4 Sept 2003, [cited 17 Oct 2003], Available HTTP: http://www.uoguelph.ca/~antoon/gadgets/555/555.html Gekco Inc., Gekco Video Test Pattern Generators: A Video Tutorial, [Online Document], 15 Sept 2002, [cited 30 Oct 2003], Available HTTP: http://www.gekco.com/vidprmr.htm Analog Devices, Data Sheet AD725AR: Low Cost RGB to NTSC/PAL Encoder with Luma Trap Port, [Online Document], October 1997 [cited 12 Oct 2003], Available HTTP: http://www.analog.com/UploadedFiles/Data_Sheets/774020909AD725_0.pdf

[2]

[3]

[4]

[5]

[6]

20