Sophia’s Status Report for 2026-09-26

This week, I was mainly working on finalizing components and creating the schematic for the PCB, along with working on the design review presentation.

We decided on the ESP32-P4 microcontroller for our main architecture. Originally, we were planning to use the eval board (ESP32-P4-WIFI6) mounted on our PCB, but were unable to due to there not being enough GPIO pins. As a result, the schematic has most of the main components (outside of input capacitors, pull-up resistors, etc.) but currently does not have the circuitry for anything that was handled on the eval board itself (such as power management, USB connection, and flash memory, and the clock) as the schematic symbol was changed recently. I am planning to copy these from the recommended hardware documentation as well as the eval board schematic. I also preordered 2 of these microcontrollers on the PCB assembly site I plan to use so that they are available for when I order my PCB.

For the LiPo battery, I decided on an MCP73832 for USB charging, along with a MAX17048 for gauging the battery level. These choices were based on Adafruit’s dedicated boards for these tasks; however, to save costs and space, I decided to put the ICs on my board directly. I also decided on a NCV8187 3.3V LDO regulator to supply power to the rest of the board, since the difference between the voltage of the LiPo battery is relatively small for most of the time, making the efficiency comparable to a buck converter.

I also selected connectors for the screen and battery, as well as a passive buzzer. I am slightly behind schedule, since I have not fully finished my schematic; however, I have selected all key components, so most of the work lies in creating the remaining components in my design software and double checking datasheets. This should not be a large issue, as the week I have allocated to ordering the PCB also doubles as buffer time. Next week, I need to work on layout, as well as the design report.

Maggie’s Status Report for 2026-09-26

This week, I was mainly working on the system design and architecture of how the major processing, communication, display, and power subsystems interact with each other. This includes the esp32p4 MCU, GPS and LoRa modules, touchscreen, battery charging and protection, voltage regulation, and thermal monitoring. I then worked on creating the system block diagrams and preparing the corresponding design slides.

I also worked on comparing our processor and peripheral options and helped finalize the specific modules we would like to proceed with, with a main focus on their processing power, power needs, development support, and compatibility. After finalizing these decisions, I have started working on developing the GPS firmware.

My work is currently on schedule overall, although the hardware selection phase took a bit longer than initially expected because we reconsidered a few different processor architectures. The main processor (and the corresponding dev board) and initial peripherals have been finalized now, so we have a stable architecture that we can start developing on.

I’m currently working on developing and testing the GPS and LoRa interfaces. This will be done on the dev board while the custom PCB is still being designed. In terms of GPS, the goal is to complete a minimal version that reliably reports latitude, longitude, fix status, and timestamps before we start adding more complicated configuration and power management features.

Next week, I plan to complete the first functional version of the GPS interface (specifically the driver configuration and message NMEA message parsing) and begin LoRa message transmission, and the expected deliverables will be committed GPS code and potentially an updated system diagram and LoRa bring-up code.

Team Status Report for 2026-09-26

This week, we were scheduled to work on our design presentation and PCB schematic. During the course of the week, we selected components for the PCB and purchased the most critical components for development – namely two esp32-p4 development boards. GPS drivers are in progress, but diverted due to a late pivot in our choice of SoC: we intended to use an (overpowered) Raspberry Pi due to lack of stocked SoCs in the 32MB RAM market, but found an appropriate chip for our purposes. A rough draft PCB schematic is nearly finished- all components are selected, but due to the eval board not having enough GPIO pins for our applications, a few more circuits are needed for power management on the MCU. Overall, we’re on track.

In the next week, we’re working on PCB layout, case design, GPS completion and testing, and LoRa first steps. We’re also working early on emulation and building familiarity with the PalmOS platform. This is a standard amount of risk for us: our schedule is tolerant of delays via rearranging software work or pushing work into break. We have about a week of breathing room on the PCB: our goal is to order it in the week of 10/4, but if we encounter delays, we can work on it then and still order by fall break. On the software side, we care right now about proving our ideas feasible, and detecting challenges that we’ll encounter during system integration.

This week, we’re also adding context about the circumstances of our system. A was written by Maggie, B was written by Tucker and C was written by Sophia.

Public Health, Safety, and Welfare

We aim to address the needs of children by providing a means of communication without exposing them to the unrestricted internet. It limits undesired online interactions while still allowing children to participate independently in digital activities. The goal is to preserve the child’s ability to safely communicate, take actions, and request assistance while balancing supervision and privacy.

As children are our primary users, physical and electrical safety plays a very important role in our design. The enclosure will be made of safe, nonhazardous materials, and we will be using rounded edges and securely fastened parts to reduce the risks of physical harm. Since the design also involve electrical components, we will use battery packs with built-in protection circuit module as well as embedding additional safety measures such as thermal monitoring and current protection into our design.

Social Factors

Our design is for children to use. While the social circumstances of children in the United States have been in constant flux, there’s a few key attributes that consistently distinguish it from modern adult conventions. For one, as adults, we must regularly interact with unfamiliar people and businesses that we find through referrals or online, especially without having met before or being located in the same geographic area. Often, we must be able to do so quickly and at unexpected times. Kids, on the other hand, have a majority social interaction dictated by physical proximity: communication tools are rarely the primary means of initiating relationships, but are a secondary component of being in the same school, sport, or neighborhood. This element of physical and temporal proximity is also practical for safety: parents generally don’t want to allow unsolicited or unmonitored internet interactions with their children.

Therefore, our design is underpinned by these social connections, particularly in our multi-device philosophy. We chose PalmOS because it’s a platform with a persistent concept of local connection – IrDA, an infrared p2p connection system, persisted throughout the lineup, but it had issues with the short connection distance and need for consistent line-of-sight. Therefore, we believe the idea was not explored to its maximum. With LoRa, we have a greater (but still local) connection distance, and can foster multi-device use cases. We can also exploit urban mesh networks. Further, we believe that the choice of technology shapes how users interact with the world, and we believe that local networking fosters developing in-person connections through interactions that the Internet was never built for.

Economic Factors

In terms of economic factors, the most important goal is for our product to be affordable to families as a viable alternative to current smartphones (or other current phones specifically manufactured to be “dumb”) short of buying legacy models that are unsupported and out of production. In order to do this, we would like to use the most affordable hardware possible that will still meet our needs, and assemble it on a custom board to save costs (and space) in the long run. In order to keep the housing durable but affordable, we’d also like to manufacture the case out of plastic via 3D printing.

In addition, users are free to install their own custom software (whether free from the internet, or self-made) as a built-in feature of the device, instead of being locked into a specific suite of apps, giving users a lot of flexibility without incurring additional costs.

Tucker’s Status Report for 2026-09-26

We are on track for work this week. In particular, we’ve narrowed down a lot about our design and component selection, including some fortunate changes towards the end.

We’re aiming roughly for Palm m515 compatibility, as it’s later-generation and fulfills our needs while still being of reasonable scope for a capstone. The m515 has 16MB RAM and 4MB flash, as well as a 33MHz processor. Very few embedded packages have this amount of RAM; for this reason, some prior art upgrades to a Raspberry Pi. This is certainly workable, but it’s overkill for our purposes. However, we don’t want to adopt the complexity of routing our own RAM chip.

I found a ESP32-P4/32 based board in stock with 32MB RAM and 32MB flash, and Sophia found stock of the chip. 400MHz will give us sufficient overhead for emulation, and the MCU has a low-power core appropriate for idle work. I developed a pin map to ensure feasibility, and I’ve started working with the HAL in Espressif’s `esp_hal` crate.

As mentioned last week, I’ve been understanding the 68k landscape. I’ve written a few simple programs using the Easy68k assembler/simulator, written by Brad Krupp and The Great Emerson.

My plan for the following week is:
– Case sketches by Monday night
– Practice using the 68k disassembler by Wednesday night
– Case model; instruction decoding in the hypervisor by Saturday night.

In case of unexpected delays, this schedule has quite a bit of room to flex, as it’s still ahead of our global schedule. I’d like to save that flexibility for future risks, if possible.

Maggie’s Status Report for 2026-09-19

We received many valuable and constructive feedbacks on our proposal, and Tucker did our proposal presentation earlier this week. Based on the feedbacks we received, we refined our design to place more emphasis on our target audiences’ perspectives and tuned the requirements to be more measurable around those specific use cases.

My primary focus this week was exploring the overall system architecture and integration strategy. I read project blogs using similar tech stacks as what we might do, researched components that may be required or beneficial to our implementation, and compared their tradeoffs in processing power, capabilities, and cost.

Next week, I plan to begin developing and testing the GPS and LoRa communication firmware. We will also  finalize the first batch of components needed for development, including the dev boards, processor, LoRa and GPS modules, and other essential peripherals, and then place the order. So far, we are still on schedule.

Sophia’s Status Report for 2026-09-19

This week, we worked on the proposal presentation slides on Sunday and helped Tucker prepare to present in front of other capstone students and faculty. I also began researching some of our hardware choices, narrowing down some of the systems and components we will used based on size, price, and compatibility.

We will be using an SX1262-based 915Hz LoRa module, likely a Wio-SX1262, for low power consumption and strong transmission, as well as to allow for Meshtastic compatibility. This will utilize SPI, and will require an external antenna, which may need to stick out of the housing.

For GPS modules, I narrowed it down to three options: the Quectel LC76G (PA), LG77L, or L96. The first two do not have built-in antennas, while the last one has an integrated antenna. All three are built for low power consumption as well, and will utilize I2C or UART.

We have not yet decided between STM32 or ESP32 for our microcontroller architecture, but plan to decide by the end of Monday’s class so that we can order an eval board for it in the purchasing sheet.  I am still on schedule as I intentionally left my tasks light this week to allow for major obligations outside of class, but I will have to put in a lot more work next week in order to finalize components and create a first version of the schematic for the PCB. Other decisions I will have to make are the touchscreen model (160×160 + color for PalmOS apps), the number and size of buttons, and passive buzzer selection.

Team Status Report for 2026-09-19

This week, we’ve been working on our design and starting on the initial implementation: selecting a development board and proof-of-concepting software components.

Our largest risk right now is designing a system incompatible with our goals. Our development board and final platform must have the radios we need and sufficient resources for emulation, and be similar enough to prepare for the final integration. We’re managing this by keeping our high-level goals at top-of-mind and thinking through the stack. In case of an error, we can generally attach further peripherals or expansions through I2C or SPI.

We learned in research that the M68000 does not have the features we’d like for emulation. Instead, we’ll use a more familiar microcontroller (a la STM32) with sufficient performance to make ISA emulation tenable. This is a favorable switch: hardware has improved substantially since the 68k, more than making up for emulation overhead, and a modern platform has better HALs and development tooling available.

Lastly, we had the proposal submission and presentation. We’ve laid out our problem statement, set our design strategy, and created an initial timeline.

Tucker’s Status Report for 2026-09-19

I’m writing an update for a week and change, since this is my first update!

At the top of my mind has been the proposal. We received great feedback on our abstract, and this led us to focus our problem statement and update our design. Ultimately, we were able to improve in areas we were given feedback and in areas we personally found weak. I presented, and planned for the points I wanted to hit — especially in making it clear to a student audience, most of whom have not used PDAs, why they’d care — and for the questions I expected to come up.

Slightly ahead of schedule, I’ve been exploring the M68k ISA and laying out the foundation for an emulator. I expect a large part of the challenge in running PalmOS apps will be understanding what assumptions they make: it would be costly to replicate every platform quirk, but insufficient to throw timing and other observable-but-flexible behaviors to the wind. Therefore, I want to understand what we’re looking at early.

As an aside: we’d like to improve upon processor speed if possible, to open the ecosystem to new capabilities. If PalmOS or particular apps depend on timing behavior, we might not be able to do this. We will find out!

This week, I’m working on the device housing design, and looking ahead to the emulator. While the deadlines are relatively lax (as the next critical dependency is ordering our PCB), this will account for software needing more time than expected.