Author: sophiak2

This week, we completed our design report and made progress on both software and hardware. In terms of software, we made progress on the emulator, as well as converting bare-mental implementation to using RTOS tasks and an embedded UI. For hardware, we completed the layout and ordered the PCB over fall break.

Our main risk is that the PCB ordering was delayed; however, the order was approved and will ship within the next few days, when we can assemble the PCB in TechSpark; we also planned for fall break and the week after as a buffer in case this happened. We also wrote about global, cultural, and environmental factors below. A was written by Maggie, B was written by Sophia, and C was written by Tucker.

 

Global Factors

The global factors we considered are tied to some of the main motivations of this product, which is to address the universal concern of technology addiction, internet safety, and healthy digital boundary for especially the younger population. Nowadays, children need to communicate independently and participate in digital activities without unrestricted access to the public internet. We design the product to address this need through a constrained application environment, messaging, and location tracking system to support the children’s independence while helping parents and supervisors monitor their safety and digital boundaries. Besides this, we also want to provide an alternative communication method using LoRa for situations where cellular service is unavailable, unreliable, or unaffordable. For now on the prototype, we use the 915MHz band, and we would adjust this frequency on future versions if we plan to use it in regions outside of the US.

Cultural Factors

Parents must often send their children to school or other spaces, such as after-school activities or playdates, independently. Our product provides a solution for parents to feel more comfortable with their child’s independence through being able to communicate with them while still maintaining safety both virtually and in the real world. The amount of hours that the child spends away from their parent may differ depending on age, family values (e.g. allowing children to play outside until late vs. keeping them at home without explicit permission), extracurricular activities (sports, cram school, or lack thereof), and more; however, we would like the battery life of the product to last 16 hours idle to allow for recharging during 8 hours of sleep.

Environmental Factors

In terms of environmental factors, we primarily considered material use, energy consumption, repairability, and e-waste. For our prototype, we use components such as LCD screen and LiPo battery, which rely on raw materials such as liquid crystals and lithium. Since they are off-the-shelf, we designed the device to reduce unnecessary resource consumption by using a rechargeable battery, and utilized a minimal number of low-power components required for the spec to reduce current draw. We also attempted to make as many aspects of our design modular as possible in order to reduce the need of replacing the entire device when one sub-component requires repair, thus improving the product’s lifespan and reducing e-waste.

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.