Wi-R reference designs — smartglasses and tactical headset

01Why this, and why now

The technology objection was answered: the BAN part in production, the near-field part close behind, the dev kit reliably producing a working link in a day. What had not moved was conversion — teams impressed in week one were quiet by week ten, consistently enough to be structural.

The commercial stake is straightforward. An evaluation that stalls between datasheet and prototype is not a slow design-in, it is a lost one — the engineer who championed us gets reassigned, and the next conversation starts in a colder room. Three options were on the table, scored against the same 27 stalled evaluations.

The two verticals bracket rather than represent. Video smartglasses is high-volume consumer, where cost and size dominate; a tactical headset is low-volume ruggedized, where certification and reliability dominate. An OEM between them finds themselves in one of the two.

02The problem as people experienced it

I took every evaluation that had gone quiet for more than sixty days — 27 of them — and reconstructed which stage it died at. Not why the partner said it died, which is usually “deprioritised”, but what they were trying to do the week before they stopped.

The reframe: we had been treating this as a sales conversion problem and staffing it with more contact. It was an engineering capability problem in the partner’s building, and no amount of attention transfers a skill — only a design they can copy does.

03My role and approach

This is the program where a delivery lens most visibly turns into a product one. The founder owned which markets mattered and why Wi-R belonged there. I owned what the designs became: which two verticals we built, what “done” meant for a design an OEM could copy, and when it was allowed out.

That last one was the fight. A reference design is finished when someone outside the building reproduces it, not when it works on our bench — so release gated on evidence from partner hardware, putting the date in other people’s hands.

Key decisions

• Two verticals that bracket, not two that are representative. Consumer volume and ruggedized spec sit at opposite ends of the integration questions. A middle-of-the-road third design would have answered fewer questions than either extreme.
• Release the layout, not just the schematic. The stalls clustered on electrode layout, exactly the file a hardware team is most reluctant to publish. Withholding it would have made the package answer the wrong question.
• Done means an outsider reproduced it. Release gated on a partner building the design on their own hardware and reaching a working link. Internal demos prove a design works; they cannot prove it is copyable.
• One firmware tree with build flags, not two. Two vertical-specific trees drift within a quarter and double the surface a small team maintains. Shared code with flags is the only version still current two years later.

04What I cut

The medical design was the hardest cut, and it had the clearest demand behind it. It failed on two constraints: electrical safety expectations mean anticipating isolation requirements we had never characterised, and the lead time to do that credibly ran past the window the other two needed. Every active design also carries a permanent support cost — three designs against three applications engineers meant all three maintained badly. An application note on isolation covers it, and the dev kit carries that segment.

05How I got it agreed

The hardware lead did not want the layout published. His objection was not territorial: the electrode geometry and its ground treatment are the part of a Wi-R design that takes real skill, they are not covered by anything we had filed, and publishing them hands a competitor the one thing they cannot reverse-engineer from a datasheet.

I could not argue the risk away, so I argued about what the package was for. A design that withholds the layout answers “does this work”, which the dev kit already answered, and leaves untouched the step where 13 of 27 evaluations died. Held back, it would be a marketing asset with a support cost.

He agreed, with one condition. Every released package ships with the exact validated BOM including tested substitutions, and any change forces a versioned re-release rather than a quiet file swap — a partner building from a stale layout is a support incident that looks like a silicon fault. The obligation is permanent, and it has no owner outside my program.

06What was built

Two complete, copyable designs. The smartglasses design streams compressed video off a head-worn device all day on a battery a consumer product can carry. The tactical headset carries voice between a headset and a body-worn radio with no over-the-air emission to locate. Both ship as schematic, layout, validated BOM and firmware.

1. 1Electrode placement is fixed in the enclosure, not left to the integrator. Thirteen of 27 stalls died on electrode layout. Specifying it inside a real enclosure is the difference between a design you copy and a design you interpret.
2. 2The BOM lists tested substitutions, not just preferred parts. The concession from section 05. A partner who cannot source our exact part now has a characterised alternative instead of a guess.
3. 3Firmware is the shared tree with a vertical flag. Two trees would have drifted inside a quarter. One tree means a fix for the tactical design reaches the smartglasses design automatically.
4. 4Released only after an outside team rebuilt it. The gate that put our date in a partner's hands, and the only evidence that a design is copyable rather than merely correct.

Ixana all-day video streaming smartglasses reference design, from Ixana's published product imagery. The design's existence and description are public and a demonstration video is linked above; schematic, layout and BOM are not shown. Happy to walk through the real program in a conversation.

07Tradeoffs

08Impact and outcomes

We agreed before starting that a reference design failed if a team outside Ixana could not reproduce it from the released files alone, without a call. That is a harsh bar and the only one that distinguishes a design from a demonstration. The guardrail was support hours per evaluation: reach bought by drowning three engineers is a bill arriving later.

How we counted. An active evaluation is one where a named engineer has requested design files and has hardware on order or in hand. Teams holding a dev kit without a project, or that only asked for pricing, are excluded — both were counted before this program, inflating the number while explaining none of the conversion. The nine period design-ins are the same nine on the dev-kit page; six cite a reference design, so the figures overlap by construction and must not be added.

Released package — schematic (PDF and source) · 4-layer layout with electrode geometry fixed · validated BOM with tested substitutions · shared firmware tree, per-vertical build flags · smartglasses design on the BAN line with compressed video · tactical design on the BAN line, PTT audio profile · electrode placement guidance per enclosure

09What I'd do differently

I gated release on an outside rebuild, then chose the outside team from people who already liked us. Both first rebuilds succeeded — which felt like validation and was closer to a formality, because a team already invested pushes through ambiguity a neutral one would file as a defect. The gate was right, the sample flattering; the rebuild should come from an evaluation not yet committed.

I would also have published the mechanical guidance as a first-class file rather than notes inside the layout package. Electrode placement in an enclosure is the second-largest stall cause, and it sits in a document people open after making the mistake.