Visibility
Large enough to read from bed without turning the interface into a giant phone screen.
PROJECT / 01
← Selected Projects
PERSONAL ENGINEERING · HARDWARE · SOFTWARE · HUMAN-CENTERED DESIGN
DexcomFrame
Technical architecture + source notes ↓
A small problem at bedtime became a display on the wall.
A bedside glucose display built around one very ordinary moment: important information existed, but it was always one phone screen away.
SCROLL TO ASSEMBLE ↓
01 / PROBLEM
THE ORDINARY MOMENT
The phone was right there. That was exactly the problem.
At night, my girlfriend would sometimes ask me to hand her phone over so she could check her glucose. The information already existed. Dexcom was already collecting it. But the information was trapped inside a device that had to be reached for, unlocked, and checked.
That led to a simple question: what if the number was just visible?
This case study uses synthetic demonstration values only. No real glucose data is shown.
NORMAL
9:42 PM
112→
SEPTEMBER 7
Sometimes the first engineering drawing is just a better question.
02 / HARDWARE
FROM IDEA TO OBJECT
A screen, a Raspberry Pi, some wiring, and a frame.
Coming up with the idea itself and coding it was one engineering problem. Installing the actual hardware together was another. I had to figure out how to make all of the pieces fit.
017-inch TouchscreenDisplay surface
02Raspberry PiCompute + kiosk
03WiringPower + display
04Shadow BoxFinished enclosure
The biggest problems were yet to come
OBJECT → BEHAVIOR
INPUTS
Glucose112 mg/dL · steady
TimeMorning · day · night
WeatherClear · cloud · rain
STATE ENGINEClassify the moment.Prioritize the reading, choose the right tone, and assemble only the context that helps.
SCENE OUTPUT
NORMAL112 →SEPTEMBER 8
The frame was built. Now it needed to think.
The physical object solved visibility. The next problem was deciding what the display should do.
03 / SOFTWARE
THE SECOND HALF OF THE BUILD
The hardware made it visible. The software made it useful.
The display became more than a large glucose number: it needed state logic, time-aware presentation, weather context, graph history, and a UI that could be understood from across the room.
dexcomframe / scene-engine.js
function renderScene(glucose, trend, time, weather) {
const state = classify(glucose, trend);
const scene = compose({ state, time, weather });
display.update({
glucose,
trend,
history,
scene
});
}SIMULATED DEVELOPMENT VIEW · PLACEHOLDER
04 / SYSTEM
HOW THE PIECES TALK
From glucose reading to something understandable at a glance.
01CGM DataGlucose + trend
→
02Data LayerRetrieve + normalize
→
03State EngineClassify + compose
→
04Pi DisplayRender + update
Design principleThe number is the priority. Everything around it exists to make the number easier to understand, not harder to see.
05 / ITERATE
REVISION CLOUDS
The interesting part was everything that didn't work the first time.
Night behavior
Reduce visual activity at night while keeping the information useful and accessible.
State changes
Different glucose conditions needed to feel meaningfully different without becoming alarming or chaotic.
Reliability
A bedside display only works if it behaves like an appliance instead of a development project.
Working software was not the finish line. Each failure became another mark on the drawing.
The drawing got quieter as the product got clearer.
06 / HARDWARE IN CONTEXT
A PUBLIC HARDWARE STUDY
Designed to disappear into the room until the information matters.
07 / TRY IT
INTERACTIVE EXHIBIT · PORTFOLIO EDITION
A slice of the real DexcomFrame.
This simulator reuses real presentation assets from DexcomFrame project files. Glucose is synthetic. Live weather is optional through the controls. Personal modules, menus, audio, device controls, and private data are not included in this build.
LIVE ENVIRONMENTOptional live weather · manual controls active
2:14 PM
SEPTEMBER 7
74° · CLEAR
112→
NORMAL
SIMULATION CONTROLS
The controls are outside the device intentionally. The public simulator has no hamburger menu or access to private DexcomFrame modules.
CURRENT SCENENormal · Day · Clear
08 / RESULT
BACK TO THE ORIGINAL PROBLEM
Now she doesn't have to ask.
The project started with a tiny inconvenience. The interesting part wasn't making a Raspberry Pi display—it was noticing that the inconvenience was a design problem in the first place.
That's the part of engineering I tend to carry with me outside of work: seeing systems, noticing friction, and wondering whether something could work a little better.
SYSTEM DESIGN / DEXCOMFRAME
A display is only as trustworthy as its state.
The hardware makes the information visible. The software has to explain whether that information is current. Those are separate engineering problems.
01 / ACQUIRELocal data service
The reviewed Node.js service uses a persistent Python Share bridge. The older Flask OAuth server is a separate sandbox experiment.
02 / INTERPRETDisplay state
Browser JavaScript selects reading, trend, freshness, weather and nighttime presentation. A stale state must stay distinct from an ordinary reading.
03 / PRESENTPi + touchscreen
The kiosk interface renders the display. A separate PiDex companion project provides cloud synchronization work; it is not connected to this portfolio.
| Area | Evidence status | What the source supports |
|---|---|---|
| Interface states | Observed in local source | Normal, high, low, urgent-low, falling-fast, stale and night-related scene logic. |
| Hardware + weather | Observed in local source | Raspberry Pi display, touch controls and weather-aware presentation. Desktop source and device runtime may differ. |
| Reliability work | Open engineering concern | A prior source review records timestamp validation, timer ownership and acquisition caching as work needing attention. No reliability certification is claimed. |
Design decision
The most consequential design choice is to keep acquisition, freshness, and visual mood separate. A reassuring scene should never substitute for a valid timestamp. Consolidating polling and preserving original sample time are sensible next steps, subject to validation in the application itself.