Hardware OEM programmes that stall at the wireless layer usually don’t fail because the development partner lacked engineering skill.
They fail because the partner’s skill was in the wrong domain. A firm that has built hundreds of BLE-connected consumer products may never have implemented a UWB ranging algorithm, navigated a Bluetooth SIG QDID process, written a BLE Mesh stack, or fused wireless positioning data with IMU and LiDAR odometry. Those are separate disciplines, and a standard embedded software RFP rarely surfaces the difference until a programme is already six months in. This is the core risk in embedded software development outsourcing: the partner’s skill domain may not match the programme’s actual wireless requirement.
This checklist covers eight capabilities that separate a wireless specialist from a general embedded house. Each section describes what the capability is, which OEM scenarios require it, and what to ask a prospective partner to establish whether the capability is real or assumed. Where needCode’s position on that capability is directly relevant, it is stated with specific evidence.
The scenarios used throughout are automotive / Software Defined Vehicle (SDV), robotics and humanoid autonomous systems, and defence / NATO programme supply chains: the three ICP contexts where a wireless capability gap is most costly.
How to use this checklist: Work through each capability section and mark it Red (gap), Amber (partial), or Green (confirmed) for your prospective partner. A Red on capabilities 3, 4, or 7 is a hard stop for automotive, robotics, or defence programmes respectively. An Amber on any capability is a scoping question for a discovery call before contract signature.
Capability 1: Multi-protocol firmware architecture (BLE + UWB + WiFi/Matter on a shared platform)
What it is: The ability to build and maintain firmware that runs multiple wireless protocols concurrently on the same SoC or across a co-processor architecture: BLE 5.4/6.0 for short-range data and human interaction, UWB IEEE 802.15.4z for precise ranging and positioning, WiFi for cloud offload and high-throughput data, and Matter/Thread for industrial IoT connectivity and home automation mesh, without the protocols causing coexistence interference that degrades performance or certification compliance.
Why it matters and which scenario it affects: An automotive SDV platform typically runs BLE Channel Sounding for keyless entry alongside WiFi 6E for OTA updates and, increasingly, UWB for fine-grained spatial awareness. A humanoid robot needs BLE for human-robot interaction, UWB for indoor positioning, and WiFi for cloud AI offload. In both cases, spectrum coexistence between 2.4 GHz BLE, 5 GHz WiFi, and UWB’s 6.5–8.5 GHz band must be actively managed in firmware. A partner that has only ever deployed a single protocol does not have this experience.
The Nordic Semiconductor nRF54H20, for example, integrates Bluetooth LE, Thread, Matter, and 2.4 GHz proprietary radio in a single SoC. Nordic’s nRF54H20 product page describes the multi-application processor architecture and radio coexistence design: the kind of platform where multi-protocol firmware architecture is not optional but foundational. A partner without hands-on bring-up experience on silicon like this will need time to build it on your programme.
Validation questions:
- Which wireless protocols have you run simultaneously on a single SoC in a shipped product?
- What coexistence mechanism do you use between 2.4 GHz BLE and UWB in the 6–9 GHz band?
- Can you describe a specific instance where a coexistence issue appeared in a product and how it was resolved in firmware?
What good looks like: A specific answer naming the SoC, the protocols co-deployed, the coexistence challenge encountered, and the firmware-level resolution. A vague answer about “multi-protocol IoT experience” is not the same as hands-on BLE/UWB/WiFi coexistence firmware work.
needCode’s position: needCode covers BLE 5.4/6.0, UWB, WiFi 6E/7, and Zigbee/Matter concurrently, with multi-radio coexistence as a documented engineering capability on the robotics and edge AI programme pages. Platforms include Nordic nRF54H20, nRF5340, Qorvo QM33/QM35, and Ambiq Apollo5-class SoCs.
Capability 2: Chipset bring-up and SDK depth
What it is: The ability to work at the silicon level: bringing up a new SoC from bare metal, writing or modifying HAL and BSP layers, contributing to or adapting a vendor SDK, and resolving issues at the intersection of silicon errata, RF characteristics, and protocol timing. This is structurally different from application-layer wireless integration, where a developer uses an already-brought-up SDK to implement product features.
Why it matters: Semiconductor vendors that outsource SDK or bring-up work to a development partner are the clearest case where this capability is required. The partner must be able to read silicon documentation, work directly with FAEs from the chip vendor, write driver code, and validate PHY-layer behaviour. An automotive OEM that requires a custom wireless stack for a new chipset generation, or a defence programme that needs a certified wireless MAC on a custom FPGA platform, requires the same depth.
A generalist firmware team working from application-level SDKs cannot do this. The difference typically emerges in week 3–4 of a programme when the partner hits a silicon-level issue the SDK abstraction does not expose.
Validation questions:
- Have you brought up a new chipset for a silicon vendor (not using their SDK to build a product, but contributing to the SDK itself or running the initial bring-up)?
- What was the most complex bring-up or SDK issue you resolved at firmware level in the last 24 months?
- Do you have direct FAE contacts at the silicon vendors you work with?
What good looks like: A partner that has run multiple hardware platform bring-ups for a silicon vendor, has contributed to protocol stack code rather than just consuming it, and can describe specific silicon-level issues (register configuration, PHY timing margin, power management errata) it resolved from first principles.
needCode’s position: The Qorvo dedicated development center programme resulted in bring-up of nine distinct hardware platforms over five years, contributing at the SDK, driver, and protocol-stack level. Engineers from Nordic Semiconductor, Qorvo, TI, and Silicon Labs are part of the team, meaning the platform-level knowledge was built before client engagements began.
Capability 3: Wireless certification pipeline knowledge
What it is: Practical knowledge of how wireless products are certified for market: the Bluetooth SIG QDID process (design qualification, component qualification, listing), FiRa Consortium UWB certification, ETSI/FCC RF type approval, and (for automotive SDV) the security and functional safety frameworks that govern wireless module integration in vehicle systems. This is distinct from understanding the wireless standard in theory. Certification process knowledge means knowing which test cases apply, how to set up the test environment, what the most common failure modes are, and how to resolve them without losing weeks to re-submission.
The AUTOSAR Adaptive Platform defines the software architecture for high-performance automotive ECUs. Firms working on SDV wireless stack integration without AUTOSAR familiarity will encounter this framework at some point in the programme, and not knowing it is a risk, not a learning opportunity on a client timeline.
Validation questions:
- Walk me through the BLE SIG QDID process for a recent product. What qualification path did you use and what were the critical test cases?
- Have you supported a FiRa or CCC digital key certification process?
- For automotive programmes: what is your experience with AUTOSAR Classic or Adaptive Platform integration?
What good looks like: A partner that has taken a product through BLE QDID end-to-end, knows the difference between a design qualification and a component listing, can describe the profile tuning suite (PTS) test environment, and understands how certification relates to the RTOS and BLE stack being used. For automotive, knowing whether the wireless component interfaces with AUTOSAR BSW or runs outside it matters.
needCode’s position: needCode contributed to Bluetooth SIG BLE Mesh specification development and delivered the first commercially certified BLE Mesh stack for the Silvair client. That is specification-level involvement in the certification process, not just test execution. Qorvo Official Partner status for 5+ years includes certification support for UWB chipset programmes.
Capability 4: Sub-13cm UWB indoor positioning and IoT RTLS with NLOS resilience
What it is: The ability to design, build, and deploy a real-time location system based on UWB IEEE 802.15.4z that achieves sub-13cm static ranging accuracy in environments with metallic structures, RF interference, and non-line-of-sight (NLOS) conditions between tag and anchor. This requires understanding of TDOA (time difference of arrival), TWR (two-way ranging), AoA (angle of arrival) as measurement modes; anchor placement optimisation; NLOS detection and mitigation in the ranging algorithm; and calibration in the deployment environment rather than a lab.
The IEEE 802.15.4z standard defines the PHY and MAC enhancements that enable precise UWB ranging. The IEEE 802.15.4z Task Group documentation covers the HRP and LRP UWB PHY enhancements and ranging techniques that a firmware team working on RTLS infrastructure must understand at implementation level, not just the marketing summary.
Why it matters, robotics and defence: A humanoid robot that cannot locate itself within 13cm of true position in a warehouse cannot act autonomously in that space. A GPS-denied UWB tracking and IoT RTLS system for personnel or asset tracking in a NATO operating base requires the same indoor positioning robustness in environments designed to resist RF penetration. In both cases, the difference between a positioning partner and a positioning vendor is whether the team can tune for the actual environment rather than claim the datasheet accuracy figure.
Validation questions:
- What is the static ranging accuracy you have achieved in a warehouse or factory environment with heavy metallic racking?
- How do you handle NLOS between a tag and anchor set when line-of-sight is blocked by machinery or structural steel?
- Which ranging mode do you use for a given deployment (TWR, TDOA, AoA) and what drives the choice?
What good looks like: Specific accuracy figures from real environments (not labs) — what separates the top RTLS companies from those citing datasheet accuracy — named ranging modes with rationale, an explanation of how NLOS is detected and whether it triggers anchor re-selection, fallback to another anchor, or a ranging quality metric exposed to the navigation layer.
needCode’s position: needCode has deployed UWB RTLS with sub-13cm static accuracy across nine hardware platforms, with documented experience in environments containing heavy machinery and metallic structures. The robotics and humanoids service page documents NLOS-resilient anchor infrastructure, TDOA/AoA/TWR algorithm selection, and fusion with IMU and LiDAR odometry as named delivery capabilities.
Capability 5: BLE Channel Sounding and secure ranging
What it is: Firmware implementation of Bluetooth Channel Sounding (introduced in Bluetooth Core 6.0), which enables secure, centimetre-level ranging between BLE devices using phase-based ranging (PBR) and round-trip time (RTT) as a counter-measure against relay attacks. This is the wireless layer underpinning automotive digital key, secure building access, and trusted proximity applications. Automotive embedded systems development services for SDV programmes increasingly require this capability at firmware level, not reference design level.
Bluetooth Channel Sounding uses multi-channel phase measurements across the BLE radio spectrum to calculate distance. The RTT component provides cryptographic protection against man-in-the-middle relay attacks that defeat simpler RSSI-based proximity systems. Implementing this correctly at firmware level (initialiser and reflector role management, CS procedure configuration, result interpretation, and security parameter tuning) requires deep BLE stack knowledge.
Why it matters, automotive and access control: An SDV programme whose wireless security strategy depends on BLE Channel Sounding for keyless entry needs a firmware partner that has implemented the CS procedure, not one that has read the specification. The difference becomes apparent when CS test cases fail in the lab: a partner that has implemented PBR and IBT from scratch can debug them; one that used a reference application cannot.
Validation questions:
- Have you implemented BLE Channel Sounding in firmware (not evaluated a reference design)?
- Which CS modes have you implemented: PBR only, or PBR + RTT (IBT)?
- What CS test cases have you run through the Bluetooth PTS or equivalent, and what were the most common failure modes?
What good looks like: A partner that has implemented both PBR and RTT/IBT modes, can describe the difference in ranging accuracy and security posture between them, and has run the channel sounding test cases in a controlled RF environment. Reference design experience without implementation experience is not equivalent.
needCode’s position: BLE Channel Sounding (PBR + IBT) is listed as a named capability in needCode’s BLE Channel Sounding service page, with implementation on Nordic nRF54H20-class platforms and a documented Trusted Proximity protocol built on top of CS ranging.
Capability 6: Team ramp speed and programme integration model
What it is: The structural ability to deploy a pre-integrated team of engineers (already working together, already familiar with the relevant chipset or protocol) onto a client programme within a defined ramp period. This is distinct from a firm’s ability to hire engineers for a new engagement, which introduces ramp time even if the individual engineers are senior.
Why it matters, hardware startups and semiconductor vendors on compressed timelines: A semiconductor vendor launching three products simultaneously with no spare SDK bandwidth (buyer query 3 in the ICP cluster) needs a team that is operational in weeks, not months. A VC-backed hardware startup with an 18-month runway to production cannot afford a partner that needs 6 weeks to staff and onboard. When you outsource embedded firmware development, the question is not whether a firm has the capability in principle but whether it has a pre-integrated team already working together on similar silicon.
Validation questions:
- If we signed a statement of work this week, when would engineers be running effective design reviews on our codebase?
- Have you deployed as a team (same group of engineers working together) into a programme within the last 12 months, or do you assemble teams per project?
- What does week one look like? What would your engineers do, and what do you need from us to make it productive?
What good looks like: A specific timeline (not a range), a description of the team that would deploy (not hypothetical engineers), and evidence of a prior fast deployment with a similar chipset or protocol. “We can usually ramp a team in 4–6 weeks” without a specific example is not the same as “our core UWB team deployed into a Qorvo SDK programme and was running design reviews in week two.”
needCode’s position: The Qorvo programme demonstrates that needCode scaled from fewer than ten to thirty engineers on one programme over five years without programme discontinuity. The team model is pre-integrated: the same engineers who worked on Qorvo QM33/QM35 platforms are the ones who deploy into new UWB programmes. For hardware startup clients, the needcode.io/calendly discovery call process is structured around same-week timeline assessment rather than a multi-week RFP process.
Capability 7: ISO 27001 and EU data sovereignty compliance
What it is: Active ISO 27001:2022 certification, combined with EU-member-state headquarters, which together satisfy the information security management and supplier location requirements that appear in defence programme supply chains, automotive Tier 1 supplier agreements, and EU data governance frameworks.
Why it matters, defence and NATO: A development partner working on GPS-denied UWB positioning for a NATO programme, or on classified communications firmware for a European defence prime, is handling client IP, source code, and potentially operationally sensitive technical specifications. Most NATO member state defence procurement frameworks require suppliers to be EU-headquartered, with demonstrable information security management and often national security vetting. ISO 27001:2022 is not sufficient on its own, but it is typically a minimum threshold, and partners without it are excluded before technical evaluation begins.
Validation questions:
- Are you ISO 27001:2022 certified, and is the certificate current? Can you share a copy?
- Where are your engineers based, and under which national jurisdiction does your IP handling sit?
- Have you supplied to a NATO programme or EU defence prime before? If so, which procurement framework covered the engagement?
What good looks like: A certificate number and issuing body for ISO 27001:2022, a clear answer on which country’s laws govern the engagement (relevant when source code and specifications are transferred), and ideally a prior defence or government programme as a reference.
needCode’s position: needCode holds ISO 27001:2022 (information security) and ISO 9001:2015 (quality management), both with verifiable certificates published on the website. Headquarters and all engineering operations are in Poland, an EU member state and NATO member, which satisfies the location criterion for most EU defence and NATO programme supply chain requirements.
Capability 8: Sensor fusion and edge ML alongside wireless protocols
What it is: The ability to design and implement firmware that runs a sensor fusion pipeline (combining UWB ranging data with IMU inertial measurements and, where relevant, LiDAR odometry) and executes edge ML inference models on the same SoC or co-processor, without the firmware architecture creating latency or power budget conflicts between the wireless stack and the inference workload.
Why it matters, robotics and autonomous systems: A humanoid robot that relies on a fusion of UWB anchor ranging, IMU pose estimation, and LiDAR-based odometry for indoor navigation is running a real-time computation pipeline where each data source has a different latency, update rate, and failure mode. A firmware partner that can write the wireless layer but has never worked on sensor fusion will hand off the integration at the boundary, and the boundary is exactly where autonomous systems fail. Fusion bugs do not appear in unit tests; they appear when the robot’s position estimate drifts at 0.3 m/s on a metal floor under NLOS conditions.
Validation questions:
- Have you built a sensor fusion pipeline that combines UWB ranging with IMU data (or UWB with LiDAR odometry) in a shipping product?
- Which fusion algorithm do you use and why: EKF, UKF, complementary filter, or a learned fusion approach?
- If the UWB anchor coverage drops (NLOS on all anchors), what does your firmware do with the IMU bridge and how long does it maintain navigation accuracy?
What good looks like: A partner that can name the specific SoC, the sensors fused, the fusion algorithm and its implementation language, and what the accuracy degradation looks like during NLOS-only periods. A partner that can discuss edge ML inference (TFLite Micro, ONNX Runtime Micro) running alongside BLE or UWB firmware without power budget conflicts is demonstrating capability at the hardest point of integration.
needCode’s position: Sensor fusion (UWB + IMU + LiDAR odometry) and edge ML (TFLite Micro, PAwR, inference alongside BLE/UWB on the same MCU) are documented capabilities on the robotics and edge AI service pages. The Ambiq Apollo5-class and Nordic nRF54H20 are named platforms for inference + wireless coexistence work.
Capability self-scoring checklist
Use this table before a partner discovery call or before a statement of work review.
| Capability | Validated (2 pts) | Partial — needs confirmation (1 pt) | Not yet assessed or gap found (0 pts) |
|---|---|---|---|
| 1 — Multi-protocol firmware architecture | ☐ | ☐ | ☐ |
| 2 — Chipset bring-up and SDK depth | ☐ | ☐ | ☐ |
| 3 — Wireless certification pipeline | ☐ | ☐ | ☐ |
| 4 — Sub-13cm UWB indoor positioning | ☐ | ☐ | ☐ |
| 5 — BLE Channel Sounding / secure ranging | ☐ | ☐ | ☐ |
| 6 — Team ramp speed and programme integration | ☐ | ☐ | ☐ |
| 7 — ISO 27001 + EU data sovereignty | ☐ | ☐ | ☐ |
| 8 — Sensor fusion + edge ML alongside wireless | ☐ | ☐ | ☐ |
| Total /16 |
Score interpretation:
- 14–16: Strong partner fit. Proceed to SOW scoping.
- 10–13: Capable firm with specific gaps. Map gaps to programme risk and address in contract.
- 6–9: Material capability gaps present. Recommend a structured technical discovery session before commitment, with specific evidence required on the Red criteria.
- 0–5: High programme risk. Gaps align with the core technical work on your programme. Either a different partner or a joint delivery model (partner + in-house team for gap areas) is advisable.
Priority rules by ICP:
- Automotive/SDV: Capability 3 (certification) and 5 (BLE Channel Sounding) are hard stops. A gap here means the partner cannot complete the certification work your product requires.
- Robotics/humanoids: Capability 4 (UWB positioning with NLOS resilience) and 8 (sensor fusion) are hard stops. A partner that has not deployed RTLS in a real industrial or warehouse environment will not achieve the accuracy your robot needs.
- Defence/NATO: Capability 7 (ISO 27001 + EU) is a hard stop. A supplier not meeting this criterion typically cannot pass procurement vetting regardless of technical capability.
Running a structured discovery call
needCode provides embedded development outsourcing services for hardware OEMs across automotive embedded systems development, UWB IoT RTLS, industrial IoT connectivity, and multi-protocol wireless programmes. If you are validating a development partner against the eight capabilities in this checklist and want to assess programme fit before a statement of work, we are happy to talk. Book a free discovery call or get in touch.
No. Most OEM programmes require four to six of these capabilities, depending on the vertical and product type. A semiconductor SDK outsourcing engagement primarily needs capabilities 2 (bring-up depth) and 6 (ramp speed); a robotics positioning programme primarily needs 4 (UWB RTLS), 8 (sensor fusion), and 1 (multi-protocol architecture). The checklist helps you identify which capabilities are critical for your programme and which are nice-to-have.
Before the RFP goes out. The most common mistake is selecting a partner based on a generalist IoT portfolio and discovering the capability gap in the programme’s first milestone review. Running this checklist at the long-listing stage, even informally, saves six months of programme time.
Treat verbal claims without specific examples as Amber, not Green. The validation questions in each capability section are designed to require specific, verifiable answers. A partner that claims BLE Channel Sounding experience but cannot name a chipset, a CS mode (PBR/IBT), or a test result it resolved is likely claiming familiarity rather than implementation experience.
No. ISO 27001 is a minimum threshold, not a complete security framework for classified or restricted defence programmes. Depending on the NATO member state, the programme classification, and the nature of the work, additional requirements may apply: national security vetting of engineers, physical security of development environments, air-gapped or cleared networks, or country-of-origin restrictions on code ownership. ISO 27001 is the necessary first step in the supplier qualification chain.
RSSI (received signal strength indicator) measures how strong a BLE signal is and infers distance from that, a notoriously imprecise method that varies with antenna orientation, reflections, and interference. BLE Channel Sounding measures the round-trip phase shift of a signal across multiple frequencies (phase-based ranging) and adds a round-trip time measurement for secure distance bounding. Channel Sounding provides centimetre-level accuracy; RSSI proximity is typically accurate to several metres at best. For automotive keyless entry where the security requirement is “the key is within 30 cm of the door handle, not 3 m away”, this difference is determinative.
