Progress Report for Charles Hansen

Week 1:

Date: 1/18/2017
Total hours: 4
Description of design efforts:
Week 1 was predominatly brainstorming solutions for different aspects of Party Pong implementation. Several solutions were determined for detecting balls entering the Beer Pong cup, including IR in the side of the cup, capacitive sensors, and hall-effect sensors. Since the cups need to be removed for disposal of the liquids, conductive contacts between the cups and the table will be used if IR is the final detection of the balls, whereas the other sensors will be built into the table. I was also responsible for setting up the website and filling in the appropriate information.

Week 2:

Date:1/20/2017
Total hours: 5
Description of design efforts:
Week 2 began implmentation of prototyping. Arthur and I created the circuit for an IR detection system and secured IR sensors in the prototype cup. A difference amplifier was used to ensure more accurate responses from the IR sensors. The sensors were able to be adjusted in angle as well to detect the ball and return a 4V difference, pontentially negating the need for ADC interpretation on the microcontroller. I was the primary author of the Functional Specification for the Party Pong Table, which can be found in the Documents tab. .

Week 3:

Date:1/27/2017
Total hours: 5
Description of design efforts:
Week 3 was a continuation of the progress made in Week 2. Design of the table was finalized and a plan for creation of the table was created. A prototype of the motor raising mechanism was created from cardboard and the motors that arrived this week. The primary difference beteween the prototype and the final motor enclosure will be the location of the motor, shifting from outside to inside. Additional circuitry will be required per motor (h-bridge) in order to supply enough current to power the motors as the MSP432 microcontroller that will be dictating the raising and lowering of platforms does not supply enough. A photo of the motor design can be seen below. The component analysis was split between Arthur Huang and me.

Week 4:

Date:2/03/2017
Total hours: 10
Description of design efforts:
Week 4 was spent writing the initial Raspberry Pi code. Rather than sending reracking information to the MSP432 from the RPi via SPI, a one-bit NRZ encoded bit is sent at a rate of 1 millisecond. Since six options are available for reracking, 3 bits are sent after a two-bits of syncronization are sent to indicate data transmission. Once recieved by the microcontroller, each data corresponds within the microcontroller to raise and lower specific motors. The RPi will monitor which reracking options are avilable and only when the specific number of remaining cups matches the reracking option will the rerack be sent to the microcontroller. This offloads the computation from the microcontroller to the Raspberry Pi. Pins were set up to allow for input for reracking buttons and game start. Work began on controlling the individually addressable LEDs from the Raspberry Pi, but current attempts have been unsuccessfull. Currently, this is believed to be due to the data outputting from the RPi at 3.3V whereas the LED strip requires 5V for data. Supplies for the table were aquired this week, namely the wood and plexiglass for the table. Work on these areas will continue next week.

Week 5:

Date:2/10/2017
Total hours: 16
Description of design efforts:
Week 5 was predominantly spent writing and completing CPLD ABEL Code. Rather than having multiple PLDs, one CPLD will be used for each side of the table. The CPLD chosen is the ispMACH 4256ZE with the breakout board. Since a PCB will be printed for the microcontrollers and RPi, the CPLDs will remain on their breakout boards will be accessed in this manner for the final design. The CPLD has the added benefit of having an on-chip oscillator, removing the need of a clocking singal from the Raspberry Pi. The CPLD works as several state machines, one for each cup and one for rerack buttton lighting, 11 in total. The cup state machine begins in an on state, lighting a ring of LEDs around each cup. Since the voltage for scoring a cup is not large enough to trigger a logic high, the motor down signal from the microcontroller is pulsed, triggering a state change to flashing. When the motor down signal is sent again, the cup is retracted into the table by the motors and the cup LED state changes to off. Since the cup could be reraised during a rerack, if a motor up signal is recieved, the cup will go back to the initial on state. The button state machine is required to light up specific buttons to indicate which reracking options are available during the course of a game. Internally, a score count is kept that is updated by the score singal that is sent from the microcontroller to both the CPLD and RPi. When specific numbers of cups are in play, the appropriate button will light up. If a reracking button is pressed, the CPLD recieves a singal from the Raspberry PI to turn off all lighted buttons. Both state machines can be reset to their initial states with an nRST signal. Current plans for Week 6 involve Raspberry Pi Code, as well as building the table.

Week 6:

Date:2/17/2017
Total hours: 10
Description of design efforts:
Week 6 began with construction of the table, writing Raspberry Pi code to allow for communication between processes, and finished with completion of the circuitry for the CPLD. The table is broken into three sections, two end pieces and a middle section. Each of the two end pieces will hold the mechanisms and circuity for raising and lowering the cups as well as be the location of the cups. The middle section is a lowered section that will be brought flush with the two end pieces with a piece of plexiglass. The lowered section holds the LED Matrix that will display the score and patterns throughout the game.

The score for the LED matrix is updated via the Raspberry Pi and is computationally lengthy. Since the main process would miss singals due to a lack of interrupt support on the RPi, the score display must run a seperate process on a different core. To allow the main loop to still update the score, both processes now communicate over an internal socket. The game sends either an 'r' or a 'b' to the socket which is then interpreted by the score process to decrement the score of the red team or blue team respectively.

Since the CPLD does not supply enough current or voltage for the LEDs surrounding the cups that display if a cup is in play or has been scored on, additional circuitry was required to be able to power the LED strips. N-channel mosfets are used as a switch to provide the 12V required to activate the LED strips by applying the output of the CPLD to the gate of the mosfet. The mosfets will be located on the microcontroller PCB to allow for consistant packaging as the CPLD breakout board that will be used in the final design does not have locations for mosfets. Plans for week 7 involve finishing the prototype of one cup and beginning mass assembly of the table.

Week 7:

Date:2/24/2017
Total hours: 6
Description of design efforts:
Week 7 was predominantly spent debugging the LED matrix for the table. The socket communication code written during Week 6 was tested with the LED matrix. However, when the socket was accepted by the score control process, the LED matrix could no longer be updated. The reason for this is unknown. To accomidate for this, the LED matrix control is run as a subprocess of the game that is killed and restarted whenever a cup is scored on. Additional code for controlling the LED matrix will be written during Week 8. Due to several strips requiring the first LED of the strip to be replaced, the grid will be resoldered as well.

Week 8:

Date:3/03/2017
Total hours: 4
Description of design efforts:
Week 8 was predominantly spent on preparing for the design review. The secions on component choice, block diagram, and product packaging were all my responsiblities. With regards to the table, the LED matrix was soldered together with individual power and ground lines for each strip. The data line passes through a 100 ohm resistor and feeds into the first strip. All strips were tested individually and found to work by themselves. However, the last 5 strips did not power up with the first 12. Testing revealed that the last 5 worked individually. The voltage for the data line was compared at Row 0 and Row 12 and it was found that the voltage had decayed to the point that the last 5 strips were no longer recieving information. Solutions to this issue will be investigated during Week 9. Pattern display for the table was also started this week, beginning with a Purdue P. Since the updating of the score was now turned into a subprocess of the main game loop, whenever the process is killed and restarted, the table flashes for a few seconds with the color of which team scores. More patterns will be added during Week 9.

Week 9:

Date:3/10/2017
Total hours: 4
Description of design efforts:
Week 9 was spent working on the LED Matrix and Raspberry Pi code. The problem that was found with the matrix during Week 8 was resolved with pull-up resistors on the data-line coupled with an n-channel mosfet. The mosfet is triggered on the gate by the data output from the raspberry pi, the drain is tied to ground, and source is connected to both 5V and the data in line of the LED matrix. This supplied enough voltage and current to allow the signal to reach through all 17 led strips. More patterns were created for the table, as well as more game logic was coded.

Week 11:

Date:3/10/2017
Total hours: 9
Description of design efforts:
The circuit implemented in Week 9 was reimplemented after Spring Break, but the LED matrix reverted back to only displaying with the first 12 of the 17 rows. It was found that the individual LEDs recreate the incoming signal, but over time the signal becomes distorted. At the end of row 12, the final LED was recieving an input data signal but not outputting one. This LED was replaced, as well as the LED following it. When the board was tested again, 16 rows succesfully worked. The team decided that the grid would be 16 rows instead of 17 because the signal was too distoted by the end and could not be recovered. More work was done on patterns, including a function that would allow the team to design a matrix as it would appear on the table then convert it into the appropriate matrix for inputting to the table. This allowed for several more patterns to be quickly designed.

Week 13:

Date:4/7/2017
Total hours: 15
Description of design efforts:
Work was done on the grid for the LED matrix. The grid's purpose is to prevent bleeding between LEDs when displaying patterns and scores for the game. The bulk of the work done this week however was on the CPLD. It was found that the CPLD logic tables were switching multiple states per signal, so the logic was converted to wait until the signal goes down before looking for a high signal again. This required doubling the number of possible states as well as adding more states for reracking to ensure proper LEDs are lit during the course of a game. Work was done on the Raspberry Pi game logic as well for debugging purposes as well as updating the pins that were moved around for the PCB layout to be simplified. Next week more work will be done integrating all the electrical components to work together as well as any associated debugging.

Week 15:

Date:4/21/2017
Total Hours: 30
Description of design efforts:
Week 15 was the beginning of the integration of all the seperate components. Work was done to where blue team is completed, as well as tested with the middle of the table scoreboard. The CPLD code needed to be altered slightly to work correctly with the microcontroller. The display matrix was completely tested with imitation signals from the microcontroller and now succesfully kills the child process and displays the correct scores. When a team scores, the color of that team briefly flashes as well. The LEDs around the cups were tested with the CPLD recieving the motor down signal from the microcontroller after it detects a cup from IR and successfully rotates through the flashing, off, and back on states from reracking. UART transmission was also tested from the Raspberry Pi to the microcontroller and the reracking is performed successfully. Next week the red side will be finished and the team will compete in SPARK.

Week 16:

Date:4/21/2017
Total Hours: 55
Description of design efforts:
Week 16 was spent completing the project. The red side was completed and debugged. The table was put together entirely for testing and the scoreboard was debugged with both red and blue sides triggering scores. A bug was fixed that was causing multiple scoreboard processes being spawned in pattern mode. Another bug in the matrix was that patterns were not being set correctly and was fixed. The table was then set up to be easily wired for transportation and cleaned up. The team competed in SPARK on Friday and won second place. The team will be giving our final presentation Wednesday.