Preliminary Design Report

Transcription

1 EEL 4924 Electrical Engineering Design (Senior Design) Preliminary Design Report 31 Jan 2012 Project Title: Keyboard Jockey Team Members: Name: Jeffrey Kaufman Name: Jacob Meacham Project Abstract Our project is a portable version of the musical play-along game genre popularized by "Rock Band", using keyboards. We intend to accomplish this by constructing a center game console and designing a generic keyboard "controller" that allows for each person with their own controller to play the game. Two keyboards will be used to demonstrate the game. The center console will have a monitor controlled by a Serial-to-VGA graphics module that scrolls the notes that are to be played horizontally; in addition, this module will play the song through a speaker while the players follow along on their keyboards. This module will have an SD card port to allow the user to easily add new songs to the pool from their PC, provided that they are encoded as a.wav file. The individual controllers will have an LCD, but it will mostly be used to navigate a menu and tutorial. The controllers will each have keys that will be pre-programmed to play specific tones, depending on the key of the song. Both the console and the individual controllers will be outfitted with XBee transceivers, allowing for easy wireless communication. All of these peripheral devices will be controlled by ATmega1284P microcontrollers. The console will be powered from a wall outlet, and each controller will be powered by a single 9V battery. Additional educational software will be provided so that the user of a controller can learn the basics of playing the keyboard while not connected to the multiplayer game console. 1

2 Table of Contents Project Features... 3 Concepts and Technology... 4 Flowcharts and Diagrams... 6 Work Division... 9 Gantt Chart Table of Figures 1. XBee Modules µvga II (SGC) top view µvga II (SGC) bottom view Keyboard Jockey Block Diagram Console Software Flowchart Controller Software Flowchart Work Division Table Keyboard Jockey Gantt Chart

3 Project Features This project will have several features that make it more attractive than what is currently on the market. Keyboard Jockey will have a single gaming console. This console will be responsible for coordinating challenge matches between multiple controllers. Since the controllers communicate wirelessly with the game console, there is also no need to restrict the number of players to 4, as is frequently done on commercial game consoles. The console will have an AC power plug stepped down to a 5V DC for the Serial-to-VGA graphics module. This single module will perform both the.wav decoding from an SD card and the VGA output to a monitor for follow along gaming. Keyboard Jockey will also have the capability to add up to as many controllers as desired. Each console will be battery powered for portability. They will each have actual keys that teach gamers note location and tone memorization. These controllers will be considerably less expensive than comparable competitor products. 3

4 Concepts and Technology ATmega1284P We decided to use the ATmega1284P for both the console and controller microcontrollers, because of the relatively large size of its flash memory and internal timers. The ATmega1284P has 128KB of flash memory, which we believe will be suitable for holding our programs. The size of this memory was the largest we found in a 40-pin DIP package, which ensures that we will be able to solder the part without too much difficulty. The ATmega1284P also contains four timers, which we will need to produce the pulses for the audio circuitry on the keyboard controllers. We intend to use a timer interrupt for each simultaneous tone, requiring three timers to produce chords of three tones, and leaving one timer for general purposes. The ATmega1284P also contains two serial UARTs; the console requires a UART to operate the uvga-ii console, and both the console and controllers each require a UART for the XBee wireless modules. XBee We chose to use the XBee units for wireless communication between our console and controllers in order to avoid the need to construct our own antenna and filtering circuitry. We believe that such a task would cost a lot of time and would take away attention from other important aspects of the project. The Xbee units provide wireless communication in the 2.4 GHz radio band at a maximum rate of 250kbps. Since the communication units are only intended to initially synchronize the controllers before a song and then tally score information at the end of the song, this data rate is quite sufficient. The units can transmit this data at a range of up to 100 feet indoors, which is also suitable for the design of our project. We will be establishing a point to multipoint communications network, where the channel of communication facilitates information exchange between a designated hub (the console) and a large number of outer units (the controllers). Figure 1: XBee Modules Source: 4

5 µvga II (SGC) Originally, it was proposed that the project's console would display the game data (mostly scrolling notes) on an LCD, since programming the LCD would be simple enough so as to not take away time from other aspects of the project. Unfortunately, using an LCD presented a couple of problems. The first issue is that the size of the LCD (a couple of square inches) is simply not large enough if the users intend to play the game from distances of more than a meter. Secondly, we were concerned that writing data to the LCD would take too long, and would not meet the needs of our timing-sensitive game logic. We decided that displaying the game data to a standard VGA monitor was the cleanest and most appealing solution to our problems. We have chosen to use the uvga-ii for the console's graphics rendering and music streaming purposes. The uvga-ii is an embedded module that possesses audio (.WAV) streaming and VGA graphics capabilities, which are controlled by a master microcontroller through an easy serial interface. The module is able to play music and display images from a built in microsd card reader on the module itself; individual files on the SD card are accessed through serial commands. Programs of these commands are also able to be stored on the SD card, so a large enough flash memory would free up the console to perform other tasks (such as communicating with the controllers and handling game logic).the SD card reader is visible in the bottom view of the module, shown in a figure below. The decision to use the uvga-ii module was made on the basis of cost and time reasons. The uvga-ii is listed at $ designing, programming, and constructing the VGA controller alone would take many hours and the cost of a suitable FPGA and board would well exceed the price of the uvga-ii. Once the development time and cost of adding an SD reader and audio decoding circuitry were considered, it became even more apparent that the uvga-ii module is a near perfect solution for the console's objectives. Figure 2: µvga II (SGC) top view Figure 3: µvga II (SGC) bottom view Source: 5

6 Flowcharts and Diagrams The following figure is the current block diagram for our project. The block diagram is divided into both a single console and single controller area, but it should be noted that the controller block represents a generic controller which could be replicated numerous times. This diagram also shows most of the hardware flowcharting that has been designed so far. Figure 4: Keyboard Jockey Block Diagram 6

7 The next figure shows the current logic for the program that will be loaded into the console s microcontroller. Since the uvga II (GSC) has the capability to execute extended programs in the SD card s flash memory, most of the graphics rendering commands will be stored outside of the microcontroller, and are not shown here. This will free up both space and time for the console s microcontroller. Figure 5: Console Software Flowchart 7

8 The final figure of this section shows the current logic for the program that will be loaded into the microcontrollers of the keyboard. The subroutine that produces the pulses that will constitute the musical tones and chords is not shown here; we believe that we will implement this by constantly scanning the keys (attached to GPIO pins) and then loading the prescaler registers of the timers according to how long we want the period of the pulse to be. This subroutine would replace the Correct Chord Pressed diamond decision box. It should also be noted that the Tutorial Logic has been omitted for simplicity in this figure. We can make the tutorial as complex or simple as possible near the end of our project, since changes to the tutorial will not affect the constructed hardware. Figure 6: Controller Software Flowchart 8

9 Work Division The Work Division Table produced below is fairly self-explanatory. We intend to split the entire work of the project evenly, with Jeff focusing on Digital interfacing and programming and Jacob focusing on Analog circuitry and project construction. Jeff Jacob Preliminary Research 50% 50% Design 50% 50% Board construction 50% 50% Analog circuitry 40% 60% Programming/interface 80% 20% Test/ Debug 60% 40% Physical Assembly 20% 80% Figure 7: Work Division Table 9

10 Gantt Chart As shown in the Gantt Chart, we intend to finish most of our prototyping before Spring Break, so that we can focus on module integration and project assembly as soon as we return. According to this schedule, we should have at least 2 weeks to test our project (and add more songs!) before the final project demonstration on April 19. 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28 3/6 3/13 3/20 3/27 4/3 4/10 Preliminary Research Ordering Parts Prototyping Chords Prototyping Power Prototyping Xbee Testing.wav Streaming Prototyping Display Module Integration Console Construction Controller Construction Game Software Final Product Testing Figure 8: Keyboard Jockey Gantt Chart 10