Replacing PANS: migration options for DWM1001C and MDEK1001 RTLS deployments

Short answer

PANS still runs on DWM1001C modules, which remain in production, but the platform is ageing: the MDEK1001 kit is end of life, the DW1000 radio is Not Recommended for New Designs, the gateway needs a Raspberry Pi 3 Model B, and Qorvo has not published PANS for its DW3000- or QM33-based modules.

Four ways forward: buffer stock, LEAPS RTLS, your own stack on newer Qorvo silicon, or a cloud location engine. Migrate zone by zone behind a compatibility layer that keeps MQTT and API consumers unchanged.

Key facts at a glance

What PANS is, and why replacing it is harder than it looks

PANS, the Positioning and Networking Stack, is the firmware that turned Decawave’s DWM1001 module into a complete real-time locating system (RTLS). The same module can be configured as an anchor, a tag or a bridge, and one anchor acts as the initiator that starts the network. A gateway built from a DWM1001-DEV board and a Raspberry Pi 3 Model B connects the UWB network to an IP network. Qorvo’s documentation notes that the Raspberry Pi 3B+ is not supported.

Applications reach PANS in two ways: an external API over UART, SPI or Bluetooth LE, and an on-board user application written in C. The Android app DRTLS Manager configures the nodes. The last major release, PANS R2, shipped as a firmware image, an Android app and a Raspbian image.

The DWM1001 system overview documents its limits:

• Ranging method: single-sided two-way ranging (TWR), with each tag ranging to up to four anchors. A position needs at least three anchors.
• Update rate: a maximum location rate of 10 Hz per tag; the documented example is 15 tags at 10 Hz.
• Code access: PANS is a pre-built library. The firmware user guide states that Decawave “does not provide the library source code, or support any use of the PANS library except through the PANS API”.
• Licence: a free, non-exclusive licence for use only in systems and products based on Decawave semiconductor products.

That is why a replacement is more than a firmware swap. A product built on PANS depends on its API, its network management, its gateway behaviour and its location engine. Each of those has to be reproduced or replaced, and the integrations that consume its data must keep working.

The 100 ms superframe and its limits

PANS is a TDMA network. The initiator sets a 100 ms superframe with 30 beacon slots (one per anchor “seat”), two service slots, 15 ranging slots and 30 bridge-node beacon slots. Each ranging slot carries one tag’s exchange with four anchors, so a cluster delivers at most 150 fixes per second. A tag without a free slot retries every 60 seconds, and Qorvo staff confirmed that one tag cannot exceed 10 Hz without fully custom firmware. Other limits to match, or consciously drop:

• Anchors: 30 seats within mutual radio range, reusable farther apart; synchronisation hierarchy up to clock level 127.
• Radio: channel 5 (6.5 GHz) only, 6.81 Mbps, 64 MHz PRF.
• Location engine: on the tag, three or four ranges, maximum likelihood estimation, quality factor 0–100, average of the last three results.
• Data: 34 bytes of IoT data per exchange; 100 ms latency from tag to gateway.

Four API surfaces

All interfaces feed one internal Generic API:

• UART TLV at 115200 baud is the default. Enter twice within one second opens a text shell, quit leaves it, and a request ends after about 763 µs of silence.
• SPI TLV runs as a slave at up to 8 MHz: write the request, poll SIZE/NUM, read the response.
• BLE GATT uses service 680c21d9-c946-4c1f-9c11-baa1c21329e7; DRTLS Manager relies on it.
• On-board C runs on eCos with at most five threads, 5 kB of RAM and 40 kB of flash, built with GNU Arm Embedded Toolchain 5.4 2016q3.

Positions are little-endian int32 millimetres plus a quality byte, rates use units of 100 ms, and every response starts with an error code from 0 (OK) to 5:

dwm_upd_rate_set (1 s / 5 s stationary)  03 04 0A 00 32 00

  response                               40 01 00

dwm_loc_get                              0C 00

  response from a tag (abridged)         40 01 00             err_code 0

                                         41 0D <x y z qf>     int32 LE mm, qf 0-100

                                         49 51 04 <4 x 20 B>  addr, dist, qf, anchor pos

dwm_cfg_get                              08 00

  response                               40 01 00 46 02 <cfg_node>

The gateway and its MQTT contract

LEAPS, which wrote much of the stack, described the gateway path on Qorvo’s forum: bridge node, Linux kernel module, one DWM daemon per gateway, one DWM proxy per network, then the MQTT broker and its clients. Settings live in /etc/dwm1001/:

# /etc/dwm1001/dwm1001.config, values as shown in the Gateway Quick Deployment Guide

panid = 0x1234                    # must match the network’s PAN ID

enc_en = false                    # UWB encryption off

enc_key = “11111111222222223333333344444444”

uwb_fwup = true

uwb_mode = 2                      # 0 = off, 1 = passive, 2 = active

proxy_server_host = “localhost”   # other gateways point at the proxy host’s IP

proxy_server_port = 1885

mqtt_user = “dwmuser”

mqtt_password = “dwmpass”

mqtt_topic_prefix = “dwm”

# Location message from the gateway guide; IoT downlink as LEAPS showed it

# (“ASNFZ4mrze8=” is base64 for 01 23 45 67 89 AB CD EF)

dwm/node/031e/uplink/location

{“position”: {“x”: 2.1618538, “y”: 1.5142754, “z”: 1.0212752, “quality”: 50}}

echo ‘{“data”:”ASNFZ4mrze8=”,”overwrite”:false}’ | \

  mosquitto_pub -h localhost -p 1883 -t ‘dwm/node/11cb/downlink/data’ -l

Clients connect on port 1883, the default for plain MQTT. Node topics follow dwm/node/<id>/uplink/… and dwm/node/<id>/downlink/… (listed in the FAQ), with positions as floats in metres and user data in base64. LEAPS notes that configuration downlinks are confirmed and retried, while user data is not.

The gateway is also the weakest lifecycle link. Qorvo staff said in 2020 that the gateway application is only compatible with the Raspberry Pi 3 Model B and that there was no plan to port it. Its documented defaults are not production-grade either: SSH login pi/raspberry, plain MQTT, and no BLE together with UWB encryption.

What changed in 2025 and 2026

Three facts changed the economics of staying on PANS.

1. The development kit is gone. PCN 25-0154 ended the MDEK1001, a kit of 12 DWM1001-DEV boards in enclosures, citing “lack of demand”. The last time buy date was 15 June 2026 (the product page later showed 15 July 2026) and the last shipment date is 15 December 2026. No replacement part is named.
2. The radio underneath is NRND. The DWM1001C is still in production, but the DW1000 inside it is no longer recommended for new designs.
3. Qorvo points elsewhere for PANS-style systems. When a developer asked on Qorvo’s forum about a migration path from DWM1001C and PANS to the DWM3001C, the reply sent them to their local Qorvo sales representative for the DWM3001 longevity plan and added that “Leaps has a solution built around the QM33/DW33 family used in the DWM3001C”. Nobody in that thread confirmed a PANS build for the DWM3001C.

Two broader trends point the same way. Qorvo narrowed its UWB focus to automotive, industrial and enterprise markets in November 2025. And China’s UWB provisions, in force since 1 August 2025, limit new approvals to 7,163–8,812 MHz, a band that none of the DW1000 channels reach.

Four ways forward

Option 1: stay on PANS and buy stock

This is a legitimate choice for an installed base that works and a product that is near the end of its life. The DWM1001C has no end-of-life notice yet. On Qorvo’s forum, LEAPS advised users who need DWM1001-DEV boards to buy them “earlier than later”, since there is no official information about their end of life.

The risks are structural. You cannot fix vulnerabilities inside a binary stack, which matters under the EU Cyber Resilience Act: reporting obligations apply from 11 September 2026, and manufacturers must handle vulnerabilities in the components they integrate. The radio cannot do secure ranging, so PANS devices will never interoperate with FiRa infrastructure or phones.

Two points reduce the risk. Flash new stock with your network’s exact image before installation, because mismatched firmware either updates over UWB while the node is offline or, with updates disabled, can cause compatibility problems. And if the Raspberry Pi gateway is the weak point, LEAPS’ PANS PRO RTLS, the production version of PANS, is listed as PANS-compatible and uses a dedicated gateway such as the LC5A.

Option 2: license LEAPS RTLS

LEAPS, based in Prague, describes itself as “the creators of Qorvo’s DWM1001 and PANS RTLS”, and the PANS licence documentation confirms that the stack incorporated source code licensed to Decawave by Leaps s.r.o. Its current stack supports two-way ranging, uplink TDoA and downlink TDoA. LEAPS’ own comparison lists up to 50 Hz for UL-TDoA and DL-TDoA, against up to 10 Hz for PANS TWR.

LEAPS RTLS runs “out of the box” on the DWM1001C, DWM3001C, Murata Type2AB and Insight SiP ISP3080, according to the company’s reply on Qorvo’s forum. It is licensed as binary code, royalty-free when modules are pre-loaded, and LEAPS states that it “does not support User Applications”. LEAPS also offers a support programme for products built on LEAPS RTLS, PANS RTLS or the DWM1001.

Two details matter for migration planning. First, LEAPS’ comparison page lists LEAPS RTLS as not compatible with PANS RTLS, so a mixed network needs a zone-by-zone plan. Second, Qorvo’s QM33120WDK2 kit, the “UWB Design Kit” with six devices that evaluates DL-TDoA, UL-TDoA and TWR, is LEAPS’ development kit, which is why Qorvo recommends it for a PANS-like experience.

Option 3: build your own stack on Qorvo’s newer silicon

Owning the stack gives you control over features, update rate, security and the product roadmap. It also means building what PANS gave you for free: ranging scheduling, anchor synchronisation for TDoA, a location engine, network management, OTA updates, a gateway and diagnostics.

Qorvo’s public SDKs help with the radio, not with the system. The DW3_QM33 SDK supports FiRa ranging on the DWM3001CDK, QM33120WDK1 and Murata Type2AB, but Qorvo confirmed in June 2026 that it has no TDoA example for the DWM3001C: “the DWM3001C is just as capable as the LEAPS kit in making a TDoA system. It’s just that we (Qorvo) don’t have any example to use as a starting point.”

Option 4: a cloud location engine

Some deployments move positioning out of the device and into the cloud. In February 2026, Dublin-based Danalto announced that its Cardinal Cloud Location Engine had been integrated with Qorvo’s latest UWB SoC and its industrial and enterprise SDK. Qorvo is also pursuing infrastructure-led RTLS: in May 2026 it presented UWB built into enterprise Wi-Fi access points, with the QPK3000 module for tags. These approaches suit enterprise sites with IT integration needs. You still need firmware for tags, a deployment plan and someone to own the device side.

How to choose: seven questions to answer first

1. How long must the product ship and be supported? Under the CRA the support period is at least five years unless the product is expected to be used for less. A binary stack makes that period harder to honour.
2. Do you need to change the stack’s behaviour? Custom features, new sensors or tight integration favour owning the code.
3. What update rate and tag count do you need? PANS is documented at 15 tags at 10 Hz. TDoA scales further because tags only transmit and anchors do the timing work.
4. TWR, TDoA or AoA? The answer drives anchor density, synchronisation and tag battery life.
5. Do you need phone interoperability? FiRa sessions, Apple Nearby Interaction and Android’s ranging API all require 802.15.4z features that the DW1000 lacks.
6. Where will you sell? China’s band rules favour channel 9, and certifications differ per market.
7. Which cost model fits? Per-device licences and royalties against an engineering investment you own, and who handles vulnerabilities over the support period.

A migration path off PANS

1. Inventory the deployment. Record firmware versions, node roles, anchor layouts and every PANS API call your applications use. List the consumers of gateway data, such as MQTT topics, dashboards and enterprise integrations.
2. Define the target architecture. Choose the ranging method, the synchronisation scheme and where the location engine runs: on the tag, at the gateway or in the cloud.
3. Protect your integrations. Put a compatibility layer between the new system and existing consumers, so the back end keeps receiving the same data format while the radio layer changes.
4. Pilot side by side. Compare accuracy, update rate, latency and battery life in one zone, with the old and new systems running in parallel.
5. Migrate zone by zone. PANS does not share a network with LEAPS RTLS or with a stack of your own, so move whole areas at a time and keep a rollback plan.
6. Build in diagnostics and OTA. The new system should be easier to support than the old one: remote logs, status reports and safe firmware updates.

Step 1 in practice: measure what the deployment uses

The inventory should prove which part of PANS you actually use:

1. Node state: shell output from every anchor, initiator and bridge and a sample of tags, kept as restore data for a rollback.
2. Gateway: both files in /etc/dwm1001/ and the Raspberry Pi model.
3. Traffic: a working day of dwm/# with receive times and retained flags, which also collects every node’s config and status messages.
4. Code: dwm_ calls, raw TLV bytes, the BLE service UUID and dwm/ topic strings in host firmware, back ends and apps. An on-board application needs a full port.

# 1) Per node, UART shell (115200 baud; press Enter twice within one second)

si      # fw_ver, cfg_ver, panid, addr, mode, enc, ble, fwup, label

nmg     # node mode; “le” or “nole” shows the location engine state

aurg    # update rate and stationary update rate, in units of 100 ms

apg     # stored position in mm and quality factor

la      # anchor list: seat, cluster maps, firmware version and checksum

stg     # health counters: twr_ok, twr_err, rx_err, enc_err, cl_coll …

quit    # back to TLV mode

# 2) One working day of gateway traffic: receive time, retain flag, topic, payload

mosquitto_sub -h 192.168.1.20 -p 1883 -t ‘dwm/#’ -F ‘%U %r %t %p’ > pans-day.log

# 3) Topic families and message counts

awk ‘{print $3}’ pans-day.log | sed -E ‘s#/node/[0-9a-fA-F]+/#/node/<id>/#’ \

  | sort | uniq -c | sort -rn

# 4) PANS calls in host code

grep -rhoE ‘\bdwm_[a-z0-9_]+\(‘ src/ | sort | uniq -c | sort -rn

Designing the compatibility layer

Put the layer where consumers already integrate:

Qorvo staff and LEAPS have both steered gateway users to MQTT rather than the bridge’s SPI link. LEAPS publishes an MQTT migration guide from PANS PRO, whose topics share the PANS dwm/node/<id>/… layout, to LEAPS RTLS. It lists what an adapter must absorb: a network ID in the topic with the device ID moved to the end, coordinates under location instead of position, no superFrameNumber, and location and status published without the retained flag. It also advises a staging rehearsal and a fallback adapter until consumption is stable. An illustrative adapter:

# Illustrative adapter: republish a new stack’s locations in the PANS gateway format.

# Source topics follow the LEAPS RTLS MQTT guide; change SRC for another stack.

import json

import paho.mqtt.client as mqtt

PREFIX = “rtls”                          # set to the new stack’s topic prefix

SRC = PREFIX + “/+/node/uplink/location/+”   # <prefix>/<network>/…/<device>

ID_MAP = {“NEW-ID-0001”: “031e”}         # new device ID -> PANS node ID in the back end

def on_connect(client, userdata, flags, reason_code, properties):

    client.subscribe(SRC, qos=0)

def on_message(client, userdata, msg):

    node = ID_MAP.get(msg.topic.rsplit(“/”, 1)[-1])

    if node is None:

        return                           # not migrated yet: PANS still publishes it

    loc = json.loads(msg.payload)[“location”]

    out = {“position”: {k: loc[k] for k in (“x”, “y”, “z”, “quality”)}}

    client.publish(f”dwm/node/{node}/uplink/location”, json.dumps(out),

                   qos=0, retain=True)   # QoS 0 and retained, as PANS PRO publishes it

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)

client.on_connect = on_connect

client.on_message = on_message

client.connect(“localhost”, 1883)

client.loop_forever()

A TLV emulator must also copy PANS framing: 763 µs of silence ends a UART request, one extra byte (UART) or a chip-select pulse of at least 35 µs (SPI) wakes a sleeping module, and SPI hosts poll SIZE/NUM. An illustrative answer to dwm_pos_get:

/* Illustrative: answer a PANS dwm_pos_get request (02 00) from a new stack’s fix.

 * Layout from the DWM1001 Firmware API Guide: 40 01 err, then 41 0D x y z qf. */

#include <math.h>

#include <stddef.h>

#include <stdint.h>

static void put_i32le(uint8_t *p, int32_t v)

{

    p[0] = (uint8_t)v;

    p[1] = (uint8_t)(v >> 8);

    p[2] = (uint8_t)(v >> 16);

    p[3] = (uint8_t)(v >> 24);

}

size_t pans_pos_get_rsp(uint8_t out[18], float x_m, float y_m, float z_m, uint8_t qf)

{

    out[0] = 0x40; out[1] = 0x01; out[2] = 0x00;        /* TLV_TYPE_RET_VAL, err 0 */

    out[3] = 0x41; out[4] = 0x0D;                       /* TLV_TYPE_POS_XYZ, 13 B */

    put_i32le(&out[5],  (int32_t)lroundf(x_m * 1000.0f));  /* millimetres */

    put_i32le(&out[9],  (int32_t)lroundf(y_m * 1000.0f));

    put_i32le(&out[13], (int32_t)lroundf(z_m * 1000.0f));

    out[17] = qf;                                       /* quality factor 0-100 */

    return 18;

}

Zone-by-zone runbook, acceptance tests and rollback

First measure the PANS baseline in every zone and run the adapter in shadow mode under a separate prefix. Then, per zone:

1. Plan the boundary. Edge anchors also serve tags in the neighbouring PANS zone; keep them until it migrates. If the active initiator is in the zone, configure another with nmi and restart the remaining network in a maintenance window, because PANS documents initiator election only at start-up.
2. Install alongside PANS. PANS is fixed to channel 5. Where your stack and markets allow, run the new zone on channel 9, which the DWM3001C supports, and watch the stg error counters of nearby PANS anchors.
3. Shadow run. Put a PANS tag and a new tag on the same carriers and run the tests below.
4. Cut over. Map the zone’s node IDs to the new stack in the adapter and retire its PANS tags.
5. Soak, then decommission the PANS anchors that no remaining zone needs.

PANS reference values: under 10 cm typical X-Y accuracy in line of sight and 100 ms tag-to-gateway latency (system overview); server-side latency of the update period plus 50 ms and over 99% of fixes at 10 Hz on a correct installation (LEAPS). ISO/IEC 18305:2016 defines metrics and test scenarios for indoor localisation and tracking systems. To check update rates on the step 1 capture:

# Fixes and longest gap per tag, from the mosquitto_sub capture (%U %r %t %p)

awk ‘$3 ~ /uplink\/location$/ {

       if ($3 in t && $1 – t[$3] > gap[$3]) gap[$3] = $1 – t[$3]

       t[$3] = $1; n[$3]++ }

     END { for (k in n) printf “%s fixes=%d max_gap=%.2fs\n”, k, n[k], gap[k] }’ \

    pans-day.log

Set rollback triggers before cut-over, such as a metric below baseline for a full shift. Rollback means pointing the adapter back at PANS topics, re-enabling the zone’s PANS tags and restoring node settings from the inventory:

# Restore a node from the inventory (UART shell; aps takes millimetres)

nis 0x1234        # PAN ID first: the role commands reset the node

aps 0 0 1800      # anchor position x, y, z

nma               # or nmi / nmb / nmt, as recorded

aurs 10 50        # tags: 1 s update rate, 5 s stationary rate (units of 100 ms)

# DWM1001C hardware that was reflashed: J-Flash Lite, target nRF52832_XXAA,

# SWD at 1000 kHz, data file DWM1001_PANS_R2.0.hex (needs physical access)

From our engineering work

Inside Qorvo’s UWB programme, needCode engineers developed an RTLS solution using TDoA algorithms, one-way-ranging angle of arrival, data transfer and multi-session scheduling. We validate ranging on hardware-in-the-loop benches with robotic positioning for TWR, TDoA and AoA.

Our building blocks include Autopositioning Anchors, where only the master anchor is set against a reference point and the others locate themselves, running over Wi-Fi and on batteries. They also include the UWB Precision Location Pack, with ranging algorithms, calibration tools and RTLS APIs for positioning below 30 cm.

Typical migration failures and how to diagnose them

How needCode helps

We help PANS users decide and move. A 2–4 week Product Assessment inventories your parts, firmware and integrations, compares the four options for your case and ends with a 90-day plan. If you build your own stack, we deliver it as a phased Upgrade or Extend project with HIL validation, certification support and a zone-by-zone transition plan. If a licensed stack such as LEAPS RTLS fits better, the assessment will say so.

Frequently asked questions

Does PANS run on the DWM3001C?

Qorvo has not published a PANS build for the DWM3001C. When asked on Qorvo’s forum, Qorvo referred the developer to sales for the DWM3001 longevity plan and to LEAPS, whose stack runs on the DWM3001C. For PANS-like evaluation on newer silicon, Qorvo recommends the QM33120WDK2 kit.

Is the DWM1001C end of life?

No. In October 2026 Qorvo lists the DWM1001C and the DWM1001-DEV board as in production, with no end-of-life notice. The MDEK1001 kit is end of life, and the DW1000 inside the module is Not Recommended for New Designs.

What replaces the MDEK1001 development kit?

Qorvo named no replacement in PCN 25-0154. For a PANS-like RTLS evaluation, Qorvo points to the QM33120WDK2, a six-device kit that demonstrates DL-TDoA, UL-TDoA and TWR. For development on the DWM3001C module, Qorvo offers the DWM3001CDK.

Can PANS and LEAPS devices work in the same network?

Plan for no. LEAPS’ own comparison lists LEAPS RTLS as not compatible with PANS RTLS. Migrate whole zones at a time and keep the data format seen by your back end stable through a compatibility layer. LEAPS’ PANS PRO RTLS, by contrast, is listed as compatible.

Can I get the PANS source code?

No. PANS ships as a pre-built library, and the DWM1001 firmware documentation states that the library source code is not provided. Only the user application and examples come as source.

Is TDoA better than TWR for large deployments?

Usually, for many tags. In TDoA, tags only transmit short messages and synchronised anchors measure arrival times, which saves tag energy and scales to more tags. TWR needs no anchor synchronisation and is simpler to deploy. PANS uses single-sided TWR, documented at up to 10 Hz per tag.

Which MQTT topics does the PANS gateway publish?

Each node has dwm/node/<id>/uplink/location, /status, /config and /data, plus the matching downlink/config and downlink/data; each gateway publishes dwm/gateway/<id>/uplink. Positions are floats in metres and data is base64. The PANS guides do not list the topics, so capture dwm/# on a running system first.

Can the PANS gateway run on a Raspberry Pi 4 or 5?

No. Qorvo supports only the Raspberry Pi 3 Model B, and LEAPS says newer models break the kernel module’s timing; a 3B+ works only with Ethernet disabled. Raspberry Pi states production of the 3 Model B until at least January 2028.

How do I get raw ranges out of PANS for side-by-side tests?

On the tag. dwm_loc_get (TLV 0x0C) over UART or SPI returns each anchor’s distance and position, and the shell commands les and lec print them. According to LEAPS, only positions travel over UWB, so ranges never reach MQTT unless an on-board application sends them as IoT data.

Sources

1. Qorvo PCN 25-0154: MDEK1001 end of life and MDEK1001 product page
2. Qorvo DWM1001C product page and DWM1001-DEV product page
3. DWM1001 System Overview (forum attachment)
4. DWM1001 Firmware API Guide, Firmware User Guide and Gateway Quick Deployment Guide (mirrors)
5. Qorvo Tech Forum: “Migration path from DWM1001C/PANS to DWM3001C”
6. Qorvo Tech Forum: “Mdek1001 deprecated?”
7. Qorvo Tech Forum: “DWM3001C series positioning firmware”
8. Qorvo Tech Forum: “Success with DWM3001 TDoA firmware?”
9. Qorvo Tech Forum: “Qorvo DW1000: Recommended for New Designs?”
10. LEAPS home page, LEAPS FAQ, LEAPS RTLS FAQ and LEAPS comparison
11. LEAPS RTLS specification v1.0
12. Qorvo QM33120WDK2 product page and DWM3001CDK product page
13. Qorvo Tech Forum: DW3_QM33 SDK v1.0.2 release
14. Qorvo: Danalto Cardinal integration with Qorvo’s UWB SoC (11 Feb 2026)
15. Qorvo: UWB in enterprise Wi-Fi access points and the QPK3000 (18 May 2026)
16. Qorvo Q2 FY2026 earnings call transcript (3 Nov 2025)
17. CAICT: China’s UWB equipment provisions
18. Qorvo Tech Forum: “Raspberry Pi 4 compatibility”
19. Qorvo Tech Forum: “DWM1001 Raspberry Pi Model 4 Gateway?”
20. Qorvo Tech Forum: “DWM1001 Gateway on RPi 3B+ (Ethernet Interrupts)”
21. Qorvo Tech Forum: “Gateway solution without Raspberry Pi 3B?”
22. Raspberry Pi 3 Model B product page (obsolescence statement)
23. Qorvo Tech Forum: “10 000 m² area to cover with RTLS web manager also”
24. Qorvo Tech Forum: “Downlink data from bridge to tag”
25. Qorvo Tech Forum: “Documentation on MQTT topics and message payloads”
26. Qorvo Tech Forum: “mqtt_topic_prefix” name
27. Qorvo Tech Forum: “IoT data exchange vía SPI”
28. Qorvo Tech Forum: “Getting ranges to anchors on a MQTT topic on PANS 2”
29. Qorvo Tech Forum: “PANS R2 – Record tag positions on highest update rate from gateway?”
30. Qorvo Tech Forum: “150 Hz with only 1 Tag (MDEK1001)”
31. Qorvo Tech Forum: “Extract data from DWM1001 running PANS firmware”
32. LEAPS: MQTT Migration Guide (PANS PRO RTLS to LEAPS RTLS)
33. LEAPS: PANS PRO RTLS, PANS PRO MQTT Connector and PANS PRO specification
34. Qorvo DWM3001C product page
35. ISO/IEC 18305:2016, Test and evaluation of localization and tracking systems
36. Eclipse Mosquitto: mosquitto_sub manual
37. Eclipse Paho MQTT Python client documentation and migration notes

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 reflects public sources and needCode’s own engineering work; it does not represent Qorvo, LEAPS or any other company named. All trademarks belong to their respective owners.