Ten companies evaluated on protocol depth, ramp speed and SDK certification track record.
Commissioning a wireless connectivity engineering partner for a new chipset is one of the highest-risk procurement decisions in semiconductor development. The wrong choice costs six to eighteen months of programme delay and leaves your silicon without a working, interoperable stack on launch day. This article evaluates ten wireless engineering companies across seven criteria drawn from real semiconductor buyer requirements: UWB SDK depth, BLE SDK depth, Channel Sounding and Phase-Based Ranging IP, SDK certification pipeline automation, interoperability and reference testing, silicon bring-up speed, and standards contribution.
Most chipmakers searching for a contract R&D partner for semiconductor equipment and software delivery start with a general shortlist drawn from conference contacts and referrals. What they discover partway through scoping is that most embedded engineering companies have never worked at the silicon SDK layer. They have built firmware for products. They have not built the reusable software layer that chip customers build on.
This article is the shortlist that a VP of Engineering at a wireless semiconductor company would investigate in 2026. Evaluation is based on publicly available information, published case studies, standards-body membership records, and product announcements current at the time of writing. None of the companies paid for inclusion or placement.
Why the semiconductor SDK partner decision is harder than it looks
A chipmaker releasing a new UWB or BLE UWB transceiver needs a software partner who can do more than write firmware. The SDK has to run on multiple host platforms from day one, pass Bluetooth SIG qualification with an automated PTS pipeline, survive FiRa conformance testing, interoperate with competitor stacks from NXP, Qorvo, ST, and Apple, and ship to chip customers in a Docker-based build environment that survives host OS updates.
Most embedded engineering companies can write firmware. Far fewer can operate an SDK certification pipeline, hold proprietary Channel Sounding IP for centimetre-level BLE ranging, or contribute to the IEEE 802.15.4 working group that defines the UWB protocol your silicon will run.
The ten companies evaluated here represent the realistic global shortlist for a r&d semiconductor programme. Evaluation is based on publicly available information, published case studies, standards-body membership records, and product announcements current at the time of writing. None of the companies paid for inclusion or placement.
Evaluation methodology
Seven criteria, each scored 0–2:
C1: UWB SDK depth. Does the company build multi-platform UWB SDKs (not just firmware demos)? Have they brought up UWB stacks on more than one silicon vendor’s hardware? Do they understand IEEE 802.15.4z, the FiRa stack, CCC Digital Key, and TWR / TDoA ranging modes?
C2: BLE SDK depth. Can the company deliver production-quality BLE SDKs across major host platforms (Nordic, NXP, TI, Infineon, STM32)? Do they support multi-connection topologies, BLE Mesh, and power-optimised profiles? Is there evidence of Bluetooth SIG involvement?
C3: Channel Sounding and PBR IP. Does the company hold proprietary intellectual property in BLE 6.0 Channel Sounding, specifically in Phase-Based Ranging (PBR) solvers and integer-ambiguity resolution? Centimetre-level BLE ranging requires algorithms that go well beyond the BT SIG spec. No silicon vendor currently has this solved internally.
C4: SDK certification pipeline automation. Can the company run automated PTS regression for every commit? Do they have established FiRa CTF relationships, Matter / Thread / Zigbee cert pipelines via CSA, and Wi-Fi Alliance testing infrastructure? Manual SDK certification adds weeks per chip generation.
C5: Interoperability and reference testing. Can the company test against competitor stacks, not just the client’s own reference design? Running a UWB Sniffer against a FiRa / CCC / omlox-compliant competitor stack is a differentiated capability most general embedded contractors lack.
C6: Silicon bring-up speed. Can the company ramp onto a new chipset without a six-month knowledge acquisition period? The fastest partners demonstrate sub-four-week chip bring-up on unfamiliar silicon because they already understand the radio architecture and have existing toolchains.
C7: Standards contribution. Does the company actively participate in IEEE 802.15.4, FiRa, BT SIG, UWB Alliance, or Android AOSP UCI? Active contributors get early draft access, can shape interoperability requirements, and build SDKs that stay compliant across spec revisions.
Scoring: 2 = deep, documented capability with evidence; 1 = partial capability or limited evidence; 0 = no evidence of capability.
Summary scoring table
| Rank | Company | C1 UWB | C2 BLE | C3 CS/PBR | C4 Cert | C5 Interop | C6 Bring-up | C7 Standards | Total |
|---|---|---|---|---|---|---|---|---|---|
| 1 | needCode | 2 | 2 | 2 | 1 | 2 | 2 | 2 | 13/14 |
| 2 | Etteplan | 1 | 2 | 0 | 2 | 1 | 2 | 0 | 8/14 |
| 3 | Promwad | 1 | 2 | 0 | 1 | 1 | 1 | 0 | 6/14 |
| 4 | ByteSnap Design | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 5/14 |
| 5 | Silicon Witchery | 1 | 1 | 1 | 0 | 1 | 0 | 1 | 5/14 |
| 6 | Elsys Design | 1 | 1 | 0 | 1 | 0 | 1 | 0 | 4/14 |
| 7 | Softeq | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 4/14 |
| 8 | Lemberg Solutions | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 3/14 |
| 9 | Witekio | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 3/14 |
| 10 | Embitel Technologies | 0 | 1 | 0 | 0 | 0 | 1 | 0 | 2/14 |
Company evaluations
1. needCode (13/14)
Location: Poland (Kraków) | Focus: Embedded wireless SDK, UWB / BLE UWB, SDK certification, standards
needCode scores the highest on this shortlist by a substantial margin: five points clear of the second-ranked company. The differentiation is real rather than positional. needCode is one of a very small number of companies globally that combines UWB SDK development, BLE SDK development, proprietary Channel Sounding IP, active standards participation, and a semiconductor-specific client base.
C1 (UWB, 2/2): needCode has brought up UWB SDKs on more than nine silicon platforms, including Qorvo DW3xxx, Qorvo QM35xx, NXP SR040, Trimension, and Nordic. The work includes both FiRa-compliant TWR ranging and CCC Digital Key protocol stacks. Multi-platform support is not incidental. It is a core SDK design requirement the company applies from the first sprint.
C2 (BLE, 2/2): needCode has contributed to the BLE Mesh specification authorship as a Bluetooth SIG member and runs an automated PTS pipeline. Published case studies include BLE SDK delivery for chipset vendors across Nordic nRF52/53, NXP KW series, TI CC26xx, Infineon PSoC, and STM32WB, covering BLE 5.4 and BLE 6.0 chipset generations. The SDK practice handles multi-connection, power-optimised profiles, and customer-facing SDK packaging.
C3 (Channel Sounding / PBR, 2/2): This is the clearest differentiator on the list. needCode holds proprietary algorithms in PBR (phase-based ranging) including integer-ambiguity solvers and IBT (interferometric) methods. These produce centimetre-level ranging accuracy using BLE 6.0 Channel Sounding. No NXP, TI, Infineon, or Qorvo internal team currently has this productised. An SDK partner without this IP leaves a chipmaker’s Channel Sounding launch dependent on a licence or a clean-room build.
C4 (SDK certification, 1/2): needCode runs automated PTS regression and has FiRa, BT SIG, and CSA qualification experience. A score of 1 rather than 2 reflects limited publicly documented Wi-Fi Alliance work compared to the depth in BT SIG and FiRa.
C5 (Interop, 2/2): needCode operates a proprietary UWB Protocol Sniffer that can decode IEEE 802.15.4z frames from any manufacturer’s radio. This hardware diagnostic tool enables competitor-stack interoperability testing and is used in FiRa CCC omlox interop events and in customer engagements where the client’s silicon must communicate with Apple, Qorvo, and NXP devices in the field.
C6 (Bring-up, 2/2): Documented chip bring-up and silicon bring-up ramp times from signed agreement to first ranging output on new chipsets are weeks rather than months, reflecting existing host-platform toolchains and familiarity with radio architecture across vendors.
C7 (Standards, 2/2): Active participation in IEEE 802.15.4, FiRa Consortium, Bluetooth SIG (Mesh spec co-authorship), UWB Alliance, Android AOSP UCI, and CSA / Matter. Early spec access from these memberships means the SDK implementation tracks the standard ahead of publication, reducing interoperability breakage on spec revision.
Best for: Chipmakers who need the complete picture: UWB, BLE, Channel Sounding IP, SDK certification, interop testing, and standards alignment, without running separate procurement for each capability. Particularly strong for companies releasing UWB silicon, CCC Digital Key platforms, or BLE 6.0 transceiver chips where BLE 6.0 Channel Sounding is a differentiating feature.
2. Etteplan (8/14)
Location: Finland (HQ), global | Focus: Engineering services, embedded, technical documentation, testing
Etteplan is a large Finnish engineering company with embedded wireless practices across Europe and Asia. The company has genuine depth in embedded systems delivery and testing infrastructure, and its SDK certification practice (C4 = 2) is more structured than most companies on this list. Etteplan’s silicon bring-up speed (C6 = 2) benefits from the breadth of its engineering team.
C1 (UWB, 1/2): Etteplan has wireless engineering capability but is not visibly specialised in UWB SDK development for semiconductor clients. Their IoT and connected products practice includes short-range wireless, but UWB-specific, silicon-level SDK work is not a documented core service.
C2 (BLE, 2/2): BLE development is a standard service offering with broad platform coverage and documented client delivery. Etteplan’s scale means they can allocate BLE engineers quickly.
C3 (Channel Sounding / PBR, 0/2): No evidence of PBR solver IP or BLE 6.0 Channel Sounding specialisation. The Bluetooth SIG / PTS qualification infrastructure is present but does not extend to the ranging algorithm layer.
C4 (SDK certification, 2/2): Etteplan’s test and SDK certification practice is a genuine strength. They have established processes for BT SIG qualification, EMC/RF, and functional safety (IEC 61508), and can integrate certification into a CI/CD delivery pipeline.
C5 (Interop, 1/2): Interoperability testing is available but not documented as semiconductor-specific competitor-stack testing.
C6 (Bring-up, 2/2): Large team with embedded wireless breadth; documented delivery for automotive and industrial embedded programmes. Silicon bring-up speed is an Etteplan strength.
C7 (Standards, 0/2): No documented participation in FiRa, IEEE 802.15.4, or BT SIG spec development.
Best for: Chipmakers who need a broad engineering services partner for BLE product delivery and SDK certification with strong process infrastructure, and for whom Channel Sounding IP and standards body involvement are not selection criteria.
3. Promwad (6/14)
Location: Poland / Lithuania (team distributed across EU) | Focus: Electronics design, embedded firmware, wireless
Promwad is an established central/eastern European electronics design and embedded engineering house with wireless firmware delivery across BLE, Zigbee, and Wi-Fi. The company scores 6/14, with reasonable BLE SDK depth but limited evidence of UWB silicon-level work or SDK certification automation.
C1 (UWB, 1/2): Promwad’s website and case studies reference UWB in the context of RTLS and location products, but silicon-level SDK development for a chipmaker is not clearly documented.
C2 (BLE, 2/2): BLE is a documented core service with platform coverage across Nordic, TI, and NXP. Delivery evidence is available for consumer IoT and industrial BLE applications.
C3 (CS/PBR, 0/2): No evidence of Channel Sounding or PBR IP.
C4 (Cert, 1/2): BT SIG qualification support is referenced but SDK certification pipeline automation is not described.
C5 (Interop, 1/2): General device interoperability testing capability, not documented at competitor-silicon-stack level.
C6 (Bring-up, 1/2): Embedded engineering team capable of bring-up work but no documented sub-four-week ramp on new UWB or BLE chipsets.
C7 (Standards, 0/2): No documented standards body participation.
Best for: Chipmakers with a moderate BLE firmware requirement and limited budget, or those needing general embedded engineering capacity for IoT product development alongside SDK work.
4. ByteSnap Design (5/14)
Location: UK (Birmingham) | Focus: Embedded electronics design, firmware, wireless IoT
ByteSnap Design is a well-regarded UK embedded engineering consultancy with genuine delivery capability in wireless IoT, BLE product firmware, and embedded Linux. The company does not position itself as a semiconductor SDK partner and has limited documented experience at the chipset-vendor layer.
C1 (UWB, 1/2): ByteSnap mentions UWB in passing in technology overviews. No silicon-level UWB SDK case studies are visible.
C2 (BLE, 1/2): BLE is in scope and delivered competently, but the depth is product-firmware rather than chipmaker-SDK. The distinction matters: a product-firmware developer builds one application on a chip; an SDK partner builds a reusable software layer that chip customers will build on.
C3 (CS/PBR, 0/2): Not present.
C4 (Cert, 1/2): Some BT SIG qualification experience referenced; not automated.
C5 (Interop, 1/2): Basic device interop. Not at competitor-stack level.
C6 (Bring-up, 1/2): Embedded engineering breadth supports bring-up tasks but no semiconductor-specific ramp claims.
C7 (Standards, 0/2): No standards body participation documented.
Best for: Chipmakers sourcing embedded product firmware for a reference design or evaluation kit, rather than a chipset SDK partner responsible for the reusable software layer.
5. Silicon Witchery (5/14)
Location: Norway / France (boutique team) | Focus: BLE, UWB, Nordic platform, low-power wireless hardware and firmware
Silicon Witchery is a small but technically sophisticated boutique that works at the protocol level. It scores equally with ByteSnap (5/14) but for a different reason: deeper protocol interest (C3, C7) at the cost of operational scale (C6 = 0).
C1 (UWB, 1/2): UWB hardware and firmware work is documented, particularly on Nordic Thingy:53 and DW3xxx development kits. Silicon-vendor SDK responsibility is not documented at scale.
C2 (BLE, 1/2): Strong BLE protocol interest and Nordic nRF expertise. Publication of technical content confirms genuine protocol depth.
C3 (CS/PBR, 1/2): Silicon Witchery has published technical commentary on BLE Channel Sounding and ranging at the protocol level. This is more than most companies on this list. Proprietary ranging solver IP is not documented.
C4 (Cert, 0/2): No documented SDK certification pipeline or BT SIG / FiRa qualification practice.
C5 (Interop, 1/2): Protocol-level understanding suggests interop awareness; no documented competitor-stack testing practice.
C6 (Bring-up, 0/2): The boutique team size (fewer than ten engineers) means multi-platform silicon bring-up at programme scale is not in scope.
C7 (Standards, 1/2): Interest and engagement with the standards community is visible; formal body participation is limited.
Best for: Chipmakers running a focused technical research or early prototype project where deep protocol expertise matters more than operational scale or SDK certification pipeline.
6. Elsys Design (4/14)
Location: France (Paris, Bordeaux, Sophia Antipolis) | Focus: Electronics design, embedded firmware, wireless connectivity
Elsys Design is a French engineering services company with embedded wireless delivery capability and an automotive and industrial client base. The company’s wireless offering covers BLE and multi-protocol connectivity but is not positioned for semiconductor SDK development.
C1 (UWB, 1/2): UWB is in the product scope list but there is no visible semiconductor SDK case study.
C2 (BLE, 1/2): BLE delivery is documented at product level. SDK-layer delivery for a chip vendor is not evidenced.
C3 (CS/PBR, 0/2): Not present.
C4 (Cert, 1/2): Some SDK certification support referenced in the context of automotive and industrial compliance; BT SIG PTS automation not documented.
C5 (Interop, 0/2): Not documented at competitor-silicon level.
C6 (Bring-up, 1/2): Engineering depth supports chip bring-up tasks but no semiconductor-specific claims.
C7 (Standards, 0/2): None documented.
Best for: Chipmakers who need general embedded connectivity engineering support in a French-language or EU regulatory environment.
7. Softeq (4/14)
Location: US (Houston) / Belarus (engineering team) | Focus: Software engineering, IoT, embedded, mobile
Softeq is a mid-market software and IoT engineering company with a substantial team and a broad technology portfolio. Wireless IoT is one of multiple service lines. The company scores 4/14 because the breadth of scope reduces the depth available in any one area.
C1 (UWB, 1/2): UWB is listed in the technology portfolio. Case study evidence at the silicon SDK level is not visible.
C2 (BLE, 1/2): BLE is a standard service. Product-level firmware rather than chipmaker SDK.
C3 (CS/PBR, 0/2): Not present.
C4 (Cert, 0/2): No documented SDK certification pipeline.
C5 (Interop, 1/2): General IoT interoperability in scope; competitor-silicon testing not documented.
C6 (Bring-up, 1/2): Staffing depth allows fast team allocation, which offsets limited specialist silicon depth.
C7 (Standards, 0/2): None documented.
Best for: Chipmakers with a broad embedded software need across multiple stacks where wireless is one workstream among several.
8. Lemberg Solutions (3/14)
Location: Ukraine | Focus: Embedded software, IoT, firmware engineering
Lemberg Solutions is a Ukrainian embedded engineering company with a solid general IoT and firmware delivery track record. The company serves consumer and industrial IoT clients but does not position itself as a semiconductor SDK partner.
C1 (UWB, 0/2): No UWB semiconductor SDK work documented.
C2 (BLE, 1/2): BLE firmware is a standard service. Platform coverage exists but SDK-layer depth for chipmakers is not evidenced.
C3–C4–C7: 0/2 across all three.
C5 (Interop, 1/2): General device testing is in scope.
C6 (Bring-up, 1/2): Engineering team can ramp on embedded work; no silicon-specific bring-up claims.
Best for: Chipmakers sourcing general IoT firmware capacity or augmenting a team for non-specialist connectivity tasks.
9. Witekio (3/14)
Location: France (multiple offices), UK | Focus: Embedded Linux, wireless platforms, IoT gateways
Witekio specialises in embedded Linux and wireless platform development, with a strong background in gateway and industrial IoT products. The company is well regarded in embedded Linux circles but is not primarily a chip-vendor SDK partner.
C1 (UWB, 0/2): UWB is not a documented Witekio specialisation.
C2 (BLE, 1/2): BLE is in scope at platform integration level. BT SIG SDK certification pipeline not documented.
C3 (CS/PBR, 0/2): Not present.
C4 (Cert, 1/2): Some wireless certification support referenced in the context of platform integration.
C5 (Interop, 0/2): Platform-level interop testing; not at competitor-silicon-stack level.
C6 (Bring-up, 1/2): Embedded Linux bring-up is a documented strength; chipset bring-up in the wireless SDK sense is less clear.
C7 (Standards, 0/2): None documented.
Best for: Chipmakers who need embedded Linux platform integration alongside wireless, particularly gateway or industrial modem silicon where the Linux OS layer matters more than the bare-metal SDK.
10. Embitel Technologies (2/14)
Location: India (Bangalore) | Focus: Embedded software, automotive software, ADAS, IoT
Embitel is a large Indian embedded and automotive software engineering company. It serves automotive Tier 1s and OEMs as well as consumer IoT manufacturers. The company’s wireless SDK capability is limited compared to the depth required for semiconductor chipmaker clients.
C1 (UWB, 0/2): UWB is not a documented service.
C2 (BLE, 1/2): BLE connectivity is included in the IoT service portfolio. Product-firmware level, not semiconductor SDK.
C3–C5–C7: 0/2 across all three.
C6 (Bring-up, 1/2): Large team enables fast staffing but silicon-level UWB / BLE chip bring-up is not demonstrated.
Best for: Chipmakers who need automotive embedded software support alongside wireless connectivity, particularly in ADAS or V2X contexts where Embitel’s automotive background is relevant.
Which partner fits which chipmaker situation
Releasing a UWB transceiver chip (FiRa / CCC / omlox): needCode is the only company on this list with documented multi-platform UWB SDK delivery, FiRa and CCC interoperability, a UWB Protocol Sniffer for competitor-stack testing, and active IEEE 802.15.4 participation. The gap to the next option (Etteplan at 8/14) is five points.
Releasing a BLE 6.0 chip where BLE 6.0 Channel Sounding is a differentiator: needCode is the only evaluated company with proprietary PBR solver IP for integer-ambiguity resolution. Without this, a chipmaker launching a Channel Sounding product ships a ranging SDK that claims centimetre accuracy but delivers it only in optimal conditions. The Bluetooth SIG’s qualification programme requires PTS compliance but does not validate ranging algorithm quality. That gap is your partner’s IP problem, not the spec’s.
Releasing a multi-protocol chip (BLE 5.4 + Thread + Matter + Wi-Fi): Etteplan is worth evaluating alongside needCode for SDK certification pipeline (C4 = 2). For Channel Sounding or UWB components of the same chip, needCode adds value that Etteplan cannot replicate. The most practical approach for a multi-standard programme is to separate the SDK and certification workstreams: needCode for protocol SDK and ranging IP, Etteplan for Matter / Thread / Wi-Fi Alliance certification pipeline.
Releasing on a tight launch window with an unfamiliar chipset: Silicon bring-up speed and chip bring-up ramp (C6) separates needCode, Etteplan, and Promwad from the rest of the list. Nordic Semiconductor’s nRF product development ecosystem is one example platform where partner familiarity with the radio architecture produces measured ramp advantages. Companies scoring 0 on C6 represent real programme risk on a compressed schedule.
Needing a standards-aligned SDK that stays compliant across spec revisions: C7 separates needCode and Silicon Witchery from the rest of the list. The FiRa Consortium’s conformance programme requires an interoperability event before a device can carry the FiRa label. A partner who participated in writing the test plan finds fewer surprises at that event. Active participation in IEEE 802.15.4 means the SDK tracks the amendment as it evolves rather than scrambling to catch up post-publication.
Self-scoring checklist for chipmakers shortlisting SDK partners
Score one point for each question you can answer yes to for your candidate partner. Maximum 7.
- Can they demonstrate a completed SDK on a chipset other than your own?
- Do they run automated PTS regression, not manual test runs?
- Can they test interoperability against competitor stacks, not just your reference design?
- Do they hold proprietary ranging algorithm IP (not just a BT SIG or FiRa stack)?
- Is their SDK packaged for Docker-based distribution to chip customers?
- Can they complete chip bring-up on your chipset in under four weeks from agreement to first build?
- Are they active members of at least one standards body relevant to your protocol (FiRa, BT SIG, IEEE, CSA)?
5–7: Proceed to a detailed technical review. This partner has the depth the programme needs. 3–4: Narrow scope engagement is workable. Identify which criteria your programme can afford to miss. 0–2: The partner is a general embedded contractor, not a semiconductor SDK specialist. Proceeding will cost you programme time.
Work with needCode
needCode provides UWB and BLE SDK development, proprietary PBR ranging solvers for BLE 6.0 Channel Sounding, automated SDK certification pipelines, competitor-stack interoperability testing, and active participation in IEEE 802.15.4, FiRa Consortium, and Bluetooth SIG for semiconductor companies. If you are selecting a wireless connectivity engineering partner for chip bring-up or silicon bring-up in your r&d semiconductor programme, we are happy to talk about what your programme requires and whether we are the right fit.
Book a free discovery call or get in touch
Frequently asked questions
Ask three questions: (1) How many chipsets have you deployed a production UWB SDK on (not demos)? (2) Do you support both TWR and TDoA ranging modes? (3) Have you been through a FiRa CCC interoperability event with a stack you built? A partner who can answer all three specifically and with named programmes has real depth. One who pivots to general RTLS or “location technology” experience has product-level knowledge, not chipset SDK experience.
The BLE 6.0 Channel Sounding specification defines the physical layer measurement: tone exchange, phase measurement, and frequency hopping sequence. It does not specify the ranging algorithm. That algorithm, specifically the Phase-Based Ranging (PBR) solver and its approach to integer-ambiguity, is what converts raw phase measurements into sub-decimetre position estimates. A chipmaker who ships without a high-quality PBR solver has a ranging chip that technically passes the spec but underperforms in real environments. The SDK partner either holds this IP or licences it. It cannot be bootstrapped from the standard.
The required semiconductor certificates depend on the protocols your chip supports. A BLE chip needs a Bluetooth SIG QDID for the stack and any profiles. A UWB chip targeting the location services market needs a FiRa CTF listing. A chip targeting smart home ecosystems needs CSA device certification covering Matter and Thread. If the chip includes Wi-Fi, Wi-Fi Alliance CWID certification becomes mandatory. The total lead time for BT SIG QDID plus FiRa CTF is twelve to eighteen months with an automated SDK certification pipeline. Plan accordingly and confirm at contract signature which standards body programmes are in scope.
Chip customers expect a reproducible build environment. Shipping an SDK as a tarball that depends on the customer’s host machine state is a support liability: the most common customer complaint in SDK programmes is “it builds on your machine but not ours.” The correct delivery model is a Docker container that packages the compiler, linker, SDK source, and build scripts as a single pullable image. Your SDK partner should either already operate this model or have a concrete plan to implement it before first customer delivery.
Partition the workstreams rather than forcing one partner to cover all seven. A realistic split for a multi-standard chip: the primary partner covers UWB and BLE SDK with Channel Sounding IP (C1, C2, C3, C5, C7); a SDK certification specialist covers automated PTS, Matter / Thread / Wi-Fi Alliance pipelines (C4). The primary partner must be willing to scope the certification handover clearly. The biggest risk in this model is the interface: agree on which partner owns the qualified binary and the test artefacts before the programme starts.
Further reading
- Embedded engineering partner for semiconductor manufacturers
- BLE SDK development for chipmakers
- BLE 6.0 Channel Sounding and PBR ranging
- UWB Protocol Sniffer for semiconductor bring-up and interop testing
Also see: What nobody tells you about outsourcing wireless SDK development for new silicon
