Team Status Report for 3/14/2026

As with last week, the largest risk to the project is the arrival of the ordered PCB.  It is expected to arrive by Monday, so we should be able to test with it on the day we don’t have our ethics meeting. Unless it is delayed further, we should be able to continue with our current schedule.

In terms of design changes, we are considering moving from Bluetooth low energy to Bluetooth classic, due to an improvement in documentation providing additional aid in troubleshooting, but the decision is not final.  We did not plan to implement Bluetooth functionality this week so this decision does not undo any previous work or cost much time, but a decision will likely be made before starting implementation.

In addition, after discussion we have settled on the desired variables to be tracked by the schedule JSON, details of which can be found in the individual status reports for this week.  Since this was largely changing fields from strings to integers, it has a very small upfront cost but will hopefully make our run more efficiently as we now don’t have to parse/interpret as many strings.

Felipe Status Report 3/14/2026

This week I finalized the plans for the schedule JSON structure that will be created in the companion app and sent over to the device.  This did involve some small minor design changes, but shouldn’t affect the planned user experience of the app and device, as most changes were made in the backend structure.  Most of these small changes were made to transform as many of the JSON field as possible into integers, since those are easier to send as characteristics which is what the device will save relevant data as.

For example, while users can select what days of the week they want to receive certain reminders through a series of toggled buttons, the actual JSON will save the days active as a seven bits, where each 1 corresponds to a day the reminder will be triggered.  As an example, a reminder triggered only on weekdays will have value 0111110.  This prevents us from having to save a list of strings and instead only work in the form of an integer.

In a similar vein, start/end time selection will be done with a standard time picker included in material (example shown below), but the specific time will be saved as a single integer that corresponds to minutes after midnight.

 

The final major change comes in the parameter that determines how often a reminder should be repeated.  User will be given several initial options like every hour or every three hours, but will also have the option to set an hour and minute value so they can have reminders repeat whenever they want.  In the backend again it will be saved as a single integer that corresponds to the minutes between each reminder.

 

Overall these changes don’t much impact my planned schedule, as they all involve simple material components that are largely interchangeable.  I should have a first look at the schedule creation application done in a week, but medical appointments may push me to next weekend.  Overall I feel like I am in a good position and am ready for the coming weeks.

Italia’s Status Report for 03/07/2026

Over the week, I mapped out how the menu selections and button toggles will interface with one another. I created a finite state machine to show the different modes that a user can be in when receiving a reminder. The fsm has six states: WAIT, SNOOZE, RFID, MANUAL, CONFIRM, and COMPLETE. There are 5 signals that the fsm takes in, 4 of which represent reprsent the button toggles and the 5th signal representing the remainder signal. Below is a preliminary fsm to represent this.

Currently, I am behind schedule as it took longer than expected to figure out the various software programs we are using for the project. The plan for the upcoming week is to finish mapping out the firmware and start developing it once these mappings are fully fleshed out. To ensure I get back on schedule, I will work on finishing diagrams by Tuesday night and start developing firmware the following day.

As I mentioned previously, this upcoming week will be focused on getting back on schedule and having a complete plan before developing any firmware.

Felipe’s Status report for 3/7/2026

As a reminder, this status report includes two weeks, starting from 2/21 and ending on 3/7.  Of course, the second week was Spring break and as per the TAs recommendation little work was done over that time.  In terms of the week prior to spring break, the majority of that time was spent on creating the design report document incorporating feedback received from the design presentation.  My contributions to that report, which can be found in the design review tab on this blog, was the sections regarding the companion application as well as a fair portion of the reports introduction, use case requirements, and high level overview.  Also in response to issues our team had in the design slides, I spent time learning how to ensure that images were correctly displayed when using overleaf to create the document.  I believe that myself and the team was able to create a readable report but I understand that I am still not experienced in overleaf and will likely make edits when adapting the design report to our final report.

 

In terms of work on the application I have created a list of tasks that will inform my development process, first prioritizing JSON editing and saving before moving to Bluetooth integration.  Hopefully the app will start to come together in the coming week and I will have a basic, if ugly UI by the time of my next status report.

Team Status Report for 3/7/2026

The most significant risks that could jeopardize the success of this project are issues with the PCB we ordered. We have taken a number of measures to mitigate against this risk. The first is that we are planning to order two different PCB designs. Version 1 is already in production, and the second will be an improvement upon the first based on any bugs we find with the first PCB after testing. Additionally, the design for version 1 has been made to be as reconfigurable as possible, by using solder jumpers, test points, and breakout headers. If there’s a mistake on version 1, it should be relatively easy to fix, so we’re not waiting for an entire new PCB before we can test any modifications.

There were no significant design or schedule changes made since last report.

The product solution we are designing meets specific needs as they relate to global factors in that this interface and this device is meant to be universal. Anyone, no matter their technical background, should be able to intuitively use Remigotchi. We hope to appeal to a wide range of ages, although as stated earlier, our primary design focus is college-age students, specifically at CMU. We are designing an easy-to-understand and an easy-to-use graphic user interface for Remigotchi to minimize the barriers between individuals and their wellness goals.

With consideration of cultural factors, we are designing a product that will allow users to be more present in what’s going on around them while still helping them stay on top of their health. Remigotchi provides user-specified reminders, but since it’s a separate device, it won’t hoard users’ attention, preventing them from interacting with the world and people around them.  Another concern with cultural factors is considering how groups respond to devices taking in potentially identifiable data that could be used to link them to a specific identity, which may cause legal trouble.  As an example users might worry that telling the device whether they walked or how much they drank might be used to infer details about their life including location data which could then be used to harm them.  Of course Remigotchi as it stands has  no plans to implement any location tracking or sharing of any personal user data, but if the user fears that they might, then that will interfere with Remigotchi fulfilling its intended purpose of providing stress free motivation.  Our current solution to this problem will likely be to add information screens to the Remigotchi companion application that provides assurances to the user on what data the device will and will not collect.  This will hopefully be sufficient to ease the concerns of vulnerable users.

Another group of people that we need to consider in our device is those suffering from depression and other mental illnesses.  As discussed in a previous status report, while we want the Remigotchi device to be motivating to users, we do not want to add additional stress in the form of a virtual pet.   While those suffering might benefit the most from a second entity to take care of as they improve their lifestyle, they are also the group that may take it the hardest should their virtual pet begin to suffer from a few honest mistakes.  This complication is slightly harder to address, since it requires surveying those with a condition that people generally don’t like to advertise they have.  A simple solution would be to interview users after letting them test the device in order to find out what is an appropriate level of motivation in letting the virtual pet be damaged, but without specifically interviewing those with depression results may be wildly incorrect.  Overall there is no easy solution to this issue but the team will discuss it further and attempt to make sure our device does not cause active harm to vulnerable users.

With consideration of environmental factors, device is meant to be low-power, reducing users’ carbon footprint when compared to electricity used to charge ones phone for constant use. Additionally, Remigotchi encourages users to take care of themselves in a sustainable manner—and users are also living organisms on this planet.  Possible suggestions include taking walks outside, which could reduce the time users spend in front of a screen drawing power to various devices.  In addition, text reminders can be programmed to provide basic advice like recycling water bottles when appropriate.  While these reminders may go ignored they serve to show that we at Remigotchi do care. Other considerations made is using sturdy, yet widely available materials so that the device is unlikely to break warranting a user by more devices therefore adding to general electronic waste.  Remigotchi also has no plans for forced obsolescence, meaning that it will be designed to last with minimal part replacement again reducing overall waste.  While this is less applicable in the testing stage where construction is extremely small scale and devices need not last months or years, should the time allow we could also look into how this device would be manufactured in a sustainable way.

Part A, was written by Delaynie.

Parts B and C were written by Felipe and Delaynie

Delaynie’s Status Report for 3/7/2026

Over the past two weeks, I finished the layout for the PCB, finalized all 39 parts that are being placed on it, and ordered it. After ordering, JLC reached out to me because there was one small issue with two of the three LEDs I selected. These LEDs were in a reverse-mount package, meaning they are placed on the board “upside down,” and also require a hole drilled through the board for their light to shine through. I did not realize this, and thought that they were just your normal 1206 SMD LEDs. After emailing JLC, I replaced the reverse-mount LEDs with normal ones.

Additionally, I worked with my team to complete our Design Report due before spring break. My contributions included detailing certain design decisions and tradeoffs we thought through, as well as calculating conservative estimates for Remigotchi’s power requirements. We concluded that Remigotchi would, at most, require a 2000 mAh 1S lipo battery to ensure a full day’s worth of power.

Also, I started drafting some ideas for what the menu options in Remigotchi are going to look like, and how users are going to navigate through them. Below are notes I wrote down. They are just a first draft, and are not set in stone.

According to the Gantt chart, all hardware development is on schedule. I achieved my deadline of ordering the PCB by the Friday before spring break. However, it’s possible I may fall behind schedule if the boards don’t arrive soon. I’m supposed to test the PCB next week, and I may have to push that back by a few days. At the time of writing this, manufacturing and PCBA has completed, and the boards are on their way to the JLC shipping center. I expect them to arrive sometime before next Friday. To catch up and keep this project on schedule, I will work on testbench firmware while I wait. This will start out as basic sample programs to ensure that the ESP32 can effectively communicate with the other sensors and devices onboard.

Deliverables I hope to have next week are a completed and finalized idea for menu architecture, to be discussed with Italia. Additionally, I’ll have a more detailed PCB test plan before the boards actually arrive. I’ll start out by simply testing electrical connections, then move onto testing it’s DC-DC conversion capabilities, make sure I’m able to flash the ESP32 onboard, then move onto running some sample firmware to make sure I mapped the pins correctly.