% !TEX root = master.tex
\section{Conclusion}
After the completion of this document, a convention was held between the group members in order to assess the  feasibility of what we have discussed in the document above. Throughout the group, there  is a consensus that the work that we have provided here is of our own work, and also should be considered adequate for the assigned task. Overall, the work was our own original work, and any location where work was pulled from a foreign location, proper references have been made. Please reference section 9, references, for any external sources that were referenced during the production of this document. 

Not only has the paper here been prepared originally by the four group members, it is also important to note that the plans provided indicate a reasonably successful project. This means that we expect that, within a reasonable amount of stress and difficulty, we will be able to manage a successful build of the aforementioned product within the time period of one semester. Granted, a large amount of work has been put in this semester, including large amounts of planning regarding parts accumulation, schematic design, and a small amount of board design. Please reference section 4 for most of the design considerations already considered.

The group believes that, through the use of I-con, and through the budget granted and given by the various group members, we should have no problem at all with the physical build. The software design may prove to be the most difficult part, and difficult in this sense does not actually necessarily mean difficult in terms of learning new  material to apply to the project as a whole. In actuality, a majority of what is needed for this project is simply knowledge that the two software engineers already are privy to. The difficulty may result from the simple scale of the project. Keep in mind that, through the project is expected to be successfully completed within the time frame given (1 semester), this does not necessarily make it an easy task to complete. A large code base will have to be developed for the success of this product to be operated correctly. Software design, in terms of feasibility and flow charts, as well as other important relevant discussions, can be found in section 4 above in the software design sections.

It is also important to keep in mind the potential difficulty of creating a table from scratch, which is still an option for the group to decide the feasibility of. Should the decision to be made to go with this method, there is both a larger cost associated with this decision in terms of time and actual monetary value. That being said, it is important to remember that we plan on attempting the TI competition mentioned at the beginning of the semester. As a result, it is possible that having a better aesthetic for the project would provide an edge that would allow us to win the competition and potentially have the project pay for itself.

The group has considered several issues that could arise during several portions of the build. The first section for the potential for failure has actually already been assessed and evaluated throughout the previous 120 pages, and that is the design section. The design has already been mostly complete in terms of hardware, but there are several sections of design that have yet to be approached. Not only this, but these sections of design will likely be left until most of the board has been put together and software begins to seriously be written. For example, there is to be a film on the table on top where the pixels will sit under and project their colors onto. This is likely to be a foggy section of plexiglass, but the final decisions on what type of plexiglass and other considerations such as width, will need to be tested live once the final product is almost done. This should not provide a large amount of project delay, but it is something to consider in the grand scheme of things. Not only should this particular detail be left until the end, the actual table will be decided rather early on into next semester, but still will not be finalized until next semester or possibly the time between semesters.

The next section to discuss is parts procurement. We are also lucky in several regards with respect to this portion of the product development. Firstly, in the same vein as the design, much of this section has been successfully completed. A large number of parts, including the main microprocessor, the bluetooth module, and the individual pixel LEDs (neopixels), have already been procured. Not only have they been procured, but they have also been tested and ensured that they are the parts that we actually want to use. This is exceptional, because this allows us to simply populate the board once the design is finalized and the boards come in from the board houses. That being said, this portion of the build cannot be simply ignored. There are still several components on the board that cannot be tested in the final design, such as various resistor values. While we expect values such as 200k to be sufficient for pull up resistors, and for the values on the actual neopixels to be sufficient in terms of brightness, there is still the potential for change there. This does present an issue if a problem is found, as this would require a new part order and about a week delay. This is why it is important to have the complete, populated board in our hands as fast as possible so that software design can get underway. Capacitors for bypassing any AC interference are also subject to change, but these changes are relatively easy to make. 

As a side note to any mention of parts procurement, another benefit of working at I-con is that various parts are already sourced by this company. In other words, in an emergency situation, it is extremely easy to simply grab several parts from the workplace and throw them into the product as needed. This has already been discussed with the workplace, and has been verified by Ryan Mulvaney's boss. Seeing as any part that would be taken from this location would likely cost fractions of cents, there is no large concern for this. This provides an unbelievable amount of flexibility in terms of final design choices, and prevents a large amount of problems from happening when the time crunch is occurring later in the second semester. We expect to avoid a large amount of pain and misery by taking advantage of this.

Another production consideration to worry about is the board and stencil procurement. This will be handled by an outside company (likely tropical stencil for the stencil and Alberta printed circuits for the printed circuit board), however they do take around a week to get back with the finished products once you submit a design with the gerber files. An in depth discussion on the gerber files we expect to be producing to these companies can be found in section 4.1.2. Now, these considerations in terms of a time consideration will not be relevant unless there is a serious problem in terms of design. The design has already been finished and checked, so it is not likely that this issue will arise to cost us any time delay. However, it is important to not gloss over any situation that could arise, and have a contingency plan for everything so that any situation that does arise, however unlikely, can be dealt with accordingly. 

Now, as mentioned we have a finished design that will produce gerber files to produce to these foreign companies. If, for some reason, should the companies produce incorrect boards, at that point there is a time loss. They will fix the problem free of charge in terms of cost, but they cannot role back the clock and any time lost fixing the problem is lost. This is incredibly unlikely, and has never happened in my experience. However, it is a potential problem. This is going to be avoided by handling the board procurement over winter break. This is an excellent solution for two reasons. First of all, if there is a problem it will be handled before the semester even starts in theory. The second, and better reason that this is a good solution is that, in the more likely case that the board comes back alright, we can begin building the final product immediately, and potentially even before the second semester begins. Overall, this is likely over planning in terms of what is practically going to cause us issues, but it is better to be over prepared than under prepared.

The next section to concern ourselves with is the physical build of the board. This has been briefly considered in section 4.1.2, however the practical issues that can be seen are going to be seen here. The board design in terms of layout has been carefully considered from an electrical standpoint. However, several problems can arise when actually building the board. There are a number of issues that can arise from building a board through a pick and place, followed by a reflow oven. Such issues are not immediately noticeable from a simple schematic diagram or eagle layout .brd file. This is where practical experience comes in handy. However, even with practical experience, it is possible to miss some problem and have to have a board design at worst or simply hand solder the parts at best. It is likely that, due to the simplicity of the board, we would never have to experience the problems discussed below, however they will be laid out as to prepare for their potential. The primary issue when picking and placing a board with a pick and place machine comes from differing heights of parts. If the board is being placed, and one part is placed incorrectly, which means that a larger part is placed before a smaller part, there can be a conflict. This problem is typically avoided by intelligently designing the program that is physically placing the parts onto the board. 

Our group will be working with the I-con production team to ensure that the board is intelligently handled in terms of how the board is placed. This intelligent program will avoid a large number of problems in this realm. This will also ensure that the quickest and most efficient pick and place procedure will occur, causing less issues in the long run. In a similar manner to the previously discussed problem, there is also a problem that can arise in a reflow oven, called shadowing. This is a process where a large part can overshadow (where the name comes from) a smaller part if they are close together in the reflow oven. This large part prevents the smaller part from receiving the proper heat through the reflow procedure, and can cause problems with the solder not flowing properly. This problem is expanded when using non standard solder, such as lead free solder. As a result, our solder will be lead based so that we have as few problems in the build as possible. The solution to prevent shadowing is to build the board in such a way that there are no very small parts that are surrounded by very large parts. We do not expect to have any abnormally large parts on the board, but it is important to understand why some issues can arise so that in the future they can be avoided. As previously said, neither of these issues are likely to be seen in our particular build, however understanding the issues is very important so that if any problem arises from the build it can be dealt with quickly and efficiently.

Once the board is built, various testing procedures such as the ones discussed in section 5 will be implemented to ensure the correct functionality of the board. This is likely to be successful, and if it's not the board can be tested through various methods to ensure that the problem is resolved and the issues are dealt with. Then, any issues from this point are software related. The software challenge will be, comparatively speaking, not particularly difficult. The software engineers on the team have dealt with significantly harder problems before, and as a result it is not likely to see any huge issues with the way that we approach the software. However, it is important to understand that any time code is written for a project, especially when dealing with a new type of hardware like we are with the neopixels, that problems can arise.

Issues likely to crop up from the hardware point of view are issues with communicating with the pixels and communicating with the bluetooth module. There is a proprietary method of communication that has to be dealt with when handling the pixels. This will be handled by th e microprocessor, which is a software hurdle that will need to be overcome. This provides the potential for a holdup in the design of the board. If the software proves to be more difficult than expected, this could be the most time consuming portion of the build. Or, hopefully, it could take five minutes to understand and prepare, and as a result this would be one less problem to attend to when handling the project.

The bluetooth module presents its own series of problems. Two major ones are the physical communication between the bluetooth module and the main microprocessor, and the other problem is the fact that a new interface will have to be built to handle talking to the board through bluetooth. This will likely be a web aplication of some sort, but no matter what the final realization is, any number of problems can crop up from the design of this section. Building web applications can provide it's own set of issues, and those will be dealt with in time. Bluetooth communication is very standard, and as such should not be complicated when it comes time to produce the final code.
