Progress Report for Achinthya Soordelu
Week 1:
Date: -Enter today's date here-Total hours: -Enter the number of hours you worked this week here-
Description of design efforts:
-Discuss your design efforts here. Remember to follow the guidelines presented in the Progress Report Policy, available here. This is a template entry; simply copy/paste this entry when doing progress reports each week.
Week 2:
Date: 01/19/18Total hours: 10
Description of design efforts:
My main individual effort this week focused on identifying possible hardware choices for our microprocessor, Wi-Fi module, NFC module, and locks. The hardware flow for the modules that I searched for is shown below. The main constraints that I used to narrow down my findings were functionality, cost, ease of use, amount of available documentation, and familiarity with product. After looking up parts, I narrowed down the Wi-Fi chip to the ESP8266, a cheap and well documented Wi-Fi module that group members have experience with. The NFC module chosen was the PN532. Although more expensive than some other options, such as the MFRC522, the PN532 works with cell phones, which is our specific usecase. Choosing a lock module was slightly more challenging due to the variety of different options available. I selected the Atoplee DC12v Mini Electric Bolt Lock because the sliding bolt action is best suited for our project and the power requirements are not incredibly demanding on the system. Finally, given the module selections, I was able to determine that we could use the STM32F0 microprocessor, as it accomodates our need of 2 SPI interfaces, for Wi-Fi and NFC. Additionally, I worked on parts of the functional specification, the team assignment for the week.
Next steps for my role, working on software at the embedded level, include ordering parts and building basic prototypes of some of the hardware flows with the parts we already have.
Week 3:
Date: 01/26/18Total hours: 8
Description of design efforts:
This week, I worked on beginning to acquire hardware, both for prototyping and for the finished product. I procured samples of NFC chips and checked out both an STM32F051 board and an ESP8266 board. This will ensure that there will be no blockers in starting prototyping. Some of this hardware is shown below. Additionally, I have acquired the toolchain for programming the STM32 on my personal machine. We slightly adjusted our plan for communication between the base system and the web service, opting to use the MQTT protocol for the networking. In order to familiarize myself with this, I read the documentation for the protocol. Similarly, I improved my understanding of NFC by reading the techinical specification for it. By doing both of the above, I am better prepared to jump into building and debugging with the ESP8266 and our NFC chip. I contributed to the component analysis document, the team assignment for the week as well. The next steps for me are to put together a simple Hello World program on the STM32, and then to start connecting it to the chips that I now have. Additionally, I worked on parts of the functional specification, the team assignment for the week.
Week 4:
Date: 02/02/18Total hours: 10
Description of design efforts:
This week, I began programming the STM32 using the STM32F051 Discovery Kit. I built a simple button toggle LED program on the STM32, both familiarizing myself more with the platform and demonstrating progress to show in lab. Also, found an MQTT library for the ESP8266 and built a MQTT based LED toggling program, interfacing the chip with an MQTT service set up by Sam. The picture below shows the interaction between the server and the ESP8266. The "1 - Turn LED On" message is sent from my PC MQTT client to the server. All client subscribed to the "test" topic receive the message, including the client on the ESP8266. The chip checks the message and follows the instructions, toggling its LED on. It also publishes "Message Received, LED On" to the topic, providing confirmation that it received and processed the message. The "0 - Turn LED Off" message then turns off the ESP8266 LED once the chip receives the message and processes it. Along with Sam, I finalized the communication to be done on the actual locker topic, namely what each control message looks like, both from web service to chip and chip to webservice. Finally, I contributed in researching parts and information for the Bill of Materials. For the next week, I plan to implement the aforementioned communication protocol on the ESP8266 and work on interfacing the STM32 and the ESP8266 via SPI.
Week 5:
Date: 02/09/18Total hours: 10
Description of design efforts:
This week, I fully implemented the ESP to API MQTT protocol on the ESP8266 chip, putting in duped values for the token exchange, as NFC has yet to be implemented, and randomizing whether the system send back a Cancel command or a Token command, for the same reason. I worked with Sam to modify code on both ends of the interaction, further refining our protocol and addressing hardware limitations of the ESP8266 with regards to message sending integrity. However, in its current state, the Wi-Fi component of the project is nearly finished due to my work this week. I also decided to shift from using SPI to using UART on the ESP8266 after further research, due to the fact that the subtype of ESP that we would need to use is different for SPI, and our needed functionality can be accomplished cheaper by using UART. I also found resources regarding interfacing the ESP and STM32 via serial, a link that will be used heavily in the system, as shown in the flow chart below. As prototyping ramps up, I fully mapped out the hardware flow as shown below. While the chart details the unlock flow, the lock flow is functionally the same. The only variations are that the system locks instead of unlocks, and the active LED colors are reversed between red and green. For the next week, I plan to implement bidirectional STM32 and ESP8266 communication, completing the majority of the flow. I am currently blocked on working with the NFC board and prototyping with it because it requires soldering to be used. As this week has soldering techniques on the schedule, I plan to unblock that issue and have interaction between the PN532 and the STM32 to present as well.
Week 6:
Date: 02/16/18Total hours: 12
Description of design efforts:
First, I started this week by working with Sam and Dimcho to test a simplified version of the token authentication system we will ultimately implement. We confirmed that the flow works from the App-API interaction to the Base System-API interaction. Most of my time this week was devoted to getting duplex communication between the STM32 and the ESP8266. I wrote code on both ends of that interaction, using UART as the means of communication. At first, messages from the ESP to the STM were working well, but messages to the ESP from the STM were fragmented and it would take several tries to get the data across as intended. To solve this, I experimented with different baud rates to pick the ideal speed with reliability. I also implemented software side checks to increase integrity of the data, specifically with special ending characters and character sequences that are checked to ensure that the data was properly communicated. For the lab demo this week, I showed off the communication and wrote some code to toggle external LEDs with the STM, a function that will be used in the ultimate prototype as well. The picture below shows the connection between the STM32, the ESP8266, and the status LEDs. For the next week, I will hook up the NFC module to the system, either with SPI or UART, and start working more with Dimcho on the app end to ensure that the app interface can work with the PN532 NFC chip.
Week 7:
Date: 02/23/18Total hours: 18
Description of design efforts:
The first task that I worked on this week was hooking up the PN532, our NFC module, to the STM32. I tried it with both SPI and UART, but decided to go with UART due to number of wires, which simplifies the task on the PCB layout end for Noah. As a result of my work this week, the STM32 and the PN532 are fully able to bidirectionally communicate. I developed functions that take commands in the specific packet format that the PN532 demands and send them over, as well as functions that translate packets from the PN532. The following image shows the current flow within the NFC enable function, where the STM32 gets an NFC message from the MQTT server via the ESP8266. The STM then wakes the NFC chip, checks some status bits and adjusts them, initializes the board as a passive NFC target for a phone to interact with, then pings the board for data from the phone. I worked heavily with Dimcho to try to get PN532 to Android communication working. Although we made some progress over the week, we are still having difficulty with successfully brokering a connection between the board and the phone and are thus not able to get the token transmitted from the phone to the system yet. The second task I had this week was to write the Software Formalization. This task took a significant amount of time, especially with regards to thoroughly fleshing out each software component description and testing plan. Additionally, I hunted down authors and descriptions for each third party library used in each component of our project. For next week, I will continue to work with Dimcho to try and resolve our issues with the PN532 and Android connection. In addition, I will build some more supporting functions to make PN packets more usable for the ESP8266 and will start looking at prototyping the motor connections to the STM.
Week 8:
Date: 03/09/18Total hours: 15
Description of design efforts:
My main task this week was trying to get the PN532 to communicate with the Android phone we are using for prototyping. I tried several combinations of protocols and commands, from both ends of the transaction, but ultimately I was able to reduce the difficulty of the problem by using a MiFare Classic card as a medium between the phone and the PN532. The phone uses NFC to write the token to the card, and the PN532 reads from the card. This implementation of authentication escapes the increased complexity of getting two way active communication between Android and the PN chip. In the ultimate prototype of the Smart Locker, the card will be mounted on the inside of the base system, which will simplify another hardware problem of dynamically reading and setting up the UID for each NFC participant, as the UID for the MiFare card will be consistent. Before lab, the Android app that we have been developing was not able to interact with the MiFare card, so I used an NFC tools app available on the Google Play store to write test messages and tokens to the card. The commands shown in the following image, and variations of them to read different blocks of data on the card, are successful in authenticating the transaction between the card and the PN and are able to extract the token information. I built a simple protocol similar to the one implemented on the ESP to MQTT communication where special control characters are used to indicate the start and end of tokens. Later in the week, Dimcho was able to get our Android app to write to the MiFare card, so we are now able to fully communicate from the app through the MQTT server. Once this was accomplished, I addressed a latent issue that had appeared in the system, where the ESP8266 was having issues receiving UART messages from the STM and would often stop reading before the full message was sent, but only in UART transactions immediately following an NFC transaction. I was able to solve this issue by introducing a 1 ms delay in the ESP8266 UART read code, allowing enough time for the ESP8266 interrupt to be pinged again without the chip exiting and deciding that a full token had not been sent. Finally, I started doing work on PWM on the embedded side by writing some of the basic set up code to enable timers and PWM functionality on the STM32. Next week, I plan to work with Sam and Dimcho to do a full test of the communication system, from webservice to Android to PN to ESP to MQTT to webservice, to confirm that we have the system entirely functional. I also plan to get PWM working from the STM32, thereby completing the board-based prototyping of the system.
Week 11:
Date: 03/23/18Total hours: 10
Description of design efforts:
I started this week by working on writing code to get PWM working on the STM32 in order to control the actual lock mechanism. While I was able to write the setup and function code (as shown below), I was unable to actually test the system. The STM32 outputs 3.3V and the lock requires 5V, so I need to hook up the level translator to the PWM output to confirm that the locking functionality and PWM code works. Next, I performed an end to end test of the communication system with Sam and Dimcho. We ran into several problems in doing the test and were not able to complete the test as we had initially hoped. On the hardware side, I uncovered bugs with regards to authenticating and reading multiple blocks on a Mifare card that were generated during some refactoring of the code, which I solved during the week. In addition, I was able to optimize the block reading code to take place in a loop, rather than reading block by block unrolled. Dimcho, Sam, and I still need to discuss the possibility of standardizing the length of JWT tokens here to simplify this code, however, in order to make a neater and more reliable exit condition for NFC reading on the hardware end. Although I was not able to complete PWM, and we as a team were unable to complete the end to end test, uncovering and cleaning up bugs in the process now is helpful to avoid the bugs becoming more complex and harder to find in the future. Finally, I researched and wrote the legal analysis for the project, looking at both competing patents and regulatory certifications that the project needs to meet to go to market. Next week, I will finish the PWM prototyping by using the level translator to interact with the lock. Additionally, Sam, Dimcho, and I will redo the end to end test of the communication system so that we can test both successful and unsuccessful attempts and locking and unlocking the system.
Week 12:
Date: 03/30/18Total hours: 12
Description of design efforts:
I started this week by meeting with Sam and Dimcho to redo the end to end test that we had attempted last week. The goal was to confirm both failure to unlock/lock as well as successful unlock/lock flows. In the process, I needed to make adjustments to the microprocessor code on a few levels. The first is that the buffers that I had been using to store keys was too small, so I needed to expand them on both the STM32 and the ESP8266. The ESP8266 had an additional issue where the MQTT library used did not support messages of the size of the key being sent in a single MQTT message. To rectify this, I had to edit the library itself and expand the MQTT buffer that is made available. In this first set of tests, we used a Mifare Classic card in a mobile fashion, in that the phone would dump a token from the webserver onto the card, then the card would be moved onto the PN532 when it was ready to scan. Later on in the week, we performed the tests with the Mifare Classic card being stationary, which opened up a previously unseen problem in NFC. The phone would refuse to dump a token onto the card when the card was mounted on the PN532, likely because of the PN532 outputting a field that interfered with the phone to card process. To adjust for this, I had to write a power off command for the PN and integrate it into the microprocessor flow, so the PN is only on when it needs to read the card and is otherwise in an off state. An additional task I worked on this week was finalizing the LED interface for the system. The attached picture shows the wiring and setup of the currently prototyped system, with the STM32, ESP8266, PN532, and LED interface all hooked up together. The interface itself has a pair of red and green lights for each locker and one yellow light for NFC. The NFC light turns on when the mounted Mifare card is being read. The red and green lights indicate locked and unlocked status, respectively, for each locker. The other task that I continued working on this week was getting PWM on the STM32 to function. To test PWM, I decided to use the signal analyzer in lab because the level translator is hard to work with, but getting PWM output on the signal analyzer would allow me to confirm that the code from the micro end works.The code I had written previously was not working using this test method so I tried out some other changes in the code. However, as of right now, PWM is still not functional and I am continuing to investigate how to correctly implement this. Next week, I will focus entirely on PWM as it is the last part of the prototyping left, and everything else from the microprocessor end has been completed.
Week 13:
Date: 04/06/18Total hours: 10
Description of design efforts:
I started this week by finishing prototyping with the STM32F0 Discovery board. The last remaining function that I needed to build was PWM for the actuating the locks. While the function has yet to be tested on the locks themselves, due to level translator limitations, the lock documentation provides information on what kind of signal it requires to actuate. The MG90S requires a 50 Hz period with a 1 to 2 ms duty cycle (5%). As shown in the following picture, I was able to achieve that signal on two different STM32 ports, which is what the project calls for to be able to independently actuate two different locks. Next, the team task was to start programming the PCB. To accomplish this, I wrote a simple LED light-up code in order to test our ability to program the STM32 on board the PCB and to test our ability to step through code flashed to the PCB. We were initially unsuccessful in programming the chip due to using the wrong schematic for the layout of the SWD pins on the board. However, once we found the correct pinout for the PCB SWD pins, we were successful in programming the board. Another task I worked on was addressing a latent issue where resetting the ESP8266 caused garbage to be sent through UART to the STM32, which then caused the code to break because the garbage did not fit the specs laid out for the STM32 to ESP8266 communication. I wrote code to handle this garbage output and now the system works even in the case of an ESP reset. Finally, I attempted to flash the ESP code to the ESP8266-01 chip, the Wi-Fi chip that will actually be put on the PCB. However, the Arduino IDE threw errors on attempting to flash the code, possibly due to incorrectly wiring the USB connector to the chip. Next week, I plan to debug and solve the issues with flashing the ESP8266-01 chip. Once done, I will test the current system code by flashing it to the STM32 and placing the ESP-01 on the board. If running the code on the PCB causes any issues, I will resolve those problems as they arise.
Week 14:
Date: 04/13/18Total hours: 15
Description of design efforts:
This week, I worked on finally putting the project together in terms of wiring and packaging, and debugging any latent issues that arose. First, we worked on mounting the motors to the locks. In testing the locks, several were broken or did not work well enough. We tried a few different forms of mounting, including only epoxy, duct tape, and a mix of both. Once mounted, I ran tests on whether the lock would actuate with the motor or not. Although the lock would move, the motor was not able to get it all the way over with the initial code. To address this, I had to adjust the duty cycle to work in 2 waves. The first duty cycle is stronger to overcome the inertia of the lock. The second duty cycle is weaker in order to prevent the motor from continuing to move its gears and potentially burning out. Later in the week, I worked with the rest of the group to complete the base system box, mount it on the lockers, and wire everything together. I also found that NFC was being temperamental because of a wiring issue, which caused problems during some demos and trial runs of the system. Fixing the wiring issue immediately resolved all extant problems with the PN532. Finally, the team demoed the system several times this week, getting all preliminary and final PSSCs checked off. A side shot of the assembled locker system can be seen below.
