Building a UWB RTLS or a UWB-enabled consumer device is rarely a straightforward firmware project.
UWB operates across a narrow band of specialist knowledge: IEEE 802.15.4z protocol stacks, Scrambled Timestamp Sequences (STS), chip-specific timing calibration, FiRa interoperability certification, and RF environment mitigation that no textbook fully describes. Most embedded development firms can write firmware. Very few have shipped UWB in production.
The result is a recurring mid-project failure mode. A company engages a capable-looking firmware house, discovers six months in that nobody on the team has attended a FiRa interoperability event or debugged an STS mode mismatch, and has to start again: often after spending a significant budget and losing a product launch window.
This guide gives engineering leaders and CTOs a structured method for evaluating UWB development partners before the contract is signed, and the specific questions that surface experience claims that do not hold up. Evaluating UWB-specialist firms is different from comparing the top RTLS companies or system integrators: the criteria here are specific to software development depth, not deployment footprint.
Why UWB development is harder to outsource than general embedded firmware
UWB is not a feature you add to a product; it is a system discipline. Accurate ranging depends on the correct configuration of dozens of interdependent parameters: channel selection (channel 5 or channel 9), preamble code, STS length, antenna delay calibration, and the ranging message exchange sequence (SS-TWR, DS-TWR, or TDoA). A firm that has experience with Bluetooth or Wi-Fi firmware is not automatically equipped to handle these.
Three factors make UWB expertise unusually hard to fake.
Protocol stack depth. The FiRa Consortium’s UC specification defines session management, ranging parameter negotiation, and error handling in detail. A real UWB team can explain the difference between DL-TDoA and UL-TDoA, tell you which FiRa controller/controlee role applies to your hardware, and describe how BLE is used as an out-of-band channel to set up UWB sessions. A team that has read the spec but not implemented it tends to speak in generalities.
Chipset specificity. The Decawave DW3000, Qorvo QM33/QM35, and NXP SR040 each expose UWB functionality through different driver architectures, register maps, and timing quirks. Calibration procedures that work on a DW3000 do not transfer directly to the QM33. A firm that lists “UWB experience” but has only worked with one chipset is poorly positioned to advise on platform selection or migrate a codebase between chips when supply chain demands it.
Interoperability testing reality. Interoperability events, run by FiRa and (for automotive access) the Car Connectivity Consortium (CCC), are the only reliable way to validate that a UWB implementation actually works with devices from other vendors. The event format involves real hardware from 10–20 companies being tested pairwise. Teams that have participated know which corner cases break interoperability; teams that have not are discovering those issues for the first time in your lab.
7 criteria for evaluating a UWB development partner
1. Protocol expertise: ask for specifics
The fastest way to distinguish surface-level knowledge from engineering depth is to ask protocol-specific questions in the initial technical call.
Ask the candidate firm to:
- Describe the ranging message exchange in DS-TWR and explain why it corrects for clock drift errors present in SS-TWR
- Explain what STS modes 0 through 3 differ in, and which mode is required for FiRa compliance
- Describe how a FiRa controller initiates a UWB session, including the role of BLE OOB and the SESSION_KEY derivation
A team that has implemented these sequences can answer from memory. A team that has read the spec but not written the code will give vague answers or ask to follow up.
The UWB Alliance, which represents companies across the full UWB ecosystem, notes that the industry is converging on FiRa for industrial and consumer applications and omlox UWB for open industrial positioning, so familiarity with both standards matters depending on your use case.
2. Chipset portfolio: verify with part numbers
General claims about UWB experience are not useful. Useful claims are specific:
- “We have shipped production firmware on DW3000, QM33, and NXP SR040.”
- “We have 9 hardware platform designs across three chipset generations.”
- “We contributed a DW3000 antenna delay calibration fix to a client’s production design.”
Ask for the chipset names. If the firm can only name one chip, their architecture decisions will be biased toward what they know, not what fits your product. If they can name multiple chipsets and describe practical differences between them, they have breadth.
This matters particularly for UWB RTLS projects, where anchor and tag hardware may come from different vendors, and the firmware team may need to work simultaneously with two different chipset APIs.
3. FiRa and CCC interoperability event track record
Participation in FiRa interoperability events is the clearest proxy for production-readiness in the UWB space. These events test whether a vendor’s device can range correctly with devices from a dozen or more other companies using the same spec. A team that has participated multiple times across multiple event locations has been exposed to the full range of real-world interoperability failures: message timing edge cases, STS resynchronization issues, and ranging data format mismatches.
Ask directly: how many interoperability events has your team attended? In what locations? What bugs did you find and fix? The specificity of the answer is more revealing than the number.
Qorvo, a leading UWB chipset vendor, maintains a certified UWB partner directory listing firms that have demonstrated technical qualification across UWB design, engineering, and certification. Being listed there, or holding a formal designation from Qorvo or another chipset vendor, reflects demonstrated technical competence, not just a marketing relationship.
4. IP ownership: read the contract before the proposal
Mid-project handoffs are rarely caused only by technical failure. They are often triggered by an IP dispute that surfaces when a client tries to take the codebase to a different vendor.
The critical questions for any outsourced UWB engagement:
Who owns what, and when? Some contracts assign IP only upon final payment. Others assign incrementally. Some retain a license to reuse developed components in other client projects. You need to understand the IP timeline before month six.
Is source code delivered as part of the engagement? Some vendors deliver binaries with a runtime license, not source. If you need to modify or port the firmware, you want source.
Are there carve-outs for existing IP? A legitimate UWB vendor may have pre-developed code for antenna calibration routines, FiRa session management, or CCC frame handling that they license rather than assign. This is reasonable, but the scope of what is licensed versus what is transferred must be explicit.
What happens if the engagement ends early? Define ownership of all work-in-progress at every milestone.
These questions should be answered in the contract before the engagement starts, not negotiated after a technical disagreement at month eight.
5. Security posture
UWB security is not trivial. Consumer UWB applications (ranging from phone-to-car access to indoor navigation) depend on the Scrambled Timestamp Sequence (STS) mechanism defined in IEEE 802.15.4z to prevent spoofing and relay attacks. Industrial RTLS applications increasingly require tag identity verification to prevent position spoofing.
A partner who takes security seriously can:
- Describe the difference between STS mode 0 (no STS) and mode 3 (AES-128 key-based STS) and when each is appropriate
- Explain how session keys are derived and exchanged in a FiRa-compliant implementation
- Describe the threat model for relay attacks against UWB-based access control
Formal security certification (ISO 27001 for information security management) is a useful proxy for organizational security discipline, particularly when the engagement involves access to proprietary designs or production key material.
6. Debug and test tooling
A UWB development firm’s own tooling tells you a great deal about how they approach hard problems. Protocol-level debugging in UWB requires capturing raw frames at the air interface and decoding them against the specification, a task that standard tools cannot fully satisfy for UWB-specific fields.
Ask your candidate firm what tools they use to:
- Capture and analyze UWB ranging exchanges in real time
- Identify the root cause of a ranging timeout or STS desync
- Automate regression testing of a FiRa session sequence
Firms that rely entirely on chipset vendor evaluation kits and reference software hit a ceiling when issues go beyond what the vendor’s documentation covers. Firms that have built or adapted their own protocol analysis tools (for example, a hardware sniffer that captures raw UWB traffic and displays it in a structured protocol view) are operating at a deeper technical level. For asset tracking RTLS tags in production, the ranging mode architecture also shapes the debug surface: Inpixon’s overview of TDoA versus TWR is a useful starting reference for understanding how the mode choice determines which failure modes appear most often on-site.
7. Production track record
Years in the market and the number of shipped hardware platforms both matter. Ask:
- How many distinct hardware platform designs has your team shipped with UWB?
- What is the oldest UWB product in your portfolio that is still in production?
- Which industries have you shipped in: automotive, industrial UWB asset tracking, indoor positioning with UWB tags, consumer IoT, medical?
Production experience surfaces problems that lab work does not: electromagnetic interference from co-located radios, temperature effects on crystal oscillators used for UWB timing, regulatory certification challenges in multi-region products, and firmware update workflows for deployed tag populations.
Scoring checklist: run this with every candidate
Use this table to score each candidate firm on a 0–2 scale per criterion. 0 = no evidence. 1 = partial or indirect evidence. 2 = direct, specific evidence with verifiable details.
| Criterion | What to look for | Score (0–2) |
|---|---|---|
| Protocol expertise | Can they explain DS-TWR clock drift correction, STS mode differences, and FiRa session setup via BLE OOB from memory? | |
| Chipset portfolio | Do they name at least 2 chipsets they have shipped in production, with specific platform details? | |
| Interoperability events | Have they attended FiRa or CCC events? How many, in which locations, and what issues did they discover and fix? | |
| IP ownership | Does the contract assign all work-product IP to you, with source code delivery at each milestone? | |
| Security posture | Can they describe STS mode selection, AES-128 session key handling, and the relay attack threat model? | |
| Debug tooling | Do they have protocol-level UWB capture capability, beyond chipset vendor tools? | |
| Production track record | Years of production UWB work plus number of distinct hardware platforms shipped? |
Scoring guide: 12–14 = proceed. 8–11 = proceed with additional due diligence. Below 8 = high risk of mid-project failure.
Warning signs that predict mid-project failure
The firm lists UWB alongside dozens of other technologies. A firm that offers UWB, 5G, Wi-Fi, LoRa, and Zigbee with equal prominence is unlikely to have deep expertise in any of them. UWB requires specialist depth.
They cannot name the chipsets they have used. “We have worked with UWB chips” is not an answer. Part numbers are.
They cannot describe a past interoperability failure. Any team that has shipped real UWB has hit an interoperability issue. If they cannot describe one they have fixed, they have not shipped.
IP terms are vague or back-loaded. “IP transfers on final payment” is a risk factor, not a standard term. Milestone-based IP assignment or source code escrow is the safer structure.
No in-house debug tooling. If a firm’s entire debugging workflow is chipset vendor EVK plus UART logs, they will hit a ceiling on complex protocol issues.
No formal certifications. ISO 9001 for development process and ISO 27001 for information security are not guarantees, but their absence in a vendor claiming production UWB capability is a yellow flag.
Consumer UWB and Apple Nearby Interaction: a separate evaluation dimension
Consumer UWB is expanding fast. Apple’s Nearby Interaction framework supports FiRa-compatible UWB sessions between iPhone (U1/H1 chip) and certified accessories, meaning your UWB accessory’s ranging stack must interoperate correctly with Apple’s session management and ranging data format. If your product targets the consumer market, ask your candidate firm whether they have implemented or tested against Apple Nearby Interaction on real hardware. Many firms have not.
This is not a trivial qualification. The FiRa-compatible profile used in Apple’s framework specifies session setup, ranging data format, and notification semantics in ways that differ from a generic FiRa TWR implementation. A ranging timeout in the lab against an iPhone often comes from a session parameter mismatch, not an RF problem.
How to structure the engagement itself
Even with the right partner, engagement structure reduces risk.
Start with a proof of concept, not a full project. A 4–8 week POC that demonstrates ranging accuracy on your target chipset in your target RF environment de-risks the technical assumptions before the main engagement begins. You discover scope unknowns while the cost is still small.
Milestone-based IP transfer. Assign IP at each milestone, not only on final delivery. This protects you if the engagement terminates early.
Embedded team, not staff augmentation. For UWB projects, you want a team that collectively holds the protocol expertise, not individual contractors who may leave mid-project. A senior UWB engineer, a junior engineer, and a test engineer working as a unit outperforms three individuals in most scenarios.
Define test criteria upfront. What does “ranging accuracy of ≤15 cm at 20 m in a warehouse environment” mean as a test? Specify it before the Statement of Work is signed. Vague success criteria are the source of most technical acceptance disputes.
needCode’s position in this landscape
needCode (Kraków, Poland) is a specialized UWB embedded software partner with a team that has been building production UWB indoor positioning systems for over 8 years. Their Qorvo Official Partner status reflects demonstrated technical competence against Qorvo’s certification requirements. The team has participated in 5+ FiRa interoperability events across two continents and holds ISO 9001 and ISO 27001 certifications.
Chipset coverage includes QM33, QM35, DW1000, DW3000 (Qorvo), and NXP SR040, spanning three chipset generations. The UWB Sniffer, available from needcode.io, reflects in-house protocol analysis tooling built from real protocol-level work rather than from documentation alone. Service offerings span UWB RTLS development, UWB positioning system design, SDK development, proof-of-concept phases, and structured UWB workshops for teams building internal expertise.
Against the scoring checklist above: specific chipset history, verified interoperability event track record, ISO 27001 security certification, and proprietary debug capability. Whether or not needCode is the right fit depends on your specific requirements, but those are the criteria to apply to any firm you evaluate.
needCode provides UWB development and RTLS engineering services for teams building production UWB positioning systems, consumer ranging accessories, and automotive digital key implementations. If you are evaluating UWB development partners and want to run through the checklist above with a team that has shipped across TDoA, TWR, and AoA architectures, we are happy to talk. Book a free discovery call or get in touch.
Frequently asked questions
UWB requires deep knowledge of specific protocol stacks (FiRa, CCC, omlox UWB), chip-specific firmware across platforms like DW3000, QM33, and NXP SR040, and hands-on experience from interoperability events where real hardware from different vendors is tested together. General embedded firmware experience does not transfer automatically to protocol-level UWB work.
There is no magic number, but at least two to three events across at least two spec versions is a meaningful signal. Firms that attended only one event, or attended years ago without recent participation, may not be current on the spec revisions that affect interoperability today.
IP should transfer to the client at each milestone, not only upon final payment. Source code (not just binaries) should be delivered at milestones. Pre-existing IP (libraries, calibration routines) should be explicitly identified and licensed separately. Work-in-progress ownership in case of early termination must be defined before the engagement starts.
At minimum, the ability to capture and decode raw UWB frames at the air interface. This goes beyond chipset vendor SDK tools and requires either a purpose-built hardware sniffer or deep integration with custom capture hardware. Without protocol-level debug capability, diagnosing STS desync, ranging timeout, and interoperability failures is significantly harder and slower.
A Qorvo Official Partner designation requires demonstrated technical competence across UWB design, development, and certification against Qorvo’s program requirements. It is not a reseller or marketing relationship. A general firmware contractor with no chipset vendor partnership has made no verifiable technical commitment to UWB depth.
Further reading
- Basics of UWB Indoor Location Systems (Indoor RTLS): system-level context for UWB RTLS architecture and ranging mode selection
- UWB Sniffer Buyer’s Guide (2026): evaluation guide for protocol analysis tools used in UWB development
- Best UWB Ranging Mode for RTLS (2026): TDoA vs TWR vs AoA ranked by use case and infrastructure cost
- Dedicated Development Center for RF Solutions: Qorvo Case Study: how embedded partnership models work in practice
