Why LOUP Is Speakerphone-First Instead of a Small Smartphone
Removing the browser, camera and text stack changes both the product and the firmware architecture.
TOPIC
Lessons, explainers, experiments, and implementation notes.
Removing the browser, camera and text stack changes both the product and the firmware architecture.
Contact approval has to be enforced by backend identity and call routing, not only hidden buttons.
Hard-coding one PBX would turn infrastructure choice into a firmware release dependency.
Sharing SIP credentials across devices makes revocation, auditing and fleet diagnosis ambiguous.
Factory, pairing, active, blocked and retired are operational states with different permissions.
Identity and parental policy should not be embedded inside SIP routing rules.
Product restraint changes threat modeling as much as it changes UX.
A voice device should remain operable when the display is slow or partially refreshing.
Hardware development and firmware product logic have different long-term ownership requirements.
A stable voice path is more valuable than several new features built on a regression.
Observed flash and PSRAM capacity define what the build and runtime can actually support.
Speaker output and microphone capture travel through different codec responsibilities.
AEC depends on what signal actually lands in each TDM slot.
Power rails that are not part of the design should not be left in an accidental state.
Short current transients can make a stable-looking digital design fail under real audio and radio load.
A digital LED can still sit on an analog margin problem.
A screwed back plate makes battery replacement possible but also affects sealing, state retention and service procedure.
One external connector does not remove the need for reliable programming and recovery access.
One wrong GPIO can imitate a codec, driver or clocking failure.
Acoustic complaints have to be separated into source, amplifier, transducer and enclosure effects.
MCLK, BCLK and LRCK have to agree before higher-level audio debugging means anything.
Sample-rate conversion is audible when the implementation is crude or placed in the wrong part of the pipeline.
More buffering reduces underruns until it starts creating latency and hiding drift.
RTP arrival time should not directly schedule the speaker.
DMA behavior after underrun can shape what a user hears during gaps.
A slider value is meaningless until every digital and analog gain stage is mapped.
A clean frequency response is irrelevant if the playback path periodically stops feeding samples.
A 30-second audio test can pass while two clocks slowly walk apart over several minutes.
Short audible failures can be network gaps, scheduling gaps or local conversion artifacts.
Listening tests become more useful when the input and operating point are controlled.
An echo canceller cannot remove playback it never receives as a reference signal.
Turning processing off can reveal whether the artifact is created before, inside or after the algorithm.
A bad experimental build can be valuable when it changes a small set of variables and is easy to revert.
More signal processing is not automatically better audio.
AEC has finite cancellation authority when the speaker physically couples strongly into the microphones.
A delayed copy of far-end speech and an unstable acoustic loop require different diagnosis.
A valid reference that arrives at the wrong time can be almost as useless as the wrong reference.
The first seconds of a call should not depend on whatever history remains in DSP buffers.
Processed audio alone hides whether the wrong signal entered the algorithm.
A speakerphone must handle the user talking while the far end is also active.
A successful REGISTER proves more than network reachability because it joins device credentials to PBX state.
Call setup includes dialog state, SDP negotiation and route continuity after the first request.
A SIP call can connect perfectly and still carry no useful audio if the negotiated media description is wrong.
Media cannot be debugged reliably if the firewall and PBX disagree on where RTP is allowed.
If one side hears audio, several parts of the media path are already proven.
Burst timing can hurt a speakerphone even when aggregate RTP loss is close to zero.
Transport choice should match the test objective before adding more complexity.
A call that starts and carries audio but does not terminate cleanly can leak state across the device and PBX.
Telephony credentials are runtime configuration, not compiled product identity.
A real endpoint pair exposes assumptions hidden by softphones and local echo tests.
The first PBX needed to be inspectable, scriptable and easy to correlate with packet captures.
Named test identities make repeatable call scenarios easier to describe and automate.
External ingress adds routing and policy that a local PBX call does not exercise.
Server scheduling can inject media timing problems even when embedded firmware has not changed.
Packet timing only becomes actionable when it is tied to endpoint tolerance.
A LAN test still exercises SIP, RTP, codecs and clocks while excluding WAN variability.
A green registration table can coexist with broken dialog routing or media.
Asterisk should route calls, not become the only database of parent-approved relationships.
Fleet size introduces registration churn, simultaneous calls and operational visibility that a pair cannot show.
Linphone provides a known endpoint for separating PBX problems from embedded endpoint problems.
A factory-fresh device has to join a trusted network before any cloud or PBX workflow can begin.
Scanning a code is useful only if the backend can prove which unit and account the ceremony joins.
Per-device PBX credentials should be provisioned after identity is established, not cloned into every unit.
A board leaving production and a consumer device waiting for ownership are not the same operational condition.
A backend revocation is ineffective if the device keeps registering and calling because local state still says active.
Moving a device between accounts needs an intermediate state while old and new authority are resolved.
Some firmware updates are optional improvements; others must gate service because compatibility or security changed.
A backend cannot manage a fleet from a last-seen timestamp alone.
Convenient shared bootstrap secrets create the largest possible blast radius.
A device that loses power or Wi-Fi halfway through setup should not become permanently ambiguous.
An old build can be more useful than a new branch when a regression removes the reference point.
A release is stronger when the exact app image and the source snapshot both survive.
Updating only the application partition avoids rewriting unrelated state during tight firmware experiments.
Booting the new partition once is not enough to declare it safe.
Transport security alone does not prove an artifact should be trusted after download.
Returning to an older binary is unsafe if the newer release already changed data the old code cannot read.
A release that works on one device should not silently become the fleet default.
Old local status text can outlive the release that originally produced it.
Calling a release STABLE while its channel remains canary creates two sources of truth.
A successful download is not the same thing as a successful deployment.
Portrait monochrome e-paper rewards stable hierarchy and punishes unnecessary redraws.
A UI transition has a display cost, so redraw scope becomes part of firmware design.
Infinite scroll plus push maps naturally to small menu selection when the display is not interactive.
Critical in-call actions should not require navigating back to a menu.
A single status light can become confusing if color, blink and priority are not treated as a protocol.
The user must see caller identity before deciding whether to answer, despite slow display behavior.
During a call, the screen is for confirmation and control feedback rather than continuous content.
A physical button needs visible confirmation without forcing a page transition.
Tiny icons can imply precision the underlying measurements do not actually support.
Prototype hardware can be adapted in firmware without turning the prototype limitation into the final product.
Microphone count changes acoustics, PCB, enclosure, DSP assumptions and factory test.
Speaker, microphone, buttons and battery access all create splash-resistance paths.
A polished render can validate product communication while an ugly prototype answers technical questions.
A prototype phase name is useful only when the team knows what evidence graduates the build.
Flashing firmware is only one step in turning a PCB into a managed product.
Production fixtures need a recovery path below the application firmware.
Remote descriptions of sound are not enough when hardware, assembly and enclosure can all differ.
Fleet growth should happen after the representative call path is stable on real hardware.
A worker saying a unit sounds fine cannot be the only acoustic acceptance criterion.
Teams move faster when hardware decisions and application decisions meet at explicit contracts.