Device Overview & Specs
One page that names every hardware subsystem and links its deep dive.
Overview
Section titled “Overview”At the hardware level, yoyopod today is V0 “Dawn”: one supported bundle of off-the-shelf boards and kits, wired together to realize the kid’s device fast — a Raspberry Pi Zero 2W wearing the PiSugar Whisplay HAT (screen, side button, microphone, and speaker in one package), plus a PiSugar 3 battery HAT for power and a SIM7600-family 4G modem for the radio. None of these parts were designed for yoyopod; they were picked because they are available on the market, and that is the point — see From Prototype to Product for the V1 “Daylight” designed-PCB story. Non-canonical boards were deliberately removed from the repository; everything below assumes this bundle. There is no camera, no browser, and no app store — and no haptics or LEDs either; both are future-hardware options that appear in mockups only.
Spec table — V0 “Dawn”
Section titled “Spec table — V0 “Dawn””| Subsystem | As built today |
|---|---|
| Compute | Raspberry Pi Zero 2W |
| Display | ST7789 panel on the Whisplay HAT: 240 × 280 portrait, RGB565, SPI |
| Input | One physical side button (GPIO 17, pull-up) — the device’s only control |
| Audio | Speaker + microphone through a WM8960 codec over I²S, on the HAT |
| Power | PiSugar 3 battery HAT: battery telemetry, RTC, hardware watchdog |
| Radio | SIM7600-family 4G modem (serial AT commands + pppd); GPS via the modem |
Battery capacity, enclosure dimensions, and weight are prototype-dependent and not yet published as committed product specs.
Key components
Section titled “Key components”| Subsystem | Deep dive |
|---|---|
| The panel and the button | The Canvas: Display & Input |
| Speaker, microphone, signal chain | Audio Path |
| Battery, charging, watchdog | Power & Battery |
| 4G modem, SIM, GPS | Connectivity: 4G & GPS |
| Compute and the V1 “Daylight” story | From Prototype to Product |
Interfaces & contracts
Section titled “Interfaces & contracts”Every subsystem sits behind exactly one owner in software, so the rest of the Rust runtime never talks to a bus directly:
- Display — driven from userspace over SPI by the UI host itself; there is no kernel display stack (no framebuffer device, no DRM/KMS) by choice.
- Audio — two software paths, one codec: the media worker supervises mpv for playback, the voip worker runs calls through Liblinphone, and both converge on the WM8960 via ALSA.
- Power — the power worker wraps
pisugar-serverfor telemetry and RTC, and feeds the hardware watchdog directly over I²C. - Radio — the network worker owns the SIM7600 over its serial port and supervises the pppd process that turns a registered modem into an IP link.
The as-built docs site (docsite/website/ in the repository) documents the current
wiring of each subsystem in depth.
Today vs. target
Section titled “Today vs. target”V0 “Dawn” is explicitly a prototype path, not a permanent promise: off-the-shelf hardware chosen to iterate on the experience before committing to a board spin. The target is V1 “Daylight” — a designed PCB with components picked and soldered per the product design, which may integrate its own display, audio, power, and modem choices. What is fixed by intent rather than by the prototype: one button, a small calm portrait screen, speaker plus microphone, 4G plus GPS, and no camera. The migration story — including the EVT → DVT → PVT build stages — lives in From Prototype to Product.
Open questions
Section titled “Open questions”- Which spec-table values can we commit to publicly now, and which stay TBD until the V1 board is designed?
- Do Wi-Fi and Bluetooth appear in the product spec at all, or is 4G the only radio we promise? (They exist on the Pi’s SoC but sit outside the documented path — drawn dashed in the diagram.)
- What enclosure durability targets (drop, water resistance) does a kids-carry-it-daily device need to state?