My test setup:
two DWM1000s 50cm apart each attached to a micro controller running Linux.
My test:
One is running ex_02a_simple_rx and the other ex_01a_simple_tx or ex_01c_tx_sleep_auto (all with default parameters).
The results:
I’m seeing between 10 and 90% of the transmissions fail. The receive SYS_STATUS_ID reg for the successful transmissions reads x806b02 (which seems like everything is nominal). The error from the unsuccessful transmissions fall in three categories: 1) SYS_STATUS_ID=x801302 (phy header error) 2) SYS_STATUS_ID=x4800102 (receive SFD timeout) and 3) no signal received at all. Performance is much worse when running ex_01c on the transmit side than when I run ex_01a.
Possible conclusion:
My guess would be that the SNR at the receiver is close to the minimum threshold at the receive side, despite the two being 50cm apart. Is this an obvious power supply issue or something else I’m missing? The DWMs are dead-bugged right now (boards are coming), so I imagine the antenna gain is degraded slightly. I would think this wouldn’t matter at this range.
Anyone have a similar problem or any useful insight? I should add that all my SPI checks have passed so far at 2MHz pre-initialization and 20MHz post-initialization.
Cheers,
Bryan
Hey Brian,
Try checking the crystal frequency. The more they vary between transceivers the worse the sensitivity. Furthermore, check the stability of the power supply as transmissions/receptions draw significant power. Maybe add some capacitance to be sure.
I calibrated the crystals (using the crystal-trim feature of the DW1000) with the help of simple two-way symmetric ranging. I derived the clock-difference from the timestamps and selected a crystal-trim value that minimises the difference. This way I did not need a spectrum analyser and this method could even be used in the field and online.
Kind regards,
That sounds like good advice. I’m also looking at section 2.5.5 in the
user manual, “Default Configurations that should be modified.” I will
try adding the recommendations in that list and see if performance
improves.
Has anyone else seen improvements by changing this list of values?
-Bryan
Be they way, as you mention it: there are a number of configuration options (PRF/preamble length/channel/non-standard SFD/TX power/PAC) that might perform better or worse in certain combinations. See chapter 9 of the user manual for details on selecting a good config.
For long range communication I am using:
datarate 110kbit/s
channel 2
preamble 2048 symbols
non-standard SFD
PRF 64 MHz
TX/RX preamble code 9
PAC size 64
TX power 0x67676767
smart power disabled
0xC2 PGdly value
The first set is selected according to user manual ch 9. The latter set is selected according to the information in the API documentation.
I currently communicate at a range of about 100 meters.
Kind regards,
I wanted to follow up on this thread with some results. To prevent confusion, I wanted to mention that everything in section 2.5.5 of the user manual is addressed by the dwt_initialize and dwt_configure functions and does not need to be implemented by hand. Adding the dwt_configuretxrf parameters mentioned about helped mitigate this problem by eliminating the phy header error (SYS_STATUS_ID=x801302) and lost transmission error, but the receive SFD timeout errors persist (SYS_STATUS_ID=x4800102). I believe this may just represent the false detection rate of the system.
I’m now have the same test setup (two DWM1000s 1.5m apart on a table) and am seeing seeing strange behavior when doing single-sided two way ranging with the following configurations:
/* SHORT RANGE MODE /
static dwt_config_t config_short = {
2, / Channel number. /
DWT_PRF_64M, / Pulse repetition frequency. /
DWT_PLEN_128, / Preamble length. /
DWT_PAC8, / Preamble acquisition chunk size. Used in RX only. /
9, / TX preamble code. Used in TX only. /
9, / RX preamble code. Used in RX only. /
0, / Use non-standard SFD (Boolean) /
DWT_BR_6M8, / Data rate. /
DWT_PHRMODE_STD, / PHY header mode. /
(129 + 8 - 8) / SFD timeout (preamble length + 1 + SFD length - PAC size). Used in RX only. */
};
// TX CONFIG SETTINGS
static dwt_txconfig_t txconfig = {
0xC2, //PGdly
//TX POWER
//31:24 BOOST_0.125ms_PWR
//23:16 BOOST_0.25ms_PWR-TX_SHR_PWR
//15:8 BOOST_0.5ms_PWR-TX_PHR_PWR
//7:0 DEFAULT_PWR-TX_DATA_PWR
0x67676767 //power
};
When I have node A initiate and node B respond I get a plot of distance (in meters) vs measurement like the following (note the nodes are stationary):
At first I thought this was a multipath issue. But looking at the noise estimates (0x2E:0000 – LDE_THRESH) and (0x12:00 - STD_NOISE) hinted it might be an AGC problem? The following is a plot of LDE_THRESH vs measurement for the same data.
Can anyone tell me what is causing the noise estimate to vary in the way? I’ve verified it is repeatable and nothing is changing in the environment.
Finally this problem only appears when node A initiates and node B responds. If I reverse this then I get the following for Distance and LDE_THRESH vs measurement, respectively:
The variation in the distance is simply clock drift from the single-sided ranging I believe. Could one of my modules have a faulty AGC? Has anyone else run into this?
The piece of data I have is from trying to calculate the RX_POWER and the FP_POWER (first path power) as described in section 4.7 of the user manual. RX_POWER for both cases in generally flat and -84 to -82dBm for both cases, while the FP_POWER is closer to -104 to -100 dBm for both cases. From section 4.7 this implies that I have a heavily NLOS channel which seems strange since they are sitting on a bench next to one another. Has anyone dug into this?