Author: jnfink

This week, I was able to fully integrate the servo motor as the locking mechanism. Quite a bit of iteration was required in getting the code to work, but I was also able to implement a locking function whereby the servo will move to the locked position whenever the “*” button on the keypad is pressed. This can be done at any point in the system, allowing for the user to lock their door easily. I also did research on linear actuators to attach to the servo motor to exhibit more of a “locking” behavior during the public demo next week. With Brooke, we 3D printed a linear actuator that I found on Thingiverse .

I also presented the final presentation, which took a bit of time to prepare for at the start of last week, in addition to losing two class periods to listening to presentations. Earlier this week, I also helped Brooke with choosing new materials for the mat after running into issues with materials flexing too little or too much. During this time, we consulted one of the wood shop operators in Techspark as well as my father, who works with polyurethane, to get an opinion on what materials and pliability we should be aiming for.

The other main thing I have been working on was testing and integrating a new DAC-amp module that Brooke ordered. During initial testing, I believe I found a hardware malfunction and read of a shortcut on an online forum that will circumvent this issue. This worked in testing the sound quality and amplification ability (which is much better than the amplifier circuit I built earlier), however, the functionality of choosing songs and setting the volume still does not work, as the shortcut does not address the main issue of connecting properly. This is an issue, as it won’t allow for song selection, will shuffle through the mp3 files endlessly, and is much too loud for our application. I am going to ask Brooke to take a look at it tomorrow, although I don’t plan to spend much more time on it, as the amplifier circuit works fine enough for the demo.

By Monday, I will settle either on the DAC-amp module or the amplifier circuit so that I can laser-cut the final lock housing and secure the servo in its linear actuator. I will also integrate the new BT module that Zoe ordered to work with the mat’s BT signal (this module is different from the one I originally tested, but did not work for Zoe in testing communication between the Seeed and the lock module).

I definitely feel that I am behind schedule, due to these new modules I am trying to implement not allowing me to finish the lock housing and work solely on the mat with Brooke. This week will be spent getting everything put together for the demo. As mentioned above, I will have settled on the lock electronics and cut out the housing by Monday. I will also be helping Zoe with the poster that is due Tuesday, and working with Brooke to produce the video by Thursday.

For the past two weeks, I have ordered additional parts that should bring the lock sub-system to completion. This included amplifier transistors, more robust speakers, and servo motors. Addressing the most pressing issue of the lock over the last two weeks, the lack of speaker amplification, I used an example circuit, the amplifier transistor I ordered, and various resistors and capacitors sourced from the 18-220 lab to build an amplifier circuit, modifying the resistance and capacitance values in attempts to improve the overall sound quality and volume. There is still some room for improvement here, and I hope to reach out to Prof. Sullivan to discuss possible adjustments if time permits. If I don’t have time, and since this is now a lower-priority item, the current speaker setup is sufficient for the final demo. I also added an elementary “song selection” function to the main lock code to select from different songs that are stored on the microSD card. In terms of testing the speaker, I downloaded a decibel reader onto my phone and checked for a safe reading (<75dB) at 6″, 1′, 2′, and 3′ away from the speaker, uncovered. All were under 75dB, and the 6″ reading is included in the images below.

Addressing the issue of the solenoid lock not having sufficient power and being an unclear indicator of the lock being locked or unlocked, the servo motor will soon replace the solenoid. The servo requires much less power and does not need constant power to be “unlocked”, meaning the system can be more efficient. It is also easy to make more clear with the servo what is “locked” and what is “unlocked.”

Another key item I began was testing possible coverings for the keypad to add another layer of security. With Brooke’s help, I was able to 3D print a 0.5mm thick sheet to tape over the keypad and hide the numbers. While the keypad still functions fully with this cover, I am unsure if it will be implemented in the final demo.

Every module needed for the lock is now physically added to the main circuit, aside from the servo which will replace the solenoid tomorrow. My next steps will be to move the amplifier circuit to a much smaller breadboard to consolidate space, solder any connections that I haven’t done yet,  laser cut a box to act as a housing for the lock electronics, and 3D print a small part to connect to the servo and act as the lock piece that moves in and out. I am not a mechE, however, so I doubt I will be able to create a simple box or door to accompany the lock in a sufficiently short amount of time.

All of these tasks can be completed in this upcoming week, so I feel that I am on track to completing my tasks for the project. However, I am concerned about testing the full BeatLock system, as we are still working on connecting the three sub-systems. To catch the team up this week, I’m hoping to have the lock completely ready at the beginning of the week for Zoe to work on the Bluetooth functionality when she is ready to work on the connection between the mat and the lock.

Additional Considerations: Learning Strategies

As I have gone throughout this process of creating the lock subsystem this semester, I have gained new knowledge about how to work with Arduino, specifically the Uno R3, its specific architecture, and how to be flexible with finding modules to accommodate it, such as the Bluetooth and microSD card reader modules. My strategy throughout the semester for each new addition has been to read datasheets when available to get a sense of different design parameters and how the item generally functions, then to move from that to looking for examples of the item being used, either through reading through example code to get an idea of function or through videos of someone walking the viewer through an example circuit with the item used. From here, I tend to debug and optimize, using strategies such as googling Arduino IDE errors for understanding, reading forums when I run into specific hardware issues, and even downloading multiple libraries to try to get a specific component working. I have also learned through the short time span of this class that while certain ideas in theory will work best, when trying to debug for two weeks leads nowhere, it is time to pivot and choose another plan; this can specifically be seen in my attempts at getting the Seeed Xiao to work and switching to the Arduino Uno R3 after being unsuccessful.

This past week, I have been working on the Bluetooth module and the microSD card module. I was able to solder speaker connections to the Bluetooth module as well as manipulate two audio files for testing the system; however, I’ve run into two problems that set me slightly behind schedule. Once the microSD card module and microSD cards arrived, I had some difficulty finding an SD card adapter until this morning (Saturday); once I had the adapter, getting test song mp3 files downloaded and wiring the microSD card module for testing was straightforward. The other, still standing, issue I’ve run into is getting the Bluetooth module to see the files that are on the microSD card. I believe the current library for the Bluetooth module was made for a specific adaptation of an Arduino Uno that includes built-in memory, so I’m currently researching how to get the BT module to reach the files. One step I’ve made towards getting this working is verifying that the microSD card module works; I found that Arduino has built-in example code for memory cards, which can both verify that there is a connection to the card as well as list files on the card (as seen in the photo at the bottom). I plan to take time tomorrow to learn from the example code how to see the files so that I can copy the paths for the BT module.

Another potential issue that may come up once I solve the file issue is wiring the speaker to the BT module since it has a useful audio function library. In the diagram given for the BT module, there are three connections (GND, VCC, and DACL) going from the BT module to the speaker; however, our current speaker only has two connections. This may be as simple as wiring only GND and DACL, but I won’t know until after I can get the BT chip reading from the SD card.

Because of these main issues, my progress is slightly behind schedule. To catch up, I plan on working most of tomorrow to get the BT and microSD card communicating, and maybe testing my speaker hypothesis if I have time. If the speaker doesn’t work, I will look for a speaker to order.

This upcoming week, I hope to have the speaker, microSD card module, BT module working together. After this, I hope to have these items integrated into the main lock system as well as begin testing the BT connection between the app and the lock.

Additional Discussion

In terms of verification of the lock subsystem, I have tested or plan on testing the following measures:

• Keypad functionality – this was completed by hardcoding a correct PIN and verifying that the keypad outputted a “correct” signal when the correct PIN was entered.
• Solenoid lock functionality – this was completed by connecting the solenoid to the 5V pin of the Arduino and verifying that it unlocked when powered.
• Bluetooth connection – this was initially confirmed by connecting my iPhone to the module without the rest of the system. Better validation will come by testing the connection between app/lock, and mat/lock.
• Audio quality and level – this will be verified in two parts. Quality will be qualitatively measured by listening to the audio files through my laptop and comparing to the audio quality from the speaker. Level will be measured hopefully through a decibel reader, likely through a downloaded phone app.

This past week, I mainly continued work on the lock, solidifying our use of the Arduino Uno by continuing to research compatible Bluetooth and microSD modules for the Uno, writing up an updated wiring diagram (as shown below) to visualize the potential additional parts, and ordering the Bluetooth and microSD slot modules as well as 2GB microSD cards.

Beyond this, I was able to get the Bluetooth module running after downloading its respective library and example code. Surprisingly, my iPhone was able to discover and connect to it in this initial testing (as shown below). I also assisted Brooke with laser-cutting the boards necessary for the mat construction. Fun fact:  the Rabbit lasers in Ideate are superior to the Techspark Rabbit lasers (good to know, but not a fun walk with heavy items).

I feel that I am a bit behind schedule, as Bluetooth is not integrated into the system yet. As long as Zoe and I can get the lock and the app communicating by the end of this week, I should be in a much better place, as getting song selection set up and a 3D-printed container for the lock *should* be relatively straightforward and not too time-consuming.

By the end of next week, I hope to have Bluetooth between the app and lock completed, including soldering the BT module for speaker connection. After that, if the microSD cards and module come in quickly, I will begin working on getting songs loaded and playing through the lock.

Also, Happy Easter!