05508 – EE PLASMON Multimedia Kiosk - EDGE



05508 – EE PLASMON Multimedia Kiosk

Team:

Tracie Johnson

Chris Brazener

Sponsor/Mentor:

Dr. Robert Bowman

Coordinators:

Paul Garsin

Dr. Daniel Phillips

Introduction:

The PLASMON system (Project #05508) is a multi-media kiosk for the Electrical Engineering Department. The kiosk will serve as a center for up-to-date information as well as a form of entertainment. The intended target audience consists of both current and prospective students.

Needs Assessment:

The PLASMON Multimedia Kiosk resides outside of the department of Electrical Engineering in the Kate Gleason College of Engineering at RIT. Prior to its inception as a senior design project, the kiosk allowed the user to view a PowerPoint presentation, which was played repeatedly by a personal computer (PC). The subject matter of the slide show consisted of information relative to the department of Electrical Engineering, its staff, faculty, and students.

The existing kiosk is comprised of a widescreen flat-panel monitor, a Pentium III PC, an audio amplifier, a pair of loudspeakers, an interface board, and a capacitance-sensing touch plate.. The initial setup of the PLASMON was intended to facilitate additional hardware for interactivity. The department purchased a capacitive touch panel for use with the system, as well as interface circuitry and harnessing for connection of the panel to the parallel port of the computer.

The PLASMON project entailed the creation of design modifications in an effort to make the kiosk presentation more interactive and informative. Instead of repeatedly playing a slide show, the new kiosk facilitates interaction with the user, allowing the user to extract information efficiently. The PLASMON also provides a degree of entertainment while supplying information about the department.

The end realization of the PLASMON system is a completely interactive and informative kiosk that incorporates documents, calendars, photos, audio, and video streams that can be controlled by the user. Since the majority of the users of the kiosk will be people with an interest in the EE field or the department, the quality of the overall presentation will be of utmost importance. A strong presentation will allow the kiosk to attract users and encourage them to learn about the department.

Specifications:

The PLASMON multimedia presentation shall be able to provide the user with the following content:

• Academic Flowcharts for each EE Degree Program

• Event Calendars and Department Information

• Photo Albums of Faculty/Staff /Students

• Information about the PLASMON itself

• A Virtual Tour of the Electrical Engineering Department

• Provide an entertaining, interactive experience

The PLASMON System shall offer the following to the Operator/Administrator:

• Simple and Efficient Updating of Presentation via common Microsoft Applications

The PLASMON hardware shall consist of the following:

• A Pentium 4, PC-Compatible personal computer with the following requirements:

o 2GHz or better CPU

o Minimum 1GB of free Hard drive space

o 128M video card or better

o Minimum 256 MB of RAM

o PS2-configurable Parallel Port

• A Quantum Research E-160 six-button charge-transfer touch panel

• A 50” High-resolution color plasma display

• An audio amplifier and speaker system Part Number: 31-1982B

• A presence-sensing device that will begin the presentation when a potential user approaches the kiosk within five feet

• An Interface board to facilitate communications between the touch panel and the Software.

Deliverables

Below is the list of deliverables to meet customer satisfaction:

1. Complete/functional Software application, which complies to all required specifications.

2. A Functional interface board with all required harnessing

3. One unpopulated Interface PCB board along with all required parts for assembly of one additional Interface PCB

4. One Technical Manual Detailing Software and Hardware Installation and configuration

5. One Users Manual Detailing Presentation Updating.

6. CD containing all software, hardware schematics and layout files, pictures, videos, manuals, etc.

Concept Development:

The conceptualization for the PLASMON kiosk had been underway prior to becoming a senior design project. The kiosk booth had been constructed. The monitor, a Pentium III PC, a touch panel, an interface box, and complete set of harnesses were also acquired prior to the inception of the 05508 PLASMON senior design project. The concept development phase was therefore bounded by pre-existing hardware requirements. Issues addressed in the concept development phase included:

• Type of executive programming language

• Incorporation of photo albums and video streams

• Polling I/O scheme versus interrupt-driven I/O

• Hardware and software interaction in response to stimuli from the user

• Design of both hardware and software for testability

• File structure for easy maintainability

Perhaps the most important concept to be considered is the type of programming language to be used for the presentation. Prior to Senior Design involvement in the PLASMON project, the kiosk software was constructed entirely with the Flash MX web graphics/animation package available from Macromedia. Although this software facilitates high-quality graphics images and effects, it provides little control over I/O peripherals such as the parallel port. The files created by Macromedia are very large, and as a result require a significant amount of time to load before execution can take place. For these reasons, a brainstorming session was held to determine the best method for creating the structure of the kiosk software. One result of the session was the idea of implementing an executive program that could call much smaller files when prompted by the user. The executive program could run the hidden functions necessary for I/O handling and menu navigation, while the “slave” program would run the applications visible to the user, such as photos and video animation.

The executive program idea brought about other issues to be looked at further-- one being which software would be the best for this executive code. Visual Basic and C++ were both considered during brainstorming to serve as the executive programming language. The characteristics determined to be most important in choosing an executive language include:

• Compiling time

• Execution Speed

• Graphics Capabilities

• Easy import/ export of different file types to the presentation

Using these characteristics, a rating system was established. The rating system was implemented, and results were tabulated in the Feasibility Assessment section of this report.

A second consideration that required some analysis was the method of communication between the executive language and the parallel port. Recent Microsoft Windows operating systems (Windows ’98 and later) require the use of a Kernel-mode device driver in order to gain access to hardware peripherals. On-line research was conducted, and four drivers were weighed according to the following characteristics:

• Compatibility with executive programming language and operating system

• Possible conflicts with existing parallel port drivers

• Ease of incorporation of parallel port driver with executive software

• Simplicity of Syntax

• Ability to read or write to port registers

• Ability to respond to hardware interrupts

• Price

The results of the rating procedure are documented in the Feasibility Assessment section of this report.

Visual basic has the ability to read the contents of a folder and point to files. Because the photo albums were required to be easily modifiable, the concept of file and folder access was examined closely. It was determined that a photo album folder could be created to hold all pictures. Within this folder, the administrator could add and remove files without having to modify code if pointers to files are used in the executive skeleton. The same is true of faculty interviews. This could allow the users to “page” through selections simply by moving a pointer.

Design for testability was considered in the early stages of the project. Only one set of hardware existed, which made testing and development challenging at times. Over the course of software design, provisions were made that would enable the software developer to test code on a laptop without requiring the use of the touch panel. Likewise, during the design of a new interface board, provisions were made that would enable a system test with only the interface box and a PC. Consideration of design for testability proved very useful and will benefit future developers of the system.

While the project was in the design stage certain concerns about the polling structure were expressed. This consideration of interrupt-driven I/O led to conceptualization of a hardware-software communication scheme that will provide an interface that is as error-free as possible. Hardware interrupts can be caused by a button press at the touch panel, or by detection of a user by the presence sensor. The interface PCB could provide hardware that can allow the software to disable certain events, or being able to monitor signals without causing an interrupt. This is discussed more in depth during the feasibility section.

Presence/motion sensors were researched concurrently to conceptualization of the Interface PCB. Both infrared and ultrasonic sensors were being considered. See the Feasibility section of this report for a synopsis of sensor selection.

Feasibility:

After assessing the needs and creating software concepts as stated above, the choices were summarized and then a brief analysis was preformed. Due to previous decisions determined by the first Engineering Team, the project already had a definitive direction, which in turn created less of a need for an elaborate feasibility assessment. One of the focal points in the beginning of the project centered on how the execution of the menu navigation was going to be preformed. Below, in Table 1, shows a summation of the decision process. . The two options considered were:

• Create an executive skeleton that could call smaller portions of the presentation upon each input from the user.

• Keep the presentation entirely within Macromedia and try to use Macromedia’s ‘Action Script’ for interfacing.

| |Executive Program |Macromedia |

|Rank |Pro’s |Con’s |Pro’s |Con’s |

|4 |Apparent Parallel Port | | |No Apparent Parallel Port |

| |communication capability | | |communication capability |

| |(4) | | |(-4) |

|3 | | |Approximately 2+ fewer weeks | |

| | |Approximately 2+ additional |implementation time | |

| |Faster execution time. (3) |weeks of implementation time |(3) |Slower execution time |

| | |(-3) | |(-1) |

|2 | |Would require 30+ (small) |Ability to have one (large) | |

| |Past Experience with Software |graphics Swf files |graphics .exe file |No Prior Experience |

| |(2) |(-2) |(2) |(-2) |

|1 |Approximately a fourth of the | | |Large files size and processor |

| |File Size. (~112Mb) | | |usage. (~ 400Mb) |

| |(1) | | |(-1) |

| |Total: |+5 |Total: |-3 |

Table 1: Concept Decision 1 - Executive Vs. Macromedia

The above table made it apparent that the Macromedia option wasn’t a feasible choice. This was confirmed with the shortcomings the previous Engineering team encountered using this approach. With this evaluation complete, another obstacle presented its self. The executive program could have been developed using various software packages. At the time of the concept development the two obvious choices were to use either C++ or Visual Basic 6.0 due to the software package capabilities. Refer to Table 2 below for the results.

Visual Basic was ultimately chosen as the executive language for the kiosk. Visual Basic (VB) has the ability to call other applications such as Macromedia Flash, Windows Media Player, or Microsoft Office applications within the GUI. This provides a degree of modularity with respect to modification and upkeep of the presentation. If a video or spreadsheet needs to be changed, the administrator can simply replace the source file. This modularity gives rise to the overall file and directory structure of the kiosk software.

| |C++ |Visual Basic 6.0 |

|Rank |Pro’s |Con’s |Pro’s |Con’s |

|4 |Software created for data and |Software package not created for |Microsoft package allows easy | |

| |register manipulations. Important|additional “plug and play” graphics |compatibility with other Microsoft | |

| |for the Parallel Port |(-4) |products using OLE containers (Word, excel| |

| |(4) | |etc.) | |

| | | |(4) | |

|3 | |Approximately 2 additional weeks |Software package designed specifically for|Software package not used for in|

| | |added to implement time |GUI applications |depth register manipulation |

| | |(-3) |(3) |needed for the PP |

| | | | |(-3) |

|2 |Compiled language | |Current .swf integration available |Interpreted Language |

| |(2) | |(2) |(-2) |

|1 | | |Prior VB team experience, leading to | |

| | | |approximately 2 fewer weeks for | |

| | | |implementation time | |

| | | |(1) | |

| |Total: |-1 |Total: |+5 |

Table 2: Concept Decision 2 - C++ Vs Visual Basic

Using both of these assessments the project went underway using a Visual Basic executive program that utilizes different Macromedia .swf movie files depending on user input.

The project initially adopted a polling structure in order to detect a user key press. However there were a few concerns expressed pertaining to the CPU processing power being consumed consistently while the program was running. Although the presentation seemed to be operating within the real time specification, future additions may have an impact and create a time lag or a discontinuous appearance. At this time, a proposal to transfer to an interrupt driven structure was considered. Although this would involve a complete redesign of the current I/O scheme, the system would be a more robust and practical application. Below in Table 3, is the layout of the decision process.

| |Alter to an Interrupt Structure |Pursue Current Polling Structure |

|Rank |Pro’s |Con’s |Pro’s |Con’s |

|4 |Frees up to 10 times the CPU Processing time |Loose up to 3 weeks of project |Will have up to 3 additional |May limit future additions, |

| |(4) |design |weeks to create additions |and usage of the kiosk |

| | |(-4) |(4) |(-4) |

|3 | |Design/build/purchase new | | |

| |Creates a smoother real-time presentation |Interface board capable of | | |

| |(3) |interrupts | | |

| | |(3) | | |

|2 |Would satisfy customer specifications to a greater | | | |

| |extent | | | |

| |(2) | | | |

|1 |Provides valuable team experience | | | |

| |(1) | | | |

| |Total: |+3 |Total: |0 |

Table 3: Concept Decision 3 - Interrupt Vs. Polling

After evaluating the different aspects and possible consequences of this change during the design stage, the team came to the conclusion to peruse the hardware interrupt structure. In order to make the transition as smooth as possible, most of the existing code was utilized.

Using a similar process as the previous concept feasibility, the team created a rating system for the multiple drivers available to implement communication to the parallel port. Below is a table format of this decision method.

|  |PortTalk |TinyPort |Inpout32 |TVicLPT |

| |1 |1 |3 |5 |

|Executive Compatibility | | | | |

| |3 |3 |3 |5 |

|PC HW Compatibility | | | | |

| |0 |3 |3 |5 |

|Syntax | | | | |

| |3 |3 |3 |4 |

|Port Manipulation | | | | |

| |0 |0 |0 |5 |

|Interrupt Capability | | | | |

| |5 |5 |5 |3 |

|Price | | | | |

|Total |12 |15 |17 |27 |

Table 4: Concept Decision 4 – Communications Driver

The TVicLPT driver was determined to be the best choice given the above results. The main features this particular driver offered was the hardware interrupt capability. This driver provided extensive technical documentation that proved to be useful during the initial implementation stage.

During the hardware brainstorming session various motion/presence sensors were considered, the two primary types being infrared and ultrasonic. The ultrasonic was determined to be more suitable for this application due to the directionality as well as the dual adjustable ranges. Although the infrared sensor is more cost effective, the previously mentioned characteristics are not available within this option. The functionality of the presence sensor is addressed in more detail within the Hardware section.

Project Plan:

During the preliminary stage of the project, a schedule was fashioned using Microsoft Project as shown in Appendix A, Figure 1. The milestones during the primary phase centered on obtaining communication from the hardware to the software, along with preparing the prototype version for beta testing on the EE floor of RIT. These milestones were met with a few exceptions. Obstacles were encountered that impeded the implementation slightly. However, problems were anticipated and extra time was built into the project schedule.

During the succeeding stage of the Plasmon Project, a revised schedule was produced to account for pursuing the replacement of the polling I/O scheme with the interrupt-driven scheme. The main milestone then became the completion of the Hardware and Software interrupt driven Interface. Other software milestones included the implementation of Photo Album software, which also allows the user to view pictures and interviews of the Electrical Engineering Professors. The proposed project schedule was subjected to some delays when introduced to additional features that were requested by the customer. However, the milestones were met with the addition of approximately 20 work hours. For further details on obstacles and solutions that were encountered during the complete project process, see the section “Compatibility/Debug Issues” of this report.

A flexible budget of $500 was originally allotted to the Plasmon project. The final project was completed below budget by approximately $200. In the initial design phase of the PLASMON, software was the focus and no major purchases were necessary. The budget was split into four broad categories, additional parts, replacement parts, resources, and miscellaneous. During Sr. Design II the budget became more pertinent due to the design of a new interrupt capable interface board as well as the integration of a presence sensor. For a detailed purchase tracker refer to Appendix A, Figure 2.

Hardware:

The user interface consists of a charge-transfer touch panel. The part chosen for this design is an E160 evaluation board offered by Quantum Research Group, and is depicted in Appendix B, Figure 1. See Appendix B, Figure 2 for a schematic diagram taken from documentation supplied by Quantum.

The touch panel consists of six buttons, which detect body capacitance upon the presence of the user’s finger. The user’s body capacitance adds to the button capacitance to actuate the logic level that is sent through the interface box to the parallel port. The E160 is covered with a clear plexiglass face that fits over the top of the buttons. Upon installation of the touch panel onto the kiosk structure, this cover is removed such that it can be fastened to the underside of the plexiglass panel in front of the PLASMON monitor. Each button on the touch panel is assigned a number. Button #1 is located adjacent to the pin header, and the numbers increment in a clockwise direction.

The output of the touch panel can be configured via on-board switches to provide either pulsing actuation or toggling. When set to pulse, the output goes high and then returns to a low logic level when the user removes his/her finger. When set to toggle mode, the button must be activated a second time to return the logic level to a low state. For the PLASMON application, the pulse mode was chosen.

The presence sensor chosen for the kiosk was a SonaSwitch Mini-S. This sensor has two adjustable sense ranges (“long” and “short”). The sensor emanates periodic bursts of high-frequency sound waves, which bounce off of anything in front of the sensor (up to ten feet in range, with a fifteen-degree dispersion angle). For the sensor to detect a body, three successive reflections must be received. This feature is useful in minimizing interrupts to the kiosk from rapidly-moving objects or people. See Figure 1 for a visualization of how the sensor responds to objects at varying distances. The Mini-S is powered by the +12V supply from the PC. It has two open-collector outputs (one corresponding to each range), which are pulled up to +Vcc on the Interface Board. Upon detection of an obstruction within a range, the output transistor pulls the corresponding output low. The sensor is connected to the interface board via a four-conductor Presence Sensor Harness.

[pic]

Figure 1: Sensor Reaction to Various Distances

The original interface PCB was designed by Dr. Robert Bowman. It consisted of a series of buffer amplifiers that convert the +5V logic levels to +3.3V, one for each of the six buttons. There were also seven through-hole LEDs. One LED indicates when power is applied to the circuit. The other six each illuminate when their respective buttons have been pressed. The original interface PCB was used in system development for the first half of the project. Upon completion of Senior Design II, the decision was made to change the interface scheme to respond to hardware interrupts at the parallel port. Dr. Bowman’s design served as a starting point for the new design. As the new interrupt capable interface PCB was deigned, all possible I/O stimuli were considered. The embodiment was to consist of circuitry that would accept six logic levels from the touch panel as well as a logic level from the presence sensor, which had yet to be defined in the initial design phase of the interrupt-driven interface PCB. Figure 2 shows a conceptualization of the interface PCB.

The interface PCB is connected to the touch panel through a 10-conductor ribbon cable that shall be referred to as the touch panel harness. The touch panel harness is terminated to a DB-9 connector in order to mate with the interface PCB. The other end of the cable is terminated with an insulation-displacement ribbon connector that mates to the ten-pin header on the E160. For construction and pinout diagrams of the touch panel harness, see Appendix B, Figure 9.

[pic]

Figure 2: Conceptualization of Interface PCB in the PLASMON System

The hardware design of the Interface PCB was dependent on the methods in which the parallel port would accept and respond to hardware interrupts. The hardware design of the interface board and the design of the interrupt-handling scheme were thus developed concurrently. See the Software Implementation section of this report for information on the Interrupt Service Routine used in the kiosk software.

Possible inputs from the environment would include button presses, presence sensor signals, and the current state of the presentation. In design of the interface, all possible combinations of stimuli were considered and desired system responses were chosen. Hardware was designed accordingly. See Table 7 for a visualization of possible situations and responses.

It was determined that three control signals were needed for dependable operation. These three signals could guarantee that only one interrupt would be serviced at a time. The software could receive the stimulus, take proper actions to service it, and then send a control signal to hardware indicating the interrupt has been processed. The hardware can then be reset by software to send another interrupt upon the next user input. See Appendix B, Figure 3 for a schematic of the Interface PCB.

Button logic levels are fed into a hex buffer chip. On-board tactile switches SW1-SW6 provide the ability to activate a touch panel input when one is not available, and also feed the buffers in a wired-OR configuration with the button signals from J1. Quad NOR-gate U2 is used to invert the open-collector outputs of the presence sensor and to hold the lines low when the PRES_SENSE_DISABLE line from the parallel port is high. Jumper JP1 is added in a wired-OR configuration to hold PRES_SENSE_DISABLE high in hardware. While the interrupts due to the sensor lines are disabled, their respective logic levels still propagate to the 8-bit latch U5. The open-collector outputs of the sensor are inverted and fed into an octal-input OR/NOR gate U3 along with each of the button signals. When any of these signals go high, U3 clocks a D flip-flop U4. The non-inverting output of U4 goes high. This signal is used to latch the button and sensor logic levels into U5. The slope of the interrupt line needed to generate a hardware interrupt can be either a negative-going transition or a positive-going transition, depending on the PC the system is operating on. Pin header J6 allows the user to select either transition type. Once a hardware interrupt is generated, subsequent interrupt transitions are prevented to occur by hardware until the /INT_CLEAR line resets U4 from software, and all inputs to U3 go low again (ie. the user releases the button). The LATCH_CLEAR line enables software to make the latch outputs all low. Pin header J5 allows the technician to select either 5V logic or 3.3V logic. This is, again, dependent on the type of parallel port. A Bill of Materials is shown in Appendix A, Figure 3 and a Layout diagram for the Interface PCB can be seen in Appendix B, Figure 4.

The output of the interface PCB consists of eight logic levels (corresponding to each of the buttons and two sensor lines) and a ground line. The interface PCB is connected to the parallel port via the parallel port harness. The parallel port harness (PPH) mates to the interface PCB via a DB15 solder-cup connector. The cable consists of thirteen conductors- a ground line, six button lines, two presence sensor lines, a hardware interrupt line, and the three control lines used by software to facilitate I/O protocol. The PPH mates to the 25-pin parallel port on the back of the PC. An assembly diagram for the parallel port harness can be found in Appendix B, Figure 5.

The interface PCB requires a +12V supply, +5V supply, and a ground wire for power. This is supplied by the PC’s power supply via a standard 4-conductor disk drive power cable. This harness is shown in Appendix B, Figure 6. Once all harnesses have been constructed, the PLASMON system assembly becomes a simple procedure. Figure 3 depicts the connections required to construct the PLASMON interface system.

[pic]

Figure 3: System Interconnection

The Parallel Port:

The parallel port connector on the PC is of the DB-25 (IEEE-1284-A) ilk. A pinout diagram of the PC parallel port connector is shown in Figure 4 below.

Figure 4: PC Parallel Port Connector

The six button lines from the interface PCB connect to the data pins on the parallel port. Button #1 connects to D0, #2 connects to D1, and so on. There are two unused data lines (D6 and D7), these are left unimplemented for future revisions of the design. The use of the parallel port interface requires software to be able to access the logic levels present on the port pins in order to discern what buttons have been pressed. There is a bank of registers that resides in the PC’s memory that governs the operation of the parallel port. For a standard PS/2 port, the bank consists of the data register, the status register, and the control register. In order to control the parallel port, the locations and functions of each of these registers must be understood. Figure 5 shows the three parallel port registers for a standard bidirectional PS/2 port. There are multiple types of parallel port interfaces. Table 5 shows a comparison of each type. For the PLASMON system, a bidirectional port is necessary. Regarding the operation and configuration of the parallel port, the assumption will be made that the port is either of the PS/2 type, or is emulating the PS/2 type.

[pic]

Figure 5: Parallel Port Registers

Table 5: Parallel Port Types

The memory locations of the parallel port registers are somewhat standardized. Typically, the data register for LPT1 resides at memory address 0x378. Its status and control registers are usually found at 0x379 and 0x37A, respectively. Since these addresses may not apply to all machines, they must be ascertained before parallel port interface is possible. This can be accomplished by running WINMSD.EXE from the RUN selection of the START menu in Windows NT/XP. Figure 6 shows the menu selections necessary to locate the parallel port (LPT1) addresses.

[pic]

Figure 6: WINMSD.EXE

Since the parallel port will be used entirely as an input, the bidirectional port must be configured accordingly. By setting bit 5 of the control register, the output buffers of the port are placed into a high-impedance mode. The driver will then read high logic levels from the pins until an external device (the touch panel) pulls the level low. If the data pins are not configured as inputs, the touch panel could sink enough current through the port output buffers to damage the port circuitry. A simplified schematic of the parallel port can be seen in Figure 7.

[pic]

Figure 7: Simplified Schematic of the Data Register

Parallel Port Interface Implementation:

The TVicLPT parallel port driver was used in the kiosk software to provide hardware/software interfacing. It is available for download at: dev/lpt/index.shtm. Benefits of TVicLPT over previous port drivers include simple syntax and integration into Visual Basic. The TVicLPT driver has the ability to locate LPT1 in memory automatically, which requires less low-level hardware knowledge from the programmer.

As discussed earlier, the parallel port must be able to accept eight inputs from the buttons and sensor (PP data lines), and one input to generate hardware interrupts (ACK). Three parallel port pins must be used as outputs to control interface hardware. There are three bits available in the control register that can be used as outputs. The following table shows choices of parallel port bits to be used as interface control signals:

|Parallel Port |Control |Inverting |Interface Control |

|Signal |Register Bit | |Signal |

|nAutoLF |1 |Y |LATCH_CLEAR |

|nInit |2 |N |PRES_INT_DISABLE |

|nSelectIn |3 |Y |/INT_CLEAR |

Table 6: Parallel Port Bit Options

The interrupt service routine needed be designed such that upon the occurrence of an interrupt, software will disable further interrupts until it has completed servicing the current interrupt. Further detail pertaining to the software Interrupt Serious Routine refer to the Software Implementation section.

A synopsis of possible combinations of stimuli and appropriate actions are given in Table 7. A similar table was used in the creation of the software ISR.

|Button 1 |Button 2 |Button 3 |Button 4 |Button 5 |Button 6 | |Long |Short |Action Taken |

| | | | | | |Awake |Range |Range | |

| | | | | | | |Sensor |Sensor | |

|0 |0 |0 |0 |0 |0 |0 |1 |0 |Wake-up Presentation from Screen Saver. |

| | | | | | | | | | |

| | | | | | | | | |Disable further Presence Sense |

| | | | | | | | | |Interrupts |

|0 |0 |0 |0 |0 |0 |0 |0 |1 |Wake-up Presentation from Screen Saver. |

| | | | | | | | | | |

| | | | | | | | | |Disable further Presence Sense |

| | | | | | | | | |Interrupts |

|0 |0 |0 |0 |0 |0 |0 |1 |1 |Wake-up Presentation from Screen Saver. |

| | | | | | | | | | |

| | | | | | | | | |Disable further Presence Sense |

| | | | | | | | | |Interrupts |

|1 |0 |0 |0 |0 |0 |0 |x |x |Wake up. Go to Main Menu |

|1 |0 |0 |0 |0 |0 |1 |x |x |Navigate to Menu Choice #1 |

|0 |1 |0 |0 |0 |0 |0 |  |  |Wake up. Go to Main Menu |

|0 |1 |0 |0 |0 |0 |1 |x |x |Navigate to Menu Choice #2 |

|0 |0 |1 |0 |0 |0 |0 |x |x |Wake up. Go to Main Menu |

|0 |0 |1 |0 |0 |0 |1 |x |x |Navigate to Menu Choice #3 |

|0 |0 |0 |1 |0 |0 |0 |x |x |Wake up. Go to Main Menu |

|0 |0 |0 |1 |0 |0 |1 |x |x |Navigate to Menu Choice #4 |

|0 |0 |0 |0 |1 |0 |0 |  |  |Wake up. Go to Main Menu |

|0 |0 |0 |0 |1 |0 |1 |x |x |Navigate to Menu Choice #5 |

|0 |0 |0 |0 |0 |1 |0 |  |  |Wake up. Go to Main Menu |

|0 |0 |0 |0 |0 |1 |1 |x |x |Navigate to Menu Choice #6 |

Table 7: Combinations of User Input and System Reaction

Parallel Port Interface Development/Test:

Visual Basic was used to create a test application to verify proper port operation. This application was also used in the development of the interrupt service routine intended to handle hardware interrupts. A screenshot of the test application can be seen in Figure 19. The interface provides three text boxes displaying a hexadecimal representation of the data, status, and control ports. Another text box displays an “INTERRUPT!!” message when a hardware interrupt occurs. The “CLEAR” button changes the text box back to read “Zzzzz…” Six buttons at the bottom of the window offer bitwise manipulation of the three control lines used as control signals for the interface PCB. Once the prototype interface board was constructed, it was connected to the PC and the test application program was used to verify proper operation of the hardware. The test application also served as a development tool for the proper handshaking steps required of the interrupt service routine. The test application was eventually modified to automatically handshake with the hardware. These modifications became the basis for I/O interfacing in the kiosk software. The source code can be seen in Appendix C, Figure 1.

Software Concept:

After evaluating the objectives of the project it was necessary to understand what had already been completed. The majority of the project still needed to be created but initial graphics structure and menu navigation had been developed. However much of the previous work was recreated and elaborated in order to better meet customer satisfaction. The animation was created using a software package called Macromedia Flash MX. This software uses a timeline frame-by-frame animation process for which the user defines the frame rate. An animated scene is created by compiling multiple frames and layers, which typically include motion ‘tween’. The motion ‘tween’ capability of Flash is a major defining application for the software, which allows an automatic transition of motion, color manipulation, etc of an object in two separate frames. This automatic ‘tween’ can be created over any length of time and distance giving the user control over various speeds and positioning. A screen capture with component labeling is shown below in Figure 8.

Figure 8: Macromedia Flash MX

The initial conceptualization included some brief code written in Macromedia’s ‘Action Script’, which used the PC’s keypad numbers 1-6 as user input. This input allowed for navigation through the different menus and animations. However, there were many drawbacks found in using such a high level script- the most critical being the inability of ‘Action Script’ to manipulate port registers. The only user input that was supported by Macromedia was the PC’s keyboard and mouse; the touch pad couldn’t be incorporated.

Another major issue was the cumbersome maintenance process for the presentations information. The Macromedia Presentation text can be changed in two ways, one by using the editing process found in the .fla file. However, the presentation would have to be exported to a new executable. Macromedia also has the capability to point to text files (.txt), however, in order for the text to be displayed correctly, the text file needs to have a code-like syntax instead of plain text. This process also limits how the text is formatted, (size, color, font, etc). Both of these processes were too time consuming and technical to be acceptable to meet the customer requirements.

The team decided to use an executive program that would be constructed using the Visual Basic software package 6.0 as discussed in the Feasibility section. Visual Basic is an interpreted language, which has the capability to program low-level functions along with creating and programming high-level GUI’s. This was an important feature due to the fact the software entailed high-level User Interfaces such as the calendars and photo albums, but still required low level communication to the PC’s parallel port. In addition, VB is a Microsoft software package, which facilitates compatibility with many other Microsoft applications. This provided a solution to the problem of information maintenance and upkeep. The software now entails standalone Microsoft word documents and bitmap pictures that can be easily integrated into the presentation.

Software Implementation:

During the actual implementation of the Software design, a top-level menu map was created and presented to the customer for approval. This can be seen in Appendix B, Figure 7. After this was done the original Macromedia presentation was broken apart into many separate Shock Wave Flash (.swf) movies instead of one large executable. The executive program calls to these 28 short animations to be transition movies between the menu navigation. The main purpose of these animations are to provide an entertaining way of presenting different department information as well as display menu options to the Kiosk user. In addition to the top-level menu map, a lower level software flowchart was made to represent the Interrupt Service Routine (ISR) as seen in Appendix B, Figure 8. The next step was the actual development of the software. Figure 9 displays part of the main code executed at the Visual Basic form1 start up in the VB application window. The function of this code is to set the appropriate parallel port configurations need to set the touch pad as a user input. This also serves as the initial visual setup by importing a word document into the richtextbox1, which is a component object of form1. This is depicted in Figure 10 below. For the complete Visual Basic source code see Appendix C, Figure 2

Figure 9: Main Menu Startup Code

To prevent idle images from causing “burn-in” on Plasma Screen, a screen saver appears if the program remains idle for five minutes while in the main menu or ten minutes while in any sub menu. The screen saver displays random pictures from the “My Pictures” folder on the PC. If a user walks within a five-foot radius of the kiosk, an Ultra Sonic Presence Sensor is activated and starts the Plasmon Presentation in the Main Menu regardless of what menu selection was active when the screen saver was called. The main menu screen appears as shown below in Figure 10.

[pic]

Figure 10: Kiosk Main Menu

When the program is in its active mode, the object TVic standby until a hardware interrupt is detected. When an interrupt occurs it is then processed by the ISR which first masks further interrupts and determines whether it was a key press or a sensor triggered interrupt. Note that in the active mode all sensor interrupts are masked until the presentation becomes idle again. When the activated button is determined a variable intrpval is set to an integer 1-7 depending on a HEX value given by the parallel port using the Hex(ParPort.DataPort) command. Throughout the code execution a variable runmain is set and stored to act as a placeholder of where the user currently is in the menu navigation. These variables are sent to a service routine which determines which SWF movie to play and what key mapping to creating depending on both the variable intrpval and runmain. This service routine is depicted in flow chart format seen in Appendix B, Figure 8.

For an example if button 1 is pressed the parallel port sends either Hex C1 or 1 (depending on if the presence sensor is enabled or not) to the TVic object. The variable intrvpal is set to 2. If the user was currently in the main menu (runmain = 1) when the button was pressed the variable runmain is set to 2. The movie, PLASMONPresentaion_about.swf, is played using the VB container shockwaveflash1 for the “About” sub menu and form2 is displayed while form1 is hidden. The user now has different options and can press 1-6 to perform selections pertaining to “About the PLASMON”. Below is a screen shot of the ‘About’ menu as seen in Figure 11.

Figure 11: Kiosk About Menu

In the About mode the user can find out how to use the kiosk, who created the kiosk, how it works and how to become involved. The About menu offers and option for the user to view informational help and how to become involved in similar project. This information is imported into the Visual Basic form2 using another richtextbox object which calls to Word documents. If the user wants to return to the previous menu at any time, button 6 has been dedicated to a return command.

The main function of the kiosk is to provide up to date information about the Electrical Engineering department at RIT. One menu (See Figure 12) that provides information about the different programs available in the EE department is the Academic menu. Here, the user can call up seven different flow charts and information nine academic programs offered at RIT. These flow charts are easily updated by adding pdfs to Microsoft Word documents located in a EE flow Charts folder.

Figure 12: Kiosk Academic Menu

Another option in the kiosk presentation is the Calendar menu. In this menu, four months of the department calendar of events are available for viewing along with a list of upcoming important events. The calendars were created using a Microsoft Word VBS (Visual Basic Script) program while the “Important dates” file is a standard Word document. Both were made easy to update by incorporating these often-used Microsoft applications. This menu can be seen in Figure 13 below.

During the execution of the Calendar code, the program must create six different user options that are determined by the current month. First the PC’s internal clock is accessed to obtain a numerical representation of the current month. Next, four variables are set monthname1, monthname2, monthname3, and monthname4 to the string which holds the month’s name. These variables are then used to set four Visual Basic objects called lable1 – 4. These objects are embedded into form2 and are made visible only while in the Calendar Menu and represent the users six options while in this menu. If option 1-4 is chosen, a calendar is called and embedded into an OLE container located in form3. These calendars are Microsoft word documents, which contain VB macros.

The maintenance of the calendars was simplified by creating an automatic calendar creator. The administrator would have to simply click on a button, which would open a GUI, then select the appropriate month and year and chose “Apply Changes”. The program would automatically renumber the days for that month/year, and create a heading as shown in Figure 15.

[pic]

Figure 13: Kiosk Calendar Menu

[pic]

Figure 14: Kiosk Calendar View

[pic]

Figure 15: Calendar Program

The fourth option available to the Kiosk users is the Department Information menu. In this menu the user can find information pertaining to student and faculty awards, different clubs and organizations available, Current Sr. Design Projects, Research Areas, as well as 8 different Photo Albums. Below in Figure 16 is a screen capture of the Department Information Menu.

The code execution for this menu consists of calling different SWF movies as well as informational word documents. The concept is similar to the one described for the previous menus.

[pic]

Figure 16: Department Information Kiosk Menu

While in the Department Menu the user can access eight different photo albums, which contain pictures of students, faculty and staff. This album software was written to be compatible with a Visual Basic Object ImageBox that displays bitmap pictures. A sample of the Photo Albums is shown in Figure 17.

The execution of the Album software begins by employing a VB object called a filelistbox. This object is a visible pointer, which calls to a certain folder path and compiles all of the files with in the specified path. These files names are then displayed in the filelistbox and used as an available picture list. The Visual Basic form4 consists of the filelistbox as mentioned, four small image objects used to display picture preview thumbnails, one large image to display the currently selected picture, five textbox objects containing the user options and Album title, along with one richtextbox to display any informational text. During the execution of the Album software a variable index is used to determine which picture to display while two other variables are used to determine the next and previous picture.

If the user is the EE Faculty Photo Album only, they have an option to view an interview of the displayed Professor. When this option is employed form5 displays an embedded windowsmediaplayer object capable of playing different video and audio files.

[pic]

Figure 17: Kiosk Photo Album

One of the last menu options available is the virtual tour as seen in Figure 18. This option allows the user to go on a guided tour of the EE department directed by department head Dr. Robert Bowman. This menu also consists of different tours of the research, teaching and studio labs located on the Electrical Engineering floor at RIT. These videos are viewed in the same fashion as the professor interviews.

[pic]

Figure 18: Kiosk Virtual Tour Menu

The option labeled “Who Am I” is to be implemented by other Engineering Teams in years to come. This option will enable a face/voice recognition system that will allow students to “register” their faces and voices into the kiosk so that the kiosk will “remember” them in future encounters. For the current version of the project, there is a page holder prompting the user to visit this option in the future. In the software an empty menu slot was made available for easy additions.

Along with the actual PLASMON Presentation software, a test application was created for easy configuration of the PC’s Parallel Port. In Figure 19, a screen capture of the GUI application software is shown. Depending on the computer architecture, parallel ports are either positive or negative edge triggered. Using this application can give the administrator an easy one-shot way to determine the PC’s structure, register address and LPT number. This GUI is also used to place the parallel port in either read or write mode, however for the PLASMON software the parallel port must always remain in the Read Mode. This program may also be used for an easy debug process to determine if the parallel port is functioning in the appropriate fashion and reading the correct button HEX values. The complete Visual Basic source code may be found in Appendix C, Figure 1.

[pic]

Figure 19, PLASMON Test Application

Compatibility/Debug Issues:

An initial prototype of the PLASMON system was constructed in the laboratory while still employing the polling structure. Upon integration of the parallel port driver code in the presentation software, menu navigation via the touch panel was successful. However, when trying to port the application to the PLASMON PC, Visual Basic indicated a “Privileged Instruction” error message. This is an error typically shown when Windows refuses port access to user-mode applications. It was later discovered that two versions of the INPOUT32 driver were available online. The version initially evaluated and eliminated from consideration was available from .

The second version, downloaded from and based upon the initial version, does perform under Windows XP and uses the same syntax. The DLL file was copied into the Drivers folder of the PLASMON machine. The PLASMON application was started up, and no errors resulted. Upon execution, the parallel port read functions did not return the correct values. When the computer is cold-booted, the BIOS indicated that the user can select one of many types of ports that LPT1 can emulate. PS/2 mode was chosen, but after configuring the port data lines as inputs, a data byte of 0x00 was returned. With further investigation it was found that the parallel port was in fact not configured to the PS/2 mode as stated in the BIOS. INPOUT32 was used for bit-manipulation of the control ports to force the parallel port into PS/2 mode. Proper operation was verified by reading port values and validating the proper bit configurations for PS/2 mode.

Upon implementation of the TVicLPT driver, these problems were eliminated as a result of the driver’s ability to automatically detect both the memory location and type of parallel port, as well as improved syntax that eliminates much of the need for individual bit manipulations.

Design Projections:

The PLASMON Multimedia Kiosk currently has multiple software additions that will need to be implemented outside of this project. One that was previously mentioned is the face and voice recognition software. Along with this anticipated addition, the kiosk software and hardware was designed for flexibility to allow upgrades and feature improvements for future endeavors.

Conclusion:

In conclusion the project completion was a success. The completed software and hardware is currently a functioning part of the Electrical Engineering Department. The project presented many challenges in both the software and hardware realms, as well as an introduction to hardware/software interfacing. The design team needed to consider all I/O situations in order to create a robust product. Concurrent hardware and software redesign required constant communication between team members, as well as a solid concept for how the interface would work.

-----------------------

Added Audio

Motion ‘tween’

Layers

Timeline / Frames

Richtextbox1

Form1 (Main Menu)

Form2, shockwaveflash1

User options while in the “About” menu

Animated Graphics created in Macromedia Flash

Labels 1-6 displays the user options in the Calendar Submenu

Days are automatically renumbered

A clipart Heading is automatically creating to display Month and year Selected

Easy to Use GUI

Title textbox

User options textboxes

Four thumbnail imageboxes

filelistbox

Large imagebox

richtexbox

Current Scene’s graphic screen

[pic]

[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download