To test the prototype I alarm lamp we sent the project home with some of the group members. Parker did most of the testing as he was most familiar with it. On the first test the alarm and light turned on at the right time but we did discover some problems. The light was too bright, and the python script to run the alarm had to be started manually which defeated the purpose of having an alarm. To fix the first problem Parker put some paper over the light to dim it. this was a quick temporary fix just for prototype I. On the second test the light did not turn on because the app used to control the light was difficult to use. The alarm sound quality was also bad so for prototype II we will have to find a different alarm. Before the third test we added a raspberry pi to run the python code, so you wouldn't have to wake up and start the alarm manually. The third test was mostly successful, the alarm and light worked at the right time. However there were a couple problems including the light still being too bright and the entire project being really difficult to set up. Overall the tests uncovered a lot of problems to be fixed in the next prototype.

Most of Edison Co.'s stakeholder feedback originated from the in-class showcase of the prototype. There, the team's peers (students, who were listed as a potential user group in our initial planning) talked about what they liked and thought needed improvement in the lamp design. A key area of improvement was the alarm tone the team was employing. Audio quality for the tone definitely left a bit to be desired, leaving waking up as more of a pain than enjoyment. Several points of the clip used as the wake up tone had a vaguely static sound in the background. The group couldn't tell whether static was intended to represent thunder or rain, or was simply artifacts introduced from a poor initial quality. Either way, this needed improvement. Another student suggested that the user should be able to customize the color of the lamp light. This was a feature Edison Co. had planned and will probably implement in the 3rd prototype, but it was reassuring nonetheless for the company to to have their vision for the product reinforced.

Edison Co. considered Prototype II to be a bit of a "bridging" prototype to show that the company could use to prove that they would be able to pull off the functionality in Prototype III. In of itself, Prototype II did not need to be entirely functional, and it certainly was not. For example, a small LED was the only light-based stimuli. Thus, Edison Co. did not complete any in-field testing for Prototype II. Nobody took the prototype home to see whether or not it would wake them up, because it likely wouldn't without the functionality of the lightbulb. However, testing was performed to ensure that all systems worked properly, both in isolation and synchronization. These results were largely positive: the speaker worked pretty much from square one. This device only malfunctioned once, and it was due to user error (AKA Parker not properly plugging in the audio jack). On the other hand, the LED provided a bit more trouble. Testing revealed that the system functioned, but also that it was of utmost importance that the proper GPIO pin was selected in the Python program.

These simple results, in the form of basic bugs which could easily be resolved, proved to Edison Co. that the system they wished to design was indeed feasible. The speaker was already prepared, and it was as simple as plugging in both a charging cord and aux out to the Raspberry Pi. When it came time to swap over to the dimmer, this process was also very straightofrward. RPi.GPIO was an intuitive module, as evidenced by the ease with which the group was able to get an LED to dim/brighten. To apply RPi.GPIO to the dimmer, the only real challenge would just be a bit of additional wiring.

For the second prototype, the stakeholder feedback consisted mostly of Ms. Mason's observation of the prototype. She was impressed by the solid foundations of a stronger potential product, and encouraged the group to keep working at their goal. Ms. Mason was also incredibly valuable in working out a cron bug which simply involved system time on the Raspberry Pi being set incorrectly.

For prototype III Edison co was not able to finish the complete prototype with enough time to get any conclusive testing. They were, however, able to present the prototype at the CTE Foundation fundraiser student showcase. At the showcase the team was able to gauge what features people liked and disliked. One problem that was immediately identified was that the light bulb would flicker as it was increasing in brightness.

The light dimming test was an overall success due to David's and Parker's efforts. The team identified a couple problems that could be leading to the flickering. First was the wiring of the AC to DC converter that was powering the pi was under-powered, so the team replaced it with a new one which helped the flickering but did not completely solve the problem. Next the team realized that some LED bulbs did not like to be dimmed, so they switched to an incandescent bulb. This greatly improved performance, however there was still smoothness in the transition from dim to light is left to be desired. This was left up to Parker to finish some software fixes.

For the third prototype, most of Edison Co's feedback was derived from a fundraising event they attended with industry professionals from companies like Keysight, where they showed off their prototype. At the showcase, the main feedback given was to reduce the flickering present when dimming the bulb, having an emergency backup so that you would wake up at a certain time, and having some way to snooze the alarm. For the first piece of feedback, Edison Co. would eventually switch to a different Python module which would stop the flickering entirely. For the second piece of feedback, this was already a planned feature which would require just a small amount of code -after a certain amount of time without user input, the alarm would play a loud sound, more akin to a traditional alarm. This would be meant as a last resort if one was not woken up by the primary alarm, and wouldn't be needed often except for the heaviest of sleepers. Finally, it is possible to implement a snooze relatively easily - the user would push a button, and would cancel the alarm, and a set a new, temporary alarm for 10 minutes in the future. This would not be too difficult to program, but the team also felt that having a snooze would undermine the purpose of their product.