I.  IR Receiver / Decoder


Our IR receiver / decoder was designed to be sample a signal at 0.1 ms.  However, because of interference as well as some aspects of the remote and the demodulator in the receiver, the signals are not always exactly the same pulse-width.  Some times we sample 6 (+1) times and some times we sample 4 (-1) times in a 0.5 ms pulse.  Such are not important because in pulse-coded IR signals, short pulses are 0.5 ms (count of 5) and long pulses are 1.5 ms (count of 15).  Therefore, we have a substantial margin of error.  We have designed the code to recognize any count less than 10 as a short pulse and any count greater than 10 to be a long pulse.  As discussed in the previous section, we have successfully filtered out the problem of decoding a degenerate signal from rapid button pushes.  The question is then what is the fastest that an impatient user can push and still have the signal be recognized.  We have set a grace period of 9ms in between button pushes, so theoretically if the remote does not send a degenerate signal (which it often does) at a rapid succession of 9ms our decoder will accurately decode it.  Otherwise, our decoder will decode as fast as the remote can send a non-degenerate signal. 


Infrared signals do not pose any significant threat risks requiring special safety design features.  In completing and testing our design, we sought out other groups who were working on IR.  We did not receive complaints about our 32-38 KHz signal causing an interference.  We believe that the signal will attenuate within the normal range of a living room in the direction that it is pointed.  Therefore, even if another group we did not know about was working in the 32-38 KHz range, there would be interference only if that group was situated adjacent to us.  Occasionally we do get interference from the sun or some light source perhaps giving off infrared.  We have corrected this problem by placing a strip of electric (black) tape over our infrared receiver.





Our receiver / decoder design is very versatile.  It allows the user to entertain the illusion of reprogramming his or her remote by allowing the receiver / decoder to be reprogrammed.  All this can be done on a user-friendly menu from HyperTerminal.  Now, if the user wanted to disconnect our design from the video game and implement it on something else, i.e. television, he or she will have to understand the workings of the television IR receiver and change a few output pins in our source code. 




II.  Connect Four


Our video game code is highly accurate in timing.  Since the TV input signal requires a synchronized signal, the “sleep” command in the video code makes every loop occur at synchronized intervals.  If the game code takes longer time than is available during the vertical blanking period, there will immediately appear on the TV screen artifacts that will remain.  We have taken the severest pangs to simplify our code so that no artifacts occur during the entire game play, and therefore proving that the timing of our code is highly accurate.


We also spend much time to test for the accuracy of our match-testing algorithm by isolating the test of each general direction at various regions on screen.  Our final checking algorithm should be very accurate.  The entire set-up is very user friendly.  The remote control receiver / decoder has a user friendly numerical menu which allows a number of features such as testing button presses, reprogramming all keys, and reprogramming just numbers.  Our game is very user friendly as it is very self-explanatory.  Each column is labeled with a number so that the player knows which column the token will fall in.