Wi-R NFE — XA-NFE2001

01Why this, and why now

The commercial question was whether Ixana was a one-line company. A single line makes every investor and large-customer conversation about concentration risk, and puts one thing on the roadmap. A second line answers both — and a second line that slips adds an execution problem to the concentration risk.

The buyers were already there, and they were not asking for a body-area network. A secure-payments device maker and an industrial-handheld OEM wanted the same thing: move a firmware image between two devices held near each other, without an exposed port and without lighting up a radio. Their incumbent was NFC, and what they disliked was the clock.

That chart is the argument for a second line. Neither incumbent is bad; each is bad at a different half of a transaction these segments perform hundreds of times a day.

02The problem as people experienced it

I did not run a study for this one. I coded eighteen months of inbound evaluation requests by what the sender actually wanted to do, because a request for a body-area part from someone describing a payment terminal is a demand signal for something we had not built.

The reframe: we had been reading this as poor qualification by the sales team. It was demand for a different part, arriving in the only vocabulary available to people who had seen one page of our website.

03My role and approach

The split is the same as on the BAN program: the founder owned the bet that a near-field line should exist and what it was for; I owned the delivery system that made it a part — the same five functions across two sites, now running two silicon programs against one pool of validation capacity.

Running two lines is where delivery fed product hardest. Shared validation capacity forced the range decision below, and the interop matrix we could afford set how configurable the part could be. Those were settled as scheduling questions, and they shaped the datasheet.

Key decisions

• Make the second line boring wherever it can be. Host interface, driver model, provisioning flow and test fixtures were reused from BAN rather than redesigned. A second line proves the company only if it arrives on time.
• Three characterised range profiles, not a continuous knob. Range is the NFE product variable, and every extra setting multiplies an interop matrix somebody has to sit at a bench and run.
• BAN keeps its dates; NFE is scheduled into the gaps. With one validation pool and two programs, either both slip or one has priority. I made that explicit up front rather than discovering it in month four.
• Sell it against NFC, not against Bluetooth. Requests arrived describing NFC’s limits, so the datasheet, comparison figures and launch material all answer NFC. Choosing the comparison is choosing the buyer.

04What I cut

Runtime-adjustable range was the hardest cut, and the one partners asked about most. A continuous knob the host could turn is obviously useful — tight for a payment, open for a bench transfer. It failed on validation capacity already split with BAN: every additional setting multiplies the interop matrix, and we could afford twelve configurations, not sixty. Three profiles cover the cases the inbound requests described; a partner needing a fourth gets it characterised in a later revision rather than finding at integration that nobody tested theirs.

05How I got it agreed

The COO would not commit a build plan for a second line on gen-1 demand signal. His objection was capital: committing wafer starts and package tooling for a part with no shipped revenue, on the strength of inbound emails, looks obvious beforehand and reckless in a quarter where BAN needs the same money.

I had been arguing that the demand was real, which is unfalsifiable and therefore useless. So I made it falsifiable: we converted the 96 coded requests into a sample-request commitment — before any long-lead spend, that population would formally request samples against a spec sheet with a price on it. Interest that survives a form and a price is a different signal.

104 requests came back — eight of the 96 companies asked from two teams, which is how 96 coded requests produce 104. He committed the build plan, with a condition I had not planned to offer: the second line gets its own line in the capital plan, so if NFE underperforms it is visible as NFE underperforming. Every subsequent conversation about a third line has been shorter for it.

06What was built

A near-field transceiver moving 5 Mbit/s between two devices at touch to decimetre range, under a milliwatt, sub-millisecond, with no radiated RF. It couples through a contained electric field rather than a magnetic one, which buys both the throughput and the range NFC lacks while keeping what buyers came for: nothing to intercept from across the room.

1. 1Same host interface as the BAN part. A partner already evaluating BAN can bring this up against a driver they have. Reusing it cost us a cleaner interface design and bought a second line that shipped on schedule.
2. 2Range is a provisioning-time profile, not a runtime register. The cut in section 04, visible in the part. Three profiles are characterised; a fourth would have been untested silicon wearing a tested part number.
3. 3No antenna, no matching network on the reference layout. Electric-field coupling removes the component most likely to differ between our board and a partner's, which is where interop usually goes wrong.
4. 4Marked as a distinct family, not a BAN variant. Internally it shares most of its lineage. Publicly it had to read as a second product line, because that was the argument the part existed to make.

Ixana XA-NFE2001 package, from Ixana's published product photography. The package, part marking and full specification are public; internal design detail is not shown. Happy to walk through the real program in a conversation.

07Tradeoffs

08Impact and outcomes

Before the build plan was committed we agreed the line failed on one condition: if the part could not hold a link across the majority of host and range configurations on hardware we did not design, it was a demo, not a product. The BAN program was the guardrail — a missed BAN milestone while the second line spun up meant NFE was being paid for out of the first.

How we counted. A configuration passes when 34 of 40 attempts establish and hold a link for ten seconds on hardware the partner built — the reference board is excluded deliberately, being the one platform guaranteed to work. Design-ins count NFE-line evaluations including direct silicon engagements, a wider population than the dev-kit page’s kit-mediated figure. Latency here is the 0.6 ms median on partner hardware; the 0.9 ms on the XA-NFE3001 page is the worst-case characterisation figure a requirement line is scored against.

Part configuration — XA-NFE2001 Wi-R NFE transceiver · up to 5 Mbit/s · under 1 mW at full rate · three provisioning-time range profiles across 5–25 cm, up to 1 m at reduced rate · sub-1 ms end-to-end latency · RF-silent electric-field coupling · host interface and reference driver shared with the BAN line

09What I'd do differently

I let the interop matrix be sized by what we could afford rather than where risk was. Twelve configurations was a capacity number, not an analysis, and the cell that failed was predictable from first principles — slowest host, longest range. An hour of thinking would have spent the same twelve slots on the twelve riskiest combinations instead of a tidy four-by-three grid.

I would also have run the sample-request test earlier. It settled section 05 in a fortnight, and I reached for it only after two months of arguing that demand was real. The instrument that turns an unfalsifiable claim into a number is usually cheap.