Getting to grips with DWM1001: various Questions

Hi folks,

Am trying to work out how the DWM1001 works and have a some questions that I need to understand before I can start developing a custom app:

  1. How does the Deca stuff interact with the BLE? Can you add custom BLE characteristics in exactly the same you do with the Nordic soft device (of which I have some experience) .

I would assume that you set up a custom characteristic (CC), data pops out of the Deca stack, then you pass it to the LE CC using the user thread as the way of knitting it together, but it also talks about these TVL packets being passed straight from LE to Deca. This makes me think that maybe you can only use the preprogrammed Deca code to talk over LE to other LE devices.

  1. It looks like the Deca is connected to the nRF via SPI so I am assuming that the Deca libraries on the nRF take care of all that comms. I am not clear whether the DW1000 processes all the data and spits out x,y,z data over SPI or whether it squirts raw data out and the nRF libs process that data which is then passed to the LE libs as x,y,z co-ordinates. Or passes it to the UART. Or the user thread. Or all three possibly.

  2. Is there any source code that has the Nordic set up or is that done in the Deca libs that run on the nRF? If the latter, then that probably means the answer to q1 is that you cannot do anything with LE other than what Deca have told us we can do.

  3. Can a “roaming” token, ie one that is being tracked by the anchors send out data over LE? This is what we want to do as with our set up the LE target could be out of range of the initiator, but will always be right next to the “roaming” device.

I might not have all the terminology correct here, apologies if not.

Many thanks for any advice. If anything is unclear because of my inexperience of this product, then please ask me to clarify.

On question 2:

The DW1000 has no real processing capability, it’s basically a radio which can very accurately time stamp transmission and reception times. The libraries configure it, tell it what data packet to send, read the data packets received, read the packet times and do all of the distance and position calculations.

All the information on how to do that is in the DW1000 datasheet/user manual so in theory you could write your own library and not be limited to how decawave has done things but that’s a lot of work.

I’ll leave BLE and DWM1001 specific questions to those more familiar with them.


Thanks Andy. Much appreciated.

Thorowing this out to everyone, this is alarming

It surely cannot be that it’s not possible to add LE custom characterstics? It’s a relatively straightforward thing to do with the soft device. Surely, surely you haven’t locked it down to prevent you being able to do this?

Are there even some general purpose characteristics we can get at?

Alternatively, can we just add the PANs library as linkable library to, say, a standard FreeRTOS project running the soft device? Pull the data out of the Deca APIs and pass it to the custom characteristics?

If not, the whole system is hugely flawed and far too locked down to be very useful.

Hi DiBosco,

I’m afraid at the moment the BLE gatt model cannot be customized, sorry for that. There is no plan to modify that at the moment but I’ll update the topic if it changes in the future.


Hi Yves,

Thanks for the reply, much appreciated.

Can I ask why it would be so difficult to add another service and a couple of general purpose characteristics to the system? I have created custom characteristics on the nRF and while it’s not trivial, I think now I have the experience I could knock one up in a day without any difficulty.

This would not affect in any way the basic way your system worked, but give users the opportunity to send their own data. If you made simply two characteristics of a decent size (say 230 bytes) - one read, one write - as is available with the latest BT, people could use it to send any sort of data with their own protocol used in the characteristic. You could then have an API call to write to and read from those characteristcs. This would not be a big job for your software engineers at all.

Of course, as an end user I am absolutely bufuddled why a silicon manufacturer would want to lock down their software at all, surely you want people to use and buy your devices? Providing the source code in ANSI C so it can be ported to any processor seems like the most basic common sense thing to do to sell more silicon to my simple mind!

Merci pour votre assitance. :slight_smile:

Keep in mind there are two arms to their business.

Selling chips and selling position solutions - often in partnership with another company.

If all they sold were DW1000 chips or modules which are basically just the chip on a board to make it easier to use like the DWM1000 then making all of their code available would make sense.

But those parts are cheap, no a lot of margin there.

However you can sell a positioning solution and integrated modules at far higher margins. But when you do that you don’t want to give away all of your IP. If it was open source it would make it too easy for someone to make a very similar board, run your software on it and sell the same basic thing for less since they didn’t need to do anywhere near as much development.

I’d say they’ve got a reasonable compromise, there is code available for an API library that gives you access to the chip if you want to implement your own system. That is all you need to use the chip (well technically you don’t even need that, I’ve not used it).
Giving away the code to a full positioning system is a different matter, that would cut into the sales of higher margin modules and probably annoy some of their design partners who want to sell you systems.

I see the point you’re making, Andy, but we’re not the first people on the forum to ask about custom characteristics. To my mind it’s just going to put people off using the products in the first place because it won’t do what they need and that’s far more damaging to sales.

They’re not exactly cheap parts either! 1k figure is £4.71 from Digikey who are generally not outrageous price-wise.

It’s possible that we could do absolutely everything we wanted with an nRF52 and a DW chip if we could hook up the acceleromter we wish to use and send that info out over LE along with the DW info. However, we can’t, which essentially makes the project a non-starter.

How many other companies are looking at this and thinking the same thing? It’s impossible to know for sure, but every time it happens they’re throwing sales away.

In this particular instance it’s not even the DW code that we particularly want access to, it’s the ability to add custom LE characteristics which would be done through Nordic’s stack; we can’t even do that because that’s somehow been locked down even more than Nordic manage it! Everything seems to be set up for a very limiting specific system and that seems a shame to me as it’s otherwise a neat idea!

Hi guys,

The main reason for PANS customization to be limited is to ensure users cannot break the TDMA scheme and the whole localization system by adding high priorities functionalities.

In order to perform correctly, each node belonging to the network must respect a very accurate timing. The nordic softdevice has the highest priority and any wrongly timed interrupt will actually impact the UWB performance, potentially break the communication scheme between devices. For the best localization performance we would actually recommend not to use the ble and disable it. (BLE would be used for network deployment only).

PANS is a fairly complex software project and we don’t have the bandwidth to support advanced customization of it, so we took the decision to provide it as a compiled library/api.

We will discuss the possibility of adding some characteristics for customization but at the moment we cannot support this.

DiBosco, keep in mind Decawave is a semicondutor company,. We are developing and providing software solutions to enable the market and demonstrate UWB potential to customers, but it is difficult for us to supports all the customers request.

If you need further BLE features as well as UWB, you may have to develop a fully customized stack. This may require an extensive design effort but this is the path selected by several of our customers.

I guess your best option at the moment is maybe to use a host mcu for the dwm1001 that would also have a BLE chip. I understand it is not optimized in term of resources but it is probably the shortest path to get a PoC or early design.

Hope it helps,

Hi guys,

I agree with all of you guys. Let me respond to your questions DiBosco:

  1. The PANS controls completely the BLE interface and there is no option at the moment to send data via user characteristics. The list of restricted and available interfaces are listed here:
    SoftDevice also restricts or blocks a certain interface for the same reason. The BLE would not work correctly if you let the user do what they want.
    The SoftDevice idea is in general obsolete and it really limits the range of real-time application the user can create. Yves has mentioned correctly the reason of the limitation. That is the reason why Nordic is abandoning the SoftDevice and open-sourcing the code with the Zephyr community It has however the luxury to do so since BLE stack is no longer the hot selling know-how.
  2. The DW1000 is only a transceiver as Andy mentioned. The measurement and LE logic is done in PANS using the nRF52 MCU. The schematics might help you to understand the physical blocks:
  3. If your intention is to write a new LE then you can get the measurements via UART/SPI/SHELL/BLE/UserApp/Gateway and do the calculation as you need. The position calculated by PANS can be ignored or you can disable the internal LE.
  4. The PANS will keep track and select the most suitable Anchor to do the measurement with. It will ‘roam’ as you move the Tag across the installation. This cannot be changed or controlled by the user. But you can get the Anchor addresses and distances to them (as mentioned in the Q3 above).

Regarding the business strategy: as Andy and Yves have mentioned, Decawave is a semiconductor company. The development of a system which would satisfy every user is very expensive or rather impossible. Hence there were a set functionalities which have been defined and implemented and I think DWM1001+PANS already help a lot of users/clients. There will be always some unhappy clients but to make a product successful there are technical and also business sides. Both are limited.

Decawave is a start-up and cannot be compared with a public traded company like Nordic, which exists here for almost four decades. Decawave might get there, but the evolution takes time.

Another reason is there is no standardization of the RTLS at the link/network/transport/application layers which would simplify the adoption of the technology. So the more skilled companies/groups do invest to their own solution and if Decawave open-source a comparable solution it can have a negative effect on the market development. When the investments will be recovered there is a high chance some valuable open-source implementation will pop-up. This needs time to evolve.

I think the suggestions to solve your issues by Yves make sense. Another option is to develop your own system which I can say is very challenging and expensive. Or you can buy one if you have investment capacity.

I hope this would help.


1 Like

Thanks leapslabs and Yves for further clarification.

We of course have the issue that we are a small company and cannot invest thousands of man hours to develop our own stack.

Had I been developing this [at Decawave] - were it technically possible - I would have made the DW1000 an SoC with use configurable registers that spat out x,y,z data, whether that be as VHDL or as software with something like a Cortex on chip with the UWB and it implemented with software. Indeed I would make that the next release if it were possible. That means no extra chips and maximum flexibility with end users at minimum development time.

I think where I fundamentally disagree is the open-source side of it, but that’s bordering on holy war territory. :wink:

Not sure how this will play out in the end for us, The only current vaguely practical solution is to have a DW1000, an nRF almost purely as the DW1000 interface and a second nRF or similar as our LE/general purpose processor which also interfaces to the accelerometer.

It’s basically an extra processor with the cost and complexity that brings. Having two general purpose LE characteristics would likely solve all our (and I’m willing to bet, many other customers’) issue I believe. It’s this latter part that I fail to see the difficulty with at the moment, but I may still misunderstand something.

Good news about Nordic open sourcing the LE stack though!

Thanks again for engaging with us though, it’s great that you’re willing to do so and much appreciated.

Hi DiBosco,

you are welcome and thanks also for your feedback!

Just to be more precise on the open-source Bluetooth stack in Zephyr: it is not Nordic who opened it. From what I know the stack has been developed by Intel and Nordic contribute a good part to bring it to the level as it is today. From the experiments I can say it works very well and it should solve the timing issues we had with the SoftDevice in PANS.

Another thing I have noticed is with LE we refer to Location Engine while you use it probably for Bluetooth Low Energy.


But how would you do that?

TDoA or TWR positioning? How do you get the anchor locations into the position calculation engine?
Even when it comes to how you calculate positions once you have the measurements there are lots of options.
e.g. The DWM1001 system takes 3 or 4 ranges and calculates positions of up to 15 tags at 10 Hz.
The system I’m using takes 8 ranges and calculates the position and velocity of a single tag at 100 Hz.

Because the DW1000 is just a radio there is a lot of flexibility in what you can do with it. If it was a full SoC with built in position calculation then things may be easier for people who want to do what the designers allowed for but harder for people who want to come up with a different solution to a different problem. Best case scenario I’d have to spend more time working out how to disable and work around features I didn’t want that were running on a more complex chip that I had to pay for but didn’t need.

Also from a production point of view the manufacturing process used to produce logic for something like an M3 CPU core is probably very different from the process used to produce an RF chip. Yes they can be combined but that doesn’t mean that it’s easy to do.

1 Like

Indeed, which is why I said if were technically possible.

As far as TDoA or TWR positioning etc, I appreciate I might not understand how these work well enough yet, but I would have thought if you have registers you could put the device into different modes via SPI/I2C/UART so it would spit out what you want.

Similarly with anchor positions, you communicate over a serial interface to set it up, like you would any peripheral.

I fully accept I might be looking at this a little too simplistically and know you can’t please all the people all the time. :slight_smile: