Designing UWB tags for Wi-Fi access-point RTLS: what Qorvo’s QPK3000 and FiRa/omlox infrastructure mean for device makers

Facts checked on 16 October 2026

Short answer

On 18 May 2026 Qorvo presented ultra-wideband (UWB) in enterprise Wi-Fi access points as real-time location (RTLS) infrastructure, with the QPK3000, a module “designed for tags and end devices” that supports uplink TDoA or two-way ranging for FiRa- and omlox-based systems.

The hard engineering moves to the tag, which may meet UWB access points, dedicated anchors and omlox core zones. It must interoperate, last years on a battery, update safely over the air and pass certification. Budget the charge per blink, set the profile per site and test on each infrastructure.

What Qorvo announced

Qorvo’s release of 18 May 2026 positions enterprise Wi-Fi access points as the location infrastructure itself. In Qorvo’s words, it enables “precise, real-time location services without the need for dedicated RTLS infrastructure”. It names three “industry-first” milestones:

• “FiRa-compliant RTLS deployments on EAPs in healthcare and logistics”;
• “Omlox-compliant RTLS deployments on EAPs in automotive manufacturing”;
• “Combined support of FiRa and Omlox standards within enterprise Wi-Fi infrastructure for interoperable RTLS deployments”.

EAP stands for enterprise access point. The release refers to “collaboration with leading enterprise Wi-Fi providers” but names no access point partner, chip inside the module, accuracy or battery life. Alexis Bizalion, Director of Product Marketing & Enablement at Qorvo, summarised the aim: “we’re making real-time location a native capability of the network.”

The idea is not new to the industry. Juniper announced its AP47 Wi-Fi 7 access point in September 2024 with UWB integrated “along with BLE”. Not every enterprise access point has UWB, though. HPE Aruba Networking’s 730 Series QuickSpecs, updated in August 2026, describe GNSS and Wi-Fi fine timing measurement for access point self-location and do not mention UWB. Check the exact access point model a customer runs before you plan a deployment around it.

The QPK3000 at a glance

The figures below come from Qorvo’s QPK3000 product page and product brief (Rev B, March 2026). The full data sheet was not publicly readable.

One detail matters for FiRa uplink TDoA. In August 2026 a Qorvo staff member wrote on Qorvo’s forum that there is “a plan through NDA to enable customers to use the QPK3000 as a UT-Tag”, the FiRa term for an uplink TDoA tag, and that “a QM33 UT-Tag SDK” is available through NDA. Ask Qorvo what is available to you before you commit to a positioning mode, and whether one unit can carry both the FiRa and the omlox software, which ship under separate order codes.

What changes when the access point is the anchor

A dedicated RTLS network is designed for location: the integrator chooses anchor positions, density and synchronisation. When access points carry the UWB radio, three things change for the tag maker.

• The infrastructure belongs to someone else. Access points are placed for Wi-Fi coverage and managed by the customer’s IT team. Your tag must work with the geometry it finds, and you cannot change the anchor firmware.
• One tag meets several systems. A hospital may run a FiRa-based system on its access points, while a car plant runs an omlox core zone. A tag sold into both needs both profiles, or a clear statement of which one it supports.
• The tag becomes a managed network device. Customers expect onboarding, configuration, security updates and diagnostics through their own tools, often over Bluetooth LE.

Qorvo’s own framing explains why vendors take this route. In April 2025 Qorvo’s then Director of Ecosystem Development told Wi-Fi NOW that “the UWB coverage area is in practice virtually the same as for a Wi-Fi 7 AP”.

Juniper’s Mist documentation shows one division of work. Its AP47s “act as passive UWB sensors for Omlox-compliant asset tracking deployments”, forwarding tag blinks to SICK’s Coriva location engine, while timing synchronisation stays with the external SICK infrastructure. Mist UWB “operates on channel 9”, needs access point firmware 0.15.34994 or later and refers installers to the tag vendor’s placement guidelines. The tag maker owes channel 9 support, location-engine compatibility and that guide.

FiRa and omlox: what a tag has to meet

Three facts shape a tag roadmap:

• omlox V2 replaced V1. PI states that “omlox Core Zone Specification Version 2 is not backwards compatible to omlox Core Zone Specification Version 1” and that “future products, however, shall implement” version 2. The V2.2.1 corrigendum of August 2026 brings the text closer to IEEE 802.15.4z and clarifies “the synchronization and mathematics for DL-TDoA”.
• FiRa now covers uplink TDoA. FiRa’s Core 4.0 release says the UL-TDoA design “ensures interoperability between the tags and the infrastructure, which optimizes tag simplicity and power consumption”, and the certification program now includes it.
• The two bodies work together. FiRa and omlox formed a joint working group in March 2025. FiRa’s release names “a primary long-term goal” to “integrate functionalities developed by FiRa into the omlox core zone”.

Supporting both standards in one tag is realistic, because both build on IEEE 802.15.4z. It still means two configurations, two compliance tests and two sets of interoperability tests.

Running both profiles on one tag

Juniper’s documentation states that “Omlox uses Uplink Time Difference of Arrival”; frame details sit in PI’s members-only specification. Treat the two profiles as separate sessions:

• one parameter set per profile: channel, preamble, STS, identifier format, intervals and transmit power;
• the profile chosen at provisioning from the site configuration, not guessed from the air;
• one active session, de-initialised before the other starts;
• tests per profile, plus tests of the switch itself.

Positioning mode, seen from the tag

For asset tags on access-point infrastructure, uplink TDoA is the natural fit: the tag stays simple and the location engine runs in the network. Two-way ranging suits small zones and phone interaction. Downlink TDoA suits navigation, where the device should know its own position.

The DW3000 data sheet quantifies the gap: its profile for a frame “compatible to a DW1000 TDoA tag blink” sums to about 9 µC, and its double-sided two-way ranging initiator profile to about 32 µC per responder, plus idle gaps at 18 mA.

What a UL-TDoA blink carries and how often it is sent

FiRa’s asset-tracking leaflet sums up the model: anchors timestamp each tag message, report the time of arrival to a localisation engine, and “for each message a tag transmits, the infrastructure computes one tag position”.

Qorvo’s UCI specification for the QM35 SDK and the Android Open Source Project’s UWB stack expose the tag-side settings; Qorvo marks the UL-TDoA fields “Not part of FiRa 2.0”. Android defaults to a 2,000 ms interval, a 0 ms random window and no device ID or timestamp, and sends these fields only for the UT-Tag role. An illustrative set-up with example values:

SESSION_INIT            id=0x00000001  type=0x00 (FIRA_RANGING_SESSION)
SESSION_SET_APP_CONFIG  id=0x00000001
  RANGING_ROUND_USAGE   (0x01, 1 octet)   = 0x00  OWR UL-TDoA
  DEVICE_ROLE           (0x11, 1 octet)   = 0x04  UT-Tag in Android's FiraParams
  CHANNEL_NUMBER        (0x04, 1 octet)   = 9     5 or 9, per site profile
  UL_TDOA_TX_INTERVAL   (0x33, 4 octets)  = 1000  ms in Android
  UL_TDOA_RANDOM_WINDOW (0x34, 4 octets)  = 100   ms in Android
  UL_TDOA_DEVICE_ID     (0x38, 1/3/5/9)   = 0x01 + 16-bit ID (none/16/32/64)
  UL_TDOA_TX_TIMESTAMP  (0x39, 1 octet)   = 0x00  none (or 40-bit, 64-bit)
SESSION_START           id=0x00000001
SESSION_STOP, then SESSION_DEINIT, before a profile switch

Three consequences follow:

• Optional fields cost airtime. The data-sheet blink spends 135 µs on its synchronisation header and 16 µs on header and payload, so 1,000 tags at 1 Hz occupy about 15 % of the channel before anchor synchronisation and any STS.
• Fixed intervals can collide repeatedly, for example after a power cut restarts a site. Use the random window and stagger start-up.
• The position is not a security proof. Qorvo’s FiRa protocol document notes that in FiRa 2.x, UL-TDoA “must use Static STS”, “based on a publicly known secSessionKey”.

Module or own design

A module usually wins for pilots and for products below a few tens of thousands of units a year. An own design wins when size, housing or unit cost dominate. In both cases, plan the firmware, test and certification work: they take most of the effort.

Battery life: turn “multi-year” into your own numbers

Qorvo describes “multi-year battery-powered operation” but publishes no current figures for the QPK3000. Build your own budget:

1. Measure the charge of one positioning event (wake-up, blink or ranging exchange, back to sleep) on real hardware.
2. Multiply by the update rate for each operating state: moving, stationary, in storage.
3. Add Bluetooth LE advertising and connections, sensor polling and the sleep current of the MCU.
4. Model the share of time in each state for the real use case, for example a hospital pump that rests most of the day.
5. Derate the battery for temperature and ageing, then validate the result with long-running current measurements.

Motion-triggered update rates usually save the most energy: a stationary tag does not need to blink every second. Keep the energy test in your release pipeline, so a firmware change that raises consumption is caught before it ships.

A worked budget from data-sheet currents

Public figures for a DW3000-class radio, plus the nRF52833 and LIS2DH12 of Zephyr’s DWM3001CDK board, give a first estimate. It is not a QPK3000 figure; replace it with measurements.

Blink, UWB:   1.5 mA x 1000 us + 8 mA x 10 us + 18 mA x 20 us
            + 48 mA x 135 us + 40 mA x 16 us                  =  9.06 uC
Blink event:  9.06 uC + 3.3 mA x 0.5 ms (MCU, assumed)         = 10.71 uC
Scenario A:   8,640 blinks moving + 1,296 still                =  9,936 per day
Blinks:       9,936 x 10.71 uC                                 =  0.106 C/day
Floor:        5.86 uA x 86,400 s                               =  0.506 C/day
Advertising:  8,640 events x 12 uC                             =  0.104 C/day
Total:        0.716 C/day = 8.3 uA average = 0.199 mAh/day
Life:         434 mAh / 0.199 mAh per day = about 2,180 days

• The floor dominates scenario A at about 70 % of the charge; the accelerometer alone draws more than all the blinks. Measure the floor first.
• The preamble is about 70 % of a blink. At the data sheet’s 1017.63 ns per symbol, 64 preamble symbols plus an 8-symbol SFD take about 73 µs instead of 135 µs (about 6 µC per blink). The profile sets the length; Android’s FiRa parameters offer 32 or 64 symbols.
• Rated capacity overstates usable capacity. The DW3000’s VDD2 needs 2.4 V and the QPK3000 2.5 V, while the 620 mAh rating runs to 2.0 V. With a 47 µF capacitor a single frame still draws 14 mA (channel 5) or 17 mA (channel 9), above the CR2450’s 9.0 mA pulse test.

Motion-triggered update rates with an accelerometer

An any-motion interrupt switches the tag to the fast interval and restarts a still timer; when it expires, the tag drops to the slow interval, and a longer timer can switch UWB off. Zephyr’s DWM3001CDK board file wires the LIS2DH12 (I²C address 0x19) with one interrupt line, so any-motion must use INT1. The LIS2DH12 data sheet gives threshold steps of 16 mg at ±2 g and duration steps of 1/ODR. Illustrative Zephyr code, where tag_post_event() feeds your state machine:

/* app.overlay: any-motion on the only wired interrupt line */
&lis2dh12 {
    anym-on-int1;
};

# prj.conf
CONFIG_SENSOR=y
CONFIG_LIS2DH_TRIGGER_GLOBAL_THREAD=y
CONFIG_LIS2DH_OPER_MODE_LOW_POWER=y
CONFIG_LIS2DH_ODR_2=y              # 10 Hz in the driver's numbering
CONFIG_LIS2DH_ACCEL_RANGE_2G=y
CONFIG_LIS2DH_ACCEL_HP_FILTERS=y

#include <zephyr/kernel.h>
#include <zephyr/drivers/sensor.h>

#define STILL_TIMEOUT K_SECONDS(60)                 /* example value */

static const struct device *accel = DEVICE_DT_GET(DT_ALIAS(accel0));

static void still_handler(struct k_work *work)
{
    tag_post_event(EV_STILL);
}
static K_WORK_DELAYABLE_DEFINE(still_work, still_handler);

static void motion_handler(const struct device *dev,
                           const struct sensor_trigger *trig)
{
    tag_post_event(EV_MOTION);
    k_work_reschedule(&still_work, STILL_TIMEOUT);  /* restart still timer */
}

int motion_init(void)
{
    static const struct sensor_trigger trig = {
        .type = SENSOR_TRIG_DELTA,                  /* any-motion */
        .chan = SENSOR_CHAN_ACCEL_XYZ,
    };
    struct sensor_value th = { .val1 = 0, .val2 = 980665 };  /* 0.1 g */
    struct sensor_value dur = { .val1 = 2 };        /* 2 samples at 10 Hz */

    if (!device_is_ready(accel)) {
        return -ENODEV;
    }
    sensor_attr_set(accel, SENSOR_CHAN_ACCEL_XYZ, SENSOR_ATTR_SLOPE_TH, &th);
    sensor_attr_set(accel, SENSOR_CHAN_ACCEL_XYZ, SENSOR_ATTR_SLOPE_DUR, &dur);
    return sensor_trigger_set(accel, &trig, motion_handler);
}

Count motion interrupts per hour in the pilot: on vibrating equipment a tag that never settles loses most of the saving.

What the tag firmware must handle beyond positioning

• Provisioning and onboarding over Bluetooth LE: identity, keys, site configuration and the standard profile to use.
• Configuration per infrastructure: FiRa or omlox profile, update rates, channel, regional transmit power settings.
• Secure boot and signed over-the-air updates, with rollback. In the EU, radio equipment has had to meet the RED cybersecurity requirements (EN 18031) since 1 August 2025, and the Cyber Resilience Act applies in full from 11 December 2027.
• Diagnostics: battery state, last successful fix, error counters and firmware version, reported to the customer’s tools.
• Phone interaction: the QPK3000 page lists last-metre finding that follows Apple’s Nearby Interaction Accessory Protocol “and Android equivalent”.

A tag firmware state machine

Write the behaviour down before the drivers. Each state fixes the UWB session, the Bluetooth LE mode and the accelerometer mode; intervals come from the site profile. An illustrative sketch:

enum tag_state { ST_SELFTEST, ST_UNPROVISIONED, ST_MOVING, ST_STILL,
                 ST_STORAGE, ST_OTA, ST_LOW_BATT };
enum tag_event { EV_SELFTEST_OK, EV_PROVISIONED, EV_MOTION, EV_STILL,
                 EV_STORAGE_TIMEOUT, EV_OTA_START, EV_REBOOT, EV_BATT_LOW };

/* State          UWB             Bluetooth LE        Accelerometer
 * SELFTEST       test frame      off                 self-check
 * UNPROVISIONED  off             connectable         off
 * MOVING         fast interval   slow advertising    any-motion
 * STILL          slow interval   slow advertising    any-motion
 * STORAGE        off             rare advertising    any-motion
 * OTA            stopped         connected           off
 * LOW_BATT       slowest         status only         any-motion */
static enum tag_state next_state(enum tag_state s, enum tag_event e)
{
    switch (e) {
    case EV_BATT_LOW:        return ST_LOW_BATT;
    case EV_OTA_START:       return ST_OTA;
    case EV_REBOOT:          return ST_SELFTEST;    /* test, then confirm */
    case EV_SELFTEST_OK:     return provisioned() ? ST_STILL : ST_UNPROVISIONED;
    case EV_PROVISIONED:     return ST_STILL;
    case EV_MOTION:          return (s == ST_STILL || s == ST_STORAGE)
                                    ? ST_MOVING : s;
    case EV_STILL:           return (s == ST_MOVING) ? ST_STILL : s;
    case EV_STORAGE_TIMEOUT: return (s == ST_STILL) ? ST_STORAGE : s;
    default:                 return s;
    }
}

Decide EV_BATT_LOW on the voltage under load, right after a blink, and log every transition with a counter for diagnostics.

Over-the-air updates on a battery budget

On Zephyr the usual route is MCUboot with MCUmgr’s Simple Management Protocol over Bluetooth LE, in the order Zephyr’s SMP server sample gives: upload the signed image, list images, mark it for test, reset, confirm. After a test swap MCUboot will, “absent a confirm command, revert back on next boot”.

• Authenticate: the sample’s Bluetooth transport is “unauthenticated”; CONFIG_MCUMGR_TRANSPORT_BT_PERM_RW_AUTHEN requires “encryption and authentication for access”.
• Own key: the sysbuild default key file points into the MCUboot module; set SB_CONFIG_BOOT_SIGNATURE_KEY_FILE.
• Revert path: in overwrite-only mode “it is not possible to revert back to previous version”.
• Flash: Zephyr’s DWM3001CDK board file (512 KB) reserves 48 KB for MCUboot, 224 KB and 216 KB for the image slots and 24 KB for storage; the QPK3000 lists 2,048 KB.
• Energy: measure one full update, refuse updates on a low battery and enable CONFIG_MCUMGR_TRANSPORT_BT_CONN_PARAM_CONTROL, recommended “if SMP is used for DFU”.

An illustrative configuration and confirm routine:

# sysbuild.conf
SB_CONFIG_BOOTLOADER_MCUBOOT=y
SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y
SB_CONFIG_BOOT_SIGNATURE_KEY_FILE="/secure/keys/tag-fw-p256.pem"

# prj.conf (excerpt)
CONFIG_MCUMGR=y
CONFIG_MCUMGR_GRP_IMG=y
CONFIG_MCUMGR_GRP_OS=y
CONFIG_IMG_MANAGER=y
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_SMP=y
CONFIG_MCUMGR_TRANSPORT_BT=y
CONFIG_MCUMGR_TRANSPORT_BT_REASSEMBLY=y
CONFIG_MCUMGR_TRANSPORT_BT_PERM_RW_AUTHEN=y
CONFIG_MCUMGR_TRANSPORT_BT_CONN_PARAM_CONTROL=y

#include <zephyr/dfu/mcuboot.h>
#include <zephyr/sys/reboot.h>

/* Run once after boot, when the self-test has finished */
void ota_confirm_or_revert(bool uwb_ok, bool ble_ok, bool battery_ok)
{
    if (boot_is_img_confirmed()) {
        return;                         /* no test image pending */
    }
    if (uwb_ok && ble_ok && battery_ok) {
        boot_write_img_confirmed();     /* keep the new image */
    } else {
        sys_reboot(SYS_REBOOT_COLD);    /* MCUboot reverts the test image */
    }
}

Testing against more than one infrastructure

A tag that works on your own anchors can still fail on a customer’s access points. Build a test plan with:

• An infrastructure matrix: at least one access-point-based system, one omlox core zone and your reference anchors, each with the firmware versions customers run.
• Positioning checks against ground truth across the update rates you sell, with the tag moving and stationary.
• Protocol visibility: capture the air interface with a UWB sniffer that decodes FiRa and omlox frames, so a failed fix can be traced to the tag, the infrastructure or the configuration.
• Long runs and battery tests, because many field problems appear after days, not minutes.
• Plugfests and test events: the first omlox plugfest, at SmartFactoryOWL in Lemgo in 2023, brought together eight companies, and FiRa runs test events for its members.

Battery-life test procedure

1. Instrument the battery line with a power analyser; Nordic’s Power Profiler Kit II covers 200 nA to 1 A at 100,000 samples per second.
2. Charge per event: at least 100 blinks per configuration, mean and maximum; repeat for advertising and a full OTA update.
3. Floor: at least 10 minutes idle, then disable peripherals one by one. Pass: within 10 % of the budget.
4. Long run: three tags for seven days on the real motion profile. Pass: within 15 % of the model.
5. Temperature and regression: repeat steps 2 and 3 at both rated temperature limits (CR2450: −30 °C to 60 °C) and fail the release build on a rise above 10 %.

Accuracy test on access-point infrastructure

1. Record access point models, firmware and positions as entered in the location engine.
2. Survey at least 20 ground-truth points, including edges, ten times more precisely than the accuracy you claim; Juniper notes that TDoA “must stay within anchor geometry for accuracy”.
3. Static: at least 100 fixes per point with the tag mounted as on the asset. Report median, 90th and 95th percentile error and availability (fixes per blink sent).
4. Dynamic: a surveyed path at the asset’s real speed; record track error and latency.
5. Repeat per profile, update rate, mounting and tag count, and judge against the customer’s requirement. ISO/IEC 18305:2016 “identifies appropriate performance metrics and test & evaluation scenarios”.

Typical failures

On Nordic’s DevZone, one developer reported a 13–18 µA sleep floor on a DWM3001C tag instead of a few microamperes; a reply suspected GPIO leakage or another device on the supply.

Certification

Plan three tracks from the start:

1. Radio regulation: FCC and ISED in North America and CE under the Radio Equipment Directive in the EU, including EN 18031 cybersecurity. A pre-certified module shortens this work but does not remove the end product’s own obligations.
2. FiRa certification for the features you claim, such as UL-TDoA or two-way ranging.
3. omlox conformity through a PI test lab, if you sell into omlox core zones. PI’s V2 compliance test specification (members only) tests “at MAC and application level (air interface only)” for “fixed satellites or mobile tags”.

From our engineering work

needCode engineers build Qorvo’s public QM35 SDK. Inside Qorvo’s UWB programme we built an RTLS with TDoA algorithms and verified TWR, TDoA and AoA on hardware-in-the-loop benches with robotic positioning. Our Modular UWB Sniffer decodes FiRa and omlox traffic, and our Device Management & OTA building block covers secure onboarding, configuration and updates with rollback.

How needCode helps

We help device makers build tags and end devices for access-point and dedicated-anchor RTLS on Qorvo silicon: positioning firmware for UL-TDoA, DL-TDoA or two-way ranging, FiRa and omlox profiles, Bluetooth LE provisioning, secure OTA and diagnostics. We set up the test plan across infrastructures with sniffer captures and long-running battery tests, and we prepare FiRa and CE/RED certification as one managed stage.

Frequently asked questions

What is the Qorvo QPK3000?

The QPK3000 is a UWB RTLS module for tags and end devices that Qorvo presented in May 2026. Its product page lists IEEE 802.15.4z UWB on channels 5 and 9, Bluetooth LE 5.4, uplink TDoA or two-way ranging, support for FiRa and omlox, a Zephyr-based software environment and SESIP Level 2. The page gives no battery life or accuracy figures.

How does UWB in Wi-Fi access points work for RTLS?

The access point carries a UWB radio and acts as an anchor. Tags send UWB signals, the access points timestamp or range them, and a location engine in the network computes positions. Qorvo says this enables location “without the need for dedicated RTLS infrastructure”, although the access points must actually include UWB.

Can one tag work with both FiRa and omlox infrastructure?

Yes, if its firmware implements both profiles. Both standards build on IEEE 802.15.4z, and Qorvo states that the QPK3000 works with both. Each profile still needs its own configuration, compliance testing and interoperability tests, and omlox version 2 is not backwards compatible with version 1.

Does the QPK3000 support DL-TDoA?

Qorvo’s product page names uplink TDoA and two-way ranging but does not mention DL-TDoA. For FiRa DL-TDoA, Qorvo staff point to the QM35 SDK. Confirm the current feature list with Qorvo for your project.

How long does a UWB RTLS tag battery last?

It depends on update rate, positioning mode, radio settings and battery size. Qorvo describes “multi-year battery-powered operation” for the QPK3000 but publishes no figures. Measure the charge per positioning event on your hardware, model your use case and validate with long-running tests.

Do I still need certification if I use a pre-certified module?

Yes. A pre-certified module simplifies radio testing, but the end product still needs its own regulatory declarations, and FiRa or omlox conformity applies to the product’s features and firmware. As of October 2026 Qorvo lists the QPK3000’s FCC, ISED and ETSI listing as pending.

How often should a UL-TDoA tag blink?

As often as the use case needs a position, because each blink yields one. FiRa describes rates from “many times per second” to “once a day”, and Android’s UWB stack defaults to 2,000 ms. Use an accelerometer to switch between a fast moving rate and a slow still rate.

Is a UL-TDoA position secure enough for access control?

Not on its own. Qorvo’s FiRa protocol document notes that in FiRa 2.x, UL-TDoA must use static STS, which is based on a publicly known key. For access decisions use two-way ranging with a dynamic or provisioned STS, or another authenticated check.

Sources

1. Qorvo: “Qorvo Transforms Enterprise Wi-Fi Access Points into Scalable UWB RTLS Infrastructure” (18 May 2026)
2. Qorvo QPK3000 product page
3. Qorvo Tech Forum: “DWM3001CDK — availability of TDoA example / reference code” (staff reply, August 2026)
4. FiRa Consortium: FiRa Core 4.0 specifications and certification program (December 2025)
5. FiRa Consortium launches Certification Program 2.0 (Business Wire, December 2023)
6. FiRa Consortium: omlox (PI) and FiRa join forces (March 2025)
7. PI: omlox, the open localization standard
8. PI: omlox Core Zone Specification (versions and notes)
9. PI: omlox version 2.0 (November 2022)
10. PI: world’s first omlox test lab (February 2024)
11. Fraunhofer IOSB-INA: first omlox plugfest (June 2023)
12. Juniper AP47 announcement (September 2024, Silicon UK copy)
13. HPE Aruba Networking 730 Series QuickSpecs (August 2026)
14. Wi-Fi NOW: “Enterprise Wi-Fi: Ultra-wideband (UWB) poised to power a raft of innovative use cases, Qorvo says” (April 2025)
15. Qorvo: QPK3000 Fully Integrated UWB RTLS Module, product brief Rev B (March 2026)
16. DW3000 Datasheet, version 1.3 (Decawave/Qorvo, Mouser copy)
17. DW3000 Datasheet, version 1.1 (Decawave/Qorvo, LCSC copy; power profiles in figures 26, 28 and 30)
18. FiRa Consortium: UWB Asset Tracking leaflet (2023)
19. Qorvo QM35 SDK: UWB Command Interface (UCI) Specification, release R12.34.0 (July 2025)
20. Qorvo QM35 SDK: UWB FiRa Protocol, release R12.34.0 (July 2025)
21. Android Open Source Project: UCI packet definitions (uci_packets.pdl)
22. Android Open Source Project: FiraParams.java
23. Android Open Source Project: FiraOpenSessionParams.java
24. Android Open Source Project: FiraEncoder.java
25. Juniper Mist documentation: Ultrawideband
26. Juniper Mist documentation: Enable Ultrawideband
27. STMicroelectronics: LIS2DH12 data sheet (DocID025056 Rev 6)
28. Nordic Semiconductor: nRF52833 Product Specification, sleep current
29. Nordic Semiconductor: nRF52833 Product Specification, CPU running current
30. Nordic Semiconductor: nRF52833 Product Specification, radio current
31. Energizer: CR2450 product data sheet
32. Zephyr: decawave_dwm3001cdk board devicetree
33. Zephyr: LIS2DH devicetree binding (st,lis2dh-common.yaml)
34. Zephyr: LIS2DH driver, Kconfig and trigger code
35. Zephyr: public API headers (kernel.h, device.h, drivers/sensor.h, dfu/mcuboot.h, sys/reboot.h)
36. Zephyr: SMP server sample documentation
37. Zephyr: SMP server sample configuration (prj.conf, bt.conf)
38. Zephyr: MCUmgr Bluetooth transport Kconfig
39. Zephyr: sysbuild MCUboot Kconfig
40. Zephyr: sysbuild documentation
41. Zephyr: MCUmgr documentation
42. Nordic Semiconductor: Power Profiler Kit II
43. ISO/IEC 18305:2016, Test and evaluation of localization and tracking systems
44. Nordic DevZone: “Power consumption – DWM3001C” (user thread, 2026)
45. PI: omlox V2 Core Zone Compliance Test Specification

About needCode

needCode is an independent embedded engineering company from Kraków, Poland, and an official UWB business partner of Qorvo. Its engineers have worked inside Qorvo’s wireless programmes for more than eight years, including on the public QM35 SDK. needCode is certified to ISO 9001:2015 and ISO/IEC 27001:2022 and is a member of the UWB Alliance. This article does not represent Qorvo. All trademarks belong to their respective owners.