Ryan Rhodes' Lab Notebook

Week 01

January 10, 2012 (1 hour):
Met as a team after class to discuss preliminary project proposal.

January 12, 2012 (3 hours):
Met as a team after class to finish writing preliminary project proposal.

WEEK 01 SUMMARY
Accomplishments: Submitted preliminary project proposal.
Weekly Work Total: 4 hours
Project Work Total: 4 hours

Week 02

January 18, 2012 (1.5 hours):
Met with Stephan Zabrecky before class to discuss potential issues with Bluetooth connection to iOS device. Had a phone conference in the evening with Stephan to discuss resolution of the Bluetooth connection issues. The particular issue was related to Apple's requirement that Bluetooth devices be registered and have a firmware authenticator installed when communicating with mobile devices. This isn't feasible for a non-commerical project, so we will instead interface with a computer via Bluetooth. As a fallback, we can use a ZigBee connection via USB adapter to communicate wirelessly.

January 19, 2012 (3 hours):
Met with entire team after class to finalize design proposal. Simplified the design slightly by reducing the number of water tanks and addressed concerns. The design was altered slightly to account for the reduced number of components.

WEEK 02 SUMMARY
Accomplishments: Submitted finalised project proposal.
Weekly Work Total: 4.5 hours
Project Work Total: 8.5 hours

Week 03

January 24, 2012 (2 hours):
Created a Powerpoint presentation for the TCSP on Wednesday 25, 2012. Also discussed and clarified our PSSCs pending review.

January 25, 2012 (5.5 hours):
Created the parts library for the HW 2 PCB board tutorial using Eagle PCB layout editor. Parts in the library included three surface mount capacitors, an inductor, a voltage regulator IC and a diode. Also began to experiment with the schematic layout.

January 26, 2012 (1.5 hours):
Completed my individual schematic and PCB layout using the parts libary created 1/25/12.

WEEK 03 SUMMARY
Accomplishments: Learned the basic operation of the Eagle PCB layout tool. Reviewed PSSCs based on input from returned proposals.
Weekly Work Total: 9 hours
Project Work Total: 17.5 hours

Week 04

January 31, 2012 (1.5 hours):
Met with the rest of the team to go over the electrical requirements of the various peripherals in the design. Discovered a problem that could require further review with our heating and cooling system. It's currently unable to both heat and cool at the same time.

February 1, 2012 (3 hours):
Reviewed feedback from the final design proposal and last weeks presenation. The review necessitated changes to the PSSC. Created a new presenation to address design contraints. Microcontroller design constraints will require a decision between a single or multiple microcontrollers. Also require a decision about the user interface for the device (LCD/touch screen/ RPG).

February 2, 2012 (6 hours):
Completed the design constraints and analysis homework. Most of the parts for the design were chosen. The most important constraint is the number and type of I/O ports available.

WEEK 04 SUMMARY
Accomplishments: Created design constraints for the project. Based on those constraints major components were selected.
Weekly Work Total: 10.5 hours
Project Work Total: 28 hours

Week 05

February 7, 2012 (1 hours):
Met with the rest of the team to discuss packaging. Brandon had completed basics of the packaging and had started to select components.

February 9, 2012 (7.5 hours):
Finished selecting passive components and continued to revise the list of components that will be incorporated into the PCB. Discussed and raised potential power issues and circuit safety methods that should be employed.

Of particular interest, there is concern about the H-Bridge driving the thermoelectric peltier drawing too much current if all four MOSFETs are on at the same time. This would cause the thermoelectric peltier to draw far too much current that would result in device failure. The power supply we have selected could supply a very large current draw, potentially causing the board damage. The current solution pending review is to add a 7 amp fast burnout fuse to prevent too much draw. Power consumption by the device (including MOSFETs and diodes) will need to be evaluated to confirm this value. A detailed PCB size estimate based on known parts and sizes was generated. This is included below:

The actual size of this layout is 12cm x 12cm.

WEEK 05 SUMMARY
Accomplishments: Refined parts selection and found most passive components. Created a PCB size estimate based on the major parts used.
Weekly Work Total: 8.5 hours
Project Work Total: 36.5 hours

Week 06

February 14, 2012 (3.5 hours):
Worked with the team to create schematic symbols for all of our parts. Reviewed documentation for the PIC32MX micro that was selected in order to determine programming and layout with respect to pins.

February 15, 2012 (1.5 hours):
Began to create PCB packages in the Drinkmaster 8000 project library for all parts. Completed 2 of the major components.

February 16, 2012 (3 hours):
Completed all of the PCB packages and partially completed the devices necessary for schematic creation to begin on EAGLE.

WEEK 06 SUMMARY
Accomplishments: Generated the majority of components needed for PCB layout and schematic creation.
Weekly Work Total: 8 hours
Project Work Total: 44.5 hours

Week 07

February 21, 2012 (9.5 hours):
Finished library of all necessary components for PCB layout. Investigated required circuit layout for ICs used (decoupling capacitors, etc.) Began to roughly design a PCB schematic on paper. Added new elements to the existing design schematic. Fixed a number of issues with the design schematic (pin misalignment, unrecognized junctions, etc).

February 22, 2012 (12 hours):
Completed the first draft of the PCB layout. It contains all components and reveals schematic deficiencies. Specifically, the power system for the schematic will need to be redesigned for easier PCB layout. I completed the TCSP slideshow related to PCB layout. Included below are the updated schematic and PCB layout:

February 23, 2012 (10.5 hours):
My first step was to review my previous work and make a few improvements on the layout of the PCB components. Satisfied that this layout would work, I began routing the Drinkmaster 8000 PCB by hand. The PCB layout proved to work well, with minimal repositioning necessary. In general, routing proceeded from start to finish in the following order: 12V rails and corresponding ground, solenoids/diodes, h-bridge, power supply, bluetooth module, bottom sensors and finally any remaining components (left side of the board). I stopped my work today after completing a few of the bottom sensors. Danny was in the lab with me and, for a portion of that time, I began work on the PCB Layout homework.

February 24, 2012 (11 hours):
I continued my work from 2/23 and managed to finish the board. The routing around the microcontroller required the most careful work. With so many condensed traces, it was decided to locate the decoupling capacitors under the board. By moving them under the board, overall trace length was significantly reduced. The area immediately left of the microcontroller required minor changes in the layout in order to allow for tracing. The primary change was to move the design further to the left, leaving more room around the PIC32. Additionally, the passive device layout was altered on the fly as it was traced. A few final hours were spent finishing the PCB layout.

This image demonstrates the PCB routing thus far.

The microcontroller and it's surrounding peripherals (seen above) presented the greatest challenge.

The power supply layout was located here to minimize noise by having only one connection point between the 12v rails and the rest of the system.

The above image demonstrates the changes made to the h-bridge this week. They were replaced with new devices due to an eletrical property oversight in previous designs.

February 26, 2012 (3 hours):
I met with the rest of the team to work on the design review. After a brief discussion of our presentation in general,I completed the timeline slide. Having completed that slide, I assisted the other team members and took notes for my PCB layout slides.

WEEK 07 SUMMARY
Accomplishments: I came close to completing the PCB layout in its entirety. Only design changes and the ground plane layout remain. I also worked with the rest of my team to prepare for the design review.
Weekly Work Total: 46 hours
Project Work Total: 90.5 hours

Week 08

February 27, 2012 (1 hour):
I spoke with Steve and Danny in a phone conference about how the general flow of the presentation should go. More specifically, we what each team member would be responsible for discussing.

February 28, 2012 (4 hours):
I came into lab early to make a few slight alterations to the PCB design before the presentation and to update outdated pictures. The primary alteration made to the design was to replace the resistors previous used with correct ones. In addition, I added a few new slides to the PCB layout section of the presentation that focused on specific components of the layout.

March 1, 2012 (2.5 hours):
Continued working on the PCB. I added a few missing components (headers for the LCD and RPG). Adding these components after the fact required me to make some significant changes to the PCB layout in general. Namely, pins had to be reassigned slightly. During this time, I met with Brandon to come up with a list of components so he could order parts from Digikey.

WEEK 08 SUMMARY
Accomplishments: I helped present our design review. I updated portions of the PCB layout and determined how to create a ground plane.
Weekly Work Total: 7.5 hours
Project Work Total: 98.0 hours

Week 09

March 7, 2012 (10 hours):
Began to make my final changes to the PCB. The first change made was to replace the resistors again. Previously, we were using through-hole resistors which are undesirable. These were replaced with surface mount 1206 resistors to reduce inductance and minimize noise generated by traces.
Additionally, I made changes to the ground plane to exclude areas around the decoupling/bypass capacitors to make the circuitry schematically correct. Before, the ground was connected directly to the smallest decoupling cap for a given VSS pin as opposed to first passing by a larger capacitor whose capacitance is in decade with the smaller. This design change took significant time as I needed to find a tool in Eagle allowing me to do it. The next significant change was to eliminate all failing design rule checks and electronic issues. Most of these were warnings of missing junctions in the schematic and some minor clearance issues. The final change made to the design was to correct the silkscreen labels to make them visible. The values layer will be discarded in the final stage of the design. Below are images of the completed PCB.

WEEK 09 SUMMARY
Accomplishments: I completed the changes to the PCB and submitted it for fabrication.
Weekly Work Total: 10.0 hours
Project Work Total: 108.0 hours

Week 10

WEEK 10 SUMMARY
Accomplishments: Away for spring break. Resting accomplished.
Weekly Work Total: 0.0 hours
Project Work Total: 108.0 hours

Week 11

March 20, 2012 (1 hour):
I met briefly with the entire team to determine the status of the project and determine tasks for the foreseeable future.

March 21, 2012 (3.5 hours):
Our PCB came in today. I worked briefly with Stephan to resolve issues he's been having trying to connect his software to another device via Bluetooth. We found a library that should achieve the simplistic connection that we need to transmit our coded commands. Danny and I worked on the microcontroller software flowchart and function list. We determined that a mixed implementation (polling loop and interrupts for the Bluetooth) would be best. Most of the functions that were written implemented simple port I/O functions (turn on/off solenoid X, etc.)
I then helped Brandon with the assembly of the PCB power system. I identified parts on the schematic/PCB and checked their orientation while he soldered them on. We were able to complete the power supply, but had to flywire the linear regulator. Two of its pins (input and GND) weren't properly connected between the schematic and pcb layout model. After setting up a test circuit, we left the device on overnight to verify the power supplies functionality.

March 22, 2012 (2.5 hours):
I checked that the power supply was functioning as intended after being left on overnight. The voltage level was close to the desired level (3.28 vs 3.3 with a load of around 500 ohms). There was noticeable warming of the linear regulator, but nothing that we felt would be problematic. We'll need to monitor the heating of this regulator under full load to make sure the heating remains within a reasonable range.
I soldered on all but one of the bypass capacitors. The final one was lost (it was an 0605 form factor). That capacitor was an optional filter capacitor and its loss shouldn't change the microprocessor's operating significantly. We'll look to replace this after we've done some preliminary debug in case we need other parts. I also began to solder on the microcontroller, finishing one side of the micro before I needed to leave.

WEEK 11 SUMMARY
Accomplishments: I assisted with the soldering of components to the PCB board. I helped with some minor components of the software design.
Weekly Work Total: 7.0 hours
Project Work Total: 115.0 hours

Week 12

March 27, 2012 (5 hours):
Up to this point, Danny has been testing software using the provided test board. Wanting to begin testing in a more realistic environment, we worked on connecting to the microcontroller using the on-PCB RJ12 jack. The ICD3 programmer/debugger is unable to connect to the target device (our MCU). After confirming that the problem wasn't with the ICD3 device (it was still connecting to the breakout board), we began to debug the connection. The issue was determined to be that the RJ12 breakout on the PCB was reversed. To resolve the issue, we stripped a connection cable and reveresed each of the wires. After doing this, we were still unable to connect. Suspecting that our MCU was being constantly reset, we examined the MCLR pin and, while finding it was nonfunctional due to a design error, concluded it wasn't causing the issue. I began working with Danny on portions of the software before leaving. After I left, Brandon discovered the issue to be one of the pins was tied to ground rather then the required Vcc.

March 28, 2012 (0.5 hours):
After class I met briefly with the rest of the team to discuss the status of the project.

WEEK 12 SUMMARY
Accomplishments: I assisted in the debug of the connection between the debugger and our on-PCB MCU.
Weekly Work Total: 5.5 hours
Project Work Total: 120.5 hours

Week 13

April 4, 2012 (3.5 hours):
Our Bluetooth unit (when connecting to the MCU on our PCB) seems to be unable to correctly recieve data sent by the MCU. Picking up after the debug done by Brandon and Danny the day before, we (Danny and I) double checked the connections to ensure the device was configured correctly. After eliminating that, we connected the device to the LCD and discovered the LCD was receiving too many characters, suggesting that the MCU had too low a baud rate and was sending too much data. We attempted debug in order to determine the cause of the problem. Because the program we were testing worked correctly on the test board (which theoretically had the same operation) we thought that the MCU might have been damaged during soldering. We spent several hours attempting to debug the issue without success. As part of this debugging, we checked the functionality of a number of port pins and double checked our programming of the MCU clock. Finding no issues, we stopped work for the day.

April 5, 2012 (2.5 hours):
The team continued to debug the issues with the UART pin of our PCB MCU. After briefly recapping our discoveries from the previous day, we double checked that the project was functioning correctly on the prototype board. Having eliminated complete nonfunctionality as the root cause, we connected the UART pin of both the PCB MCU and the test board to an oscilloscope. We compared the two signals and Brandon observed that the PCB MCU was operating at too slow a speed. After increasing the baud rate by a factor of ten (close to the difference seen on the oscilloscope) our LCD was able to correctly receive a character. It's unclear why there was a difference between the two chips' operation. At this point Brandon discovered that the Bluetooth module's breakout pins were reversed. The orientation that would be required for it to remain on-chip would result in significant noise and interference. Specifically, the RN-41 Bluetooth datasheet strongly suggests against locating the antenna above any traces or ground planes. I mentioned this while the team was deciding how to resolve the issue. Brandon and I concluded that an off-chip enclosure with flywires was the preferred solution in order to prevent interference from corrupting the Bluetooth's ability to send and receive data.

WEEK 13 SUMMARY
Accomplishments: Debugged the problems with the UART connection of the on-PCB MCU.
Weekly Work Total: 6.0 hours
Project Work Total: 126.5 hours

Week 14

April 10, 2012 (2.5 hours):
I worked with Steve in order to debug issues with the command scheme that Brandon had designed. It required bit packing and decoding of a standard size data packet. It limited the number of commands, but allowed each command to have a number of arguments. Steve's Bluetooth connection library was designed with ASCII characters in mind. I spent a few hours learning some basic Obj C and working to understand his libraries functionality. I was unable to determine why the data (in the correct format) was not being sent as desired. Brandon and Steve continued to debug this issue after I had left. Steve, Danny and I spoke briefly later that evening and concluded that a more straightforward command system based on ASCII characters would make sense for the control scheme we had in mind. The following image demonstrates the letter-coil match that I created with Danny and Steve.

April 11, 2012 (4.5 hours):
Based on the new command scheme that Stephan designed, I assigned each of the solenoid valves and pumps an uppercase letter to serve as its command "name". Solenoids already named 1 - 18 were assigned letters in order A to R. Brandon had already associated each of those solenoids (as numbers) with various portions of the mechanical system. I consulted with him and created a guide for the rest of the team to use.

The above image correlates the command codes with the mechanical design of the Drinkmaster.

After that quick task, I assisted the team with debug where needed while also creating a prototype board for the solenoids and heating/cooling H-Bridge controllers. I acquired around 22 LEDs for the purpose, and after briefly testing them for a non-damaging current (~ 5mA) I created the board using 1.6 kOhm resistors. The resistance is appropriate for to handle the ~10V drop generated by the solenoids operating voltage. At this point, I also set up a system for testing the heaing and cooling system using a trio of LEDs broken out from the pos,neg and inhibit digital pins of the heating system (these will connect to the h-bridge IC).

April 14, 2012 (6.0 hours):
I worked with Stephan to debug issues with his Bluetooth handler. It was not consistently sending commands to and from the PCB. The issue was determined to be how the data was received from the PCB. When sending a longer command, the incoming data would be broken up into small chunks. To handle the issue, Steve and I modified the command structure to require a terminating character and to seperate individual commands with commas. This would allow us to have variable length commands while also handling the issue with 'broken' received data. To handle the 'broken' incoming data, I created an accumulating buffer that would add new data until a terminating character was received ("?"). Once such a character was received, the string would be broken off and decoded, while the index pointer is updated to point at the new starting character. The string was captured in a ring buffer of around 128 characters. This should be sufficiently long to avoid potential issues. I also wrote code that would seperate the received data in a set of substrings based on the inserted commas.

The above diagram demonstraights this in psuedocode.

After working on Steve's GUI side, I began work on the MCU to handle a heartbeat sent to the GUI software. As a preliminary test, rather then using our MCU's timer, I simply sent the heartbeat (2Z)every 3600 iterations through the main loop. Having implemented that, I began implementing code to check that I had received a heartbeat from the PC. This was done by having a connected_state variable and two variables that tracked the last "second" in which a heartbeat was received. After a few seconds without receiving a command, the system state was reverted to NOT_CONNECTED. The expectation was that it would be easy to implement some reaction to this flag at a later date. The remainder of my time was spent debugging errors with my code and assisting Steve with the debug of his software.

April 15, 2012 (6.5 hours):
Steve and I spent this time working out a method to track the status of water flow through the pipe sections of our design. This will give us some idea of where in our design water is in case there is a mode transition while water is still in the lines. This was done using a series of if/else if statements. Updating to the state occurs after a short time interval (around 0.5 seconds. When creating these logic statements, we took into account the fact that there must be some output means for the water in question. This should provide a reasonable expectation of water flow through the system. After implementing a means to send these updates to the GUI, we also created a means by which a query can be sent from the PC to the MCU in order update the system state as seen on the GUI. This will allow for minimal data to be sent by the MCU. It will only need to send one burst of the entire system status followed by changes to the system state.

WEEK 14 SUMMARY
Accomplishments: I assisted in the debug of the Bluetooth connection between the PC GUI and our MCU.
I created a test board that we could use for debugging issues with our coil control
I created code to handle heartbeats/handshakes to and from the MCU.
I worked with Steve to implement a means of tracking the internal system status of the pipes.
Weekly Work Total: 13.5 hours
Project Work Total: 134.0 hours

Week 15

April 16, 2012 (4.0 hours):
I spent this time debugging issues with code that was written the past week. Most of the issues were logical problems. For example, I incorrectly handled how water is show to propogate through the system. This is useful when a mode transition occurs while water is still in the lines. This was implemented using a series of if/else if statements. Updating to the state occurs after a short time interval (around 0.5 seconds. When creating these logic statements, we took into account the fact that there must be some output means for the water in question. This should provide a reasonable expectation of water flow through the system. After implementing a means to send these updates to the GUI, we also created a means by which a query can be sent from the PC to the MCU in order update the system state as seen on the GUI. This will allow for minimal data to be sent by the MCU. It will only need to send one burst of the entire system status followed by changes to the system state. One issue that we were encountering was the RPG button incorrectly triggering. I attempted a fix for this by requiring the pushbutton be held for a fraction of a second. This didn't, however, completly correct the issues we were seeing. Danny agreed to take a closer look tomorrow.

April 17, 2012 (8.5 hours):
With the impending deadline looming, our coding effort was kicked into high gear. I arrived in lab early and began to implement the hearbeat timer. To fully implement this, I'd require a fix from Danny for the timer ISR. While debugging this with Steve, we encountered issues with the heartbeat timeout feature. We encountered situations in which the MCU would stop receiving correct data from the PC client. We're (Steve and I) unsure what the cause of this particular issue is. We suspect that the device is getting stuck in a state that it will not correctly receive commands but are unable to identify such a state. Having created a version that worked in most cases, we moved on to debugging the ATD. Data wasn't being received by the PC client side correctly. After ensuring that this was not a transmission error (this had been implemented earlier that day) we noticed that the sensor data was moving cyclically. This led us to believe the sensor data was not being sampled correctly. I spend time reviewing the documentation of the ATD CONFIG register and determined that a single portion of the register hadn't been correctly handled. Having resolved this, we finished updating the method by which sensor data was sent to the PC client. With correct data now being received, we began some simple tests of the heating and cooling system. One issue we noticed was gas buildup in the heating and cooling lines. Brandon and I discussed a number of solutions. Brandon eventually decided to reconfigure how the reservoir tank was implemented in the line.

April 18, 2012 (9.0 hours):
Today we began extensive testing of the heating and cooling system using Brandon's Visual Basic control software. We used this time to establish highs and lows of the heating and cooling system. We expect realistic highs of around 100 degrees F and lows of 65 degrees F. As the heating system operated, we gathered data points for the heating and cooling system. This took a long time, as the heating and cooling system is particularly inefficent. While attempting to gather RTD data using the standard reference voltages, we noticed that there wasn't much change being produced. We therefore decided to attempt using the Vref+ and Vref- pins to narrow the voltage range for the RTDs. After I determined how this was done, we made a number of attempts to get meaningful readings. After a few hours of debug, it became apparent this option wouldn't work. We therefore decided to find a solution later using the standard AVdd and AVss.

April 19, 2012 (8.5 hours):
Danny finished updating the timer ISR today, allowing us to make changes to other portions of the coe (heartbeat sensor, etc). We spent a significant amount of time today debugging connection issues that we've been experiencing in an ongoing manner. We don't have a clear reason why these are happening. As the heartbeat was updated today, we suspect that it is causing a deadlock of some sort where the MCU is incapable of reading further commands. This would explain the "freezing" behavior where the software ceases to respond to sent commands. This took up quite a bit of time that we (the team) would have preferred to spend debugging other issues. It slowed progress to a halt. In addition to debugging these issues. I also spent a significant amount of time today working on the User Manual. Steve had completed most of the "marketting style" portions in addition to the software GUI section. I wrote the portions relating to setup, RPG sensor control and basic system control (ideas behind it).

April 20, 2012 (7.5 hours):
Today, I spent most of my time working with code created by Brandon and Danny to implement automatic mode. Brandon had completed the weight sensor conversions, allowing us to gauge the weights in the mix tank. This allowed Danny and I to further implement the automatic_mode_handler to interpret incoming commands. This necessitated the creation of a new set of commands. We ran into issues meshing this with Stephen's client. The way he had implemented his commands arbitratily limited the available command identifiers. I personally completed functions to dispense power, add water to the mix tank and run the pump for a desired length of time. Danny wanted to implement the remainder of the features. We were unable to perform real testing due to ongoing connection issues. We're unsure if this is bandwith issue with the Bluetooth (possible if data is sent in a "burst"). After some time debugging, we were able to confirm that the opcode handler wasn't catching all cases. It would occasionally fail to reset the buffer to the 0 index, causing commands to overwrite other commands. These garbage commands weren't recognized by the handler, causing the handler to freeze up. Another implemented feature (Danny and I) was the ability to update time from the PC client side software. When the PC connects, the time (in 24H format) is sent to the Drinkmaster, overwriting the previous value. This time will then proceed to increment normally. We estimate an error in a month of runtime (no syncs) of around 2 minutes.

WEEK 15 SUMMARY
Accomplishments: I implemented a large number of major features to the MCU program. In particular, I implemented code to correctly generate RTD values (within 1-2 degrees across the range), automatic recipe creation as defined above and updated timing functions.
I also assisted with the general debug of the syste.
I completed a portion of the user manual
Weekly Work Total: 46.5 hours
Project Work Total: 180.5 hours

Week 16

April 23, 2012 (9.5 hours):
Today, I worked with Brandon and managed to complete 2 PSSCs. We got the heating and cooling PSSC and valve control PSSC signed off today. The main packaging has been completed so the remaining tasks are finish PSSCs and complete automatic mode functionality.

We tested primarily the ability of the system to reach a desired temperature. Brandon had implemented most of this functionality yesterday. I therefore had to implement the correct command (this required significant debug). Once we had confirmed data was sent correctly, we tested and debugged the new mix feature.

April 24, 2012 (10.5 hours):
I collaborated with Stephan and Danny to complete the next two PSSCs. We updated Steve's interface to work correctly with the code Brandon and I had implemented. We then methodically worked our way through the remained bugs in the automatic mode functions. This also required additional conneciton issue debug. Our resolution was to implement a start bit to commands to define when commands start and stop.

April 26, 2012 (5.5 hours):
I collaborated with Stephan and Danny to complete the final PSSC. This was the ability to create a recipe at a later time.

April 29-30, 2012 (24 hours):
I compiled the entirety of the Final project. I assisted with the code turning and poster.

WEEK 16 SUMMARY
Accomplishments: I implemented a large number of major features to the MCU program. In particular, I implemented code to correctly generate RTD values (within 1-2 degrees across the range), automatic recipe creation as defined above and updated timing functions.
I also assisted with the general debug of the syste.
I completed a portion of the user manual
Weekly Work Total: 49.5 hours
Project Work Total: 230.0 hours