Senior Design Part 9: Can Adding a Delay Be a Good Thing?

2023-06-16 | By Will Siffer

License: Attribution Non-commercial

Recapping from last time:

In my last post, I discussed how we were having an issue with the RFID chip not replying to serial commands whenever it was running on battery power. It seemed like a really strange issue, and this week I spent the first couple of days trying to find the solution. Since I took some time away from the project, I had an opportunity to think and reflect on everything I knew about how the project worked. 

One of the first things that I did was reach out to a family member who specializes in microcontrollers and small devices, and he reminded me that there's a chance the logic level of the RFID chip was barely at 3V3, and maybe under computer power the RP2040 was sending a signal just barely high enough to trigger a response. The first thing I did this week was measure the signal both when the system was working and when it was not working. This was interesting because, as it turned out, the signal was higher on battery power than on USB power.

On USB Power

On Battery Power

As you can see, the maximum voltage sent on the channel in the USB was about the same as on the battery, with the battery being slightly higher. This rules out a possible logic-level issue and means we had to go back and try something else. This time I tried the software.

On to the software!

After spending the week reflecting in Ireland with the marching band, I remembered something that suddenly stood out to me as clear as day. My project manager said in passing once that the original code for the RAK module had a 5-second delay on startup in the setup loop. The team a couple of years ago removed it when they didn't notice a functionality change. When I was finally able to get back into the lab, the first thing that I tried was adding that 5-second delay back to the beginning of the code in the setup function, and testing the code. Sure enough, the code booted properly and the RFID chip worked consistently both on USB and on the battery. This was an interesting issue since it appears that the RFID system requires a boot delay before it can receive a message over serial, and if that boot doesn't happen then the system will never recover. 

Bonus content: launching the device on its first real-world test!

We launched the device for the first full test to watch the data come in through our dashboard. This test helped evaluate the ability of the device to function and recharge itself throughout the day. Unfortunately, it was a cloudy day, and the solar panel did not charge the battery at a single point throughout the day. So the device did not make it much longer than 12 hours. Fortunately for us, the sensors were all working, and we could monitor the voltage over time and watch the battery deplete throughout the day! 

This data is only from the evening, for some reason the system didn't store the hours before 5 pm, which is an issue the database team is working on. As you can see, the voltage steadily decreased until it fell so low that the system was unable to continue sending data. This test was important because it showed us the system couldn't yet perform reliably in cloudy weather. We will continue working on this through future tests of the board. 

This week was great since I was able to solve issues while at the same time completing the first full system test. I have really enjoyed documenting this project here and I hope you have learned something along the way. Until next time, my name is Will Siffer, the Digi-Key ambassador of Purdue University, and I hope you stay curious.

Here is my reflection for the week where I was able to look at the contrast between individual and project growth. 

Recommended Reading

• Senior Design Capstone Part 1: What (or Who?) is LoRa?
• Senior Design Part 2: Using Eagle to make a custom PCB
• Senior Design Part 3: Designing a SMD PCB full of sensors
• Senior Design Part 4: Assembling, Testing, and Debugging Circuit Boards!
• Senior Design Part 5: Diagnosing PCB Issues
• Senior Design Part 6: Protecting our Power!
• Senior Design Part 7: Compressing data with Magic? (It's just math!)
• Senior Design Part 8: Squishing Bugs and Finding More

"This week we solved a big issue, and we also field-tested the device for the first time. This allowed me to reflect on the ways that my individual good is connected to the common good of the project. For this project to be successful, it needs to be tested and retested, and evaluated at every chance for issues so we can have as few issues as possible at the end of the semester. This is similar to what I need to finish senior design since I need the project to be functioning in order to have a full presentation about the work that I completed throughout the semester. There are also ways that the project benefit and my benefit are not necessarily connected. For example, it's best for me to document all the work that I do in blog posts and in my work and accomplishments so that future students can understand my work, but the project is in a phase where it needs constant physical testing in order to find issues and solve them as fast as possible. This is something that I hope to continue reflecting on when I start working in the industry so I can make sure I keep an even balance of personal and project development. So far this senior design project has been a great reminder of the importance of that balance."