Switching from DWM1000 to DW1000 issues

Wireless Connectivity Ultra-Wideband
, , , ,
1

Hello,

I was able to make a working RTLS system with my custom boards (anchors+tags) using DWM1000 module and also added custom antennas to extend range. The system works as expected and the accuracy has been achieved.

Now I redesigned another system but this time using DW1000 chip and integrated the antenna in the PCB (the same as the previous working system).

The issue I’m having currently is the accuracy of the measurement (anchor <->Tag):

for 0.85 cm distance between tag and anchor I get the following :

  • Old anchor (dwm1000) <-> old tag (dwm1000) gives ~0.87 cm
  • New anchor (dw1000) <-> old tag (dwm1000) gives 1900-3000 m !
  • New anchor CPU (dw1000 removed) + dwm1000 from old tag <-> old tag (dwm1000) gives ~0.87 cm

I’m running the same exact code in all cases, so for deubgging I started checking:

-The quartz -> OK
-V1.8 and V3.3 -> OK

  • VDDVCO -> goes to 0 and 1.4V each time the dw1000 uses its RX/TX (see attached file). Is this the normal behavior ?

Is there anything else that I can check to verify that my setup is correct ? i’m out of ideas here !

Thank you

1 Like
2

Hi
Each DWM1000 is tested for various parameters such as current, TX RF power, RX sensitivity. They are also calibrated for crystal trim and the trim value is stored in the on-board OTP memory.
When using a DW1000 (instead) one needs to calibrate the design (pw, Crystal, Antenna delay) . Have you checked the antenna delay and TX power of the DW design (Delay might be zero, while power high)
As a starting point for antenna delay maybe use what is applied to your DWM design.
See IC user manual for details
/leo

3

Hi Leo,
Thank you for your response.
I did more debugging and found out that the tag (dwm1000) does not receive messages from the anchor (dw1000) always shows SDF timeout. The anchor can receive messages from the tag (dwm1000).

I have changed the Rx and Tx antenna delays from 0 to 65 000 and didn’t changed a lot.
I’m using channel 7 ( RFP 64, preamble 4096, PAC 64, Tx,Rx preamble code 17, Baudrate 110K) for testing since Im’ looking for the maximum range possible but when switching to channel 1 and 2 the reception works and the measurements work as expected. The rest of the channels don’t work.

So I’m suspecting to have an issue in channel 7 frequency (6.5Ghz) ! I’m suspecting the crystal (X1E000021016312 ) that I’ll check soon.

4

Hi again

What range would you get with Ch 1 and 2? I’m asking as channel 7 would not give you more range then channel 1 but maybe some more then ch 2.
We would have tested most of our SW with channel 2 and channel 5 see EVK, TREK and our example code.
So does channel 5 work for you?
Also check other threads like https://www.decawave.com/decaforum/showthread.php?tid=861
Leo

5

I didn’t test the range yet. But I remember back in the days when testing the old product we could easily get significant increase in range when using channel 7 rather than channel 2 (max tx gain 33.5 dBm and 110K kbps). If i remember right : channel 2 gave us ~150m and channel 7 300m that’s why we kept working with channel 7.

channel 5 doesn’t work.

Thank you for the link. I’ll take a look at it and check also Crystal trim aswell

6

I’m trying to get the crystal clock signal on GPIO0 but it doesn’t seem to work for me !

I added this function to set the mode on GPIO0

[code]#define GPIO_PIN0_CRYCLK 0x00000008UL

void dwt_setcrystalsingalmode( void )
{
uint32 gpio_mode = dwt_read32bitoffsetreg(GPIO_CTRL_ID, GPIO_MODE_OFFSET);
gpio_mode &= ~(GPIO_MSGP7_MASK);
gpio_mode |= GPIO_PIN0_CRYCLK;
dwt_write32bitoffsetreg(GPIO_CTRL_ID, GPIO_MODE_OFFSET, gpio_mode);
gpio_mode = dwt_read32bitoffsetreg(GPIO_CTRL_ID, GPIO_MODE_OFFSET);
}
[/code]

And while in spi low speed (2 Mbps) I configure the init the mdoule then the GPIO0

if (dwt_initialise(DWT_LOADUCODE) == DWT_SUCCESS ) { dwt_setcrystalsingalmode(); while(1); }

It doesn’t seem to change anything on the GPIO0 output ! am I misisng something ?

7

The first thing I would check is the crystal tuning. I’ve done much the same as use and hit a similar issue until I set the tuning parameter on each unit. It doesn’t take much of a clock error to mess things up and if you are using the default tuning value in the OTP (0) then things will generally be very broken unless your clock happens to be ~30 ppm wrong in the correct direction.

To do this correctly you will need a spectrum analyser that will go up to at least 4 GHz (I used a Hack RF and some PC software).
Set the system to a channel where you can see the center frequency (ideally the default channel 5 if your analyser can go that high, mine couldn’t so I used channel 4 at ~3.9 GHz).
Follow the process in section 8.1 of the DW1000 user manual to set the chip to output pure carrier (versions 2.13 and 2.14 of the manual have parts of this process missing, version 2.07 has everything but with formatting errors, if you look on the forum the errors and corrections were posted a month or two ago).

On the spectrum analyser you should see a nice sharp spike. Adjust the crystal tuning parameter until that spike is as close to the channel center frequency as you can get it. Save the value into the OTP so that next power up you can read and apply it automatically.

If you don’t trust your measurement system too much (I don’t trust the hack RF to have a particularly accurate clock internally) then rather than looking at the actual frequency put a factory tuned DWM1000 into the same test mode at the same time and use that as a reference, aim to get the two spikes on top of each other as best you can.

If you don’t have the correct equipment to hand then I’d recommend putting a simple hack into the code, read the crystal tune value from the OTP, if the value is anything other than 0 then use the value you read. If it is 0 then assume it’s unconfigured and use 16 as a reasonable middle of the range guess.

8

Hi Andy,
Thank you for taking the time and writing this helpful reply.
the default crystal trim value on the OTP is 0x10. I did change the crystal trim value in the register from 0x0A to 0x14 and checked if the reception on the tag side (dwm1000) is working but with no luck.
I don’t write the new value to the OTP since I only have 3.3V connected to the dw1000 but I update the register(0x2B:0E) using dwt_setxtaltrim(), so i’m not sure if it’s taking in consideration by the dw or not ?

I also received the tag new version with the dw1000 modules instead of the dwm1000 and guess what ? it worked right away !!! (with another dwm1000) ! same circuit, components…ect! doesn’t really make sense.

I’ll be testing with a spectrum analyzer and will keep u updated

9

Thanks to AndyA I was able to make the continuous wave mode working.
I was able to get the central frequency on the dwm1000 as showing in the picture below


span 6.5 ghz, center 3.25

I used only the following code to configure the module, no other configuration before nor after this

[code]void dwt_entertestmode( uint8 chan )
{
//dwt_write32bitoffsetreg
dwt_write32bitoffsetreg(RF_CONF_ID,0,0x0009A000);
nrf_delay_ms(1);
dwt_write16bitoffsetreg(PMSC_ID,PMSC_CTRL1_OFFSET,0x0000);
nrf_delay_ms(1);

//Configure RF TX blocks (for specified channel and PRF)
//Configure RF TX control
dwt_write32bitoffsetreg(RF_CONF_ID, RF_TXCTRL_OFFSET, tx_config[chan_idx[chan]]);
dwt_write32bitoffsetreg(TX_POWER_ID,0,0x1f1f1f1f);
nrf_delay_ms(1);
dwt_write32bitoffsetreg(FS_CTRL_ID, FS_PLLCFG_OFFSET, fs_pll_cfg[chan_idx[chan]]);
dwt_write8bitoffsetreg(FS_CTRL_ID, FS_PLLTUNE_OFFSET, fs_pll_tune[chan_idx[chan]]);

uint32_t config = dwt_read32bitoffsetreg(SYS_CFG_ID,0);
config |= 1<<18;
dwt_write32bitoffsetreg(SYS_CFG_ID,0,config);
nrf_delay_ms(1);

dwt_write16bitoffsetreg(PMSC_ID,PMSC_CTRL0_OFFSET,0x0222);
nrf_delay_ms(1);
dwt_write32bitoffsetreg(PMSC_ID,PMSC_TXFINESEQ_OFFSET,0x00000000);
nrf_delay_ms(1);
dwt_write32bitoffsetreg(RF_CONF_ID,0,0x005fff00);
nrf_delay_ms(1);
dwt_write8bitoffsetreg(TX_CAL_ID,TC_PGTEST_OFFSET,0x13);

}[/code]
I don’t configure the trim crystal value but still got a central frequency, is that normal ? I tried to change the trim value with dwt_setxtaltrim() but it doesn’t change anything.

For the dw1000 I got 3 peaks for 3 frequencies (2.8 Ghz, 3.994 Ghz and 5.18)

I was wondering if these peaks are the reason why I’m receiving SFD timeout on the dwm1000 module ? If yes, any idea how to remove them ?

Thank you guys

10

Two things looking at those traces:

The trim gives you around +/-20 ppm of variation. At 4 GHz that’s +/-80 kHz, far too small to see on the span you are using. Plus you have the resolution bandwidth set to 1 MHz, far too large to see changes in the kHz range.
Set the span to 5 MHz or less and dial the resolution bandwidth down to 5 kHz or so and then see if you can the see anything. Don’t worry if the analyser complains that it’s outside of it’s calibration when you do this (some will), you aren’t looking to make accurate amplitude measurements so that doesn’t matter too much.

The multiple spikes on the other board could be due to something saturating and so not giving you a clean sine wave. Try turning the Tx power down and see if they go away or reduce significantly.

11

Thank you again Andy, I guess I was too excited to see the spike :slight_smile:

Now I see the variation.
The only problem is for channel 4 for example the central frequency should be 3.9936 GHz. with my anchor board ( has dw1000 ) I’m only getting between 3.999625 Ghz for 0x10 trim value and 3.998975 Ghz for 0x1F (the closet to 3.9936 Ghz) and can’t get closer.
The error is around 5 Mhz which I think is huge.
for the old tag ( with dwm1000 )I’m getting 3.993550 Ghz for 0x0E trim value.
and on the new tag (the new version with dw1000) I was able to get 3.993663 Ghz for trim value of 0x1A. and this tag is working like a charme

I changed the capacitor on the crystal for the dw1000 in the anchor from 10pF to 8 pF but that didn’t help.

Any inputs and ideas would be very helpful :slight_smile:

I’ll order new crystal and try with it

12

This is where it gets tricky, it gets down to which crystal you are using, which capacitors and also your board layout could have a significant impact. It’s a little tricky to help diagnose that sort of thing remotely :frowning:

13

Hi Chaabane,

The fact that you’re getting the right spectrum output with DWM1000 suggests your code is good and would lead me to suspect the HW implementation of your DW1000 design might be at fault? Would you be able to share gerbers or pictures of the layout? Can you check if the PLLs are locking? This (https://ibb.co/cYMjXz) spectrum just doesn’t look right at all. Are any of the peaks actually at your desired channel frequency (presumably you want 3.9936 GHz [Channel 2])? I wouldn’t be too worried about the crystal trimming until the source of this strange spectrum is understood.

14

Thank you Carroll for your input,

I think I found out where the problem might be. I notice that the three capacitor for the VDDPA (330nF,10nF,100nF) are placed relatively far from the pin. their name in the PCB PCB dw1000 hosted at ImgBB — ImgBB are C222, C223 and C224. I removed these 3 capacitors and the peaks disappeared and only the 3.9936 is left. Then tested the TWR with a tag which worked perfectly.

In total I tested this (removing the 3 capacitors) on 4 boards whcih have small ajustments (quartz, capacitors…) and only 2 of 4 started working as expected.

How do you do that ? you mean he CVOTUNE and the CLK tune ?
[hr]

15

I think I’m starting to find the problem. I noticed that the VDDPA capacitors are relatively from the pin : C222,C223 and C224 on the bottom right in this image PCB dw1000 hosted at ImgBB — ImgBB.
So I removed them and the peaks dissapeared and got only the 3.9936 GHz (channel 2) left. I tested the TWR and it worked as expected.

In total I tested this on 4 boards and only 2 of 4 worked, I suspecting that there is more capacitor to ajust this is way i’m redesigning the board.

16

Yes, I think this picture tells the story - thanks for sharing.

They look like they may be 0603 case size caps, is that right? Way too big for use at high RF. The mismatch of the thin RF traces and wide component pads will alter the line impedance, causing reflections and power loss.

How many PCB layers are you using? We recommend at least four. Using smaller (ideally 0201) components will allow you to get the all-important decoupling caps as close as possible to the IC.

It’s well worth reading APH001, where the key layout guidelines are presented.

17

Unfortunately two power pins right next to each other with the RF output next to them does make it rather tricky to get good decoupling in.
We managed to get away with using 0402 parts and then mounting them at an angle so that they could be closer to the chip.

18

Indeed, it’s very tricky. i’m using only 0402 (only C418 and C425).
For your case, did u manage to put all the components on one side ? we’re redesigning the board to use 4 layers and components on both sides but this will increase the price . I was wondering if you used 4 or 2 layer PCB and If you can share the layout of the decoupling capacitors ? would really appreciate it.

19

4 layers, components all on one side other than the antenna.
I’ll message you…

20

DWM1000 modules only works within a range of 10 meters. That is very short because the dwm1000 product brief and the dw1000 datasheet says that it will work far over 100 meter outside and 20-50 meters inside a building. If the RF signal is not well you will have low range only. And this may also depend on hardware around the chip. the DW1000 is the chip inside the DWM1000 module. To achieve best results when using the DWM1000 with Deca wave’s DecaRanging software , you will need to adjust the default transmit power value programmed into the DWM1000 by the software.
Get the best results from a trustworthy custom essay writing service.