Missing and ambiguous information in DW3000 user manual

[skreborn]

Hello there!

I have recently started tinkering with the DW3000 - currently evaluating it for use cases our company specializes in. I have a few questions regarding the user manual, as it sadly lacks important information or distinction in certain places. I’d appreciate any breadcrumbs here that you can offer.

Thank you kindly in advance!

---

BIAS_KICK

The user manual (8.2.12.3) states that BIAS_CTRL (11:1F) can be loaded from OTP using BIAS_KICK (0B:08:8). While it does not show up in the bitfield, the detailed field descriptions contain the entry.

However, the reference implementation (deca_device.c:687) both triggers automatic loading from OTP and loads the value into the register manually. Why is that? One of these methods is certainly superfluous.

Note that LDO_BIAS_KICK here is defined as 0x180, which would set both LDO_KICK and BIAS_KICK.

RX_CTRL

There is, for whatever reason, a magic number (0x08B5A833) set in the reference implementation (deca_device.c:1501) for RX_CTRL (07:10).

Neither the register nor the constant value itself make an appearance in the user manual - and curiously there is no matching value for channel 5. Is there any documentation anywhere on what this is supposed to achieve?

DTUNE3

According to the user manual (8.2.7.4) the value of DTUNE3 (06:0C) needs to be changed unconditionally from the default value of 0xAF5F584C to 0xAF5F35CC.

However, the reference implementation (deca_device.c:1453) only changes this value when the no-data STS mode is used.

So which is it? Always set it to a constant of 0xAF5F35CC - as per the manual - or only do so conditionally - as per the reference?

LDO_CTRL

The user manual (8.2.8.9) contains LDO_CTRL (07:48), but gives absolutely no details on the contained fields or the specific functions of the mentioned blocks.

The reference implementation certainly has more information, but still lacks a basic description of their intended uses and when they are supposed to be powered up/down (except for a few comments here and there scattered across the codebase).

As an example, why do I need these on for calibration, and how am I supposed to learn of this - other than scouring through the poorly documented code?

TX_ANTD and RXANTD

TX_ANTD (01:04, 8.2.2.19 in user manual) and RXANTD (0E:00:0-15, 8.2.13.36 in user manual) are the transmitter and receiver antenna delays, respectively.

There seems to be a field called Antenna Delay – RFLoop (0x0B) in the OTP memory, that should contain the correct values for these registers.

However, there is no explanation on what this 32-bit field actually contains - as both TX_ANTD and RXANTD are 16-bit values. The reference implementation contains no clues on how to use this pre-configured value and instead uses a fixed value of 16385 for both.

It’s safe to say that the mentioned NOTE 2 is no help, either.

I have instead found in the DW1000 user manual a similar pair of fields called TX/RX Antenna Delay – PRF 64 and TX/RX Antenna Delay – PRF 16 - both residing within the 32-bit value at 0x1C in the OTP memory. When reading the aforementioned Antenna Delay – RFLoop as two separate 16-bit values, however, what I got was a value that was suspiciously high. Dividing by two got me a lot closer to the default value used by the reference implementation, so I figured that should be the value I have to use.

To sum it up, here is how I acquired the final transmitter/receiver antenna delay:

1. I’ve read the value of Antenna Delay – RFLoop.
2. I’ve taken the side corresponding to PRF 64 (according to the DW1000 user manual), since I’m using a 64 MHz preamble (code 9).
3. I’ve divided the value by 2.

In my case, this gave a value of 16379 for PRF 64 and 16361 for PRF 16. Do these seem correct - especially the fact that it’s higher in the case of PRF 64?

Is this the correct way to find the delays to begin with? If so, why are there separate transmitter and receiver antenna delays, if the two values are always going to be same anyway?

Furthermore, after running a few tests in a double-sided two-way ranging scenario, I’ve concluded that I get consistently more accurate measurements of flight time (and thus distance) when using the default value of 16385 (as per the reference implementation) instead of the value acquired (using the method described above) from the OTP memory. There is obviously a chance that my ranging implementation is erroneous, but let’s not get into that just yet - I’m hoping there’s a simpler explanation here.

---

The topic DW3000 User manual missing information present in the drivers has already inquired about LDO_CTRL, but it was unfortunately left unanswered.

[AndyA]

Welcome to decawave support. Questions which their support people who monitor the forum can answer will get an answer. Anything which would require technical input or support from the engineering teams will get ignored.

DW1000 we wrote our own c++ driver, to add DW3000 support I’m looking to hack their driver in, get it working and then re-factor it into something more suitable for our firmware structure. It’s a horrible way to do things but the only option due to the poor documentation.

[skreborn]

I’m perfectly fine with community members replying - I’ve had to figure out a lot of details about undocumented features and requirements already, so if someone has already done the legwork to dig into these same questions, I’d be happy to hear their thoughts.

I haven’t used a DW1000 prior to acquiring a DW3000, but I’ve studied a few drivers to see how they operate. For DW3000, I’m implementing a custom driver as well in Rust, which will then be hopefully open-sourced.

[andrew]

Hi ,Andy
→ Welcome to Decawave support. Questions which their support people who monitor the forum can answer will get an answer. Anything which would require technical input or support from the engineering teams will get ignored. → regarding to your answer
it is ambiguous , because i would wonder what or how we know what kind of the questions are suitable for the Decawave support team who monitors the forum will be able to answer ? and what kind of questions are required technical input or support from the engineering teams ?
or if it gets ignore that means those questions are required technical input or support from the engineering teams ?
why does Decawave support team can not answer all questions even those are required technical input or support from the engineering teams ? the more clearer answer from Decawave enginneer , the more creative App will be , the more Decawave DWM1000 / 3000 's sale volume will be higher , right ?

[AndyA]

But most questions here will be from people using low volumes. High volume users will probably either be in their design partners program or working through one of them and so get support that way.
Look at the questions here, the majority of them are about using the supplied hardware modules and software for them. Because that’s the easiest way to do things in low volumes.

About the only questions that get a direct answer tend to be on availability, documentation or differences between products. Anything more detailed isn’t worth the cost of supplying that support for the volume of sales that it will generate. It’s annoying for anyone not buying parts by the thousand but economically it makes sense and most semiconductor companies operate in a similar way.

[Celine]

Hi skreborn,

Hereunder some answers to your question :

Regarding the Bias kick:

You’re right, the bit8 is for the BIAS_KICK and will be updated in the next UserManual version.
In fact, the kick will actually not kick all bits, so we are writing the missing bits also in this part of the code

Regarding the RX-CTRL

The value programmed in your version of the API into RX_CTRL is actually the register default value. This register will be removed from the UserManual as the default value is now used.

Regarding Dtune3

Do not change these values, this are optimal values for the threshold, just follow the reference implementation

Regarding the LDO_ctrl

The LDO CTRL is used to manually enable internal blocks, in normal operation LDOs are controlled automatically, but in some test/calibration modes they need to be enabled manually. Please use the APIs provided when running those modes

Regarding the TX_ANT/RX_ANT

The antenna delay has to be calibrated, you can follow the app notes on the website (Application Notes - Decawave → APS014 : Antenna Delay Calibration), on the DW3000 the same value can be applied on both.

[skreborn]

Hi Celine,

Thank you kindly for your reply! Just to see if I got this right, I’ve made a few notes.

@Celine

In fact, the kick will actually not kick all bits, so we are writing the missing bits also in this part of the code

Is this also going to be noted in the new version? In any case, if there are bits missing, there’s really no reason to use kick in the first place - I might as well just write the value myself, right?

@Celine

This register will be removed from the UserManual as the default value is now used.

It’s already not in the user manual, but I suppose that means it’s safe for me to just ignore its existence and not write any value to it, as I should just keep the default.

@Celine

Do not change these values, this are optimal values for the threshold, just follow the reference implementation

So follow the reference implementation; which writes a value to it in case the no-data STS mode is used - is that right?

@Celine

The antenna delay has to be calibrated

I will look into that shortly.

Thank you once more for your assistance!

[andrew]

understood what you answered

[Celine]

Hi Skreborn,

Is this also going to be noted in the new version? In any case, if there are bits missing, there’s really no reason to use kick in the first place - I might as well just write the value myself, right? No, we recommend the provided APIs are used.

It’s already not in the user manual, but I suppose that means it’s safe for me to just ignore its existence and not write any value to it, as I should just keep the default. Yes, just keep the default value please

So follow the reference implementation; which writes a value to it in case the no-data STS mode is used - is that right? Yes, just follow the reference implementation which configures a specific threshold in case of ND STS mode

[seppe]

@AndyA

Welcome to decawave support. Questions which their support people who monitor the forum can answer will get an answer. Anything which would require technical input or support from the engineering teams will get ignored.

I’m sorry you feel this way. We do our best supporting our customers developing RTSL solutions, but sadly a lot of our attention has indeed been towards bigger projects and customers due to UWB radio becoming more prevalent in the mobile market and the acquisition by Qorvo making DecaWave a more visible player. We also lost a couple of support people, and are working on new products, meaning our presence on this forum has been bit lacking lately. Luckily we have new people like Celine who help us improve this

To elaborate on her answers:

@skreborn

In any case, if there are bits missing, there’s really no reason to use kick in the first place - I might as well just write the value myself, right?

Yes, it is possible to write these values yourself, but since they are factory calibrated, it typically makes more sense to just kick them from OTP iof reading from OTP and writing to the register. That being said, there’s still a lot of caveats related to these registers we (mainly I) have been a bit slow at addressing. New versions of the driver write the values to the registers directly with some fixes that apply to border case scenarios.

@skreborn

The reference implementation certainly has more information, but still lacks a basic description of their intended uses and when they are supposed to be powered up/down (except for a few comments here and there scattered across the codebase).

Agreed. Sadly these registers had to be excluded from the DW3000 User manual meaning the only thing that we can provide is a “do as we do, not as we say” approach. In part, incorrectly configuring these registers can cause damage to the IC, so it is easier for us to just provide the driver instead of customers correctly interpreting the user manual.

@skreborn

There seems to be a field called Antenna Delay – RFLoop (0x0B) in the OTP memory, that should contain the correct values for these registers.

However, there is no explanation on what this 32-bit field actually contains - as both TX_ANTD and RXANTD are 16-bit values. The reference implementation contains no clues on how to use this pre-configured value and instead uses a fixed value of 16385 for both.

The antenna delay of the RF loopback should not be confused with the antenna delay of a product. The value in OTP memory reflects the internal antenna delay (a sum of TX and RX delay) obtained during the chip production test. This can be used to account for part variances in the chip if antenna delay calibration is not done on the final product.

However, because there is also variation in other parts of a product that are often more significant than chip variations, e.g differences in the PCB substrate, soldering of the chip, antenna connectors, cable lengths, antenna soldering, … we recommend performing antenna delay calibration on a per device basis.

[andrew]

thanks , HAPPY NEW YEAR 2022
right , i am feeling sad for getting ignore of support in my question or some kind of questions , however, i am understood what you said , and i do not want to ask for the whole project or very complicate , very technical or code as needing a lot of time to support , i want to ask the short stuff

what i need to know is → about as attach image → Will single or one Qorvo DWM3000EVB ** be able to interact with more than 2 iPhones 11 or multi several iphones 11 or 12 or 13 SIMULTANEOUSLY ??

i want to know only about the performance or capability of DWM3000EVB that what question i ask

please let me know what i ask

thanks

[seppe]

Hi Andrew, I answered this in your original thread on this topic. Please don’t derail other people’s forum thread.

[andrew]

sorry , very thanks , i will head to see my original thread

[egnor]

@seppe

Agreed. Sadly these registers had to be excluded from the DW3000 User manual meaning the only thing that we can provide is a “do as we do, not as we say” approach. In part, incorrectly configuring these registers can cause damage to the IC, so it is easier for us to just provide the driver instead of customers correctly interpreting the user manual.

Hm. Source code isn’t available for the API any more (changed since you wrote that), so it’s hard to “do as you do” if you’re not in a position to run the binary blobs.

I suppose I can just try to work with the older version of the API, that still has source? Maybe that will be good enough?

– egnor

[egnor]

@Celine

Regarding the Bias kick:
You’re right, the bit8 is for the BIAS_KICK and will be updated in the next UserManual version.
In fact, the kick will actually not kick all bits, so we are writing the missing bits also in this part of the code

Hi! As observed in "Missing manual" for register-level access to DW3000 (without using API) - #6 by Nomad, it looks like neither BIAS_KICK or LDO_KICK actually do anything, and the code in the last driver for which source is available doesn’t entirely remedy it.

(Also, that code does some mysterious bit-shifting of the BIASTUNE_CAL OTP value before moving into BIAS_CTRL.)

Is there advice on what should actually be done here? (Other than “just use the official driver on the officially supported MCU chips”…?)