Each radio works fine alone. The hard part is all of them at once.

Q: What is multi-protocol wireless and coexistence?

Multi-protocol means running more than one wireless protocol - such as BLE, WiFi, UWB, Thread, or Zigbee - on a single device, and coexistence is the engineering that lets those radios and stacks share the device without interfering. The two together are what make a multi-radio product work in the real world. needCode builds both the software architecture and the RF coexistence.

Q: Why is wireless coexistence hard?

Coexistence is hard because each radio passes its own tests in isolation, so the problems only appear when all the radios run together, under real traffic, in a real enclosure - making the bugs late, intermittent, and difficult to diagnose. The 2.4 GHz band is especially crowded, with BLE, WiFi, Zigbee, and Thread competing, and radios on one board can desensitise each other. It's exactly why a team experienced in multi-protocol bring-up matters.

Q: Can you build a device with multiple radios (BLE + UWB + WiFi)?

Yes - needCode builds devices that combine distinct radios for distinct jobs, such as UWB for location, BLE for connection, and WiFi for data, as one coexisting design rather than three that interfere. It designs the whole multi-radio architecture, not one radio at a time. The coexistence is engineered in from the start.

Q: What is runtime protocol switching?

Runtime protocol switching lets a device change which protocol it's running on the fly - for example BLE one moment and Zigbee the next - without a reset or a dropped connection. It's how a single chip can serve multiple protocols in turn. needCode has shipped exactly this, on Qorvo silicon running BLE, Zigbee, and Infrared.

Q: How do you stop two radios on one board from interfering?

needCode uses RF coexistence techniques - Packet Traffic Arbitration (PTA), time-division coordination, antenna isolation, and filtering - together with multi-stack scheduling, so the radios cooperate instead of blocking each other. The right mix depends on the radios, the bands, and the board. This is radio-domain engineering, below the application layer.

Q: Our multi-radio device works on the bench but fails in the field - can you help?

Yes - this is one of the most common reasons teams engage needCode, because a device often passes with one radio active and fails when they all run under real traffic. needCode diagnoses the interference, fixes it, and hardens the multi-radio design. The bench-works-but-field-fails pattern is a coexistence problem, and a solvable one.

Q: Which protocols can you combine?

needCode combines UWB, BLE, BLE Mesh, WiFi (including 6E/7 and HaLow), Thread, Zigbee, Matter, and Infrared, choosing the set that fits the product. Because it builds all of these, one team designs the whole device. The combination is matched to the jobs the device has to do.

Q: Does Matter need coexistence engineering?

Yes - Matter devices typically run WiFi or Thread for data and BLE for commissioning, so coexistence between those radios is built into the design from the start. needCode builds the multi-radio Matter device cleanly. The choice of WiFi or Thread as the data transport is part of that design.

Q: Do you handle the RF and hardware side, or just software?

needCode handles both - the RF coexistence (PTA, isolation, filtering) and the multi-stack software, from silicon bring-up upward. Multi-radio problems live across the hardware-software boundary, so addressing only one side leaves them unsolved. Nine platform bring-ups give needCode the depth to work at both levels.

needCode builds devices that run multiple wireless protocols at once – BLE, UWB, WiFi, Thread, Zigbee – without the radios interfering or the stacks colliding. The multi-stack architecture, the RF coexistence engineering, and runtime protocol switching, from the team that shipped a single chip running BLE, Zigbee, and Infrared together. Because a multi-radio product only reveals its problems when every radio is on.

Book a discovery call

Explore the technologies

We work with Industry Leaders

The number of radios in a device keeps going up. Radios don't share a device politely.

A product that used to be "the BLE one" is now BLE plus UWB plus WiFi. But adding a radio isn't additive - it's a coexistence problem. The 2.4 GHz band is crowded with BLE, WiFi, Zigbee, and Thread all competing; two radios on one board can desensitise each other badly; and multiple protocol stacks have to share the hardware without corrupting each other's timing. Each radio passes its own test in isolation - the failures appear only when they all run together, under real traffic, in a real enclosure, where they're late, intermittent, and brutal to diagnose.

needCode does this for a living. We've brought up a single chip running BLE, Zigbee, and Infrared with runtime protocol switching, and nine hardware platforms beneath the radios - so the multi-stack architecture and the RF coexistence are engineering we've shipped, not theory. A device that has to run several radios at once is exactly the kind we build.

Radios that don't fight

RF coexistence engineering - PTA, scheduling, isolation - so multiple radios share a device cleanly.

Stacks that don't collide

Multi-protocol architecture and runtime switching, so several stacks share the hardware safely.

Shipped, not theorised

A single chip running BLE, Zigbee, and IR together - multi-protocol delivered in production.

What we build

Multi-radio is two problems - software and RF - plus the integration. needCode builds all of it.

Multi-Stack Architecture

Running several protocol stacks on one device - time-sharing a radio or coordinating multiple radios - with the scheduling that keeps each stack's timing intact. It's the software architecture that lets BLE, Thread, or Zigbee coexist without corrupting one another.

Platform Bring-Up & SDK

RF Coexistence

The radio-domain engineering - Packet Traffic Arbitration (PTA), time-division coordination, antenna isolation, and filtering - that stops radios on one board from desensitising or blocking each other. In the crowded 2.4 GHz band especially, this is what makes a multi-radio device actually work.

Runtime Protocol Switching

Switching a device between protocols at runtime - the pattern behind a chip that's BLE one moment and Zigbee the next - without a reset or a dropped link. needCode has shipped exactly this, with Infrared in the mix too.

Multi-Radio Integration (BLE + UWB + WiFi)

Combining distinct radios for distinct jobs - UWB for location, BLE for connection, WiFi for data - as one coexisting design rather than three that interfere. needCode builds the whole multi-radio architecture, not one radio at a time.

Ultra-Wideband

BLE

WiFi

Building a device with more than one radio?

Book a discovery call with our CEO

Book a discovery call

Where it's used

Multi-radio shows up wherever one device has more than one job. These are the most common.

Smart Locks & Access

UWB for secure ranging, BLE for the phone connection, sometimes WiFi for the hub - three radios in one lock that must not interfere. needCode builds the coexisting design these products depend on.

Digital Keys & Access

Relay Attack Prevention

Connected Home & Matter

Matter devices run WiFi or Thread for data and BLE for commissioning, so coexistence is built into the standard. needCode builds the multi-radio Matter device cleanly.

Wearables & Multi-Function Devices

BLE for the companion app, WiFi for data, sometimes UWB for location - packed into a small device where coexistence is hardest. needCode tunes the radios and the power budget together.

BLE

Industrial Gateways

Equipment bridging WiFi, BLE, and cellular, where many radios share one enclosure and must coordinate. needCode builds the gateway's multi-radio architecture end to end.

Industrial IoT & RTLS

Why teams build multi-radio with needCode

We've shipped multi-protocol

needCode brought up a single chip running BLE, Zigbee, and Infrared with runtime protocol switching - multi-protocol and coexistence delivered in production, not described in a deck. Few embedded teams have actually done it.

RF depth, from the silicon up

Nine platform bring-ups and engineers from the chipmakers give needCode the radio-domain depth coexistence demands - PTA, timing, isolation. Multi-radio problems live below the application, which is exactly where needCode works.

Every radio, one team

needCode builds UWB, BLE, WiFi, Thread, and Zigbee, so a multi-radio device is designed by one team that knows all of them - not integrated from parts that have never met. The coexistence is designed in, not discovered late.

Built for the failures that only appear together

needCode knows multi-radio bugs are late and intermittent because each radio passes alone, and engineers for the combined system from the start. It's the difference between a demo with one radio on and a product with all of them on.

Four ways to bring needCode in

From a coexistence assessment to a long-term team - including the rescue when a device works on the bench but not in the field.

01 Coexistence Assessment & Architecture

Duration:
1–3 weeks
Best for:
Planning a multi-radio device, or reviewing one before the radios collide
Deliverable:
Coexistence architecture, risk list, leadership readout

02 Multi-Protocol Build

Duration:
Phased
Best for:
Building the multi-stack architecture, switching, and RF coexistence
Deliverable:
A working multi-radio device on target silicon

03 Coexistence Debug & Hardening

Duration:
Scoped
Best for:
A device that works with one radio on but fails when they all run
Deliverable:
Diagnosed interference, fixes, and a hardened multi-radio design

04 Long-Term Team

Duration:
Multi-year, retainer-based
Best for:
Owning a multi-radio product line across its life
Deliverable:
An embedded wireless team

What we ship on

The protocols, coexistence techniques, and silicon behind a clean multi-radio device.

Protocols

UWB

BLE

BLE Mesh

WiFi (6E / 7 / HaLow)

Thread

Zigbee

Matter

Infrared

Coexistence

PTA (Packet Traffic Arbitration)

time-division coordination

antenna isolation

RF filtering

multi-stack scheduling

Modes

Runtime protocol switching

concurrent multi-radio

single-radio time-sharing

Silicon

Qorvo

Nordic

NXP

Espressif

Silicon Labs

Infineon

Case studies

The proof for coexistence work is a multi-radio product that holds - and needCode has one.

Qorvo: RF Leadership

Context: Rapid scaling for new chipset bring-up.

Scale: Grew from <10 to 30 FTEs.
Output: Supported bring-up of 9 new hardware platforms (SDKs, Drivers, Stacks).
Retention: Zero-churn core team retained for 5+ years.

Dedicated Development Center for RF Solutions

Bluetooth Mesh Smart Lighting Control System

Smart Lighting: Core R&D Extension

Context: Client needed deep, specialized expertise to pivot from proprietary tech to a new global standard.

Service: Deployed a dedicated squad of embedded engineers to function as the client's core R&D team.
Output: Co-authored official Bluetooth SIG protocols and delivered the world’s first certified BLE Mesh stack.
Value: Enabled the client to secure Series A funding and defined the industry standard for smart buildings.

Creative Werks: Innovation rescue

Context: Hardware obsolescence threatened production shutdown.

Action: Full-stack takeover (PCB redesign + Firmware + Mobile App).
ROI: 1230% ($1.6M value generated).
Speed: Payback period of 2–3 months.

NeedCode-case study - IoT Solution for Boat Lift Modernization - cover2s

PowerPollen: AgTech automation

Context: Lack of internal expertise stalled a critical automation project.

Action: Re-architected system using unified MCU and ISOBUS standards.
ROI: 13.8x ($2.9M value generated).
Impact: Enabled $1.9M increase in harvester value.

Strategic Partnership

needCode is an official business partner of Qorvo, bringing over 8 years of proven expertise and trusted service to the technology sector.

Check our performance

Members of the UWB Alliance

In 2025 we became a member of the UWB Alliance. This strategic step reinforces our commitment to pioneering Ultra-Wideband (UWB) technology.

Proudly Certified for Excellence and Security

needCode is officially certified for:
ISO 9001:2015 – Quality Management
ISO/IEC 27001:2022 – Information Security

ISO certifications reflect our focus on delivering reliable IoT solutions, smart product development, and secure technology services.

Testimonials

“I think the key takeaway from needCode is their ability to adapt and understand the customer's requirements. That took away probably a large portion of what could have been a lot of development time and expense for both companies.”

Bob Folkestad

President at Creative Werks

“One aspect that truly sets needCode apart is its profound expertise in firmware development. Their proficiency in various programming languages, embedded systems and hardware architecture is truly impressive. When faced with difficult problems, their strong problem-solving skills and analytical mindset shine through, allowing them to overcome obstacles with remarkable ease.”

Semeh Sarhan

CEO at Xtrava

“I worked with needCode while leading the NWTN-Berlin team in 2018. A big chunk for our FW development has been outsourced to them and they had proven to iterate very quickly, following specs and deliver on time. It was great working with them. I recommend working with needCode’s team on any Embedded SW development.”

Marco Salvioli Mariani

CTO at NWTN Berlin GmbH

“needCode Team proved to be one of the best engineers I have ever met. The part I like the most about the team is the more difficult an obstacle seems to be, the more motivated they were to find a solution and a way forward.”

Szymon Słupik

CTO at Silvair

“needCode is an outstanding partner. Their quick follow-up, scalability, and extensive professional network set them apart. Their expertise in wireless technologies has been valuable, supporting us from low-level drivers to architecture discussions.”

Tim Allemeersch

Director at Qorvo, Inc.

“needCode did a great job improving the firmware of the Vai Kai connected toys and developing new features, surpassing our expectations multiple times. I would definitely recommend hiring Bartek and needCode for the embedded software projects!”

Matas Petrikas

CEO & Co-founder at Vai Kai UG

Insights

Docker and Dev Containers for Embedded: Killing “Works on My Machine”

Every embedded team has lived through some version of the same conversation. A developer pushes a change that builds cleanly on their machine. The CI build fails. The developer pulls the failing log, cannot reproduce the failure locally, and spends two hours establishing that the CI is using a slightly different version of the ARM […]

Documentation as a product: how good SDKs treat docs as code

The deliverable customers interact with most often is the one most commonly treated as a secondary artifact. Six document types, six audiences, and one release gate that fixes most of the failure modes. A semiconductor SDK can have an exemplary architecture, a thoughtfully versioned C API, a security framework that maps cleanly to PSA Certified […]

FAQ