Edison Co. was excited to get their prototype up and running, and gathered the materials rather quickly. However, as with any project, issues began to compound. Programming the light to function properly became a big challenge, and the tasks the group had once thought would be simple or straight-forward quickly morphed into elaborate chains. Luckily, perseverance and a bit of help got Edison Co.'s prototype up and running, a certainly a satisfying sight.

The main goal with the first prototype was to simply see of the idea of a light-and-sound based stimuli alarm could function. Basic materials and a simple design contributed to this goal.

The first step in the prototyping process was to assemble the paper lamp. The group developed a list of necessary materials based off of the final drawing within Element D. While Edison Co. had initially designed their own expander (also referred to here as a "frame," it's the metal part that keeps the lamp stretched out) for the lamp, the package they ordered came with such supports, so the company just decided to use them. As a result, they reverted back to an older design which had the speaker mounted out of the hole at the base of the lamp. This was the only really hiccup in assembly; Figure 1 shows how the lamp's expander must also occupy the same area as the speaker was intended to be mounted in. Thus, the frame had to be pushed to the side, the speaker inserted, and then the frame fitted back into place (and fastened via tape) as in Figure 2.

The below show what the prototype looked like when assembled...

Parker would be the one hanging the lamp in his room and initially testing. Command hooks were used, as demonstrated in Figure 5 and Figure 6.

Since Edison Co. had begun gathering materials, the plan was to use the Wemo Mini Bluetooth wall plug to control the lamp's light, at least for the first prototype. The idea is that the wall plug can control the flow of electricity to whatever device is plugged in wirelessly, and via schedule. Edison Co. found the process very easy. First, connect the plug to the wall (as in Figure 7). Then, connect to the plug's wireless network, and open the Wemo app. After following the pairing procedure, a schedule can be set (Figures 8 and 9).

With both the lamp itself and Wemo light system in place, Edison Co. now turned their sights to the sound-based stimuli promised of their prototype. In truth, research for this particular aspect of the prototype had been going on for several days before even the physical prototype was constructed. The original plan was to use a basic alarm app to trigger the sound. Yes, one would have to set the sound-based alarm and Wemo light separately, but this was a first prototype after all. However, the group quickly found issues. For example, the alarm on Android's default clock app auto-snoozes after a couple of minutes (this would not suffice for the long and gentle audio prompt Edison Co. envisioned). There were troubles uploading a custom clip to Apple's alarm, and while Ely pointed out that one could generate their own tone in GarageBand, it turned out that the GarageBand clip was limited to under a minute in length.

With seemingly all options exhausted, Parker thought to himself, "If no app that already exists with the alarm functionality Edison Co. needs, I'll just have to make one myself." Using his Python experience and spare time on the way back home from a road trip to Oregon, Parker was able to develop a Python program that served the group's alarm needs. Figure 8 shows the program at work.

Unfortunately, Edison Co. quickly came to realize the flaw in their Python program: it would have to be left on all night, as turning off the computer interrupted the program. A crude workaround of waking up early in the morning (3 or 4 am), setting the alarm, and then going back to sleep was experimented with, however, it more or less defeats the entire "gentle wakeup" purpose of Edison Co.'s product, even for a prototype. To counter this issue, a Raspberry Pi was suggested. Parker's dad had pretty extensive knowledge of Raspberry Pi's and even had a few spare. He set up Parker with a router to connect to, which could in-turn be used to access the Pi, and then showed Parker how all of the mechanisms worked. The whole process was a bit complex, from installing Raspbian on an SD to SSHing in to install xRDP and then later SCP the necessary Python files onto the Pi. However, with the experience of his dad to learn from, Parker quickly picked up on the processes and educated his group on how to get everything to work the following day.

However, it didn't take long for tests to show some serious issues with the Raspberry Pi system. For one, the Bluetooth was finicky, and had a seemingly random chance of requiring a full system reboot to work after logging out and logging back in. Additionally, the Pi's system time had to be reset manually should it be shut down for any period due to the lack of internet access. Both of these had pretty easy work arounds, however; reboot before using the Bluetooth for the former, and the "sudo date" command for the latter. Unfortunately, Edison Co.'s testing quickly revealed yet another issue, this time with no easy, immediate solution; a user could easily set the alarm, but ending the RDP session with the Raspberry Pi interrupted the Python script, obviously preventing the alarm from triggering. This was discovered after several nights in which the alarm was set properly, but did not function.

What was the solution? Parker sat down again with his dad who served as a valuable resource in troubleshooting a system the team was just getting acquainted with. They gave several packages a shot, but after Parker tested each, nothing seemed like it would get the job done. Thus, Parker's dad recommended the use of the "crontab," a job scheduler. Basically, the user can set crontabs (either through Python or manual methods) which activate at the provided time/date to run a given string in the command line. Crontab uses a very particular asterisk-based syntax for recording activation time; Figure 9 provides a guide.

Using this new crontab tool, Parker completely redesigned the Python script. Now, there wasn't even need for a time-keeping Python module; all of this was handled by crontab. All the user had to do was set inputs, which the Python program plugged into a crontab, and (theoretically) the crontab would play the audio file. The Python program would also set a second, delayed crontab which pairs the speaker. This would give the user some time to reboot the Pi to ensure that the Bluetooth had just been reset and would thus properly function. A bit of troubleshooting help from Parker's dad got the script online. However, the issues were only beginning. Despite the fact that the crontab was properly set, Parker's tests found that there were no signs of the crontab actually executing it's job. There was no alarm tone at the time the prototype was set to ring; instead, Parker was met with radio silence. Thus, Parker continued collaborating with his father. They came to the conclusion that the crontab must be executing in the "background" or "batch" of the Raspberry Pi. To fix this, Parker's dad used his knowledge of bash scripts to show Parker how to write one which would play the alarm tone. Basically, this meant that the Python program would set a crontab job, which, when reaching the proper time, would run a bash script, and the bash script would play the audio file. Again, these efforts were to no avail. Finally, Parker stumbled upon a promising forum post. The post provided a line to add to the bash script which would set the environmental variable, forcing the script to run in the forefront of the Pi, instead of the background. The duo tried this out, and to their surprise, it worked! The program and system was functional, finally, after many hours. The flowchart featured in Figure 10 explains the final algorithmic process of the program to run the prototype's sound stimuli.

While this new program was complex, it was surprisingly simple on the user end. Plug in the router, plug the Raspberry Pi into the router, and then connect to the router's network. Then, RDP/SSH to the Raspberry Pi and run the Python script. Provide the Python program the inputs it prompts for, and then reboot the Raspberry Pi. Lastly, turn on the Bluetooth speaker; the Python program will automatically pair, and the alarm will play at the set time. This all takes no more than 2 minutes, maybe 3 if one considers that for the full experience (both sound and light stimuli), the light's timer must also be set separately on the Wemo app. Not too bad for a first prototype, but Edison Co. will certainly need to consolidate their systems so that the same program manages both sound and light stimuli for the alarm, instead of having the Wemo for the light and Raspberry Pi for the sound.

With both the physical design and software of the prototype sorted, more practical tests could begin. While, as described above, Edison Co. members ran many tests of smaller components (i.e. whether the Python program or Wemo app would work), the prototype was now ready to be tested as it would be used. Parker took the prototype home, looking to answer the following questions:

"How difficult is the prototype to set up?"

"Will the Bluetooth speaker battery last all night?"

"Will the prototype actually wake me up?"

"How consistently will the sound stimuli go off a minute before the light stimuli?"

For Prototype II the main goal was to implement key features of what Edison wants to see in the final product. This also includes a pseudo user-friendly experience.

For this prototype, CAD and hardware soldering was used to construct the second prototypes design. In order for Edison to get the desired results with the second Prototype such as a dimmable light and a place for the Raspberry Pi and other hardware to be stored, multiple obstacles quickly became apparent specific to what the team wanted to accomplish. Both of these features wouldn't be fully realized until the final prototype where they would be more finalized.

For the Hardware storage, a design of a storage box was made in CAD by Ely and David in order to store any hardware components that come along with the paper lamp. The CAD design was later 3-D printed out, which is where the dimming board and Raspberry Pi would be held.

The other key feature included is the breadboard with the LED. This was more of a functionality test to ensure that the code worked than anything else. By hooking up the Pi to the breadboard, the Pi was able to slowly lighten or darken the LED bulb. This would be replaced in the final prototype by a dimmer board.

Before Ely took over the CAD design for the hardware storage, due to his absence at the time, David had decided to tackle the sub-project for the time being, making the early rendition of the design. Along with this a modeled paper lamp of the what Edison used in the first prototype was also created for scale and reference. For the duration of the Prototype II the final design of the storage box would be along with Prototype III. Due to time constraints, Prototype II's storage box was created with an over sized amazon box tape and scissors.

Have image here with captions and explanations

As for the dimming features of the light stimuli, a breadboard was used to connect to the Raspberry Pi via GPIO pins. There weren't really many issues during this stage of development of the Prototype and continued smoothly. Using a pulse-width module and Parker's code, the dimming feature was a success overall with the initial test. The only issue being that the lamp's transition from dark to light wasn't as smooth as expected.

The main test of the Prototype II was the light dimming test to see if the pulse-width module worked successfully. With that completed, all that needed to be done was to test out the prototype to see if any errors or problems would occur. Other tests were conducted before hand to see if the singular components worked as expected.

Prototype III was meant to be the culmination of the group's work over the previous 3 months. Its goal was to have all the functionality that the group wished for, with a user interface that (if not pretty) would be self-explanatory

With Ely back from his COVID-induced absence, the team was ready to get the entire prototype finished. As Parker put the finishing touches on the code, David worked to get all the physical components connected and working. As they finished up their various pieces, David and Parker also worked to get the dimmer board and Pi working in conjunction. As they did this, Ely modeled a casing for the various components in Inventor. This went through many iterations, but the group eventually decided on a 6x6" box which would have the Pi bolted into the floor, with room for wires running in an out, and a way to mount the speaker in the lid. This design worked perfectly, excepting the holes which had been printed into the box. They proved to be a little too small, though did not cause too much strife. Overall, the assembly of Prototype III went very smoothly, with all the pieces falling into place over the course of only 2-3 days.

After all the physical parts had arrived, the prototype could be assembled. Firstly, the group had to ensure that everything still worked on the software side of the project. Parker checked that the light still turned on slowly after some changes to the code. After verifying the functionality, the team made the switch from controlling a small LED directly with the GPIO pins to using the dimmer board. This changed nothing on the software side; the dimmer board took the input from the Pi through the GPIO pins and converted that to a variable amount of current which was allowed to reach the lightbulb. After connecting the lightbulb to the dimmer board, the team tested the software, and found that it worked! The lightbulb dimmed and brightened on command, which was precisely what the team wanted to achieve. After they confirmed that it worked, they mounted the dimmer board to the casing that they used for the Pi. The last main obstacle facing the team was getting one wire to go into the box, and only needing one plug for the prototype to function. This was no small task, as it would require delicate handling of fragile parts, and solders which could make or break their project - literally.

In order to have only one wire go into the housing, the team needed to power both the Pi and the lightbulb with only one outlet. Part of the problem with this is that the lightbulb uses AC power, which comes out of the outlet, but the Pi requires DC power. So, they had to convert the AC power to DC. To do this, they stripped away the wire which powered the lightbulb, exposing the copper inside. They then cut off some spare wiring they had and soldered it the exposed wiring. This meant that the power from the outlet was now being split between the lightbulb and the extra wires. They then added an AC to DC converter from a phone power brick onto the extra wires, and then plugged that into the Pi. This allowed the Pi to receive the DC current it needed without having to have 2 plugs reserved for the prototype. However, the team noticed that the AC/DC converter they were using had the wrong amperage for the Pi, and was causing fluctuations in the amount of power the light was getting when there weren't supposed to be. To fix this, the team soldered the end part of an extension cable onto the part where the original AC/DC converter was, and then plugged in the correct power base with the correct amperage to the extension cord remnants, which then plugged into the Pi. This allowed for the Pi to provide an even signal, and fixed some other problems as well.

Once the wires were soldered and the boards were assembled, all that needed to be done was put the assembly of the boards, speaker, and light bulb into their housing, a process which did not prove to be too difficult, if it was time-consuming.

Prototype III had 3 main testable components; the code, the light, and the speaker. The code was working, as it was no different than Prototype II, excluding some UI changes. The speaker worked, as it also hadn't changed since Prototype II. The light, which should've worked perfectly, had some issues with flickering. The group figured this was because of the way the Pi dims the bulb. Instead of sending less current, the Pi modulates the current coming in, which can allow flickers to occur. However, excluding the flickering, everything worked as expected. This included both the individual parts, and everything working in tandem.