decaWave DW1000 User Manual

Download

Version 2.12

Page 1 of 242

DW1000 USER MANUAL

HOW TO USE, CONFIGURE AND PROGRAM THE DW1000 UWB TRANSCEIVER

This document is subject to change without notice

DW1000 USER MANUAL

DW1000 User Manual

Version 2.12

Page 2 of 242

Table of Contents

LIST OF FIGURES ........................................................ 3

LIST OF TABLES .......................................................... 4

1 INTRODUCTION ................................................. 7

1.1 ABOUT THE DW1000 ...................................... 7

1.2 ABOUT THIS DOCUMENT .................................... 7

2 OVERVIEW OF THE DW1000 ............................. 10

2.1 INTRODUCTION .............................................. 10

2.2 INTERFACING TO THE DW1000 ........................ 10

2.3 DW1000 OPERATIONAL STATES ...................... 14

2.4 POWER ON RESET (POR) ................................ 18

2.5 DEFAULT CONFIGURATION ON POWER UP .......... 20

3 MESSAGE TRANSMISSION ................................ 25

3.1 BASIC TRANSMISSION ...................................... 25

3.2 TRANSMISSION TIMESTAMP .............................. 26

3.3 DELAYED TRANSMISSION ................................. 26

3.4 EXTENDED LENGTH DATA FRAMES ..................... 27

3.5 HIGH SPEED TRANSMISSION ............................. 29

4 MESSAGE RECEPTION ....................................... 32

4.1 BASIC RECEPTION ........................................... 32

4.2 DELAYED RECEIVE ........................................... 35

4.3 DOUBLE RECEIVE BUFFER................................. 35

4.4 LOW-POWER LISTENING .................................. 39

4.5 LOW-POWER SNIFF MODE .............................. 41

4.6 DIAGNOSTICS ................................................ 44

4.7 ASSESSING THE QUALITY OF RECEPTION AND THE RX

TIMESTAMP ................................................................ 44

5 MEDIA ACCESS CONTROL (MAC) HARDWARE

FEATURES ................................................................. 48

5.1 CYCLIC REDUNDANCY CHECK ............................. 48

5.2 FRAME FILTERING ........................................... 48

5.3 AUTOMATIC ACKNOWLEDGEMENT .................... 50

5.4 TRANSMIT AND AUTOMATICALLY WAIT FOR RESPONSE 53

6 OTHER FEATURES OF THE DW1000 ................... 55

6.1 EXTERNAL SYNCHRONISATION ........................... 55

6.2 EXTERNAL POWER AMPLIFICATION .................... 58

6.3 USING THE ON-CHIP OTP MEMORY ................... 58

6.4 MEASURING IC TEMPERATURE AND VOLTAGE ...... 61

7 THE DW1000 REGISTER SET .............................. 63

8.1 IC CALIBRATION – CRYSTAL OSCILLATOR TRIM ... 198

8.2 IC CALIBRATION – TRANSMIT POWER AND SPECTRUM 200

8.3 IC CALIBRATION – ANTENNA DELAY ................. 203

9 OPERATIONAL DESIGN CHOICES WHEN

EMPLOYING THE DW1000....................................... 206

9.1 OPERATING RANGE ....................................... 206

9.2 CHANNEL AND BANDWIDTH SELECTION ............. 206

9.3 CHOICE OF DATA RATE, PREAMBLE LENGTH AND PRF 206

9.4 POWER CONSUMPTION .................................. 207

9.5 NODE DENSITY AND AIR UTILISATION ................ 207

9.6 LOW–DUTY CYCLE – AIR TIME .......................... 208

9.7 LOCATION SCHEMES ...................................... 209

9.8 GENERAL CONSIDERATIONS............................. 210

10 APPENDIX 1: THE IEEE 802.15.4 UWB PHYSICAL

LAYER ..................................................................... 212

10.1 FRAME STRUCTURE OVERVIEW ........................ 212

10.2 DATA MODULATION SCHEME .......................... 212

10.3 SYNCHRONISATION HEADER MODULATION SCHEME 213

10.4 PHY HEADER ............................................... 214

10.5 UWB CHANNELS AND PREAMBLE CODES ........... 215

10.6 ADDITIONAL DETAILS ON THE STANDARD ........... 216

11 APPENDIX 2: THE IEEE 802.15.4 MAC LAYER ... 217

11.1 GENERAL MAC MESSAGE FORMAT .................. 217

11.2 THE FRAME CONTROL FIELD IN THE MAC HEADER 218

11.3 THE SEQUENCE NUMBER FIELD ....................... 220

11.4 MAC LEVEL PROCESSING IN THE DW1000........ 221

12 APPENDIX 3: TWO-WAY RANGING ................. 222

12.1 INTRODUCTION ............................................ 222

12.2 SINGLE-SIDED TWO-WAY RANGING .................. 222

12.3 DOUBLE-SIDED TWO-WAY RANGING ................ 224

13 APPENDIX 4: ABBREVIATIONS AND ACRONYMS 230

14 APPENDIX 5: REFERENCES .............................. 233

15 DOCUMENT HISTORY ..................................... 233

16 CHANGE LOG .................................................. 233

17 ABOUT DECAWAVE ........................................ 239

7.1 REGISTER MAP OVERVIEW ................................ 63

7.2 DETAILED REGISTER DESCRIPTION ...................... 65

8 DW1000 CALIBRATION ................................... 198

DW1000 User Manual

Version 2.12

Page 3 of 242

List of Figures

FIGURE 1: SPI READ AND WRITE TRANSACTIONS ................... 11

FIGURE 2: SINGLE OCTET HEADER OF THE NON-INDEXED SPI

TRANSACTION ......................................................... 12

FIGURE 3: EXAMPLE NON-INDEXED READ OF THE DEVICE ID

FIGURE 4: TWO OCTET HEADER OF THE SHORT INDEXED SPI

TRANSACTION ......................................................... 12

FIGURE 5: EXAMPLE SHORT-INDEXED READ OF 3

OF REGISTER 0X00 .................................................. 13

AND 4TH OCTETS

FIGURE 6: THREE OCTET HEADER OF THE LONG INDEXED SPI

TRANSACTION ......................................................... 13

FIGURE 7: EXAMPLE LONG-INDEXED WRITE OF ONE OCTET TO

INDEX 310 OF THE TX BUFFER ................................... 13

FIGURE 8: DW1000 STATE DIAGRAM ................................ 15

FIGURE 9: TIMING DIAGRAM AND POWER PROFILE FOR COLD

START POR ............................................................ 18

FIGURE 10: TRANSMIT FRAME FORMAT ............................... 25

FIGURE 11: BASIC TRANSMIT SEQUENCE ............................. 25

FIGURE 12 : PHR ENCODING EXTENDED LENGTH DATA FRAMES

........................................................................... 28

FIGURE 13: BASIC RECEIVE SEQUENCE .................................. 32

FIGURE 14: FLOW CHART FOR USING DOUBLE RX BUFFERING ... 38

FIGURE 15 : TRXOFF IN DOUBLE-BUFFERED MODE ............. 39

FIGURE 16: LOW POWER LISTENING WITH TWO SLEEP TIMES ... 40 FIGURE 17: POWER PROFILE FOR LOW POWER LISTENING MODE

WHERE NO FRAME IS RECEIVED ................................... 41

FIGURE 18: STATE TRANSITIONS DURING SNIFF MODE ........... 42

FIGURE 19: POWER PROFILE FOR SNIFF WHERE A FRAME IS NOT

RECEIVED ............................................................... 43

FIGURE 20: POWER PROFILE FOR SNIFF WHERE A FRAME IS

RECEIVED ............................................................... 43

FIGURE 21: POWER PROFILE FOR LOW DUTY-CYCLE SNIFF WHERE

A FRAME IS NOT RECEIVED ......................................... 44

FIGURE 22: ESTIMATED RX LEVEL VERSUS ACTUAL RX LEVEL .... 47

FIGURE 23: DW1000 EXTERNAL SYNCHRONISATION INTERFACE

............................................................................ 55

FIGURE 24: SYNCHRONISED TRANSMISSION .......................... 57

FIGURE 25: OSRS MODE RECEIVE TIMEBASE SYNCHRONISATION

............................................................................ 57

FIGURE 26: TRANSMIT POWER CONTROL OCTET .................. 106

FIGURE 27: COMBINING EDG1 AND EDV2 TO GIVE AN ED NOISE

FIGURE ................................................................ 124

FIGURE 28: FLOW CHART FOR DIRECT READ OF AON ADDRESS 167 FIGURE 29: PPM VS CRYSTAL TRIM SETTING, V

= 3.3 V . 200

BATT

FIGURE 30: TRANSMIT AND RECEIVE ANTENNA DELAY ......... 204

FIGURE 31: UWB PHY FRAME STRUCTURE ....................... 212

FIGURE 32:- BPM/BPSK DATA AND PHR MODULATION ...... 212

FIGURE 33: PHR BIT ASSIGNMENT .................................... 215

FIGURE 34: GENERAL MAC MESSAGE FORMAT ................... 217

FIGURE 35: MAC MESSAGE FRAME CONTROL FIELD .............. 218

FIGURE 36: SINGLE-SIDED TWO-WAY RANGING ................... 222

FIGURE 37: DOUBLE-SIDED TWO-WAY RANGING WITH FOUR

MESSAGES ............................................................ 224

FIGURE 38: DOUBLE-SIDED TWO-WAY RANGING WITH THREE

MESSAGES ............................................................ 224

FIGURE 39: RANGING TO 3 ANCHORS WITH JUST 5 MESSAGES

WHERE EACH ANCHOR CALCULATES ITS OWN RANGE RESULT

.......................................................................... 227

DW1000 User Manual

Version 2.12

Page 4 of 242

List of Tables

TABLE 1: MAIN DW1000 OPERATIONAL STATES / MODES ...... 16

TABLE 2: MODE 2 EXCERPT FROM DW1000 DATA SHEET

OPERATIONAL MODES TABLE .................................... 20

TABLE 3: GPIO DEFAULT FUNCTIONS .................................. 21

TABLE 4: REGISTER ACCESSES REQUIRED TO LOAD LDE MICROCODE

........................................................................... 24

TABLE 5: PREAMBLE DURATION FIELD VALUES IN EXTENDED

LENGTH DATA FRAME PHR ...................................... 28

TABLE 6: RECOMMENDED PAC SIZE .................................... 32

TABLE 7: REGISTERS IN THE RX DOUBLE-BUFFERED SWINGING-SET

........................................................................... 36

TABLE 8: AUTO-ACK PREAMBLE LENGTH DEPENDING ON RXPSR

AND RXPACC ........................................................ 51

TABLE 9: AUTO-ACK PREAMBLE LENGTH SELECTION IN EXTENDED

LENGTH FRAMES MODE ............................................ 51

TABLE 10: OTP MEMORY MAP ........................................... 59

TABLE 11: OTP_SRDAT REGISTER .................................... 60

TABLE 12: REGISTER ACCESSES REQUIRED TO PROGRAM THE OTP

........................................................................... 60

TABLE 13: AN EXAMPLE OF REGISTER ACCESSES REQUIRED TO

READ FROM OTP .................................................... 61

TABLE 14: AN EXAMPLE OF REGISTER ACCESSES TO PERFORM A

READ OF THE TEMPERATURE AND VOLTAGE SENSORS ...... 62

TABLE 15: REGISTER MAP OVERVIEW ................................... 63

TABLE 16: PREAMBLE LENGTH SELECTION ............................. 76

TABLE 17: PREAMBLE LENGTH REPORTING ............................ 94

TABLE 18: RXPACC ADJUSTMENTS BY SFD CODE................. 96

TABLE 19: REFERENCE VALUES FOR REGISTER FILE: 0X1E –

TRANSMIT POWER CONTROL, FOR SMART TRANSMIT

POWER CONTROL ................................................. 110

TABLE 20: REFERENCE VALUES REGISTER FILE: 0X1E – TRANSMIT

POWER CONTROL FOR MANUAL TRANSMIT POWER

CONTROL (SMART TRANSMIT POWER CONTROL DISABLED)

......................................................................... 110

TABLE 21: RECOMMENDED SFD SEQUENCE CONFIGURATIONS

FOR BEST PERFORMANCE ........................................ 118

TABLE 22: OTHER POSSIBLE SFD SEQUENCE CONFIGURATIONS

......................................................................... 119

TABLE 23: REGISTER FILE: 0X23 –AGC CONFIGURATION AND

CONTROL OVERVIEW .............................................. 120

TABLE 24: SUB-REGISTER 0X23:04 – AGC_TUNE1 VALUES 122 TABLE 25: SUB-REGISTER 0X23:0C – AGC_TUNE2 VALUES 122 TABLE 26: SUB-REGISTER 0X23:12 – AGC_TUNE3 VALUES 123 TABLE 27: SCALING FACTOR FOR CHANNEL NOISE ENERGY

ESTIMATION ......................................................... 124

TABLE 28: REGISTER FILE: 0X26 – GPIO CONTROL AND STATUS

OVERVIEW............................................................ 128

TABLE 29: REGISTER FILE: 0X27 – DIGITAL RECEIVER

CONFIGURATION OVERVIEW ..................................... 141

TABLE 30: SUB-REGISTER 0X27:02 – DRX_TUNE0B VALUES142 TABLE 31: SUB-REGISTER 0X27:04 – DRX_TUNE1AVALUES 144 TABLE 32: SUB-REGISTER 0X27:06 – DRX_TUNE1B VALUES144 TABLE 33: SUB-REGISTER 0X27:08 – DRX_TUNE2VALUES . 145

TABLE 34: REGISTER 0X27:26 DRX_TUNE4H VALUES ........ 147

TABLE 35: CONSTANTS FOR FREQUENCY OFFSET CALCULATION 148 TABLE 36: REGISTER FILE: 0X28 – ANALOG RF CONFIGURATION

BLOCK OVERVIEW .................................................. 149

TABLE 37: SUB-REGISTER 0X28:0B– RF_RXCTRLH VALUES 151 TABLE 38: SUB-REGISTER 0X28:0C– RF_TXCTRL VALUES ... 151 TABLE 39: REGISTER FILE: 0X2A – TRANSMITTER CALIBRATION

BLOCK OVERVIEW .................................................. 154

TABLE 40: SUB-REGISTER 0X2A:0B – TC_PGDELAY

RECOMMENDED VALUES ......................................... 158

TABLE 41: .................................................................... 159

TABLE 42: REGISTER FILE: 0X2B – FREQUENCY SYNTHESISER

CONTROL BLOCK OVERVIEW ..................................... 159

TABLE 43: SUB-REGISTER 0X2B:07 – FS_PLLCFG VALUES ... 160 TABLE 44: SUB-REGISTER 0X2B:0B – FS_PLLTUNE VALUES 161 TABLE 45: REGISTER FILE: 0X2C – ALWAYS-ON SYSTEM CONTROL

OVERVIEW............................................................ 162

TABLE 46: CONFIGURATIONS MAINTAINED IN THE AON MEMORY

ARRAY................................................................. 166

TABLE 47: REGISTER FILE: 0X2D – OTP MEMORY INTERFACE

OVERVIEW............................................................ 171

TABLE 48: RECEIVER OPERATING PARAMETER SETS ............... 176

TABLE 49: REGISTER FILE: 0X2E – LEADING EDGE DETECTION

INTERFACE OVERVIEW ............................................ 177

TABLE 50: SUB-REGISTER 0X2E:1806– LDE_CFG2 VALUES. 180 TABLE 51: SUB-REGISTER 0X2E:2804 – LDE_REPC

CONFIGURATIONS FOR (850 KBPS & 6.8 MBPS).......... 180

TABLE 52: REGISTER FILE: 0X2F – DIGITAL DIAGNOSTICS

INTERFACE OVERVIEW ............................................ 181

TABLE 53: REGISTER FILE: 0X36 – POWER MANAGEMENT AND

SYSTEM CONTROL OVERVIEW .................................. 190

TABLE 54: REGISTER ACCESSES REQUIRED FOR TRANSMITTER

CONFIGURATION PROCEDURE ................................... 201

TABLE 55: RECOMMENDED RX POWER LEVEL FOR ANTENNA

CALIBRATION ........................................................ 204

TABLE 56: RECOMMENDED TX-RX SEPARATION FOR ANTENNA

CALIBRATION ........................................................ 204

DW1000 User Manual

Version 2.12

Page 5 of 242

TABLE 57: RECOMMENDED PREAMBLE LENGTHS .................. 207

TABLE 58: TRANSMISSIONS PER SECOND USING ALOHA ....... 208

TABLE 59: TECHNIQUES TO SAVE POWER IN RECEIVING ......... 210

TABLE 60: PREAMBLE PARAMETERS .................................. 214

TABLE 61: DW1000 SUPPORTED UWB CHANNELS AND

RECOMMENDED PREAMBLE CODES ............................ 215

TABLE 62: FRAME TYPE FIELD VALUES ................................ 218

TABLE 63: DESTINATION ADDRESSING MODE FIELD VALUES .... 220

TABLE 64: SOURCE ADDRESSING MODE FIELD VALUES ........... 220

TABLE 65: TYPICAL CLOCK INDUCED ERRORS IN SS-TWR TIME OF

FLIGHT ESTIMATION ............................................... 223

TABLE 66: TYPICAL CLOCK INDUCED ERROR IN SS-TWR TIME-OF-

FLIGHT ESTIMATION USING ACTUAL IEEE80.15.4-2011

UWB FRAME LENGTHS........................................... 223

TABLE 67: DOCUMENT HISTORY ....................................... 233

DW1000 User Manual

Version 2.12

Page 6 of 242

DOCUMENT INFORMATION

Disclaimer

Decawave reserves the right to change product specifications without notice. As far as possible changes to functionality and specifications will be issued in product specific errata sheets or in new versions of this document. Customers are advised to check with Decawave for the most recent updates on this product.

LIFE SUPPORT POLICY

Decawave products are not authorized for use in safety-critical applications (such as life support) where a failure of the Decawave product would reasonably be expected to cause severe personal injury or death. Decawave customers using or selling Decawave products in such a manner do so entirely at their own risk and agree to fully indemnify Decawave and its representatives against any damages arising out of the use of Decawave products in such safety-critical applications.

Caution! ESD sensitive device. Precaution should be used when handling the device in order to prevent permanent damage.

REGULATORY APPROVALS

The DW1000, as supplied from Decawave, has not been certified for use in any particular geographic region by the appropriate regulatory body governing radio emissions in that region although it is capable of such certification depending on the region and the manner in which it is used.

All products developed by the user incorporating the DW1000 must be approved by the relevant authority governing radio emissions in any given jurisdiction prior to the marketing or sale of such products in that jurisdiction and user bears all responsibility for obtaining such approval as needed from the appropriate authorities.

DW1000 User Manual

Version 2.12

Page 7 of 242

1 Introduction

Section

Section Name

Information covered

Overview of the DW1000

Gives an overview of the DW1000, describes how to interface to the device and details its various operating modes

Message Transmission

Describes the functionality and use of the DW1000 transmitter

Message Reception

Describes the functionality and use of the DW1000 receiver

Media Access Control (MAC) hardware features

Describes the MAC level functionality provided in hardware by the DW1000.

Other features of the DW1000

Describes other features supported by the DW1000

The DW1000 register set

Describes DW1000 user-accessible register set in detail, lists all user accessible bit fields in each register and their respective functions.

DW1000 Calibration

Describes the parameters of the DW1000 that require calibration; the methodology that should be used in calibrating them and how often they require calibration.

1.1 About the DW1000

The DW1000 is a fully integrated low power, single chip CMOS radio transceiver IC compliant with the IEEE 802.15.4-2011 ultra-wideband (UWB) standard.

• It facilitates proximity detection to an accuracy of +/- 10 cm using two-way ranging time-of-flight (TOF)

measurements.

• It facilitates real time location of assets in to an accuracy of +/- 10 cm using either two-way ranging (TOF)

measurements or one-way time difference of arrival (TDOA) Time Difference of Arrival schemes

• It spans 6 RF bands from 3.5 GHz to 6.5 GHz

• It supports data rates of 110 kbps, 850 kbps and 6.8 Mbps

• Its high data rates allow it to keep on-air time short and thereby save power and extend battery lifetimes

• Its ability to deal with severe multipath environments makes it ideal for highly reflective RF

environments

1.2 About this document

This user manual describes the operation and programming of the DW1000 and discusses some of the design choices to be considered when implementing systems using it.

Information already contained in the DW1000 data sheet is not reproduced here and it is intended that the reader should use this user manual in conjunction with the DW1000 data sheet.

The document is divided into a number of sections each of which deals with a particular aspect of the DW1000 as follows: -

DW1000 User Manual

Version 2.12

Page 8 of 242

Section

Section Name

Information covered

Operational design choices when employing the DW1000

Discusses some of the issues to be considered and trade-offs to be made when building systems based on the DW1000

APPENDIX 1: The IEEE 802.15.4 UWB physical layer

Provides background information on the UWB PHY layer of the IEEE802.15.4 standard

APPENDIX 2: The IEEE 802.15.4 MAC layer

Provides background information on the MAC layer of the IEEE802.15.4 standard

APPENDIX 3: Two-Way Ranging

Gives an introduction to the use of the DW1000 in two-way ranging proximity systems

APPENDIX 4: Abbreviations and acronyms

Provides a list and explanation of abbreviations and acronyms used in the rest of the document

APPENDIX 5: References

Lists the documents referred to in this user manual

Document History

Gives the revision history of this document

Major changes

Gives the major changes at each revision of this document

Note: Decawave also provides DW1000 device driver software as source code. This source code includes a set of API functions to initialise, configure and control the DW1000. It provides API functions for transmission and reception, and for driving the functionalities of the IC. The DW1000 driver source code is targeted for the ARM cortex M3 but is readily portable to other microprocessor systems. The code comes with a number of demo/test applications, (including a two-way ranging application), to exercise the API and the features of the DW1000.

Clock Periods and Frequencies

The chipping rate given by the IEEE 802.15.4-2011 standard [1] is 499.2 MHz. DW1000 system clocks are referenced to this frequency. Where the system clock frequency is given as 125 MHz, this is an approximation to the actual system clock frequency of 124.8 MHz. Similarly, where the system clock period is given as 8 ns, this is an approximation to the actual period of 1/ (124.8×106) seconds.

The 1 GHz PLL clock, where referenced, is an approximation to its actual frequency of 998.4 MHz.

A 63.8976 GHz sampling clock is associated with ranging for the IEEE 802.15.4-2011 standard, where a 15.65 picosecond time period is referred to, it is an approximation to the period of this clock.

PRF

PRF values of 16 MHz and 64 MHz are given in this document. These are approximations to the PRF values dictated by [1]. PRF mean values are slightly higher for SHR as opposed to the other portions of a frame. Mean PRF values are 16.1/15.6 MHz and 62.89/62.4 MHz. Refer to [1] for full details of peak and mean PRFs.

DW1000 User Manual

Version 2.12

Page 9 of 242

Data Rate

Where a data rate of 6.8 Mbps is referred to, this is equivalent to the 6.81/6.8 Mbps data rate in [1].

DW1000 User Manual

Version 2.12

Page 10 of 242

2 Overview of the DW1000

2.1 Introduction

The DW1000 consists of an analog front-end (both RF and baseband) containing a receiver and transmitter and a digital back-end that interfaces to a host processor, controls the analog front-end, accepts data from the host processor for transmission and provides received data to the host processor over an industry standard SPI interface. A variety of control schemes are implemented to maintain and optimize transceiver performance.

2.2 Interfacing to the DW1000

2.2.1 The SPI Interface

The DW1000 host communications interface is a slave-only Serial Peripheral Interface (SPI) compliant with the industry protocol. The host system must include a master SPI bus controller in order to communicate with the DW1000.The SPI bus signals, their voltage levels and signal timings are described in the DW1000 data sheet.

The host system reads and writes DW1000 registers via the SPI. This section describes the format of the SPI transactions. For details of the SPI physical circuits, operational mode configuration and timing parameters please refer to the DW1000 data sheet. The SPI-accessible registers of the DW1000 are detailed in section 7–The DW1000 register set.

2.2.1.1 SPI operating modes

The operating mode of the SPI is determined when the DW1000’s digital control function is initialised as a

result of a device reset or as it is woken up from a sleep state. At this time GPIO lines 5 and 6 are sampled and their values act to select the SPI mode.

It is possible to set the SPI mode within the DW1000’s one-time programmable configuration block to avoid needing any external components and leave the GPIO free for alternative use. This is a one-time activity and cannot be reversed so care must be taken to ensure that the desired SPI mode is set. Please refer to section

6.3–Using the on-chip OTP memory for more details of OTP configuration, and Register file: 0x2D – OTP Memory Interface.

For full details of the SPI operating modes and their configuration, please refer to the DW1000 data sheet.

2.2.1.2 Transaction formats of the SPI interface

Each SPI transaction starts with a one to three octet transaction header followed by a variable number of octets making up the transaction data. The number of data bytes allowed in an SPI transfer is not limited.

The transaction header selects whether the transaction is a read or a write and specifies the address to read from or write to. Physically the SPI interface is full duplex in that every transaction shifts bits both into and out of the DW1000. Logically however each transaction is either reading data from the DW1000 or writing data to it. As shown in Figure 1, for a read transaction all octets beyond the transaction header are ignored

DW1000 User Manual

Version 2.12

Page 11 of 242

by the DW1000, and for a write transaction all octets output by the DW1000 should be ignored by the host

Transaction Header

Host should ignore

MOSI

MISO

Read

Transaction Header

Transaction Body

–

write data input by DW

1000

Host should ignore

MOSI

MISO

Write

Transaction Body

–

read data output by DW

1000

ignored by DW

1000

SPICSn

system.

Figure 1: SPI Read and Write Transactions

Note: The octets are physically presented on the SPI interface data lines with the high order bit sent first in time.

SPI transactions are enveloped by the assertion of the active low chip select line, SPICSn. The high-to-low assertion (low) of SPICSn initialises the SPI transaction handler so that the DW1000 interprets the next octet(s) as a new transaction header. The low-to-high de-assertion of SPICSn ends the SPI transaction. Typically a software SPI interface driver will include a parameter to indicate the length of the transaction, i.e. how many octets to write to the device on the SPI bus, or how many bytes to read.

The SPI accessible parameters of the DW1000 are organised into 64 separate register file locations (detailed in section 7 – The DW1000 register set). Every SPI access transaction header includes a 6-bit register file ID that identifies which register file is being accessed by the transaction. Sub-addressing within the selected register file allows efficient access to all the parameters within the DW1000. Depending on the subaddressing being used, the transaction header is either one, two or three octets long. These three types of transaction are described in the sub-sections below.

Note: when writing to any of the DW1000 registers care must be taken not to write extra data beyond the published length of the selected register (see section 7 – The DW1000 register set).

Figure 2 shows the fields within the one octet transaction header of a simple non-indexed SPI transaction. Bit-6 is zero indicating that a sub-index is not present. The register (file) ID selects the top level addressing of the DW1000 parameter or parameter block being accessed.

DW1000 User Manual

Version 2.12

Page 12 of 242

Figure 2: Single octet header of the non-indexed SPI transaction

7 6 5 4 3 2 1 0

Operation: 0 = Read 1 = Write

Bit = 0, says sub-index is not present

Bit number:

Meaning:

Transaction Header Octet

7 6 5 4 3 2 1 0

Operation: 0 = Read 1 = Write

Bit = 1, says sub-index is present

Extended Address: 0 = no

7-bit Register File sub-address, range 0x00 to 0x7F (128 byte locations)

Bit number:

Meaning:

Transaction Header Octet 1

Octet 2

MOSI

MISO

SPICSn

0 x 00

0 x 30 0 x

01 0 xCA

xDE

Non sub indexed read from register

file ID

0 x 00

this

32 - bit register

contains the Device ID

the 4 -

octet

result is

xDECA

0130

The remaining octets of the transaction, the transaction body, immediately following this one-octet header are read from (or written to) the selected register file beginning at index zero. Figure 3 shows an example of a non-indexed read from the Device ID register using the single octet header.

Figure 3: Example non-indexed read of the Device ID register (0x00)

Note: The octets of a multi-octet value are transferred on the SPI interface in octet order beginning with the low-order octet. This is shown in Figure 3.

2.2.1.2.1 SPI transaction with a 2-octet header

Figure 4 shows the fields within the two octet transaction header of a short-indexed SPI transaction. Bit-6 of the first octet is 1 indicating that a sub-index is present. The register (file) ID in the first octet selects the top level address of the DW1000 parameter block being accessed. In the second octet bit-7 is zero indicating that a further transaction header octet is not present and that the remaining 7 bits of octet-2 are a short sub-index into the register file.

Figure 4: Two octet header of the short indexed SPI transaction

The remaining octets of the transaction, the transaction body, immediately following this two-octet header are read from (or written to) the selected register file beginning at the selected index address 0 to 127. Figure 5 shows an example of an indexed read from the Device ID register using the two octet transaction header.

DW1000 User Manual

Version 2.12

Page 13 of 242

7 6 5 4 3 2 1 0

Operation: 0 = Read 1 = Write

Bit = 1, says sub-index is present

Extended Address: 1 = yes

Low order 7 bits of 15-bit Register file sub-address

range 0x0000 to 0x7FFF (32768 byte locations)

High order 8 bits of 15-bit Register file sub-address

range 0x0000 to 0x7FFF (32768 byte locations)

Bit number:

Meaning:

Transaction Header Octet 1

Octet 2

Octet 3

MOSI

MISO

SPICSn

xC 9 0

xB 6 0 x 02 0 xA

Long sub indexed write of octet value

to the transmit buffer

(

Reg ID

0 x 09

)

at index

310

( 0 x

136

in hex

)

MOSI

MISO

SPICSn

0 x 40 0 x

xCA

xDE

Short sub

indexed read

2 - octets beginning at

index

in register file ID

0 x 00

This reads the

high two octets of this

32 - bit register

the

result is

xDECA

Figure 5: Example short-indexed read of 3rd and 4th octets of register 0x00

2.2.1.2.2 SPI transaction with a 3-octet header

Figure 6 shows the fields within the three octet transaction header of a long-indexed SPI transaction. Bit-6 of the first octet is 1 indicating that a sub-index is present. The register (file) ID in the first octet selects the top level addressing of the DW1000 parameter or parameter block being accessed. In the second transaction header octet bit-7 is set indicating the long form of indexed addressing is to be employed and thus the remaining seven bits of the second octet along with all of the third transaction header octet form a 15-bit sub-index into the selected register file.

The octets of transaction body which immediately follow the transaction header are read from (or written to) the selected register file beginning at the selected sub-index address 0 to 32767.

Figure 7: Example long-indexed write of one octet to index 310 of the TX buffer

Figure 7 shows an example of an indexed write that uses the longer the three octet header. This example is a write to the transmit data buffer at sub index 0x136. The TX buffer has register file ID of 0x09. Octet 1 of transaction header is thus 0xC9 as bit-7 is 1 to signal a write and bit-6 is 1 indicating a sub-address follows. The 15-bit sub-address has the binary value 000-0001-0011-0110. In octet 2 of the transaction header, bit 7 is set to indicate an extended sub-index and the remaining bits contain 0110110, the low 7 bits of the subaddress. Octet 3 of the transaction header then contains 00000010, the remaining eight high order bits of the sub-address index, which is 0x02 in hex.

Figure 6: Three octet header of the long indexed SPI transaction

DW1000 User Manual

Version 2.12

Page 14 of 242

The DW1000 parameters that may be read and written using these SPI transactions are detailed in section 7

– The DW1000 register set.

2.2.2 Interrupts

The DW1000 can be configured to assert its IRQ pin on the occurrence of one or more status events. The assertion of the IRQ pin can be used to interrupt the host controller and redirect program flow to deal with the cause of the event.

The polarity of the IRQ pin may be configured via the HIRQ_POL bit in the Register file: 0x0D – System

Control Register. By default on power up the IRQ polarity is active high. This is the recommended polarity to

ensure lowest power operation of the DW1000 in SLEEP and DEEPSLEEP device states. This pin will float in SLEEP and DEEPSLEEP states and may cause spurious interrupts unless pulled low.

The occurrence of a status event in Register file: 0x0F – System Event Status Register may assert the IRQ pin depending on the setting of the corresponding bit in the Register file: 0x0E – System Event Mask Register.

By default, on power-up, all interrupt generating events are masked and interrupts are disabled.

2.2.3 General Purpose I/O

The DW1000 provides 8 GPIO pins. These can be individually configured at the user’s discretion to be inputs or outputs. The state of any GPIO configured as an input can be read and reported to the host controller over the SPI interface. When configured as an output the host controller can set the state of the GPIO to high or low.

Some of the GPIO lines have multiple functions as listed in the DW1000 data sheet.

The configuration and operation of the GPIO pins is controlled via Register file: 0x26 – GPIO control and

status.

By default, on power-up, all GPIOs are configured as inputs.

2.2.4 The SYNC pin

This pin is used for external clock synchronisation purposes. See section 6.1 – External Synchronisation for further details.

2.3 DW1000 Operational States

2.3.1 State diagram

The DW1000 has a number of different operational states (or modes). These are listed and described in Table 1 below and the transitions between them are illustrated in Figure 8.

DW1000 User Manual

Version 2.12

Page 15 of 242

OFF

Crystal stable,

RSTn released & Digital 1.2V LDO

enabled?

WAKEUP

INIT

RX enabled?

RX TX

RX complete?

Snooze set?

Snooze count complete?

Wakeup Event?

SNOOZE

SLEEP

CLKPLL locked?

TX enabled?

TX complete?

DEEPSLEEP

3.3 V rail > POR threshold?

Restore selected

AON configuration

IDLE

Store selected

AON configuration

SLEEP or DEEPSLEEP?

Power off

AUTO SLEEP?

IRQ Pending?

Force to INIT?

Figure 8: DW1000 State Diagram

DW1000 User Manual

Version 2.12

Page 16 of 242

2.3.2 Overview of main operational states

State Name

State Description

OFF

In the OFF state the DW1000 is completely powered off, with no voltages applied to any of its input pins. Power consumption = 0 µA. No I/O pins should be driven or power will leak through the I/O cells.

WAKEUP

During the WAKEUP state the crystal oscillator and the band-gap are enabled. After approximately 4 ms the digital LDO will be enabled and the RSTn (output) will de-assert allowing the DW1000 to enter the INIT state.

INIT

In the INIT state the main crystal oscillator is running. The raw 38.4 MHz XTAL oscillator frequency is divided by 2 to give a 19.2 MHz internal clock called XTI. In the INIT state digital circuitry of the DW1000 is fed from this 19.2 MHz XTI clock.

If the DW1000 has entered INIT state from a SLEEP or DEEPSLEEP state, (or as a result of a reset), then the register configurations can be automatically restored from the AON memory array.

Then the DW1000 turns on the CLKPLL and after 5 µs the CLKPLL will be locked and the DW1000 will automatically transition into the IDLE state.

SPI accesses from an external microcontroller are possible in the INIT state, but these are limited to a SPICLK input frequency of no greater than 3 MHz. Care should be taken not to have an active SPI access in progress at the CLKPLL lock time (i.e. at t = 5 µs) when the automatic switch from the INIT state to the IDLE state is occurring, because the switch-over of clock source can cause bit errors in the SPI transactions.

It is possible to return to the INIT state from the IDLE state under register control by selecting the XTAL as the clock source and by disabling what is known as sequencing so the device does not automatically transfer into the IDLE state.

IDLE

In the IDLE state the DW1000 internal clock generator CLKPLL is locked running and ready for use but is gated off to most circuitry to minimize power consumption. In the IDLE state SPI communications can operate at up to 20 MHz, the maximum SPICLK frequency. In the IDLE state the analog receive and transmit circuits are powered down. The external host can control the DW1000 to initiate a transmission or reception and thus cause the DW1000 to progress into TX state or RX state respectively. If a delayed TX or RX operation is initiated (see section 3.3 – Delayed Transmission and 4.2 – Delayed

Receive) then the DW1000 will stay in the IDLE state until the delayed time has elapsed,

after which it will enter the TX state or RX state.

SLEEP

In the SLEEP state the IC consumes < 1 µA from the external power supply inputs. All internal LDOs are turned off. In the SLEEP state the DW1000 internal low powered ring oscillator is running and is used to clock the sleep counter whose expiry is programmed to “wake up” the DW1000 and progress into the WAKEUP state. While in SLEEP power should not be applied to GPIO, SPICLK or SPIMISO pins as this will cause an increase in leakage current.

Table 1: Main DW1000 operational states / modes

DW1000 User Manual

Version 2.12

Page 17 of 242

State Name

State Description

DEEPSLEEP

With the exception of the OFF state, the DEEPSLEEP state is the lowest power state of the device.

In DEEPSLEEP all internal circuitry is powered down with the exception of the always-on memory which can be used to hold the device configuration for restoration on wakeup

Once in DEEPSLEEP the DW1000 remains there until the occurrence of a wakeup event. This can be either:

1. the SPICSn line pulled low or

2. the WAKEUP line driven high

for the duration quoted in the DW1000 data sheet (nominally 500 μs).

It is also recommended to use the SLP2INIT or CPLOCK event status bits (in Register file:

0x0F – System Event Status Register) to drive the IRQ interrupt output line high to

confirm the wake-up.

Once the DW1000 has detected a wakeup event it progresses into the WAKEUP state. While in DEEPSLEEP power should not be applied to GPIO, SPICLK or SPIMISO pins as this will cause an increase in leakage current.

TX state

In the TX state the DW1000 actively transmits a frame containing the contents of the transmit buffer on the configured RF channel with the configured transmit parameters (PRF, data rate, preamble code etc.)

Once the frame transmission is complete the DW1000 may enter one of three modes depending on the programmed configuration.

After the frame transmission is complete the DW1000 will return to the IDLE state unless the ATXSLP bit is set (in Sub-Register 0x36:04 – PMSC_CTRL1) in which case the DW1000 will enter the SLEEP or DEEPSLEEP state automatically, (as long as no host interrupts are pending).

Note that it is not possible to be in the TX and RX states simultaneously – the DW1000 is a half-duplex transceiver device.

RX state

In the RX state, the DW1000 receiver is active, either hunting for preamble or (once it has detected preamble) actively receiving preamble searching for SFD, and subsequently receiving the PHR, decoding it and receiving the data part of the frame. In the RX state, the RF synthesiser and all RX blocks are active. After an event that ends the reception, (either a good frame RX, or some error or timeout event that aborts reception) the DW1000 will return to the IDLE state unless the ARXSLP bit is set (in Sub-Register

0x36:04 – PMSC_CTRL1) in which case the DW1000 will enter the SLEEP or DEEPSLEEP

state automatically (as long as no host interrupts are pending).

Note that it is not possible to be in the RX and TX states simultaneously – the DW1000 is a half-duplex transceiver device.

SNOOZE

The SNOOZE state is similar to the INIT state except that a counter is running to cause the DW1000 to automatically go to the RX state (via INIT and IDLE) when the counter expires. The snooze count times are in units of the raw 19.2 MHz XTI clock rate, (since

DW1000 User Manual

Version 2.12

Page 18 of 242

State Name

State Description

the 125 MHz digital PLL clock is not running).

IDLE

INIT

OFF

WAKEUP

CLKPLL locked

Crystal stable,

RSTn=1

POWERON

VDDBATT

EXTON

XTAL

VDDDIG

RSTn

por

SPI comms up to 3MHz

SPI comms up

to max SPI frequency

Battery Inserted

VDDBATT switched on

300µs

4ms

5µs

7µs

CLKPLL

Lock

CLKPLL enabled

SPI comms not advised

as PLL locks

2.4 Power On Reset (POR)

When the external power source is applied to the DW1000 for the first time, the internal Power On Reset (POR) circuit compares the externally applied supply voltage to an internal power-on threshold (approximately 1.5 V), and once this threshold is passed the crystal oscillator is enabled and the external device enable pin EXTON is asserted. An internal counter running off the low power oscillator is used to hold the DW1000 in reset to ensure that the crystal oscillator is stable before it gets used. Once the digital reset is de-asserted the digital core wakes up and enters the WAKEUP state. From this state it will automatically turn on the CLKPLL and wait for it to lock before entering the IDLE state.

Figure 9: Timing diagram and power profile for cold start POR

2.4.1 SLEEP and DEEPSLEEP

In the DW1000 very low power DEEPSLEEP state, the IC is almost completely powered down except for a small amount of memory necessary to maintain IC configurations. This is the lowest power mode of the IC where the power drain is < 100 nA. To wake the IC from DEEPSLEEP requires an external agent to assert the WAKEUP input line or the external host microprocessor to initiate an SPI transaction to assert the SPICSn input.

The DW1000 also includes a low power SLEEP state where the IC can wake itself from sleeping as a result of the elapsing of a sleep timer that is running from a low-powered ring oscillator internal to the DW1000 IC. In this SLEEP state the power drain is < 1 µA. The DW1000 may wake from SLEEP state when the sleep timer elapses. The WAKEUP or SPICSn inputs may also be used to wake the device.

DW1000 User Manual

Version 2.12

Page 19 of 242

The frequency of the low power oscillator is dependent on process variations within the IC, but is generally somewhere in between 7,000 and 13,000 Hz. There are facilities within the IC to measure the length of an LP oscillator cycle, in counts of the IC crystal oscillator divided by two, (i.e. this is 38.4 MHz ÷ 2, or 19.2 MHz).

2.4.1.1 Waking from sleep

The return from SLEEP and DEEPSLEEP modes, is via

 Driving the WAKEUP pin high for approximately 500 μs, (assuming the WAKE_PIN configuration bit is

set in Sub-Register 0x2C:06 – AON_CFG0).

 Driving the SPICSn pin low for approximately 500 μs, (assuming the WAKE_SPI configuration bit is set

in Sub-Register 0x2C:06 – AON_CFG0). This can be achieved by doing a dummy SPI read of sufficient length.

NOTE: When using the SPICSn pin to wake up the device it is important that the SPIMOSI line is held low for the duration of the SPICSn to ensure that a spurious write operation does not occur.

In addition return from SLEEP also occurs when

 The internal sleep timer counter expires, (assuming the WAKE_CNT configuration is bit is set in Sub-

In all of three wakeup cases the device is returned to the IDLE state by default but additional state transitions can be automatically enacted thereafter depending on configurations.

2.4.1.2 Configuration register preservation

Prior to entering the SLEEP and DEEPSLEEP states and prior to exiting the WAKEUP state, the main DW1000 configurations are copied to and from an Always-On memory (AON). Power is maintained to AON memory at all times, even in SLEEP and DEEPSLEEP states. The copying of configuration data (saving or restoring) takes about 7 µs to complete. The detail of which configurations are saved and restored is given in Table

46: Configurations maintained in the AON. Restoration of configurations during the WAKEUP state is only

done if the ONW_LDC configuration bit is set in 7.2.45.1 – Sub-Register 0x2C:00 – AON_WCFG.

Note: The host system should avoid SPI access to general system registers or OTP Memory during the copying period to prevent any conflicts occurring. Access to the TX (or RX) buffer is not restricted during this

period.

2.4.1.3 Automatically loading LDO calibration data from the OTP

When waking from SLEEP or DEEPSLEEP it is necessary to load the LDOTUNE_CAL value from the OTP if it has been programmed during IC production test calibration. To confirm if the LDOTUNE_CAL has been programmed first read the OTP address 0x4. If this reads back as non-zero (only the first byte needs to be checked) then the device has been calibrated and the ONW_LLDO bit in Sub-Register 0x2C:00 – AON_WCF must be set. This will allow the OTP parameter LDOTUNE_CAL to be automatically copied over to the required register (Sub-Register 0x28:30 – LDOTUNE) each time the DW1000 wakes up. If the OTP address 0x4 reads back as zero, then the ONW_LLDO bit must not be set.

DW1000 User Manual

Version 2.12

Page 20 of 242

2.4.2 Specific state sequences supported by the DW1000

Mode Name

Mode Description

SNIFF MODE

In SNIFF mode the DW1000 alternates between the RX (on) and the IDLE (off) states. Further details on this mode are given in section 4.5.1 – SNIFF.

LOW DUTY CYCLE SNIFF MODE

LOW POWER LISTENING

Low-Power Listening mode is a special mode where the receiver spends most its time in a low power (SLEEP or DEEPSLEEP) state only waking up occasionally to sample the air for a message. This feature is described in detail in section 4.4 – Low-Power Listening

Mode

Data Rate

PRF

(MHz)

Preamble

(Symbols)

Data

Length

(Bytes)

Packet

Duration (µs)

Typical Use Case

(Refer to DW1000 user manual for further information)

Mode 2

6.8 Mbps

128

152

RTLS, TDOA Scheme, Short Range, High Density

The DW1000 supports a number of state sequences intended to minimize power consumption in certain applications. These are: -

2.5 Default Configuration on Power Up

DW1000 is a highly configurable transceiver with many features. The register reset values have been selected with the intention of minimising user configuration required. The default configuration may be summarised as being channel 5, preamble code 4 and mode 2. Channel numbers and preamble codes are as specified in the standard, IEEE 802.15.4-2011 [1] and mode 2 is as specified in the DW1000 data sheet modes and comprises the following configurations:

Table 2: Mode 2 Excerpt from DW1000 Data Sheet Operational Modes Table

Some further details are given below on the specifics of the default device configuration. For full details the reader may refer to the register map where the default value of each register is given, section 7 – The

DW1000 register set.

2.5.1 Default System Configuration

Much of the system configuration is configured in the SYS_CFG register, please see section Register file: 0x04

– System Configuration for a full description of the register contents and defaults.

By default, interrupt polarity is active high and all interrupts are disabled, see the SYS_CFG register for interrupt polarity and the SYS_MASK and SYS_STATUS registers for interrupt configuration and information, see sections Register file: 0x0E – System Event Mask Register and Register file: 0x0F – System Event Status

DW1000 User Manual

Version 2.12

Page 21 of 242

GPIOs are set to mode 0, their default function as shown in Table 3.

GPIO Pin

Default Function

GPIO0/RXOKLED

GPIO0

GPIO1/SFDLED

GPIO1

GPIO2/RXLED

GPIO2

GPIO3/TXLED

GPIO3

GPIO4/EXTPA

GPIO4

GPIO5/EXTTXE/SPIPHA

GPIO5

GPIO6/EXTRXE/SPIPOL

GPIO6

SYNC/GPIO7

SYNC

IRQ/GPIO8

IRQ

Table 3: GPIO Default Functions

Smart TX power is on by default, see section Register file: 0x1E – Transmit Power Control and Smart Transmit

Power Control for configuration and operation information.

Sniff mode is off, see Register file: 0x1D – SNIFF Mode for details, frame wait timeout (see SYS_CFG register bit RXWTOE and Register file: 0x0C – Receive Frame Wait Timeout Period) and preamble detection timeout (see Sub-Register 0x27:24 – DRX_PRETOC) are off, whilst SFD detection timeout (see Sub-Register 0x27:20 –

DRX_SFDTOC) is on.

Other SYS_CFG register settings such as Automatic Receiver Re-Enable (RXAUTR) and MAC functions such as frame filtering (FFEN), double buffering (DIS_DRXB) and automatic acknowledgement (AUTOACK) are all off by default. Automatic CRC generation is on and the CRC LFSR is initialized to 0’s (FCS_INIT2F).

Note that CRC generation is selected as part of a transmit command, see Register file: 0x0D – System Control

External synchronisation and the use of external power amplifiers are deactivated by default, see sections

6.1 – External Synchronisation and 6.2 – External Power Amplification.

2.5.2 Default Channel Configuration

Channel 5, preamble code 4 and 16 MHz PRF are set by default in the CHAN_CTRL register, see Register file:

0x1F – Channel Control for more information.

The transmit data rate is set to 6.8 Mbps in the TX_FCTRL register, see TXBR field in Register file: 0x08 –

Transmit Frame Control . The receive data rate is never set unless 110 kbps reception is required. Note that

this must be configured in register SYS_CFG, field RXM110K, see Register file: 0x04 – System Configuration.

The RF PLL and Clock PLL are configured for channel 5 operation by default, please refer to Register file: 0x2B

– Frequency synthesiser control block for channel configuration settings for each channel.

DW1000 User Manual

Version 2.12

Page 22 of 242

2.5.3 Default Transmitter Configuration

Transmit RF channel configurations are set for channel 5 by default – see Sub-Register 0x28:0C– RF_TXCTRL.

Transmit Smart power is enabled by default via the DIS_STXP bit in SYS_CFG register, refer to Register file:

0x04 – System Configuration. Please see section 7.2.31.2 – Smart Transmit Power Control for further

information.

The transmit preamble symbol repetition length is 128 symbols, see Register file: 0x08 – Transmit Frame

Control, TXPSR and PE fields for configuration details.

2.5.4 Default Receiver Configuration

Receiver RF channel configurations are set for channel 5 by default, see Sub-Register 0x28:0B– RF_RXCTRLH.

Digital receiver tuning registers; DRX_TUNE0b, DRX_TUNE1a, DRX_TUNE1b and DRX_TUNE2 are configured by default for 16 MHz PRF, 6.8 Mbps data rate and a preamble symbol repetition of length 128. See Sub-

and Sub-Register 0x27:08 – DRX_TUNE2 for programming details.

The LDERUNE bit is enabled by default, which means that the microcode (the LDE algorithm) that has been loaded in RAM will execute on every frame reception, which in turn will calculate accurate frame time-ofarrival. However the DW1000 needs to load this microcode on power-on from a special ROM area in the DW1000. This is done by enabling the LDELOAD bit as part of DW1000 initialisation (because after powering up the DW1000 (or after exiting SLEEP or DEEPSLEEP states) the LDE RAM is empty). This should be done before the receiver is enabled if it is important to timestamp this received frame. If the LDE code is not being loaded before the receiver is enabled then the LDERUNE (LDE run enable) control in Sub-Register

0x36:04 – PMSC_CTRL1 must be turned off (set to zero).

2.5.5 Default Configurations that should be modified

Although the DW1000 will power up in a usable mode for the default configuration outlined, some of the register defaults are sub optimal and should be overwritten before proceeding to use the device in the default mode.

2.5.5.1 AGC_TUNE1

AGC_TUNE1 is set to 0x889B by default which is not the optimal value for the default PRF of 16 MHz. For best performance the user should set this value to 0x8870 before proceeding to use the default device configuration. Refer to Sub-Register 0x23:04 – AGC_TUNE1.

2.5.5.2 AGC_TUNE2

AGC_TUNE2 must be set as described in Sub-Register 0x23:0C – AGC_TUNE2 for correct functioning of DW1000.

DW1000 User Manual

Version 2.12

Page 23 of 242

2.5.5.3 DRX_TUNE2

DRX_TUNE2 is set to 0x311E0035 by default which is not the optimal value for the default PRF and PAC. For best performance the user should set this value to 0x311A002D before proceeding to use the default device configuration. Refer to Sub-Register 0x27:08 – DRX_TUNE2.

2.5.5.4 NTM

NTM is set to 0xC by default and may be set to 0xD for better performance, refer to Sub-Register 0x2E:0806

– LDE_CFG1.

2.5.5.5 LDE_CFG2

LDE_CFG2 is set to 0x0000 by default and should be set to 0x1607 for 16 MHz PRF before proceeding to use the default configuration, refer to Sub-Register 0x2E:1806– LDE_CFG2.

2.5.5.6 TX_POWER

The TX_POWER setting is 0x1E080222 by default. This value should be set to 0x0E082848 before proceeding to use the default configuration. Please see section 7.2.31.2 – Smart Transmit Power Control for further information.

2.5.5.7 RF_TXCTRL

RF_TXCTRL is not set to the optimum values by default. This value should be set for channel 5 according to Table 38 before proceeding to use the default configuration. Please see Sub-Register 0x28:0C– RF_TXCTRL for further information.

2.5.5.8 TC_PGDELAY

TC_PGDELAY is set to 0xC5 by default, which is the incorrect value for channel 5. This value should be set to 0xC0 before proceeding to use the default configuration. Please see Sub-Register 0x2A:0B – TC_PGDELAY for further information.

2.5.5.9 FS_PLLTUNE

FS_PLLTUNE is set to 0x46 by default, which is not the optimal value for channel 5. This value should be set to 0xBE before proceeding to use the default configuration. Please see Sub-Register 0x2B:0B – FS_PLLTUNE for further information.

2.5.5.10 LDELOAD

LDELOAD is reset to 0 by default. This needs to be set as part of DW1000 initialisation and before receiver

enable, if it is important to get timestamp and diagnostic information from received frames. See description of LDELOAD bit for further information. The table below outlines the programming steps to load the microcode from ROM into RAM.

DW1000 User Manual

Version 2.12

Page 24 of 242

Table 4: Register accesses required to load LDE microcode

Step

Number

Instruction

Data

Length

(Bytes)

Data

(Write/Read)

L-1

Write Sub-Register

0x36:00 (PMSC_CTRL0)

0x0301

L-2

Write Sub-Register

0x2D:06 (OTP_CTRL)

0x8000

Wait 150 µs

L-3

Write Sub-Register

0x36:00 (PMSC_CTRL0)

0x0200

2.5.5.11 LDOTUNE

It is necessary to load the LDOTUNE_CAL value from the OTP if it has been programmed during IC production test calibration. To confirm if the LDOTUNE_CAL has been programmed first read the OTP address 0x4. If this reads back as non-zero (only the first byte needs to be checked) then the device has been calibrated. To load this value automatically following a wake up from SLEEP or DEEPSLEEP see the section on Waking from

sleep. To use this value immediately, it should be read directly from OTP and written to Sub Register File

0x28:30 LDOTUNE.

DW1000 User Manual

Version 2.12

Page 25 of 242

3 Message Transmission

Preamble

SFD

PHR

Data

IEEE STD

1024

4096

symbols

*Extra

128

256

512

1536

2048

symbols

IEEE STD

symbols

*Extra

symbols

bits

IEEE STD

Up to

127

coded octets

*Extended

Up to

1023

coded octets

complete

YES

AUTOSLEEP

Write Tx data to data buffer

Configure Tx parameters

Transmit message

TX START

TRANSMIT

YES

IDLE

YES

SLEEP

Figure 11: Basic Transmit Sequence

3.1 Basic Transmission

The transmission of data frames is one of the basic functions of the DW1000 transceiver. Figure 10 shows the elements of the transmitted frame.

*Additional configurations marked “Extra” or “Extended” are proprietary to Decawave; see section 3.4 for details of

Extended Length Data Frames

Figure 10: Transmit Frame format

The modulation details of these frame elements can be found in section 10 – APPENDIX 1: The IEEE 802.15.4 UWB physical

layer.

The transmit sequence is as shown in Figure 11. The DW1000 begins in the IDLE state awaiting instruction from the host controller.

In order to transmit, the host controller must write data for transmission to Register file: 0x09 – Transmit Data Buffer. The desired selections for preamble length, data rate and PRF must also be written to Register file: 0x08 – Transmit Frame Control. Transmitter configuration is carried out in the IDLE state, but frame configurations may be carried out during active transmit as described in section 3.5 – High Speed Transmission. Assuming all other relevant configurations have already been made, the host controller initiates the transmission by setting the TXSTRT control bit in Register file: 0x0D – System Control

automatically sends the complete frame; preamble, SFD, PHR and data. The FCS (CRC) is automatically appended to the message as an aid to the MAC layer framing.

The end of frame transmission is signalled to the host via the TXFRS event status bit in Register file: 0x0F – System Event

Status Register, and the DW1000 returns to IDLE mode to await

new instructions.

DW1000 User Manual

Version 2.12

Page 26 of 242

Further transmission features are described in the following sections:

 Transmit message time-stamping – see section 3.2 –Transmission timestamp.  Delayed transmission – see section 3.3 – Delayed Transmission.  Long transmit frames – see section 3.4 – Extended Length Data Frames.  High Speed transmit – see section 3.5 – High Speed Transmission.

3.2 Transmission timestamp

During frame transmission the start of the PHR (PHY header) is the event nominated by the IEEE 802.15.4 UWB PHY standard for message time-stamping. The time the first symbol of the PHR launches from the antenna (defined as the RMARKER) is the event nominated as the transmit time-stamp.

The DW1000 digital transmit circuitry takes note of the system clock counter as the RAW transmit timestamp at the point when it begins sending the PHR. It then adds to this the transmit antenna delay (configured in Register file: 0x18 – Transmitter Antenna Delay) to get the antenna adjusted transmit time- stamp that it writes to the TX_STAMP field of Register file: 0x17 – Transmit Time Stamp.

See also section 8.3 – IC Calibration – Antenna Delay.

3.3 Delayed Transmission

For delayed transmission, the transmit time is programmed into Register file: 0x0A – Delayed Send or Receive

Time and then the delayed transmission is initiated by setting both TXDLYS and TXSTRT controls in Register file: 0x0D – System Control Register.

One of the design goals of delayed transmission was that the specified transmission time would be predictable and aligned with the Transmit timestamp. This was achieved in that the transmission time specified is the time of transmission of the RMARKER (not including the TX antenna delay), that is the raw TX time, TX_RAWST in Register file: 0x17 – Transmit Time Stamp before the antenna delay is added. This allows for the time of transmission of a message to be pre-calculated and embedded in the message being transmitted.

NOTE: The low-order 9 bits of the delayed Transmit value programmed into Register file: 0x0A – Delayed

Send or Receive Time are ignored giving a time resolution of 8 ns, or more precisely 4 ÷ (499.2×106). To

calculate the time of transmission of the RMARKER at the antenna, the low 9 bits of the delayed TX time should be zeroed before adding the TX antenna delay.

In performing a delayed transmission, the DW1000 calculates an internal start time for when to begin sending the preamble to make the RMARKER raw timestamp agree with the programmed transmit time. The DW1000 remains in idle state until the system time (Register file: 0x06 – System Time Counter) reaches the correct point to turn on the transmitter and begin preamble.

One use of delayed transmission (and reception), is in symmetric double-sided two-way ranging, (described in APPENDIX 3: Two-Way Ranging), where it is important to keep the response times the same at both ends to reduce the error in range estimate. Minimising the response time also reduces this error, and in working

DW1000 User Manual

Version 2.12

Page 27 of 242

to minimise this the host microprocessor may sometimes be late invoking the delayed TX, i.e. so that the system clock has passed the specified start time (i.e. internal start time mentioned above) and then the IC has to complete almost a whole clock count period before the start time is reached. The HPDWARN event status flag in Register file: 0x0F – System Event Status Register warns of this “lateness” condition so that during application development the delay may be chosen large enough to generally avoid this lateness. The HPDWARN status flag also serves to facilitate detection of this late invocation condition so that recovery measures may be taken should it ever occur in deployed product. For delayed transmission it is the internal start time mentioned above that is used when deciding whether to set the HPDWARN event for the delayed transmit. As long as the preamble start time is the near future, the HPDWARN event flag will not be set. If a long delay was intended then the HPDWARN flag can be ignored and the transmission will begin at the allotted time. If a long delay was not intended then the transmission can be stopped by issuing a TRXOFF via

Under normal circumstances the IC transmitter needs a few microseconds to power up the transmitter – this time is correctly handled for the RMARKER positioning, but is not included in the HPDWARN calculation. So, if the initiation of a delayed transmission is commanded early enough so that it does not generate a HPDWARN event but not sufficiently early for the IC transmitter to power up before the start of preamble; then frame transmission will still occur and the RMARKER will be sent at the correct time, but, during the initial few symbols of preamble (while the transmitter is powering-up) the preamble may not be sent correctly. For most use cases this will not be an issue, as there is generally ample preamble remaining for good reception. However for shorter preamble sequences, especially the 64-symbol preamble sequence, losing a few symbols can have a performance impact.

When using delayed transmission with 64-symbol preambles then, designers should also be aware that the power-up time for the transmitter is not included in the HPDWARN calculation which means that if the preamble start time is too close then the initial few symbols of preamble (while the transmitter is poweringup) may not be sent correctly. This is flagged in a transient TXPUTE bit status and counted in Sub-Register

0x2F:1A – Transmitter Power-Up Warning Counter, (assuming counting is enabled by the EVC_EN bit in Sub- Register 0x2F:00 – Event Counter Control). It is recommended that checks are added, during design

validation, to ensure that the HPDWARN event does not happen and also (especially for short preambles) that the TXPUTE event does not happen, and take appropriate measures to avoid them (like increasing the response delay time).

3.4 Extended Length Data Frames

Standard IEEE 802.15.4-2011 UWB frames carry up to 127 bytes of payload. The DW1000 supports a nonstandard mode of operation with frame lengths up to 1023 bytes of data. This mode of operation is enabled via the PHR_MODE selection bits of Register file: 0x04 – System Configuration.

In this proprietary mode the PHY header (PHR) is redefined to carry the 3 extra bits of frame length. In order to communicate extended length data frames between two DW1000 devices both ends must be set to the long frame PHY header mode via the PHR_MODE selection bits of Register file: 0x04 – System Configuration. If the setting is only at one end of a link any attempt at communication will fail with PHR errors being reported. When long frame mode is selected, the DW1000 will be unable to communicate with any device

DW1000 User Manual

Version 2.12

Page 28 of 242

operating with standard frame encoding because the SECDED error check sequence of the PHR in long frame

Preamble length for

BPM-BPSK modulation

mode

64 to 1024 symbols

1536 to 4096 symbols

Bit

1 2 3 4 5 6 7 8 9 10 11 12 13 14 14 16 17 18

R1 R0 L9 L8 L7 L6 L5 L4 L3 L2 L1 L0 P0 S5 S4 S3 S2 S1 S0

Data Rate

SECDED Check Bits

Preamble

Duration

Frame Length

mode is incompatible with the standard encoding.

Note also that the probability of an error occurring within a frame increases as the frame length is increased, and as a result of this increasing the frame length may or may not improve system throughput depending on the frame error rate and the need to retransmit frames when there is an error.

In long frame mode only the high order bit of the TXPSR value from Register file: 0x08 – Transmit Frame

Control is sent in the PHR and reported in the RXPSR value in Register file: 0x10 – RX Frame Information Register.

The PHR encoding for the proprietary extended length data frames is shown below in Figure 12:

Figure 12 : PHR Encoding Extended Length Data Frames

The Data Rate field has the same encoding as used for the IEEE 802.15.4-2011 PHR.

The frame length field L9-L0 is an unsigned 10-bit integer number that indicates the number of octets in the PSDU from the MAC sub-layer. Note that the high order bit of the length is transmitted first in time.

A single bit, P0, provides the Preamble Duration field, indicating the length of the SYNC portion of the SHR shown in Table 5.

Table 5: Preamble Duration field values in Extended Length Data Frame PHR

The Preamble Duration field may be used by a receiver to set the value of the preamble duration for an ACK frame.

Valid preamble lengths are 64, 128, 256, 512, 1024, 1536, 2048 and 4096 symbols. Since the Preamble Duration field in the transmitted frame covers a range of preamble lengths, a receiver may count the

DW1000 User Manual

Version 2.12

Page 29 of 242

number of preamble symbols received to additionally inform the choice of preamble length for any response frames.

The SECDED (single error correct, double error detect) field, S5–S0, is a set of six parity check bits that are used to protect the PHR from errors caused by noise and channel impairments. The SECDED calculation is the same as that defined in the IEEE 802.15.4-2011 standard except the bits C5–C0 are inverted to get S5–S0 as follows:

S0 = NOT (C0)

S1 = NOT (C1)

S2 = NOT (C2)

S3 = NOT (C3)

S4 = NOT (C4)

S5 = NOT (C5)

3.5 High Speed Transmission

Certain features of the DW1000 are designed to support maximum utilisation of the transmitter. These features are described below:

3.5.1 TX buffer offset index

The TXBOFFS field (in Register file: 0x08 – Transmit Frame Control) allows the TX_BUFFER to be used to hold more than one frame, (providing that data can fit within the 1024 octets of the buffer). In initiating a transmission then the host controller will set the TXBOFFS offset index to the first octet of the frame to be transmitted and set the length field to reflect the length of the frame to send. While sending is in progress, the host controller can prepare and write another frame to a different part of the TX_BUFFER. After transmission of the first frame then, the host has saved the time needed to write the next data frame, and just needs to set the offset and initiate the transmission of the next frame.

During a data streaming or bulk data transfer then the host controller might divide the TX_BUFFER into two areas of 512 octets each, sending from them alternately. For acknowledged data transfer then: the receipt

of the acknowledgement for frame, frame “A” (say), can be used to trigger the sending of the next frame, frame “B” (say), that is already waiting in the other half of the buffer and at the same time signalling that the buffer half that contained the acknowledged frame “A” can now, (while frame “B” is being transmitted), be filled with the data for the subsequent frame, frame “C” (say). Where the acknowledgement for frame “A” is

not received, the data for it is still in the TX_BUFFER ready to be retransmitted.

3.5.2 TX buffer write while sending or receiving

For fast turnaround it is possible to initiate preamble sending before writing the frame data to the TX_BUFFER or writing the frame length to the length as specified in the TFLEN and TFLE fields of the Register

file: 0x08 – Transmit Frame Control. So preamble transmission can begin before the TX data is written into

the DW1000. The host microprocessor then has the time of any fixed response delay, and the time for sending preamble and SFD before it needs to have the frame length set in TFLEN and TFLE ready for the

DW1000 User Manual

Version 2.12

Page 30 of 242

DW1000 to insert into the PHR, and thereafter the host microprocessor needs to have the individual octets of data written into the TX_BUFFER before they are consumed by the DW1000 transmitter.

Clearly to do this care needs to be taken to have the frame length setup ready for inclusion in the PHR and to have the data written into the TX_BUFFER before it is consumed, and, mechanisms are needed to ensure that the wrong data cannot be sent as a good frame. The mechanisms to achieve this involves using SFCST to suppress FCS transmission until all data is written to the TX_BUFFER and then CANSFCS to cancel this suppression so that the FCS will be sent. (Both SFCST and CANSFCS are in Register file: 0x0D – System Control

While this technique is of use for fast responses, it could also be used for streaming in cases where the use of the scheme described in section 3.5.1 – TX buffer offset index is not suitable, i.e. where the frame size is between 513 and 1023 octets.

Similarly if DW1000 is actively receiving, data may be written to the TX_BUFFER while the receiver is active. The following are the points of note for optimum throughput or fast response turnaround:

(a) The frame length should be set up as early as possible:

For streaming, TFLEN, TFLE, TXBOFFS, may be reprogrammed for the next frame as soon as the PHR is sent, i.e. after the TXPHS (Transmit PHY Header Sent) event has been signalled.

For transmission of a response, depending on the application, the length of the response may be known before the soliciting message has arrived. This is often true for example in two-way ranging.

(b) Initiate transmission as early as possible:

For streaming this is as soon as the previous transmission has finished or previous reception has finished (RXDFR has been set). This is signalled by the activation of the TXFRS (Transmit Frame Sent) event status bit is set in Register file: 0x0F – System Event Status Register, an event that would generally be picked up by an interrupt handler in the host system.

For transmission of a response, the application may have to parse some of the message before deciding whether a response is required. This parsing could perhaps be begun early but in any case the initiation of transmission will in general be as soon as possible after the arrival of the message soliciting the response. Message arrival is signalled by the RXDFR (Receiver Data Frame Ready) event status bit in Register file: 0x0F – System Event Status Register, an event also generally picked up by an interrupt handler in the host system.

Issue the TXSTRT with SFCST (Transmit Start with Suppress auto-FCS Transmission) instruction in

transmission.

This might be done in the interrupt handler or in a high priority task scheduled by it.

(d) Cancel the suppression of FCS as soon as possible thereafter.

This is done by issuing the CANSFCS (Cancel Suppression of auto-FCS transmission) instruction in

DW1000 User Manual

Version 2.12

Page 31 of 242

to the TX_BUFFER before the DW1000 needed to consume it, then this will be successful and the frame will be sent with a good CRC, and that is essentially the end of the discussion on this technique.

If the host system has not been quick enough in writing the data this will result in the frame being sent with the wrong data but with a bad CRC also. The DW1000 transmitter includes a circuit to detect the host microprocessor writing to the buffer between the selected TXBOFFS and any address the IC has already consumed the data from, which is taken to mean that the data is being written too late for transmission. This “Transmit Buffer Error” condition will cause the DW1000 to ignore the CANSFCS command so the frame is sent with a bad CRC. It is signalled by the TXBERR bit in Register

file: 0x0F – System Event Status Register. Clearly this is a bad condition that will not help system

performance. It is up to system designers to avoid this condition, debugging and removing it during the design phase, by ensuring the system responsiveness is sufficient such that this never happens, (e.g. by employing a faster processor or a faster SPI, or by increasing the response/inter-frame delay or increasing the preamble length).

DW1000 User Manual

Version 2.12

Page 32 of 242

Expected preamble

length of frames being

received

Recommended PAC size

64 8 128 8 256

512

1024

1536

2048

4096

complete?

YES

AUTOSLEEP?

Configure Rx parameters

Search for Preamble

RX START?

RECEIVE

YES

IDLE

Preamble

Detected?

Preamble Detection Timeout?

YES

Acquire SFD

Preamble Acquisition complete?

SFD Timeout?

YES

Acquire data

Frame

Received?

YES

Frame Wait

Timeout?

YES

Acquire Preamble

YES

SLEEP

Figure 13: Basic receive sequence

4 Message Reception

4.1 Basic Reception

The reception of a frame is enabled by a host request or by an automatic re-enabling of the receiver. The receiver will search for preamble continually until preamble has been detected or acquired, when a demodulation will be attempted. A preamble detection timeout may be set to allow the receiver to stop searching for preamble after a desired period. A basic receive sequence is shown in Figure 12.

4.1.1 Preamble Detection

The preamble sequence is detected by cross-correlating in chunks which are a number of preamble symbols long. The size of chunk used is selected by the PAC configuration in Sub-Register 0x27:08 – DRX_TUNE2. The PAC size should be selected depending on the expected preamble size. A larger PAC size gives better performance when the preamble is long enough to allow it. But if the PAC is too large for the preamble length then receiver performance will be impaired, or fail to work at the extremes – (e.g. a PAC of 64 will never receive frames with just 64 preamble symbols). Table 6 gives the recommended PAC size configuration to use in the receiver depending on the preamble length being used in the transmitter.

Table 6: Recommended PAC size

The choice of preamble length is discussed in section 9.3

– Choice of data rate, preamble length and PRF.

It is possible to abort reception if a valid preamble is not detected within a configured time. This is done by using

DW1000 User Manual

Version 2.12

Page 33 of 242

the preamble detection timeout, programmable in Sub-Register 0x27:24 – DRX_PRETOC. This may be useful after sending a message where a response is being awaited. Here if the preamble is not detected then the awaited response is not coming. The preamble detection time-out can be used to abandon the reception at the earliest possible time, saving power.

The preamble detection state also has the possibility of operating in a mode called pulsed preamble detection mode (PPDM), or SNIFF mode, programmable through Register file: 0x1D – SNIFF Mode. This is a technique that where the receiver samples (“sniffs”) the air periodically on a timed basis, e.g. 50% or 25% of the time, to reduce the power needed during preamble detection.

4.1.2 Preamble Accumulation

Once the preamble sequence is detected, the receiver begins accumulating correlated preamble symbols, while looking for the SFD sequence (a particular sequence of preamble symbols, see section 10.3 –

Synchronisation header modulation scheme for details). Accumulation stops when the SFD is detected, but

may stop earlier if the accumulator grows quickly, (as is the case in close line-of-sight conditions for instance), in this case the receiver continues receiving preamble, without accumulating, searching for the SFD sequence.

4.1.3 SFD Detection

The detection of SFD is a key event in the reception of a frame, because it marks the start of the PHY header, which defines the RMARKER that is time-stamped (see section 4.1.6 – RX Message timestamp), and it marks the change from preamble demodulation to the BPM/BPSK demodulation of the PHR (and data subsequently).

It is possible to abort reception if the SFD is not detected within a certain time after preamble is detected. This functionality is configured via Sub-Register 0x27:20 – DRX_SFDTOC. This SFD detection timeout guards against false detection of preamble (which has a finite chance of happening) that could otherwise lead to a prolonged period receiving nothing. By default the SFD detection timeout is 4161 symbol times, (i.e. greater than the largest possible preamble), but it can be set lower if it is known that all nodes in the network are using shorter preambles. It is possible to disable the SFD detection timeout but this is not advised.

The SFD sequence is 64 symbols long for 110 kbps data rate and 8 symbols long for the other two supported data rates of 850 kbps and 6.8 Mbps. The receiver needs to be configured to look for either the short 8symbol SFD or the long 64-symbol SFD. This is done via the RXM110K configuration bit in Register file: 0x04

– System Configuration.

The DW1000 also has the capability of programming non-standard SFD sequences that give improved performance, see Register file: 0x21 – User defined SFD sequence.

4.1.4 PHR Demodulation

The main role of the PHY Header (PHR) is to convey the length of the data portion of the frame, and to indicate the data rate being employed for data demodulation. See section 10.4 – PHY header for details of the PHY header. For data rates of 850 kbps and 6.8 Mbps the PHR is modulated / demodulated as per the

DW1000 User Manual

Version 2.12

Page 34 of 242

850 kbps data rate (note that because Reed Solomon encoding is not applied to the PHR, its bit rate is approximately 1 Mbps). If the PHR is indicating 850 kbps then the data demodulation continues at this rate, but if the PHR is indicating 6.8 Mbps then the demodulation changes to this rate at the end of the PHR as data demodulation begins.

4.1.5 Data Demodulation

Section 10.2 – Data modulation scheme describes the modulation scheme. In the receiver a Viterbi decoder is used recover the data bits (this is also used for PHR reception) which are then passed through the Reed Solomon decoder to apply any further correction it can. Every octet thus received is passed through a CRC checker which checks the frame against the transmitted FCS.

As the data octets are received they may also be parsed by the frame filtering function if enabled, see section 5.2– Frame filtering for more details.

Successful reception of a frame is signalled to the host via the RXDFR and RXFCG event status bits in Register

file: 0x0F – System Event Status Register. Other status bits in this register may be used to flag reception of

other parts of the frame or, events indicating failure, i.e. RXPTO (Preamble detection Timeout), RXSFDTO (SFD timeout), RXPHE (PHY Header Error), RXRFSL (Reed Solomon error), RXRFTO (Frame wait timeout), etc.

Other related features are: -

 Delayed reception – see section 4.2 – Delayed Receive.  Long receive frames – see section 3.4–Extended Length Data Frames.  Double buffering – see section 4.3 – Double Receive Buffer.  Receive message time-stamping – see section 4.1.6 – RX Message timestamp.

4.1.6 RX Message timestamp

During frame reception the SFD detection event marking the end of the preamble and the start of the PHR is the nominal point which is time-stamped by the IC. The IEEE 802.15.4 UWB standard nominates the time when this RMARKER arrives at the antenna as the significant event that is time-stamped.

The DW1000 digital receiver circuitry takes a coarse timestamp of the symbol in which the RMARKER event occurs and adds a various correction factors to give a resultant adjusted time stamp value, which is the time at which the RMARKER arrived at the antenna. This includes subtracting the receive antenna delay as configured in Sub-Register 0x2E:1804 – LDE_RXANTD and adding the correction factor determined by the first path (leading edge) detection algorithm embedded in the DW1000. The resulting fully adjusted RX timestamp is written into Register file: 0x15 – Receive Time Stamp.

See also section 8.3 – IC Calibration – Antenna Delay.

Note: Due to an issue in the re-initialisation of the receiver, it is necessary to apply a receiver reset after certain receiver error or timeout events (i.e. RXPHE (PHY Header Error), RXRFSL (Reed Solomon error), RXRFTO (Frame wait timeout), etc.). This ensures that the next good frame will have correctly calculated timestamp. It is not necessary to do this in the cases of RXPTO (Preamble detection Timeout) and

DW1000 User Manual

Version 2.12

Page 35 of 242

RXSFDTO (SFD timeout). For details on how to apply a receiver-only reset see SOFTRESET field of Sub-

4.2 Delayed Receive

In Delayed receive operation the receiver turn-on time is programmed into Register file: 0x0A – Delayed

Send or Receive Time and then the delayed receiving is initiated by setting both RXDLYE and RXENAB controls

in Register file: 0x0D – System Control Register.

The DW1000 remains in idle state until the system time (Register file: 0x06 – System Time Counter) reaches the value programmed in Register file: 0x0A – Delayed Send or Receive Time and then the IC receiver is turned on. This point marks the start time for any programmed timeouts that apply to the reception process, i.e. the preamble detection timeout (which is set and enabled by Sub-Register 0x27:24 –

DRX_PRETOC) and the frame wait timeout (which is enabled by the RXWTOE configuration bit in Register file: 0x04 – System Configuration, and whose period is programmed in Register file: 0x0C – Receive Frame Wait Timeout Period).

The benefit of delayed receive is that the receiver can be turned on at just the right moment to receive an expected response, especially when that response is coming from a DW1000 employing delayed transmit to send the response message at a precise time. This saves power because the idle mode power counting down to the RX enable time is significantly less than the power required during frame reception.

One use of delayed receive, and especially delayed transmission, is in symmetric double-sided two-way ranging, (described in APPENDIX 3: Two-Way Ranging), where it is important to keep the response times the same at both ends to reduce the error in range estimate. Minimising the response time also reduces this error, and here it is possible for the host microprocessor to be late invoking the delayed TX or RX, so that the system clock is beyond the specified start time and then the IC has to complete almost a whole clock count period before the specified start time is reached. The HPDWARN event status flag in Register file: 0x0F –

System Event Status Register warns of this “lateness” condition so that during development a delay may be

chosen large enough to generally avoid this lateness. The HPDWARN status flag also serves to facilitate detection of this late invocation condition so that recovery measures may be taken should it ever occur in deployed product.

4.3 Double Receive Buffer

This DW1000 has a pair of receive buffers offering the capability to receive into one of the pair while the host system is reading previously received data from the other buffer of the pair. This is useful in a TDOA RTLS anchor node where it is desired to have the receiver on as much as possible to avoid missing any tag blink messages. A number of ancillary registers (timestamps, quality indicators and status bits) are also doubly-buffered. The registers that are part of this “RX double-buffered swinging-set” are listed in Table 7.

Note: If overruns occur (see section 4.3.5), received frame data will be corrupted. Double buffering must not be used in systems where overruns may be likely or frequent and is best used in systems where host processing of the received frames is such that overruns will never occur.

DW1000 User Manual

Version 2.12

Page 36 of 242

Table 7: Registers in the RX double-buffered swinging-set

RX double-buffered registers

LDEDONE, RXDFR, RXFCE and RXFCG bits in Register file: 0x0F – System Event Status Register

All of Register file: 0x10 – RX Frame Information Register

All of Register file: 0x11 – RX Frame Buffer

All of Register file: 0x12 – Rx Frame Quality Information

All of Register file: 0x13 – Receiver Time Tracking Interval

All of Register file: 0x14 – Receiver Time Tracking Offset

All of Register file: 0x15 – Receive Time Stamp

4.3.1 Enabling double-buffered operation

By default the DW1000 operates in a single buffered mode that is appropriate for many applications. When using double-buffered mode it is appropriate to also configure the DW1000 to automatically re-enable the receiver (moving on to the other buffer of the swinging set) as soon as it has completed receiving any previous frame. Double-buffered receiving is enabled by setting the DIS_DRXB bit to zero, (in Register file:

0x04 – System Configuration). The RX auto-re-enable function is enabled by setting the RXAUTR bit to 1 (in Register file: 0x04 – System Configuration).

DW1000 may be operated in double buffered mode without automatically re-enabling the receiver also, which requires the host to manually enable the receiver to receive the next frame. The receiver can be enabled in advance of processing the previously received frame. This operation will reduce the amount of time for which the receiver may be actively listening for frames on the air, but will prevent both buffers being full (at the same time) and will prevent overflows. This simplifies the buffer operation, see sections

4.3.3 and 4.3.5.

Note: When enabling or re-enabling the receiver in double-buffered mode, it is important to align both host and IC receivers. That is, it is important to ensure that the buffer set that the IC receiver will first receive into is the same set that the host system is pointing to and will first process when the first frame arrives. Please refer to section 4.3.2 below for a discussion of this and how to achieve it.

4.3.2 Controlling which buffer is being accessed

There are two register sets, register-set-0 and register-set-1, but the host may only access one set at a time through the register addresses listed in Table 7. To swap between sets the host issues the HRBPT (Host Side Receive Buffer Pointer Toggle) command in Register file: 0x0D – System Control Register. The register-set currently being accessed is reported by the HSRBP (Host Side Receive Buffer Pointer) status bit in Register

file: 0x0F – System Event Status Register. Every time the HRBPT command is issued the HSRBP status bit will

toggle.

There is also a read-only IC side buffer pointer index indicating which register-set the IC receiver is using or will use for the next frame received, this is the ICRBP status bit (also in Register file: 0x0F – System Event

DW1000 User Manual

Version 2.12

Page 37 of 242

Status Register). Reception of a new frame with good CRC will cause the ICRBP bit to increment (or toggle).

In the case that a received frame is rejected by frame filtering or bad CRC the ICRBP will not move on and the buffer will be reused for the next incoming frame.

Thus, as noted in section 4.3.1 above, before enabling the receiver it is important to align both host and IC receivers. This is done by reading the SYS_STATUS register 0x0F to checking that the HSRBP and ICRBP status bits are the same, (i.e. both 1 or both 0), and if not issuing the HRBPT command to toggle HSRBP to be the same as ICRBP.

4.3.3 Operation of double buffering

In normal operation the IC will receive a frame into the RX buffer (pointed to by ICRBP) and when the frame is complete the IC will set the RXFCG interrupting the host and move on to receive into the other buffer of the double-buffered swinging-set. Following this the host system should see this interrupt and service it by reading the received data from the buffer along with any of the other ancillary registers it wants, and then issue the HRBPT command to move to point to the other buffer. This HRBPT command also serves as the mechanism to tell the IC that the host has finished with processing this received buffer (and is moving on to the next one) essentially allowing the IC to reuse it for follow on frames. Figure 14 below is a flow chart showing the use of double buffering in the receiver.

DW1000 User Manual

Version 2.12

Page 38 of 242

Set up RX channel and other

parameters as required

Read SYS_STATUS reg:0F to

checking that HSRBP == ICRBP

HSRBP == ICRBP ?

Issue the HRBPT command in

reg:0x0D

Set RXENAB bit = 1, in reg:0D,

to enable the receiver

Set DIS_DRXB bit = 0 in reg:04

to Enable double buffering

YES

Await frame arrival, as signalled

by the RXFCG event flag (IRQ)

Read the data in RX_BUFFER

reg:11.

Read other registers of interest

e.g. RX_FINFO reg:10, RX

timestamp in reg:15 and perhaps

frame quality reg:12.

RXOVRR==1

Issue the HRBPT to reg:0D to

signal finished with this buffer

and moving on to other of pair.

YES

Set RXAUTR bit = 1 in reg:04

to enable RX auto-re-enable

Clear RX event flags in

SYS_STATUS reg:0F; bits FCE,

FCG, DFR, LDE_DONE

Frames must be discarded (do

not read frames) due to

corrupted registers and TRXOFF

command issued.

Receiver must be reset to exit

errored state.

Unmask Double buffered status

bits; FCE, FCG, DFR, LDE_DONE

Mask Double buffered status

bits; FCE, FCG, DFR, LDE_DONE

to prevent glitch when cleared

Rx more frames?

YES

HSRBP == ICRBP ?

YES

Issue TRXOFF command and

clear double buffered status bits

to prevent spurious RX interrupts

YES

Rx more frames?

EXIT

In Figure 14 the section marked by the dashed black line can be omitted if the host system is able to service the buffers with sufficient speed so that both buffers are never full at the same time. If this can be guaranteed then an overrun (RXOVRR) can never occur and so cannot corrupt good frames, see section

4.3.5. In this case, buffer handling is simplified.

4.3.4 TRXOFF when using Double Buffering

To prevent spurious interrupts and for predictable behavior, TXRXOFF should be applied as shown below. The double-buffered status bits should be cleared after the TRXOFF is applied and the interrupts on doublebuffered status bits should be masked while the bits are cleared.

Figure 14: Flow chart for using double RX buffering

DW1000 User Manual

Version 2.12

Page 39 of 242

Clear RX event flags in

SYS_STATUS reg:0F; bits FCE,

FCG, DFR, LDE_DONE

Set TXRXOFF bit = 1, in reg:0D,

to disable the receiver

Mask Double buffered status bits; FCE, FCG, DFR, LDE_DONE to prevent glitch when cleared

Unmask Double buffered status

bits; FCE, FCG, DFR, LDE_DONE

Figure 15 : TRXOFF in Double-Buffered Mode

4.3.5 Overrun

An overrun condition may occur in the IC receiver if the host side is not keeping up with the arrival rate of frames. So for example, say the IC receives a frame into the first buffer, moves on to the other buffer and places a receive frame in it also. The IC will then move back to point to the first buffer again. If the host has not completed reading the data from this first buffer (i.e. not yet issued the HRBPT) then the IC will not overwrite that buffer with any new frame if one arrives. If a new frame arrives and the IC is unable to write data to the buffer (because the host has not issued the HRBPT), then this is gives rise to an overrun condition. The overrun condition occurs at the point the receiver finishes processing a good PHY header and needs to write the first octet of data to the RX buffer. This event is detected by the IC and reported in the RXOVRR status bit in Register file: 0x0F – System Event Status Register.

When a receiver overrun occurs, the frame reception in progress will be aborted and, assuming RX auto-reenable is enabled (by RXAUTR) the receiver will begin looking for preamble again. The overrun condition and the RXOVRR status bit will be cleared as soon as the host issues the HRBPT command. Receiver overrun events are also counted in Sub-Register 0x2F:0E – RX Overrun Error Counter, assuming that counting is enabled by the EVC_EN bit in Sub-Register 0x2F:00 – Event Counter Control.

The overrun condition results in the corruption of the good frames previously received. The RX_FINFO, RX_TIME and RX_FQUAL registers are affected. Received frames must be discarded due to corruption if an overrun (RXOVRR) occurs. A receiver-only reset must be applied to the receiving device to clear the errored state which may persist, see Figure 14. See the SOFTRESET field of Sub-Register 0x36:00 –

PMSC_CTRL0 for details of how to apply the receiver-only reset.

The impact of overrun corruption of previously received frames needs to be evaluated carefully in the intended application. For instance, if overruns can occur the system should not use automatic acknowledgements (see AUTOACK in SYS_CFG), as a corrupt frame will be acknowledged but then discarded.

4.4 Low-Power Listening

Low-power listening is a feature whereby the DW1000 is predominantly in the SLEEP state but wakes periodically for a very short time to sample the air for a preamble sequence. If no preamble is seen the DW1000 automatically returns to SLEEP for another period, however if preamble is seen the DW1000 does

DW1000 User Manual

Version 2.12

Page 40 of 242

not return to sleep but continues to receive preamble and the data frame, and after successful reception can

Preamble SFD PHR DATA

IFS

Preamble SFD PHR DATA

IFS

Preamble SFD

Long Sleep (e.g. 1s) Long Sleep (e.g. 1s) Long Sleep (e.g. 1s)

Long Sleep (e.g. 1s) Short Sleep (e.g. 1.3ms)

Wake-up sequence 1s long

Preamble sample

RX Frame

Detect preamble & Receive the frame

1st Listen

2nd Listen

generate a receive frame interrupt to wake the host microprocessor to process the frame.

A typical example of this would be to use a sleep time of 1 second and a wake-up period of 2 PAC intervals, where the average current for briefly listening and going back to sleep is very low. To wake up a device operating in this low-power listening receiver mode, a transmitting device has to send sufficient data to ensure that it is heard by the listener. Essentially then the transmitter has to send > 1 second of message to ensure that it intersects with the short listening period of the receiving device. In practice this is done by sending the same message repeatedly. In doing this, there is a finite chance that the listener listens at a time when the transmitted preamble is not present. To avoid this, and give a better performing wakeup, the DW1000 includes the ability to do a two-phase listen. This has a long sleep period followed by a sampling of the air, followed by a short sleep period and then another sampling of the air. The short sleep time period is set to ensure that if the first listen hits a message (missing the preamble) then the next listen will see preamble. Figure 16 below shows the periodic listening for preamble and a wakeup sequence where the first listening period intersects with the PHR or DATA, but where the second listening period allows successful reception.

NOTE: Low-power listening works best for infrequent wake-ups across a population of listening nodes. The reason is that every listening node will see preamble and wake-up and consume power receiving the packet (even if the packet is not addressed to it).

In Figure 16 there is a long period in SLEEP (or DEEPSLEEP) followed by a wakeup to the RX state (on) to sniff for preamble, followed by (assuming no preamble is detected) a short period in SNOOZE state, followed by the second RX state (on) to look for preamble, and (again assuming no preamble is detected) a return to SLEEP (or DEEPSLEEP). Figure 17 shows the power profile associated with Low-Power Listening. If a preamble is detected in either of the two receive windows, then the frame will be demodulated and an interrupt set (if configured to do so).

Figure 16: Low power listening with two sleep times

DW1000 User Manual

Version 2.12

Page 41 of 242

IDLE

INIT

GO2SLP

Sample Wakeup Event:

Sleep counter expires

SLEEP SLEEP

2 RX attempts with no RX detected,

Host RX End.

WAKEUP

CLKPLL locked

Crystal stable,

RSTn=1

Preamble

Timeout in PACs

Snooze Count (Reg:36.0c)

(in 19.2MHz cycles)

SNOOZE

IDLE

PLL Lock

Time (~5uS)

INIT

Figure 17: Power profile for low power listening mode where no frame is received

4.4.1 Configuring low-power listening

Configure the receiver parameters for channel, data rate, PRF, preamble code, etc. as required for normal receive operation. Then enable and configure the Low-Power Listening functionality as follows:

 Set ARXSLP (after RX automatically sleep) bit in Sub-Register 0x36:04 – PMSC_CTRL1.  Set preamble detect timeout (RX ON time) in Sub-Register 0x27:24 – DRX_PRETOC.  Set SNOZ_TIM (snooze time) field of Sub-Register 0x36:0C – PMSC_SNOZT.  Set SNOZE (snooze enable) bit in Sub-Register 0x36:04 – PMSC_CTRL1.  Set SLEEP_TIM (sleep time period) field in Sub-Register 0x2C:06 – AON_CFG0.  Set SLEEP_EN (sleep enable) field in Sub-Register 0x2C:06 – AON_CFG0.  Set WAKE_CNT (wake when sleep counter elapses) field in Sub-Register 0x2C:06 – AON_CFG0.  Set ONW_RX (on wake turn on the receiver) bit in Sub-Register 0x2C:00 – AON_WCFG.  Set ONW_LDC (on wake load configurations) bit in Sub-Register 0x2C:00 – AON_WCFG.  Set PRES_SLEEP (preserve sleep) bit in Sub-Register 0x2C:00 – AON_WCFG.  Set only MRXFCG bit in Register file: 0x0E – System Event Mask Register.  Set the RXENAB bit in Register file: 0x0D – System Control Register.

The DW1000 will then begin the low power listening, and will only generate an interrupt when a frame is received. Frame filtering can be enabled to further restrict the interrupt to only be generated when a correctly addressed frame is received. To save power in such a system the host microprocessor (if sufficiently capable) can enter a low power state awaiting the DW1000 interrupt to wake it when a frame arrives.

When a frame is received, low-power listening must be deactivated by clearing the ARXSLP bit before the RXFCG interrupt is cleared. This is required to ensure that the DW1000 does not go back to sleep as soon as the interrupt is cleared, which would prevent the user from reading the frame data correctly. Once the received frame has been handled, low-power listening mode can be reactivated by setting the ARXSLP bit once more and putting the DW1000 back into reception or sleep mode.

4.5 Low-Power SNIFF mode

Low-Power SNIFF mode is a lower power preamble hunt mode, also known as pulsed preamble detection mode (PPDM), where the receiver (RF and digital) is sequenced on and off rather than being on all the time. These on and off times are configurable in Register file: 0x1D – SNIFF Mode, and have default values of zero,

DW1000 User Manual

Version 2.12

Page 42 of 242

disabling the feature. Using SNIFF mode causes a reduction in sensitivity depending on the ratio and

Setup RX mode of operation as per normal RX

Configure Sniff Mode On duration in multiples of PACs

(as set in RX mode of operation)

REG:1D[3:0] = SNIFF_ON

Configure Sniff Mode Off duration in uS. After this time we start to turn on the RX blocks. Allow 5uS for the RX

RF block to be stable.

REG:1D[15:8] = SNIFF_OFF

PAC count =

Sniff on time?

Time count (µs)

= Sniff Off Time?

IDLE

(Sniff Off)

This loop will continue

until preamble

detection or an RX

end event occurs

(Sniff On)

Set RX_EN

IDLE

durations of the on and off periods.

There are two variations of low power SNIFF mode; these are termed SNIFF and Low duty-cycle SNIFF described in the sub-sections below. The difference between the two modes is that in SNIFF mode the DW1000 alternates between the RX state (on) and the IDLE (off) state, while in Low duty-cycle SNIFF mode the IC spends the off time in the INIT state, transitioning only briefly through the IDLE state when entering the RX state. The choice of mode has implications for calculating the Sniff Off time, which is described below. The Low duty-cycle SNIFF mode will consume less power than SNIFF mode during the off period, but both consume the same power during the on period. Figure 18 shows a simplified view of the state transitions during SNIFF mode.

4.5.1 SNIFF mode

In SNIFF mode the DW1000 alternates between the RX (on) and the IDLE (off) states. To enable SNIFF mode two parameters SNIFF_ONT (sniff on time) and SNIFF_OFFT (the off time) need to be configured in Register

file: 0x1D – SNIFF Mode. The on duration is programmed in units of PAC, (these are described in section

4.1.1 – Preamble Detection), and must be set to at a minimum value of 2 for functional preamble detection.

The SNIFF_ONT counter automatically adds 1 PAC unit to the total PAC count so the programmed value

Figure 18: State transitions during SNIFF mode

DW1000 User Manual

Version 2.12

Page 43 of 242

should always be 1 less than the desired total. The off duration is programmed in units of 1 µs. When both

IDLE

INIT

GO2SLP

Sample Wakeup Event:

Sleep counter expires

SLEEP SLEEP

Frame Wait Timeout,

Host RX End.

WAKEUP

CLKPLL locked

Crystal stable,

RSTn=1

RX RX

IDLE IDLE IDLE

Configure RX Sniff Mode

Sniff On Time

(in PACs)

Sniff Off Time

(in uS)

IDLE

INIT

Sample Wakeup Event:

Sleep counter expires

SLEEP

Interrupt Set RX OK

WAKEUP

CLKPLL locked

Crystal stable,

RSTn=1

(demod)

IDLE

Configure RX Sniff Mode

Sniff On Time

(in PACs)

Sniff Off Time

(in uS)

Preamble Detected

Host Activity Read RX buffer

on and off durations are programmed with non-zero values SNIFF will be operational from the next RX enable.

As an example if the PAC size is 8 symbols, (this is approximately 8 µs), and we want to have a 50:50 on-off duty cycle, then we could set SNIFF_ONT to its minimum of 2 PAC intervals (by programming the counter with a value of 1) and the SNIFF_OFFT to a value of 16 µs.

Figure 19 shows the power profile associated with SNIFF mode where the IC wakes up from SLEEP and progress into the repeated IDLE-RX-IDLE-RX… duty-cycle of the pulsed preamble detection mode. A timeout ends this and the DW1000 is returned to SLEEP.

Figure 19: Power profile for SNIFF where a frame is not received

Figure 20 shows a power profile for SNIFF mode, similar to Figure 19, except in this case preamble is detected on the second period of RX sampling, and the DW1000 completes the reception of a frame.

Figure 20: Power profile for SNIFF where a frame is received

4.5.2 Low duty-cycle SNIFF mode

In Low duty-cycle SNIFF mode, where the off time is larger, the DW1000 can be configured to spend this off time in the INIT state which is lower power than the IDLE state (used for the off period of a SNIFF). This is enabled by setting the ARX2INIT bit in Sub-Register 0x36:04 – PMSC_CTRL1, in addition to configuring the on and off times, SNIFF_ONT and SNIFF_OFFT, in Register file: 0x1D – SNIFF Mode. This instructs the receiver to go to the INIT state for the off period of the Low-Power SNIFF mode.

DW1000 User Manual

Version 2.12

Page 44 of 242

NOTE: In the INIT state the 125 MHz digital PLL clock is not running, instead the system is clocked at the raw

IDLE

INIT

GO2SLP

Sample Wakeup Event:

Sleep counter expires

SLEEP SLEEP

Frame Wait Timeout,

Host RX End.

WAKEUP

CLKPLL locked

Crystal stable,

RSTn=1

Configure RX Sniff Mode

Sniff On Time

(in PACs)

Sniff Off Time

(in 19.2MHz cycles)

INIT

IDLE

INIT

IDLE

PLL Lock

Time (~5uS)

INIT

IDLE

19.2 MHz XTI clock rate. Thus, in Low duty-cycle SNIFF mode the off period configured in the SNIFF_OFFT is in multiples of 6.6 µs (instead of the 1 µs units that apply in the SNIFF mode).

The power saving of Low duty-cycle SNIFF mode is only realised when the off period is greater than 1 (i.e. >

6.6 µs). This is because after the timer expiry the DW1000 will enter the IDLE state as the PLL is turned on and locks (this takes approximately 5 µs) before progressing into the RX state.

Figure 21 shows the power profile associated with Low duty-cycle SNIFF mode where the IC wakes up from SLEEP and progress into the repeated INIT-(IDLE)-RX-INIT-(IDLE)-RX cycles of the pulsed preamble detection mode. A timeout ends this and the DW1000 is returned to SLEEP.

Figure 21: Power profile for Low duty-cycle SNIFF where a frame is not received

4.6 Diagnostics

The DW1000 includes the following diagnostic aids: -

 The ability to drive LEDs to show TX and RX activity, which may be useful during product

development and in non-battery powered devices. The LED driving feature is an option on GPIO lines, and is configurable via Sub-Register 0x26:00 – GPIO_MODE. Please refer to the register description for details of the supported functionality.

 Access to accumulator – of use during product development diagnostics. This is provided via Register

file: 0x25 – Accumulator CIR memory. Please refer to its description for details.

 RX frame quality indications – of use for both product development diagnostics and for working

diagnostics, e.g. for network management or for deciding on confidence level for an RTLS or ranging measurement. These are available through Register file: 0x12 – Rx Frame Quality Information. Please refer to its description for details, and to section 4.7 – Assessing the quality of reception and

the RX timestamp

4.7 Assessing the quality of reception and the RX timestamp

The DW1000 receiver is capable of receiving messages under many different conditions. In some circumstances it can be useful to assess the quality of the received signals and any timestamp data based on them.

DW1000 User Manual

Version 2.12

Page 45 of 242

In a network it may be useful to assess the quality of message reception from a particular node in order to change network routing or configurations related to that node to improve the reliability of the communications. For example to improve communications reliability the frame length might be shortened, or the data rate might be reduced, or the preamble length might be increased. In other situations with consistently good communications the preamble length might be shortened to reduce the transmission time, saving power and leaving more air-time free for other nodes to communicate.

In a TDOA RTLS system where a particular tag’s transmission is received at multiple anchors the quality of

reception and more particularly the quality of the RX timestamp information might be used to select which anchors’ RX message timestamps to feed into the location engine.

The following details the elements of receive status reported by the DW1000 that may be used to assess the quality of a received message and any related timestamp.

 The Standard Deviation of Channel Impulse Response Estimate (CIRE) Noise value, reported in the

STD_NOISE field of Register file: 0x12 – Rx Frame Quality Information may be used to give a measure of the noise associated with this and the received frame’s timestamp measurement. The STD_NOISE can be used as an absolute value or it may be compared with the First Path Amplitude value – in this latter case it is recommended that the amplitude value used for comparison is the value reported in FP_AMPL2 field of Register file: 0x12 – Rx Frame Quality Information.

With a higher absolute CIRE noise figure it is more likely that the quality of receive timestamp will be poorer. High noise may mean that the real first path is irretrievably buried in the noise. Comparing the noise with the First Path Amplitude can give additional indication as to the quality of the first path measurement. Where the First Path Amplitude has a large headroom over the noise, then the

received frame’s timestamp is likely to have been determined more precisely than when the First Path Amplitude is closer to the noise level.

 It is possible to compute an estimated receive power figure (using the equation and details given in

section 4.7.2 – Estimating the receive signal power) – for the purposes of this discussion this will be called RX_POWER. It is also possible to compute an estimated power for just the first path signal (using the equation and details given in section 4.7.1 – Estimating the signal power in the first path) – for the purposes of this discussion this will be called FP_POWER. Using these two calculations it may be possible to say whether the channel is line-of-sight (LOS) or non-line-of-sight signal (NLOS). As a rule of thumb, if the difference between RX_POWER and FP_POWER, i.e. RX_POWER – FP_POWER, is less than 6dB the channel is likely to be LOS, whilst if the difference is greater than 10dB the channel is likely to be NLOS.

Where the RX timestamp relates to a frame that is received in the presence of a higher CIRE noise power, or relates to a non-line-of-sight path with attenuated first path, then that receive timestamp is naturally likely to be of lower quality than that determined from a crisp line of sight first path signal that is well above the noise floor.

Where a location system has an excess number receive timestamps to choose from then a quality estimate relating to each timestamp may be used to weight the timestamps or to choose the highest quality set to feed into the multilateration function of the location engine.

DW1000 User Manual

Version 2.12

Page 46 of 242

4.7.1 Estimating the signal power in the first path

An estimate of the power in the first path signal may be calculated (in dBm) using the formula:



 









󰇧















󰇨

Where:

F1 = the First Path Amplitude (point 1) magnitude value reported in the FP_AMPL1 field of Register

file: 0x15 – Receive Time Stamp,

F2 = the First Path Amplitude (point 2) magnitude value reported in the FP_AMPL2 field of Register

file: 0x12 – Rx Frame Quality Information,

F3 = the First Path Amplitude (point 3) magnitude value reported in the FP_AMPL3 field of Register

file: 0x12 – Rx Frame Quality Information,

A= is the constant 113.77 for a PRF of 16 MHz, or, the constant 121.74 for a PRF of 64 MHz, and N = the Preamble Accumulation Count value reported in the RXPACC field of Register file: 0x10 –

RX Frame Information Register. Note that RXPACC may need to be adjusted to remove SFD

symbol count before use, see the register field description in Register file: 0x10 – RX Frame

Information Register.

The resultant First Path Power Level (in dBm) may be compared with the estimated receive power figure calculated as per section 4.7.2 – Estimating the receive signal power.

4.7.2 Estimating the receive signal power

It is possible to calculate an estimate of the receive power level (in dBm) using the formula:



 





󰇧







󰇨

Where:

C = the Channel Impulse Response Power value reported in the CIR_PWR field of Register file:

0x12 – Rx Frame Quality Information,

A= is the constant 113.77 for a PRF of 16 MHz, or, the constant 121.74 for a PRF of 64 MHz, and N = the Preamble Accumulation Count value reported in the RXPACC field of Register file: 0x10 –

RX Frame Information Register. Note that RXPACC may need to be adjusted to remove SFD

symbol count before use, see the register field description in Register file: 0x10 – RX Frame

Information Register.

This resultant receive power estimate is very close to the actual receive power at lower receive levels, but is lower than the actual receive power level at higher levels. Figure 22 below shows the relationship between the actual receive power and the power estimated by this technique.

DW1000 User Manual

Version 2.12

Page 47 of 242

-105

-100

-95

-90

-85

-80

-75

-70

-65

-105 -100 -95 -90 -85 -80 -75 -70 -65

Estimated

RX LEVEL

(dBm)

Actual RX LEVEL (dBm)

Estimated RX LEVEL (16MHz PRF Free Space)

Estimated RX LEVEL (64MHz PRF Free Space)

Estimated RX LEVEL (64MHz PRF Multipath)

Actual RX LEVEL

Figure 22: Estimated RX level versus actual RX level

DW1000 User Manual

Version 2.12

Page 48 of 242

5 Media Access Control (MAC) hardware features

This section describes the features for media access control (MAC) that have been implemented in the DW1000.

5.1 Cyclic redundancy check

The DW1000 includes a CRC generation function capable of automatically calculating and appending the 16bit CRC frame check sequence (FCS) at the end of each transmitted frame.

The DW1000 also includes a CRC checking function capable of automatically calculating the 16-bit CRC frame check sequence (FCS) during frame reception and comparing this calculated CRC with the final two octets of the received frame to check that the calculated CRC matches with CRC transmitted by the frame’s originator. A mismatch between received and calculated CRC typically indicates that the received frame contains errors (generally handled by discarding the received frame). At the end of the frame reception as reported via the RXDFR event status bit, the result of the CRC comparison is reported by either the RXFCG or the RXFCE status bit being set, i.e. depending on whether or not the CRCs matched. These three status bits are in Register file:

0x0F – System Event Status Register.

Where a CRC is not required it is possible to suppress the CRC transmission by employing the SFCST (suppress FCS transmission) bit in Register file: 0x0D – System Control Register. This might be done when using a different MAC layer protocol. This SFCST control is also employed during a throughput maximising (response-time minimising) technique, as described in section 3.5.2 – TX buffer write while sending.

5.2 Frame filtering

Frame filtering is a feature of the DW1000 IC that can parse the received data of a frame that complies with the MAC encoding defined in the IEEE 802.15.4–2011 standard, identifying the frame type and its destination address fields, match these against the IC’s own address information, and only accept frames that pass the filtering rules. See section 11 – APPENDIX 2: The IEEE 802.15.4 MAC layer for an introduction to the message format defined in the standard.

The frame filtering functionality allows the IC to be placed into receive mode and only interrupt the host processor when a frame arrives that passes the frame filtering criteria. When frame filtering is disabled all frames with good CRC are accepted, typically to interrupt the host with event status indicating a frame has been received with good CRC (i.e. the RXDFR and RXFCG event status bits are set in Register file: 0x0F –

System Event Status Register). When frame filtering is enabled the frame filtering rules have to be passed

before these event status (interrupt) bits are set. See section 4.1 - Basic Reception for general details of reception.

Frame filtering is enabled by the FFEN configuration bit in Register file: 0x04 – System Configuration. This register contains seven additional configuration bits (FFAB, FFAD, FFAA, FFAM, FFAR, FFA4 and FFA5) for fine filtering control of the frame types.

5.2.1 Frame Filtering Rules

If frame filtering is enabled frames will be accepted or rejected based on the following rules:

DW1000 User Manual

Version 2.12

Page 49 of 242

 The frame type must be allowed for reception:

o The FFAB configuration bit must be set to allow a Beacon frame to be received. o The FFAD configuration bit must be set to allow a Data frame to be received. o The FFAA configuration bit must be set to allow an Acknowledgment frame to be received. o The FFAM configuration bit must be set to allow a MAC command frame to be received. o The FFAR configuration bit allows IEEE 802.15.4 reserved types, 4 to 7 to be received,

excluding those rejected due to the frame length check described below.

o The FFA4 configuration bit allows IEEE 802.15.4 reserved type 4 frames to be received,

excluding those rejected due to the frame length check described below.

o The FFA5 configuration bit allows IEEE 802.15.4 reserved type 5 frames to be received,

excluding those rejected due to the frame length check described below.

NB: For reserved frame types 4 to 7, if they are allowed here that is the end of the frame filtering.

The remaining rules below only apply for standard frame types 0 to 3. However, the frame header will be interpreted as for frame types 0-3 to determine the size of the received frame and reject it if it is shorter than expected. This can make the use of frame types 4, 5, 6 and 7 problematic and frame filtering may need to be carried out in software if use of frames of type 4, 5, 6, or 7 with different encodings for frame control bits affecting the header length is planned. The frame control bits concerned are the address mode fields and the PID compression field.

 The frame version field must be 0x00 or 0x01

 The Destination PAN ID if present must:

o Be the broadcast PAN ID (0xFFFF) o Or match the PAN_ID programmed in Register file: 0x03 – PAN Identifier and Short Address

 The Destination Address if present must:

o Be the (short 16-bit) broadcast address (0xFFFF) o Or be a short (16-bit) address matching the SHORT_ADDR programmed in Register file: 0x03

– PAN Identifier and Short Address

o Or be a long (64-bit) address matching the Register file: 0x01 – Extended Unique Identifier.

 If the frame is a beacon frame then the Source PAN ID must match the PAN_ID programmed in

If only the source address is present, in a data or MAC command frame, then the frame will only be accepted if the IC is configured to be a coordinator, (via the FFBC configuration bit in Register file:

0x04 – System Configuration) and the Source PAN ID matches the PAN_ID programmed in Register file: 0x03 – PAN Identifier and Short Address.

 The FCS (CRC) must be correct for the frame to be accepted.

DW1000 User Manual

Version 2.12

Page 50 of 242

5.2.2 Frame Filtering Notes

The frame filtering does not take any notice of the Security Enabled field, in the frame control, so it is up to the host software to decode any security information and accept/reject the frame is it sees fit. See section

11.2.2 – Security enabled Field for details.

The decisions on frame rejection/acceptance with respect to illegal frame control octets is made after the first two octets of data are decoded, and at the end of reception of the address fields (as specified by the frame control octets) for the relevant addressing rules. When a frame is rejected, the reception is aborted immediately and the rejection is reported by the AFFREJ event bit in Register file: 0x0F – System Event Status

While frame filtering can save some work on the part of the host system, prolonged listening with the DW1000 receiver on is a relatively power hungry activity best employed only on equipment with a mains powered source.

All the configuration bits related to frame filtering are in Register file: 0x04 – System Configuration.

5.3 Automatic Acknowledgement

The automatic acknowledgement functionality of the DW1000 allows the IC to automatically send acknowledgement frames when a frame is received and validated that includes an acknowledgement request. The automatic acknowledgement functionality only operates when frame filtering is enabled and automatic acknowledgement is enabled.

In order for automatic acknowledgement to operate:

• Frame filtering must be enabled and the received data or MAC command frame must be

correctly addressed and pass through the receive frame filtering, (see section 5.2 - Frame

filteringfor details of frame filtering configuration).

• The ACK request bit in the frame control field of the received frame must be set.

• Auto-acknowledgement must be enabled by the AUTOACK configuration in Register file: 0x04 –

System Configuration.

When these conditions are met the DW1000 will at the end of the reception automatically transition into transmit mode to send the 5-octet MAC acknowledgement frame as defined by IEEE 802.15.4-2011.

If automatic acknowledgement and double buffering are intended to be used together, the system must be designed such that overruns cannot occur, or if they can occur, that the system can deal with acknowledgement of frames which subsequently become corrupted, see section 4.3.5.

5.3.1 Preamble length & SFD in Automatic Acknowledge Frame

5.3.1.1 Preamble length

The preamble length of the frame requesting acknowledgement (ACK) is encoded in the PHR of that frame, (see section 10.4 – PHY header), and decoded in the DW1000 receiver (and reported in the RXPSR field of

802.14.4 standard, but the DW1000 supports other preamble lengths. To cope with this the DW1000 selects

DW1000 User Manual

Version 2.12

Page 51 of 242

preamble length as reported in the RXPSR field but also uses the Preamble Accumulation Count value

PSR carried in PHR &

reported in RXPSR

PSR accumulated and

reported in the RXPACC value

Resultant Preamble

Length of auto ACK

Less than 65

Between 65 and 128

128

Between 129 and 256

256

Greater than 256

512

1024

Less than 1025

1024

Between 1025 and 1536

1536

Greater than 1536

2048

4096

Any value

4096

PSR accumulated and

reported in the RXPACC value

Resultant Preamble

Length of auto ACK

Less than 17

16 *

Between 17 and 32

32 *

Between 33 and 64

Between 65 and 128

128

Between 129 and 256

256

Between 257 and 512

512

Between 513 and 1024

1024

Between 1025 and 1536

1536

Between 1537 and 2048

2048

Greater than 2048

4096

reported in the RXPACC field of Register file: 0x10 – RX Frame Information Register. Table 8 presents the resulting preamble length used for the ACK frame as a function of RXPSR and RXPACC fields.

Table 8: Auto-ACK preamble length depending on RXPSR and RXPACC

Table 8 relates to standard frames. In extended length frame mode, (as described in section 3.4 - Extended

Length Data Frames), just the Preamble Accumulation Count value (reported in the RXPACC field of Register file: 0x10 – RX Frame Information Register) is used to determine the preamble length of the ACK. Table 9

presents the preamble lengths used for the ACK frame in extended length frame mode as a function of the RXPACC field.

Table 9: Auto-ACK preamble length selection in extended length frames mode

NOTE *: These (asterisked) short preamble lengths will not be received by the DW1000. Use cases where this is likely to occur frequently should be avoided by one of the following strategies: (a) using a longer preamble for retransmission when no ACK is received, (b) not using the extended length frames mode, or, (c) by using the host microprocessor to generate the ACK in place of the DW1000’s auto-ACK feature.

NOTE 1: It is possible for the Preamble Accumulation Count value (reported in the RXPACC field of Register

file: 0x10 – RX Frame Information Register) to be significantly shorter than the transmitted preamble length,

DW1000 User Manual

Version 2.12

Page 52 of 242

because the accumulation stops when any tap value grows to be a 16-bit number. This is typically when the sending device is close to the receiver, but in any case the number reported has been sufficient for correct reception of the frame being acknowledged, so even if this results in a shorter preamble for the auto-ACK frame this preamble should still have ample length for correct reception.

NOTE 2: It is also possible for the Preamble Accumulation Count (reported in RXPACC) to be a little larger than the transmitted preamble length. This can occur with early detection of preamble and because the accumulation count may include accumulation that continues through the SFD (until the SFD is detected). If this occurs it can result in the automatic acknowledgement frame being sent with a longer preamble than the frame soliciting the ACK. In the worst case this will be one size bigger. Allowance for this fact should be made when programming a shorter than default SFD detection timeout in Sub-Register 0x27:20 –

DRX_SFDTOC, e.g. set a time-out consistent with the next greater preamble size. And similarly if setting a

very tight time for the RX frame timeout (in Register file: 0x0C – Receive Frame Wait Timeout Period) allowance should be made for the possible additional duration of the preamble sequence.

5.3.1.2 SFD Initialisation

The SFD sequence to be included in the Auto ACK frame must be initialised prior to the first Auto ACK frame being sent. The SFD sequence is only initialised upon an user TX request which will not have taken place if the Auto ACK frame is the first transmitted frame after start-up or reconfiguration of channel parameters. The most efficient way to ensure the SFD sequence is correctly initialised is to simultaneously initiate and abort a transmission thereby forcing the SFD initialisation. This can be done by writing to the the system control register Register file: 0x0D – System Control Register with both the transmission startbit TXSTRT and the transceiver off bit TRXOFF set at the same time. No signal will actually be transmitted as a result of this operation. This operation should be performed each time the communication parameters are configured or reconfigured as this can change the SFD sequence the DW1000 will use for the next transmission.

5.3.2 Automatic Receiver Re-Enable

Automatic acknowledgement can also operate correctly when the RX auto-re-enable function is enabled (by the RXAUTR bit in Register file: 0x04 – System Configuration), as may be the case in double-buffered mode (see section 4.3 - Double Receive Buffer). Here when frame filtering and automatic acknowledgements are enabled, the DW1000 will automatically transition from receiving into transmit mode to send the acknowledgement frame and when the transmission is complete, the DW1000 will automatically return into receive mode to await the next frame.

5.3.3 Automatic ACK Turnaround Time

The IEEE 802.15.4 standard specifies a 12 symbol +/- 0.5 symbols turnaround time for ACK transmission. In the DW1000 this period is configurable via the ACK_TIM parameter in Register file: 0x1A – Acknowledgement

time and response time.

5.3.4 Frame Pending bit

The standard IEEE 802.15.4-2011 MAC includes a frame pending bit in the frame control at the start of each frame (see section 11.2.3 – Frame pending field). This bit can be set to indicate more data is coming or in the case of the ACK frame to indicate that the responding node has data to send to the node soliciting the ACK.

DW1000 User Manual

Version 2.12

Page 53 of 242

Please refer to the standard [1] for details of this. The DW1000 does not automatically determine the frame pending bit inserted into the automatically-generated ACK frames. Instead it copies the value of the AACKPEND configuration bit (from Register file: 0x04 – System Configuration), which is zero by default.

5.3.5 Host Notification

The AAT status bit (Register file: 0x0F – System Event Status Register) indicates that an acknowledgement has been requested. The AAT bit is set at the same time as the RXFCG event status (indicating a good CRC at the end of frame reception).

If automatic acknowledgement is enabled then the AAT bit can be used during receive interrupt processing to detect that acknowledgement is in progress and so avoid taking any action until the transmission of the acknowledgement is completed, and signalled by the TXFRS (Transmit Frame Sent) event.

Note: If automatic acknowledgement is not enabled, then the AAT status bit must be ignored.

Note: there is a situation that can result in the AAT bit being set for the current frame as a result of a previous frame that was received and rejected due to frame filtering. This is despite the fact that the current frame is not requesting an automatic acknowledgement. In this circumstance an automatic acknowledgment is not actually transmitted, however the fact that the AAT is set could cause the user to wait for a non-existent automatic acknowledgement process to complete.

In this situation, when automatic acknowledgement is enabled and the AAT bit is observed as set, to avoid waiting for the acknowledgement process to complete and TXFRS to be set, the Acknowledgment request field in the frame control section of the MAC header of the received frame as described in Section 11.2.4 should be checked to confirm that the current frame has actually requested an automatic acknowledgement. If the Acknowledgment request field is cleared, then the user should clear the AAT bit in the status register Register file: 0x0F – System Event Status Register (as well as in any copy of the status register that is returned to the user callback when using interrupts).

5.3.6 ACK Frame Corruption

The data in the Auto ACK frame can be corrupted if a read access is made to either TX_FCTRL or TX_BUFFER during Auto ACK frame transmission.

5.4 Transmit and automatically wait for response

The DW1000 has the ability to automatically turn on its receiver after a transmission has completed in order to receive a response. This may also include an optional delay configuration between the end of the transmission and the enabling of the receiver. This is controlled by the WAIT4RESP bit in Register file: 0x0D –

System Control Register and the W4R_TIM parameter in the Register file: 0x1A – Acknowledgement time and response time.

Note: If the response that is received is a frame requesting an acknowledgement frame, the DW1000 will transmit the ACK if automatic acknowledge is enabled, but the receiver will re-enable following the transmission of the ACK. Depending on host response times this may allow the acknowledge-requesting

DW1000 User Manual

Version 2.12

Page 54 of 242

frame to be overwritten, or other behaviour such as receiver timeouts resulting from the device being in the RX state rather than in IDLE.

DW1000 User Manual

Version 2.12

Page 55 of 242

6 Other features of the DW1000

DW1000

External

Clock

SYNC

External Clock supplied

on EXTCLK / XTAL1 pin

6.1 External Synchronisation

This feature is used to synchronise DW1000 with external clocks or events or with other DW1000’s. For example, this would be required in a TDOA RTLS system employing wired clock synchronisation of the anchor nodes.

The DW1000 external synchronisation features allow the following functions:

a) The ability to reset the internal system counter in a deterministic way with respect to the assertion

of the SYNC input pin, and an external 38.4 MHz clock supplied on the EXTCLK pin.

b) The ability to initiate the transmission of a frame in a deterministic way with respect to the assertion

of the SYNC input pin, and an external 38.4 MHz clock supplied on the EXTCLK pin.

c) The ability to synchronise receive time stamping to an external counter

Figure 23: DW1000 External Synchronisation Interface

The SYNC input pin must be source synchronous with an external 38.4 MHz frequency reference clock supplied on the EXTCLK pin. The SYNC input pin is sampled on the rising edge of EXTCLK. Refer to the DW1000 datasheet for setup and hold times of the SYNC pin. The SYNC input provides a common reference point in time to synchronise the DW1000 with the accuracy necessary to achieve high resolution location estimation.

6.1.1 One Shot Timebase Reset (OSTR) Mode

One Shot Timebase Reset (OSTR) mode allows a reset to be applied to the timebase counter used for timestamping in DW1000 at a deterministic and predictable time relative to a synchronisation event.Any

given device will reset the counter at a repeatable time to within 300ps (typically less than 100ps) variation. Process variation between parts introduces a deterministic error that can be calibrated out as part of the necessary calibration process to compensate for cable transmission delays in a wired synchronization system. When several DW1000s are driven by the same reference clock and external SYNC signal their

internal timebases can be synchronised very accurately (allowing for the deterministic delays associated with the distribution network for the reference clock and SYNC signal).

DW1000 User Manual

Version 2.12

Page 56 of 242

To configure DW1000 for OSTR mode, the OSTRM bit in the EC_CTRL register is set and the WAIT value is set to the desired delay value. When a counter running on the 38.4 MHz external clock and initiated on the rising edge of the SYNC signal equals the WAIT programmed value, the DW1000 timebase counter will be reset. See Register file: 0x24 – External Synchronisation Control for register details.

At the time the SYNC signal is asserted, the clock PLL dividers generating the DW1000 125 MHz system clock are reset, to ensure that a deterministic phase relationship exists between the system clock and the asynchronous 38.4 MHz external clock. For this reason, the WAIT value programmed will dictate the phase relationship and should be chosen to give the desired phase relationship, as given by WAIT modulo 4. A WAIT value of 33 decimal is recommended, but if a different value is chosen it should be chosen so that WAIT modulo 4 is equal to 1, i.e. 29, 37, and so on.

6.1.2 One Shot Transmit Synchronisation (OSTS) Mode

DW1000 allows the transmission of a frame at a deterministic time after the SYNC signal is asserted, using the One Shot Transmit Synchronisation (OSTS) mode. OSTS mode provides for the transmission of a frame at a well-defined time relative to the assertion of the SYNC DW1000 input. This time will vary slightly per part, typically 12 ps, but may vary up to 3 ns across process for all parts.

This feature will be used where a local master locationing device is using the DW1000 as a slave to provide additional location data. Calibration can be employed by the master device to tune for the constant offset due to the SYNC trace and process variation and in that case, the delay variation across all parts will be less than 100 ps.

Note that OSTS mode works identically to OSTR in every respect except for the final action performed, e.g. to reset the timebase or to initiate a transmission.

To configure OSTSmode the OSTSM bit must be set in the EC_CTRL register and the WAIT value set to the desired delay value, see Register file: 0x24 – External Synchronisation Control. A value of 33 is recommended; see 6.1.1 – One Shot Timebase Reset (OSTR) Mode. When a counter running on the 38.4 MHz external clock and initiated on the rising edge of the SYNC signal equals the WAIT programmed value, the DW1000 will initiate a transmission, by issuing a TX START signal from the external synchronisation circuit in the clock PLL to the transmitter. The rising edge of the TX START signal is synchronised to the 125 MHz system clock domain before it is used to enable the transmission.

DW1000 User Manual

Version 2.12

Page 57 of 242

External Clock

38.4 MHz

SYNC

124.8MHz

WAIT Cycles wrt

EXT_CLK

TX START

Figure 24: Synchronised Transmission

N-1

N N+1

External Clock

38.4 MHz

Cycle Counter (RX_TS_EST)

RMARKER

1GHz Offset Counter

(OFFSET_EXT)

Time Stamp

6.1.3 One Shot Receive Synchronisation (OSRS) Mode

One Shot Receive Synchronisation (OSRS) mode provides a second timebase in DW1000 that can be synchronised to an external timebase and used to timestamp receive events. This allows a user to have a timebase outside the DW1000, and to receive timing information about the receive events in this timebase. OSRS mode is configured by setting the OSRSM bit in the EC_CTRL register, see Register file: 0x24 – External

Synchronisation Control. A 1 GHz clock for an offset counter, EC_GOLP, must also be activated in this mode,

by setting the PLLSYN field (bit 15) in the PMSC_CTRL1 register, see Sub-Register 0x36:04 – PMSC_CTRL1.

In normal operation, a ranging timestamp is calculated based on the DW1000 internal timebase; see section

4.1.6 – RX Message timestamp. The timebase counter is captured at the receive event, RMARKER, and a

number of offset values are combined with this capture value to give the ranging timestamp.

When timestamping the receive event relative to an external timebase, the procedure is similar to the normal method except that an offset is introduced to compensate for the error introduced by the use of the internal 125 MHz clock to capture a value on the external 38.4 MHz clock domain. As in normal operation, these offsets and captured values are combined to give the ranging timestamp.

Now the timestamp in the external timebase may be computed as:

Figure 25: OSRS Mode Receive Timebase Synchronisation

Trx = N×T

External+T2+T3

DW1000 User Manual

Version 2.12

Page 58 of 242

= (N+1) x T

External -T1+T3

Where:

 N is the number of external clock cycles since the SYNC signal captured in timestamp and

may be read from EC_RXTC in the RS_TS_EST field, see Sub-Register 0x24:04 EC_RXTC.

 T  T  T

is the period of the external clock.

External

is time from the rising edge of the external clock to the RMARKER.

is the time in ns reported by EC_GOLP in the OFFSET_EXT field, see Sub-Register 0x24:08

EC_GOLP.

 T

the leading path delay, calculated by subtracting the raw receive timestamp from the

receive timestamp, the difference between these will give the leading path delay, see

T3 = RX_STAMP – RX_RAWST

6.2 External Power Amplification

In some geographic regions for certain situations (e.g. for emergency first responder use in ETSI UWB regulations for EU) it is permitted to send at +20dB above the normal UWB regulation levels. To achieve this with the DW1000 it is necessary to employ external amplification of the transmitted signal. The DW1000 provides signals (using the GPIO lines in a special mode) to control the turn-on of the power amplifier and to control the analog switching of the transmitter and receiver signal paths appropriately. This mode of operation utilises the DW1000 pins EXTPA, EXTTXE and EXTRXE as configured via the fields MSGP4, MSGP5 and MSGP6 in Sub-Register 0x26:00 – GPIO_MODE.

Care should be taken when using this feature to ensure that necessary regulatory requirements have been fulfilled.

There is a separate application note giving details of the external power amplification. This includes the circuit diagram, details of configuration and various design considerations that apply. Please consult with Decawave’s applications support team for details.

6.3 Using the on-chip OTP memory

The DW1000 has a small amount of one-time-programmable (OTP) memory intended for device specific configuration or calibration data. Some areas of the OTP memory are used to save device calibration values determined during DW1000 testing, while other OTP memory locations are intended to be set by the customer during module manufacture and test.

For example, an OTP memory area is reserved for customers to programme the EUI that is loaded into

Register file: 0x01 – Extended Unique Identifier as the IC comes out of reset (see Register file: 0x01 – Extended Unique Identifier for details of the EUI functionality).

This section lists the OTP memory areas defining their functionality and describes the algorithm for programming values into the OTP memory, and how to read values from the OTP memory. Access to OTP memory is achieved using Register file: 0x2D – OTP Memory Interface.

DW1000 User Manual

Version 2.12

Page 59 of 242

6.3.1 OTP memory map

OTP

Address

Size

(Used

Bytes)

Byte [3]

Byte [2]

Byte [1]

Byte [0]

Programmed

0x000

64 bit EUID

(These 64 bits get automatically copied over to Register File 0x01:EUI on each reset.)

Customer

0x001

0x002

Alternative 64bit EUID

Customer

0x003

0x004

40 bit LDOTUNE_CAL

(These 40 bits can be automatically copied over to Sub Register File 0x28:30 LDOTUNE on wakeup)

Decawave Test

0x005

0x006

{“0001,0000,0000“, "CHIP ID (20 bits)"}

Decawave Test

0x007

{“0001”“, "LOT ID (28 bits)"}

DecawaveTest

0x008 2 -

meas

@ 3.7 V

meas

@ 3.3 V

DecawaveTest

0x009

1 / 1 - -

meas

@ Ant Cal

meas

@ 23 °C

Customer / Deca-

wave Test

0x00A

Reserved

0x00B

Reserved

0x00C

Reserved

0x00D

Reserved

0x00E

Reserved

0x00F

Reserved

0x010

CH1 TX Power Level PRF 16

Customer

0x011

CH1 TX Power Level PRF 64

Customer

0x012

CH2 TX Power Level PRF 16

Customer

0x013

CH2 TX Power Level PRF 64

Customer

0x014

CH3 TX Power Level PRF 16

Customer

0x015

CH3 TX Power Level PRF 64

Customer

0x016

CH4 TX Power Level PRF 16

Customer

0x017

CH4 TX Power Level PRF 64

Customer

0x018

CH5 TX Power Level PRF 16

Customer

0x019

CH5 TX Power Level PRF 64

Customer

0x01A

CH7 TX Power Level PRF 16

Customer

0x01B

CH7 TX Power Level PRF 64

Customer

0x01C

TX/RX Antenna Delay – PRF 64

TX/RX Antenna Delay – PRF 16

Customer

0x01D 0 - - -

Customer

0x01E 2 -

OTP Revision

XTAL_Trim[4:0]

Customer

0x01F 0 - - -

Customer

: : : : :

Reserved

0x400

SR Register (see below)

Customer

The OTP memory locations are as defined in Table 10. The OTP memory locations are each 32-bits wide, OTP addresses are word addresses so each increment of address specifies a different 32-bit word.

Table 10: OTP memory map

DW1000 User Manual

Version 2.12

Page 60 of 242

The SR (“Special Register”) is a 32-bit segment of OTP that is directly readable via the register interface upon

Bit

Function

31:5

Reserved. Defaults to all “0”. If programming the OTP_SRDATA register these bits must be set to “0”

4:3

SPI_SR_EN[1:0]. Set to “01” to enable bits [1:0] to be used instead of GPIO[6:5] boot

strapping. If set, this will disable the external selection of SPI mode via GPIO6 and 5.

Reserved. Defaults to “0”. If programming the OTP_SRDATA register these bits must be set to “0”

SPI_SR_PH. Set SPI Phase mode to this value if bits [4:3] are set to “01”

SPI_SR_POL. Set SPI Polarity mode to this value if bits [4:3] are set to “01”

Step

Number

Instruction

Data

Length

(Bytes)

Data

(Write/Read)

Configure OTP for Programming – Stage 1:

C-1

Write Sub-Register

0x36:00 (PMSC_CTRL0)

0x01

C-2

Write Sub-Register

0x2D:07 (OTP_CTRL+1)

0x03

C-3

Write Sub-Register

0x2D:00 (OTP_WDAT)

0x9220

C-4

Write Sub-Register

0x2D:06 (OTP_CTRL)

0x08

Wait 1ms C-5

Write Sub-Register

0x2D.07 (OTP_CTRL+1)

0x02

C-6

Write Sub-Register

0x2D:06 (OTP_CTRL)

0x88

C-7

Write Sub-Register

0x2D:06 (OTP_CTRL)

0x80

C-8

Write Sub-Register

0x2D:06 (OTP_CTRL)

0x00

Configure OTP for Programming – Stage 2:

C-9

Write Sub-Register

0x2D:07 (OTP_CTRL+1)

0x05

C-10

Write Sub-Register

0x2D:00 (OTP_WDAT)

0x000E

C-11

Write Sub-Register

0x2D:06 (OTP_CTRL)

0x08

Wait 1ms

C-12

Write Sub-Register

0x2D.07 (OTP_CTRL+1)

0x04

C-13

Write Sub-Register

0x2D:06 (OTP_CTRL)

0x88

C-14

Write Sub-Register

0x2D:06 (OTP_CTRL)

0x80

power up. To programme the SR register follow the normal OTP programming method but set the OTP address to 0x400. The value of the SR register can be directly read back at address Register file: 0x2D – OTP

Memory Interface.

Table 11: OTP_SRDAT Register

6.3.2 Programming a value into OTP memory

The programming of the OTP requires a number of setup steps to be carried out in sequence. Optimal programming requires that the VDDIO pin be driven to 3.8 V (or the VDDIOA pin if access to VDDIO is not available). The table below outlines the programming steps to place the OTP into its programming state and to programme a single location.

Table 12: Register accesses required to program the OTP

DW1000 User Manual

Version 2.12

Page 61 of 242

Step

Number

Instruction

Data

Length

(Bytes)

Data

(Write/Read)

C-15

Write Sub-Register

0x2D:06 (OTP_CTRL)

0x00

Configure OTP for Programming – Stage 3:

C-16

Write Sub-Register

0x2D:07 (OTP_CTRL+1)

0x01

C-17

Write Sub-Register

0x2D:00 (OTP_WDAT)

0x1024

C-18

Write Sub-Register

0x2D:06 (OTP_CTRL)

0x08

Wait 1ms

C-19

Write Sub-Register

0x2D.07 (OTP_CTRL+1)

0x00

Programming a single 32 bit word <DATA> to address <ADDR>:

P-1

Write Sub-Register

0x2D:06 (OTP_CTRL)

0x00

P-2

Write Sub-Register

0x2D:00 (OTP_WDAT)

<DATA[31:0]>

P-3

Write Sub-Register

0x2D:04 (OTP_ADR)

<ADDR[10:0]>

P-4

Write Sub-Register

0x2D:06 (OTP_CTRL)

0x40

P-5

Write Sub-Register

0x2D:06 (OTP_CTRL)

0x00

Wait 1 ms before reading back to verify

Step

Number

Instruction

Data

Length

(Bytes)

Data

(Write/Read)

Write Register

0x2D:04 (OTP_ADDR)

OTP Address

Write Sub-Register

0x2D:06 (OTP_CTRL)

0x03

Write Sub-Register

0x2D:06 (OTP_CTRL)

0x00

Read Register

0x2D:0A (OTP_RDAT)

OTP Read Value

After programming an OTP word, it should be read back using the procedure in 6.3.3 – Reading a value from

OTP memory and verified for correctness. If it does not match the expected value, then the steps P-4

through P-5 should be repeated up to a maximum of 10 times (the address and data values in the registers will still be valid and as such do not require re-programming). During the programming stages the OTP is configured to stress the read-back circuits to their limits. This may result in continuous read-verify failures. In the event that 10 attempts have been made to programme a location then a final read-verify is recommended after a full IC reset, this will reset the OTP configuration to normal read operation.

When all OTP programming is finished it is recommended to reset the IC to revert back to the default settings.

6.3.3 Reading a value from OTP memory

The OTP memory may be read by following the steps given in Table 13.

Table 13: An example of register accesses required to read from OTP

6.4 Measuring IC temperature and voltage

The DW1000 is equipped with a low speed 8-bit SAR A/D convertor which can be configured to sample values from an internal IC temperature sensor and also from a battery voltage monitor on the VDDAON

DW1000 User Manual

Version 2.12

Page 62 of 242

power supply input. These readings can be manually run under host control, or they can be configured to be

Step

Number

Instruction

Address

Data Length

(Bytes)

Data

(Write/Read)

Write Sub-Register

28:11

0x80

Write Sub-Register

28:12

0x0A

Write Sub-Register

28:12

0x0F

Write Register

2A:00

0x01

Write Register

2A:00

0x00

Read Register

2A:03

8-bit Voltage reading

Read Register

2A:04

8-bit Temperature reading

run automatically each time the DW1000 enters the WAKEUP state. This automatic mode allows the temperature and voltage to be read while the device is in a low power state, which will give the ambient temperature and unloaded battery voltage.

The automatic mode is controlled by the ONW_RADC bit in Sub-Register 0x2C:00 – AON_WCFG. When this is used the temperature and voltage readings are available in Sub-Register 0x2A:06 – TC_SARW as soon as the IC reaches the IDLE state.

The procedure for host-initiated reading of temperature sensor (or battery voltage) is as follows:

Table 14: An example of register accesses to perform a read of the temperature and voltage sensors

When in the ADC is configured for automatic operation on wakeup Register: 2C – ONWAKE_RUN_SAR, then the ADC values for both the voltage and temperature sensors will be ready to read as soon as the IDLE state is entered. These values can be read by performing steps 6 and 7 from the table above.

In the automatic mode it is possible to configure an interrupt to assert if the latest readings of temperature or voltage differ from the previously recorded values by a value of 0x0A. This is approximately equal to 60 mV for the voltage reading and 10 ⁰C for the temperature reading.

The previous values are also available to the host to read at:

DW1000 User Manual

Version 2.12

Page 63 of 242

7 The DW1000 register set

Length

(octets)

Type

Mnemonic

Description

0x00

DEV_ID

Device Identifier – includes device type and revision info

0x01

EUI

Extended Unique Identifier

0x02 - - - Reserved

0x03

PANADR

PAN Identifier and Short Address

0x04

SYS_CFG

System Configuration bitmap

0x05 - - - Reserved

0x06

SYS_TIME

System Time Counter (40-bit)

0x07 - - - Reserved

0x08

TX_FCTRL

Transmit Frame Control

0x09

1024

TX_BUFFER

Transmit Data Buffer

0x0A

DX_TIME

Delayed Send or Receive Time (40-bit)

0x0B - - - Reserved

0x0C

RX_FWTO

Receive Frame Wait Timeout Period

0x0D

SRW

SYS_CTRL

System Control Register

0x0E

SYS_MASK

System Event Mask Register

0x0F

SRW

SYS_STATUS

System Event Status Register

0x10

ROD

RX_FINFO

RX Frame Information

(in double buffer set)

0x11

1024

ROD

RX_BUFFER

Receive Data

(in double buffer set)

0x12

ROD

RX_FQUAL

Rx Frame Quality information

(in double buffer set)

0x13

ROD

RX_TTCKI

Receiver Time Tracking Interval

(in double buffer set)

0x14

ROD

RX_TTCKO

Receiver Time Tracking Offset

(in double buffer set)

The DW1000 is controlled by an associated host microcontroller system using the SPI interface to access a series of registers within the device. The DW1000 register set includes configuration registers, status registers, control registers, data buffer registers, and diagnostic registers. Section 2.2 – The SPI Interface described the SPI interface and the low level transactions for reading and writing the parameters of the DW1000. This section begins with 7.1– Register map overview and then 7.2– Detailed register description, where each individual parameter is described in detail.

7.1 Register map overview

The register map overview is given in Table 15. This lists the registers in address order, by register file ID, giving the register file length in octets, its type (RO = Read-Only, RW = Read & Write, SRW = Special Read Write – see individual register descriptions for details about how the Read/Write access is special), and a brief high level description of the register. Section 7.2 gives a detailed description of each register.

Note: When writing to any of the DW1000 registers care must be taken not to write beyond the published length of the selected register and not to write to any of the reserved register locations. Doing so may cause the device to malfunction.

Table 15: Register map overview

DW1000 User Manual

Version 2.12

Page 64 of 242

Length

(octets)

Type

Mnemonic

Description

0x15

ROD

RX_TIME

Receive Message Time of Arrival

(in double buffer set)

0x16 - - - Reserved

0x17

TX_TIME

Transmit Message Time of Sending

0x18

TX_ANTD

16-bit Delay from Transmit to Antenna

0x19

SYS_STATE

System State information

0x1A

ACK_RESP_T

Acknowledgement Time and Response Time

0x1B - - - Reserved

0x1C - - - Reserved

0x1D

RX_SNIFF

Pulsed Preamble Reception Configuration

0x1E

TX_POWER

TX Power Control

0x1F

CHAN_CTRL

Channel Control

0x20 - - - Reserved

0x21

USR_SFD

User-specified short/long TX/RX SFD sequences

0x22 - - - Reserved

0x23

AGC_CTRL

Automatic Gain Control configuration

0x24

EXT_SYNC

External synchronisation control.

0x25

4064

ACC_MEM

Read access to accumulator data

0x26

GPIO_CTRL

Peripheral register bus 1 access – GPIO control

0x27

DRX_CONF

Digital Receiver configuration

0x28

RF_CONF

Analog RF Configuration

0x29 - - - Reserved

0x2A

TX_CAL

Transmitter calibration block

0x2B

FS_CTRL

Frequency synthesiser control block

0x2C

AON

Always-On register set

0x2D

OTP_IF

One Time Programmable Memory Interface

0x2E

LDE_CTRL

Leading edge detection control block

0x2F

DIG_DIAG

Digital Diagnostics Interface

0x30

0x35

- - -

Reserved

0x36

PMSC

Power Management System Control Block

0x37

0x3F

- - -

Reserved

Note the “Type” mnemonic in the table above has the following meaning:

• RO – Read Only,

• WO – Write Only,

• RW – Read and Write,

• SRW – Special type of Read and Write, refer to individual register description for details,

• ROD – Read Only part of RX Double buffered swinging set of RX frame related information,

• RWD – Read and Write part of RX Double buffered swinging set of RX frame related information.

DW1000 User Manual

Version 2.12

Page 65 of 242

7.2 Detailed register description

Length

(octets)

Type

Mnemonic

Description

REG:RR:SS – Mnemonic – one line description

10 9 8 7 6 5 4 3 2 1 0

Length

(octets)

Type

Mnemonic

Description

0x00 4 RO

DEV_ID

Device Identifier – includes device type and revision information

7.2.1 Terminology

Section 7.1 gives an overview of the DW1000 register set presenting all top level register file ID addresses in Table 15. This section describes in detail the contents and functionality of these register files in separate sub sections. In each case the row from Table 15 is reproduced with hex register file ID, its length, type, mnemonic and one line description as follows:

This is followed by a description of the parameters within that register file. All parameters are presented with format REG:RR:SS, where RR is register file ID and SS is the sub address. Where a register is made up of individual bits or bit-fields these are identified with mnemonic and default values as follows:

Then the fields or bits identified are described individually in detail.

Because many parameters are 4-octets long, the default presentation of the register values is as a 32-bit value. This may be sub-divided into fields of various bit widths down to single bit values. It should be noted that when reading these values via the SPI interface the octets are output least significant octet first. Also of note is the fact that the indexed addressing modes allow individual octets to be accessed – a technique that may be employed to reduce SPI traffic when only part of a register needs to be read or written.

Note: unused or reserved registers return 0xDEADDEAD when read. Unused or reserved bits/ bit fields within registers return the appropriate bits / bit fields from 0xDEADDEAD.

Each register file is described below:

7.2.2 Register file: 0x00 – Device Identifier

register is read-only and cannot be overwritten by the host system. The device ID will be changed for any silicon updates. The device ID register is ideal to use in the host µP to validate that the SPI interface is operational. It is expected that the host system will validate that the device ID is the expected value, supported by its software, before proceeding to use the IC.

DW1000 User Manual

Version 2.12

Page 66 of 242

The Device Identifier register contains the following sub-fields:

REG:00:00 – DEV_ID – Device Identifier

10 9 8 7 6 5 4 3 2 1 0

RIDTAG

MODEL

VER

REV

1 1 0 1 1 1 1 0 1 1 0 0 1 0 1 0 0 0 0 0 0 0 0 1 0 0 1 1 0 0 0

Field

Description of fields within Register file: 0x00 – Device Identifier

REV

reg:00:00

bits:3–0

Revision: This number will be updated for minor corrections and changes in operation

VER

reg:00:00

bits:7–4

Version: This number will be updated if a new version is produced that has significant differences from the previous version.

MODEL

reg:00:00

bits:15–8

The MODEL identifies the device. The DW1000 is device type 0x01.

RIDTAG

reg:00:00

bits:31–16

Register Identification Tag. It is planned that this will remain constant for all Decawave parts. The value is 0xDECA in hex.

Definition of the sub fields of REG:00:00 – DEV_ID: Device Identifier:

For the production DW1000 the Device ID is set to 0xDECA0130. The register descriptions in this user manual relate to that DW1000 device and are not valid for any earlier sample parts.

DW1000 User Manual

Version 2.12

Page 67 of 242

7.2.3 Register file: 0x01 – Extended Unique Identifier

Length

(octets)

Type

Mnemonic

Description

0x01

EUI

Extended Unique Identifier – the 64-bit IEEE device address

REG:01:00 – EUI – Extended Unique Identifier

7 6 5 4 3 2 1

Octet Index

Description

0xHH

Bits 7 to 0 of the extension identifier

0xHH

Bits 15 to 8 of the extension identifier

0xHH

Bits 23 to 16 of the extension identifier

0xHH

Bits 31 to 24 of the extension identifier

0xHH

Bits 39 to 32 of the extension identifier

0xNN

Bits 7 to 0 of the OUI (manufacturer company ID)

0xNN

Bits 15 to 8 of the OUI (manufacturer company ID)

0xNN

Bits 23 to 16 of the OUI (manufacturer company ID)

every device should have a unique 64-bit device identifier. The high-order 24-bits of the EUI are a company identifier assigned by the IEEE Registration Authority, (see http://standards.ieee.org/develop/regauth/oui/), to the manufacturer. The low 40-bits of the EUI are the extension identifier uniquely chosen by the manufacturer for each device manufactured and never repeated. The resultant EUI is a globally unique identifier. It is expected that manufacturers who need to comply with this requirement will register with the IEEE Registration Authority and generate and maintain their own EUI extension identifier numbering space to ensure its uniqueness for every device made.

Manufacturers may store the EUI externally to the DW1000 or as an alternative the DW1000 has a one-timeprogrammable memory area that may be programmed with the EUI during product manufacturing. Please refer to section 6.3 – Using the on-chip OTP memory for details of programming values into OTP. Table 47:

During DW1000 initialisation, or upon waking up from sleep mode, the Register file: 0x01 – Extended Unique Identifier register value is loaded from its OTP memory area. After this the EUI register value may be overwritten by the host system if necessary.

Certain IEEE 802.15.4 defined frames use a 64-bit source address. The software (MAC) generating such frames is expected to insert the EUI within the frame before the frame is written to the DW1000’s transmit buffer.

The EUI register is used by the Receive Frame Filtering function, see section 5.2details. When frame filtering is operational the DW1000 decodes each received frame according to the IEEE 802.15.4 MAC rules and any 64-bit destination address present must match the EUI register before the frame will be accepted.

The 8-octets of the Extended Unique Identifier may be accessed as a single 8-octet access to the EUI register file starting at index 0. The bytes of the EUI are output/input in the following order:

DW1000 User Manual

Version 2.12

Page 68 of 242

The ordering of octets read from the Extended Unique Identifier register is designed to be directly

Length

(octets)

Type

Mnemonic

Description

0x02 - - - Reserved – this register file is reserved

Length

(octets)

Type

Mnemonic

Description

0x03

PANADR

PAN Identifier and Short Address

REG:03:00 –PANADR – PAN Identifier and Short Address

10 9 8 7 6 5 4 3 2 1 0

PAN_ID

SHORT_ADDR

0xFFFF

compatible with the octet ordering of the 64-bit source address fields of IEEE 802.15.4 standard MAC frames easing the task of inserting it into a frame for transmission.

7.2.4 Register file: 0x02 – Reserved

doing so may cause the DW1000 to malfunction.

7.2.5 Register file: 0x03 – PAN Identifier and Short Address

When the DW1000 is powered-up or reset both the PAN Identifier and the Short Address in this register are reset to the value 0xFFFF. The host software (MAC) should program the appropriate values into this register if it wishes to use the DW1000’s receive frame filtering or automatic acknowledgement generation functions.

In an IEEE 802.15.4 personal area network (PAN), the PAN coordinator node determines the PAN Identifier for the network, and assigns it and short 16-bit addresses to devices (nodes) associating with the PAN. The nodes in the PAN then should (at the MAC layer) use their assigned short address as the source address and include it along with the PAN Identifier in the frames they transmit. When a node receives a frame it should only process those with a destination address and PAN Identifier which matches their assigned node address and network ID.

When the receive frame filtering and automatic acknowledgement functionality is operational the DW1000 decodes each received frame according to the IEEE 802.15.4 MAC specification and when it determines that a 16-bit destination address is present in the frame, the DW1000 will compare the destination address with the short address value programmed in this register before accepting/acknowledging the frame, and will similarly only accept received frames when the PAN Identifier in the frame matches the PAN Identifier programmed in this register. See sections 5.2 and 5.3 for details of the frame filtering and automatic acknowledgement functionality.

The PAN Identifier and Short Address register contains the following sub-fields:

DW1000 User Manual

Version 2.12

Page 69 of 242

The host software (MAC) only needs to program this register if it is using the DW1000’s receive frame

Field

Description of fields within Register file: 0x03 – PAN Identifier and Short Address

SHORT_ADDR

reg:03:00

bits:15–0

Short Address. The host software needs to program this register if it is using the DW1000’s

receive frame filtering functionality, with or without the automatic acknowledgement generation function. The short address is typically assigned to a node by the coordinator function at MAC (or higher) layer as part of network association. The value may alternatively be pre-defined in a closed network where the network association phase is being skipped.

PAN_ID

reg:03:00

bits:31–16

PAN Identifier. The host software needs to program this register if it is using the DW1000’s

receive frame filtering functionality, with or without the automatic acknowledgement generation function. The PAN ID is typically assigned as part of network association. A predefined PAN ID might be used in a closed network where the network association phase is being skipped.

Length

(octets)

Type

Mnemonic

Description

0x04

SYS_CFG

System Configuration bitmap

REG:04:00 – SYS_CFG – System Configuration bit map

10 9 8 7 6 5 4 3 2 1 0

AACKPEND

AUTOACK

RXAUTR

RXWTOE

- - - - -

RXM110K

- - -

DIS_STXP

PHR_MODE

FCS_INIT2F

DIS_RSDE

DIS_PHE

DIS_DRXB

DIS_FCE SPI_EDGE

HIRQ_POL

FFA5

FFA4

FFAR

FFAM

FFAA

FFAD

FFAB

FFBC

FFEN

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0

Field

Description of fields within Register file: 0x04 – System Configuration

FFEN

reg:04:00

bit:0

Frame Filtering Enable. This bit enables the frame filtering functionality in the DW1000 receiver. The frame filtering is designed to follow the rules defined in the IEEE 802.15.42011 standard. When frame filtering is enabled receive frames must pass the frame filtering rules before being considered as a good frame. This includes the destination address matching the PAN_ID and SHORT_ADDR as defined in Register file: 0x03 – PAN Identifier

and Short Address, or the long 64-bit defined by Register file: 0x01 – Extended Unique Identifier. These addresses and the other frame filtering control bits of Register file: 0x04 – System Configuration should be configured correctly before enabling frame filtering with

this FFEN bit. Section 5.2 describes frame filtering in more detail.

filtering and automatic acknowledgement generation functions. The sub-fields are:

7.2.6 Register file: 0x04 – System Configuration

field is separately identified and described below. The System Configuration register contains the following bitmapped sub-fields:

Definition of the bit fields within REG:04:00 – SYS_CFG: System Configuration bitmap: -

DW1000 User Manual

Version 2.12

Page 70 of 242

Field

Description of fields within Register file: 0x04 – System Configuration

FFBC

reg:04:00

bit:1

Frame Filtering Behave as a Coordinator. FFEN must be set to enable this frame filtering operation. A coordinator will accept a frame without a destination address if the source address has the PAN_ID matching the coordinator’s PAN_ID. For an ordinary (non- coordinator) node the destination address (if present) must match the node’s own address or the frame will not be accepted. When FFBC is set to 1 the DW1000 will behave as a coordinator. When FFBC is clear the DW1000 will behave as an ordinary normal node. Section 5.2 describes frame filtering in more detail.

FFAB

reg:04:00

bit:2

Frame Filtering Allow Beacon frame reception. IEEE 802.15.4-2011 frames begin with three bits, indicating the frame type for beacon frames these are binary 000. When FFAB is set to 1 beacon frames will be accepted (assuming all other frame filtering rules are passed) and when FFAB is clear beacon frames will be ignored. Section 5.2 describes frame filtering in detail.

FFAD

reg:04:00

bit:3

Frame Filtering Allow Data frame reception. IEEE 802.15.4-2011 frames begin with three bits, indicating the frame type, b3 to b0, for data frames these are binary 001. When FFAD is set to 1 data frames will be accepted (assuming all other frame filtering rules are passed) and when FFAD is clear data frames will be ignored. Section 5.2 describes frame filtering in more detail.

FFAA

reg:04:00

bit:4

Frame Filtering Allow Acknowledgment frame reception. IEEE 802.15.4-2011 frames begin with three frame type bits, b3 to b0, for acknowledgment frames these are binary 010. When FFAA is set to 1 acknowledgment frames will be accepted (assuming all other frame filtering rules are passed) and when FFAA is clear acknowledgment frames will be ignored. Section 5.2 describes frame filtering in more detail.

FFAM

reg:04:00

bit:5

Frame Filtering Allow MAC command frame reception. IEEE 802.15.4-2011 frames begin with three frame type bits, b3 to b0, for MAC command frames these are binary 011. When FFAM is set to 1 MAC command frames will be accepted (assuming all other frame filtering rules are passed) and when FFAM is clear MAC command frames will be ignored. Section

5.2 describes frame filtering in more detail.

FFAR

reg:04:00

bit:6

Frame Filtering Allow Reserved frame types. IEEE 802.15.4-2011 frames begin with three frame type bits, b3 to b0. The values of binary 100 through 111 (4 to 7) are not defined in IEEE 802.15.4-2011 and would normally be rejected. When FFAR is 0 these frames may be ignored (depending also on FFA4 and FFA5 which modify this behaviour). When FFAR is set to 1 these frames are accepted. Since these frame types are unknown no further frame decoding is done (e.g. no address matching etc.) and the software will thus be responsible for validating and interpreting these frames. Section 5.2 describes frame filtering in more detail. Note that the frame filter does decode the frame control fields to determine the minimum length of the expected frame and will reject the frame if it is too short, see section 5.2.

FFA4

reg:04:00

bit:7

Frame Filtering Allow frames with frame type field of 4, (binary 100). IEEE 802.15.4-2011 frames begin with three frame type bits, b3 to b0. The value of binary 100 is not defined in IEEE 802.15.4-2011. When FFA4 is set to 1, frames of type 4 will be accepted, but no further frame decoding is done (e.g. no address matching etc.) so software will be responsible for validating and interpreting these frames. When FFA4 is set to 0, frames of type 4 will be ignored unless FFAR is set. Section 5.2 describes frame filtering in more detail. Note that the frame filter does decode the frame control fields to determine the minimum length of the expected frame and will reject the frame if it is too short, see section 5.2.

DW1000 User Manual

Version 2.12

Page 71 of 242

Field

Description of fields within Register file: 0x04 – System Configuration

FFA5

reg:04:00

bit:8

Frame Filtering Allow frames with frame type field of 5, (binary 101). IEEE 802.15.4-2011 frames begin with three frame type bits, b3 to b0. The value of binary 100 is not defined in IEEE 802.15.4-2011. When FFA5 is set to 1, frames of type 5 will be accepted, but no further frame decoding is done (e.g. no address matching etc.) so software will be responsible for validating and interpreting these frames. When FFA5 is set to 0, frames of type 5 will be ignored unless FFAR is set. Section 5.2 describes frame filtering in more detail. Note that the frame filter does decode the frame control fields to determine the minimum length of the expected frame and will reject the frame if it is too short, see section 5.2.

HIRQ_POL

reg:04:00

bit:9

Host interrupt polarity. This bit allows the system integrator the ability to control the polarity of the IRQ line from the DW1000. When HIRQ_POL is 1 the IRQ output line from the DW1000 is active high, and, when HIRQ_POL is 0 the IRQ output line from the DW1000 is active low. Active high operation is recommended for low power applications so that the interrupt is in its 0 V logical inactive state when the DW1000 is in SLEEP or DEEPSLEEP states.

SPI_EDGE

reg:04:00

bit:10

SPI data launch edge. This bit allows the system integrator the ability to control the launch edge used for SPI data from the DW1000 on the MISO SPI data output line. This may be used to select the MISO output operation most suitable to the target system. When SPI_EDGE is 0 the DW1000 uses the sampling edge to launch MISO data. This setting should give the highest rate operation. When SPI_EDGE is 1 the DW1000 uses the opposite edges to launch the data. This setting may give a more robust operation.

DIS_FCE

reg:04:00

bit:11

Disable frame check error handling. This might be of use for protocols using a different encoding scheme for error handling not based on standard IEEE 802.15.4-2011, but for normal IEEE 802.15.4-2011 operation this bit should be set to 0. Setting this bit to one makes the DW1000 treat the frame as valid, ignoring errors, so that in double buffering mode (for example) it will move on to the next buffer. In normal operation (when DIS_FCE is 0) with double buffering, a CRC error causes the current RX frame to be discarded and the buffer to be reused for next frame’s reception.

DIS_DRXB

reg:04:00

bit:12

Disable Double RX Buffer. The DW1000 has a double buffered receiver allowing reception of a new frame to proceed in one buffer while the host processor is in the process of unloading the last frame received into the other buffer of the buffer pair. The double buffering is enabled when DIS_DRXB is set to 0, and disabled when DIS_DRXB is set to 1. More details on the operation of double buffering are given in section4.3.

DIS_PHE

reg:04:00

bit:13

Disable receiver abort on PHR error. When DIS_PHE is 0 (recommended) the receiver will discontinue reception when it detects a non-correctable error in the PHY header, see section 10.4 –PHY header for details of PHR encoding and error correction. The PHR error is reported by the RXPHE event status bit in Register file: 0x0F – System Event Status Register. This bit is for debug only and should never be set in an application as it can seriously impair receiver performance when set.

DW1000 User Manual

Version 2.12

Page 72 of 242

Field

Description of fields within Register file: 0x04 – System Configuration

DIS_RSDE

reg:04:00

bit:14

Disable Receiver Abort on RSD error. During normal reception (i.e. with the DIS_RSDE bit cleared to its recommended default zero value) when the Reed Solomon decoder detects an non-correctable error then frame reception is aborted and the receiver will be disabled, (unless the RXAUTR control bit is set in which case the receiver will automatically re-enable and begin preamble hunt again). The Reed Solomon decoder error is generated when an error is found that cannot be corrected using the Reed Solomon FEC (forward error correction) data. The Reed Solomon decoder error is flagged in the RXRFSL event status bit in Register file: 0x0F – System Event Status Register. When the DIS_RSDE bit is set the receiver will not abort reception when the Reed Solomon error occurs, but will instead continue to demodulate the data to the end of the frame (i.e. for the length specified in the PHY Header). Typically the non-correctable Reed Solomon error will mean that the frame is corrupted and that the CRC will not be correct.

FCS_INIT2F

reg:04:00

bit:15

This bit allows selection of the initial seed value for the FCS generation and checking function that is set at the start of each frame transmission and reception. By default the FCS_INIT2F bit is 0 selecting the FCS generation/checking seed initialisation to be all zero (0x0000) – this is the standard setting required for IEEE 802.15.4 compliance. When the FCS_INIT2F bit is 1 the FCS generation/checking initialisation value will be all ones (0xFFFF).

PHR_MODE

reg:04:00

bits:17,16

This configuration allows selection of PHR type to be one of two options. The default setting gives IEEE standard PHR encoding and a maximum data payload of 127 octets. The other option enables the proprietary long frames mode which allows a data payload of up to 1023 octets. In this mode the PHR encoding does not follow the IEEE standard. For successful communications between two nodes both must be configured for the same PHR mode. Supported PHR_MODE configurations are:

00 – Standard Frame mode. Use this setting is for IEEE 802.15.4 compliance. 11 – Long Frames mode. Proprietary PHR encoding. Frame Length 0-1023.

DIS_STXP

reg:04:00

bit:18

Disable Smart TX Power control.

Smart TX power control applies at the 6.8 Mbps data rate. When sending short data frames at this rate (and providing that the frame transmission rate is < 1 frame per millisecond) it is possible to increase the transmit power and still remain within regulatory power limits which are typically specified as average power per millisecond.

When DIS_STXP is 0, the transmitter automatically sets the transmitter power levels when sending a frame at the 6.8 Mbps data rate, depending on the frame length specified in the TFLEN field of Register file: 0x08 – Transmit Frame Control.

The actual power levels used are selected by the values configured in Register file: 0x1E –

Transmit Power Control, described in section 7.2.31.

NB: It is up to the external system to keep the frame rate below 1 frame per millisecond to ensure that the power boost is not breaking the regulations.

When DIS_STXP is 1, the smart TX power control function is disabled and TX power does not depend on data rate and frame length. In this case the values configured in Register file:

0x1E – Transmit Power Control are used to specify the power in different phases of the TX

frame separately, see section 7.2.31.

reg:04:00

bits:21–19

These bits are reserved and should always be set to zero to avoid any malfunction of the device.

DW1000 User Manual

Version 2.12

Page 73 of 242

Field

Description of fields within Register file: 0x04 – System Configuration

RXM110K

reg:04:00

bit:22

Receiver Mode 110 kbps data rate. This configuration when set to 1 will cause the receiver to look for long SFD and process the PHY Header and RX data as per the 110 kbps frame mode. When this configuration is 0, (the default), the receiver will look for short SFD and will determine the RX data rate from the PHY header as either 850 kbps or 6.8 Mbps.

reg:04:00

bits:27–23

These bits are reserved and should always be set to zero to avoid any malfunction of the device.

RXWTOE

reg:04:00

bit:28

Receive Wait Timeout Enable. When set RX Enable will initialise an RX_FWTO down count which will disable the receiver if no valid frame is received before the timeout occurs. The timeout period is set in Register file: 0x0C – Receive Frame Wait Timeout Period. The occurrence of the timeout is signalled by the RXRFTO event status bit in Register file: 0x0F –

System Event Status Register.

RXAUTR

reg:04:00

bit:29

Receiver Auto-Re-enable. This bit is used to cause the receiver to re-enable automatically. Its operation changes depending on whether the IC is operating in single or double buffered modes. The default value is 0. With this setting, the IC will not automatically re-enable the receiver but will stop receiving and return to idle mode whenever any receive events happen. This includes receiving a frame but also failing to receive a frame because of some error condition, for example an error in the PHY header (as reported by the RXPHE event status bit in Register file: 0x0F – System Event Status Register). In such cases if the host wants to re-enable the receiver it must do it explicitly, using the RXENAB bit in Register file:

0x0D – System Control Register. The operation when RXAUTR = 1 is as follows:

(a) Double-buffered mode: After a frame reception event or failure (except a frame

wait timeout), the receiver will re-enable to receive another frame.

(b) Single-buffered mode: After a frame reception failure (except a frame wait

timeout), the receiver will re-enable to re-attempt reception. For more information on frame reception see section 4 – Message Reception. Note: In double-buffered mode when automatic frame acknowledgement is enabled (by the AUTOACK bit below) the receiver will be re-enabled after the ACK frame has been transmitted.

AUTOACK

reg:04:00

bit:30

Automatic Acknowledgement Enable. Default value 0. This is the enable for the Automatic Acknowledgement function. See section 5.3– Automatic Acknowledgement for details of operation of Automatic Acknowledgement.

AACKPEND

reg:04:00

bit:31

Automatic Acknowledgement Pending bit control. Default value 0. The value of the AACKPEND bit is copied into the Frame Pending bit in the Frame Control field of the DW1000 automatically generated ACK frame. See section 5.2 – Frame filtering for details of operation of frame filtering.

Length

(octets)

Type

Mnemonic

Description

0x05 - - - Reserved – this register file is reserved

7.2.7 Register file: 0x05 – Reserved

doing so may cause the DW1000 to malfunction.

DW1000 User Manual

Version 2.12

Page 74 of 242

7.2.8 Register file: 0x06 – System Time Counter

Length

(octets)

Type

Mnemonic

Description

0x06 5 RO

SYS_TIME

System Time Counter (40-bit)

Notes (a)

On power up, before the digital PLL is enabled, the System Time Counter increments are still in units of 512 however the increment rate is half the external crystal frequency, (e.g. at 19.2 MHz for the 38.4 MHz crystal). The counter wrap period is then: 231 ÷ 19.2e6 = 111.8481 seconds.

(b)

In sleep modes the system time counter is disabled and this register is not updated.

Length

(octets)

Type

Mnemonic

Description

0x07 - - - Reserved – this register file is reserved

Length

(octets)

Type

Mnemonic

Description

0x08

TX_FCTRL

Transmit Frame Control

REG:08:00 – TX_FCTRL – Transmit Frame Control (Octets 0 to 3, 32-bits)

10 9 8 7 6 5 4 3 2 1 0

TXBOFFS

TXPSR

TXPRF

TXBR R TFLE

TFLEN

0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 1 1 0

0 REG:08:04 – TX_FCTRL – Transmit Frame Control (Octet 4, 8-bits)

10 9 8 7 6 5 4 3 2 1 0

IFSDELAY

0 0 0 0 0 0 0

designed to be based on the time units which are nominally at 64 GHz, or more precisely 499.2 MHz × 128 which is 63.8976 GHz. In line with this when the DW1000 is in idle mode with the digital PLL enabled, the System Time Counter is incremented at a rate of 125 MHz in units of 512. The nine low-order bits of this register are thus always zero. The counter wrap period of the clock is then: 240 ÷ (128×499.2e6) = 17.2074 seconds.

7.2.9 Register file: 0x07 – Reserved

doing so may cause the DW1000 to malfunction.

7.2.10 Register file: 0x08 – Transmit Frame Control

Each field is separately identified and described below. (For a general discussion of transmission please refer to section 3 – Message Transmission.

DW1000 User Manual

Version 2.12

Page 75 of 242

The fields of the TX_FCTRL register identified above are individually described below:

Field

Description of fields within Register file: 0x08 – Transmit Frame Control

TFLEN

reg:08:00

bits:6–0

Transmit Frame Length. Standard IEEE 802.15.4 UWB frames can be up to 127 bytes long. The value specified here determines the length of the data portion of the transmitted frame. This length includes the two-octet CRC appended automatically at the end of the frame, unless SFCST (in Register file: 0x0D – System Control Register) is use to suppress the FCS. The frame length is also copied into the PHY Header of the TX frame so that the receiving device knows how much data to decode.

TFLE

reg:08:00

bits:9–7

Transmit Frame Length Extension. The DW1000 supports a non-standard mode of operation with data frame lengths up to 1023 bytes. This mode of operation is enabled via the PHR_MODE selection bits of Register file: 0x04 – System Configuration. In this long frame mode TFLE adds three high-order bits to TFLEN to extend the frame length to 10-bits, allowing frame length from 0 up to 1023 bytes to be sent. Please refer to section 3.4 –Extended Length Data

Frames for more details of this non-standard mode.

Reserved. Bits 12, 11 & 10 are reserved for future expansion. They should be set to zero.

TXBR

reg:08:00

bits:14,13

Transmit Bit Rate. This sets the user bit rate for the data portion of the frame as follows:

Bit 14

Bit 13

Bit Rate

0 0 110 kbps

0 1 850 kbps

1 0 6.8 Mbps

1 1 reserved

reg:08:00

bit: 15

Transmit Ranging enable. This bit has no operational effect on the DW1000; however it is copied into the ranging bit in the PHY header (PHR) of the transmitted frame, identifying the frame as a ranging frame. In some receiver implementations this may be used to enable hardware or software associated with time-stamping the frame. In the DW1000 receiver the time-stamping of the receive frame does not depend or use the ranging bit in the received PHR.

TXPRF

reg:08:00

bits:17,16

Transmit Pulse Repetition Frequency. This sets the mean Pulse Repetition Frequency (PRF) used in the transmitter:

Bit 17

Bit 16

Nominal PRF

0 0 4 MHz

0 1 16 MHz

1 0 64 MHz

1 1 reserved

Note: (a) For successful reception of a frame the PRF in the receiver needs to be

configured to be the same as the PRF used for transmitting the frame.

(b) The choice of preamble code also needs to be appropriate to the configured PRF

and needs to be the same in both transmitting and receiving ends for successful communication – please use Table 61 to select the appropriate preamble code.

DW1000 User Manual

Version 2.12

Page 76 of 242

Field

Description of fields within Register file: 0x08 – Transmit Frame Control

TXPSR

reg:08:00

bits:19,18

Transmit Preamble Symbol Repetitions (PSR). This sets the length of the transmitted preamble sequence in symbols. Each preamble symbol is approximately 1 µs in duration1.The two TXPSR bits are copied into the PHY Header. The receiving end is thus made aware of how much preamble was sent. This might inform its choice of preamble length in any reply message. There are four standard preamble lengths are defined for the 802.15.4 UWB PHY – these are 16, 64, 1024 and 4096 symbols. The DW1000 has facility via the PE (Preamble Extension) configuration to send preambles of additional (non-standard) intermediary lengths. Table 16 below lists the selectable preamble lengths.

reg:08:00

bits:21,20

Preamble Extension. This field allows specification of a non-standard number of preamble symbol repetitions, thus extending the set of preamble lengths that are available to optimise system performance. The resultant preamble lengths depend the setting of both PE and TXPSR above. Table 16 below lists the useful preamble lengths that can be selected.

Table 16: Preamble length selection

Bit 19

Bit 18

Bit 21

Bit 20

TXPSR

Preamble Length

0 1 0

128

0 1 1

256

0 1 1

512

1 0 0

1024

1 0 0

1536

1 0 1

2048

1 1 0

4096

The bit numbers quoted above are the bit numbers in the TX_FCTRL register.

The choice of preamble length has a bearing on operating range and system performance, a discussion of the factors affecting the choice of preamble length (and other parameters) may be found in section 9.3 below.

TXBOFFS

reg:08:00

bits:31–22

Transmit buffer index offset. This 10-bit field is used to specify an index in the transmit buffer of the first octet to be transmitted. The TX frame begins with the octet at the TXBOFFS index and continues for the number octets specified by the frame length (TFLEN and TFLE) less 2 for the CRC. Care should be taken that the TXBOFFS plus the frame length does not extend past the end of the TX_BUFFER. Some uses for TXBOFFS are outlined in section 3.5.1.

The duration of preamble symbols is 993.59 ns with the 16 MHz PRF setting and 1017.63 ns with for 64 MHz PRF.

DW1000 User Manual

Version 2.12

Page 77 of 242

Field

Description of fields within Register file: 0x08 – Transmit Frame Control

IFSDELAY

reg:08:04

bits:7–0

Inter-Frame Spacing. This delay in preamble symbol times will be applied between successive transmitted frames. One use of the IFSDELAY is to allow the receiver time to unload and process the frame before another frame is sent to it. For this reason IFSDELAY is logically considered to be a post-amble to the transmitted frame, and it begins counting down after the last symbol of data is sent. Where the transmitter is enabled to begin a new frame the DW1000 makes sure that IFSDELAY symbol times have passed. A new value of IFSDELAY for the next frame should not be set until after the end-of-frame TXFRS (Transmit Frame Sent) event has occurred. The IFSDELAY sets a minimum time between frames enforced by the DW1000, assuming that the host has initiated a new transmission. Note: Because of internal IC delays the on-air gap between the end of the previous frame and the start of the new one is actually 6 symbol times larger than specified here, e.g. an IFSDELAY setting of 34 will result in an on-air gap of 40 preamble symbols.

Length

(octets)

Type

Mnemonic

Description

0x09

1024

TX_BUFFER

Transmit Data Buffer

Length

(octets)

Type

Mnemonic

Description

0x0A

DX_TIME

Delayed Send or Receive Time (40-bit)

7.2.11 Register file: 0x09 – Transmit Data Buffer

during the data payload portion of the transmitted frame. Section 3 – Message Transmission discusses the basics of frame transmission and details the various parts of the TX frame.

The general procedure is to write the data frame for transmission into the TX_BUFFER, set the frame length and other details in the TX_FCTRL register and initiate transmission using in the TXSTRT control bit in

Note that read operations from the transmit data buffer are NOT supported. Reading the transmit data buffer during an active transmit can corrupt the transmitted data. A read of the TX_FCTRL register will also read the transmit data buffer so the TX_FCTRL register should not be read during an active transmit operation.

7.2.12 Register file: 0x0A – Delayed Send or Receive Time

either turn on the receiver to be ready to receive a frame, or to turn on the transmitter and send a frame. The low-order 9-bits of this register are ignored. Delayed send is initiated by the TXDLYS control bit in

Register file: 0x0D – System Control Register. Delayed receive is initiated by the RXDLYE bit. Register file: 0x0D – System Control Register. For more information see section 3.3 – Delayed Transmission and section

4.2 – Delayed Receive.

DW1000 User Manual

Version 2.12

Page 78 of 242

Refer to the TX_PSTM field of Sub-Register 0x2F:24 – Digital Diagnostics Test Mode Control for details of

Length

(octets)

Type

Mnemonic

Description

0x0B - - - Reserved – this register file is reserved

Length

(octets)

Type

Mnemonic

Description

0x0C

RX_FWTO

Receive Frame Wait Timeout period

how to program this register for use in Transmit Power Spectrum Test Mode and note that bits 31:0 only are used in this mode, whilst the 9 least significant bits are ignored in functional modes.

7.2.13 Register file: 0x0B – Reserved

doing so may cause the DW1000 to malfunction.

7.2.14 Register file: 0x0C – Receive Frame Wait Timeout Period

function is provided to allow the external microprocessor to enter a low power state awaiting a valid receive frame and be woken up by the DW1000 when either a frame is received or the programmed timeout has elapsed. While many microcontrollers have timers that might be used for this purpose, including this RX timeout functionality in the DW1000 allows additional flexibility to the system designer in selecting the microprocessor to optimise the solution. The frame wait timeout is enabled by the RXWTOE bit in Register

file: 0x04 – System Configuration.

When the receiver is enabled (and begins hunting for the preamble sequence) and RXWTOE is set, then the frame wait timeout counter starts counting the timeout period programmed. Thereafter, assuming no action is taken to change the operation, one of two things should happen:

a) The Receive Frame Wait Timeout period elapses. This disables the receiver and sets the RXRFTO

(Receiver Frame Wait Timeout) bit in the status register, (and resets the counter).

b) A valid receive frame arrives and sets the RXDFR and RXFCG bits in the status register. This stops the

receive frame wait timer counter so RXRFTO will not be set.

The receiver will not re-enable immediately following a RXRFTO (Receiver Frame Wait Timeout) irrespective of whether the device is using the Double Receive Buffer, see section 4.3, or the Automatic Receiver Reenable, see section 5.3.2.

The timeout period should only be programmed when the device IDLE. Programming the timeout value at other times is not prevented but may result in unpredictable behaviour.

The MRXFCG and MRXRFTO mask bits in the SYS_MASK register may be configured (before enabling the receiver) to generate interrupts to the controlling microprocessor. If RXWTOE is cleared while the countdown is running the countdown will be disabled, and RXRFTO will not be set.

DW1000 User Manual

Version 2.12

Page 79 of 242

When frame filtering is employed, any frames rejected are not treated as valid RX frames (neither RXDFR or

REG:0C:00 – RX_FWTO – Receive Frame Wait Timeout Period

10 9 8 7 6 5 4 3 2 1 0 - - - - - - - - - - - - - - - -

RXFWTO

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Field

Description of fields within Register file: 0x0C – Receive Frame Wait Timeout Period

RXFWTO

reg:0C:00

bits:15–0

The Receive Frame Wait Timeout period is a 16-bit field. The units for this parameter are roughly 1µs, (the exact unit is 512 counts of the fundamental 499.2 MHz UWB clock, or 1.026 µs). When employing the frame wait timeout, RXFWTO should be set to a value greater than the expected RX frame duration and include an allowance for any uncertainly attaching to the expected transmission start time of the awaited frame. The Receive Frame Wait Timeout feature is enabled by the RXWTOE in Register file: 0x04 – System Configuration. When RXWTOE is set then each time the receiver is enabled a timer is started with the RXFWTO specified period, and if no data is received before this RX Frame Wait Timeout timer expires, then the receiver is returned to its idle state and the timeout is signalled by the RXRFTO event status bit in Register file: 0x0F – System Event Status Register.

reg:0C:00

bits:31–16

These bits are reserved and should always be written as zero.

Length

(octets)

Type

Mnemonic

Description

0x0D

SRW

SYS_CTRL

System Control Register

REG:0D:00 – SYS_CTRL – System Control

10 9 8 7 6 5 4 3 2 1 0

RXFCG are set) so the receiver and the receive frame wait timeout just continues its countdown

The individual sub-fields are described below:

Note: The frame wait timeout may also be employed with double buffering, where after a frame is received the DW1000 automatically re-enables the receiver (moving on to potentially receive a new frame in the next buffer). Here when RXWTOE is set the countdown will be restarted as the receiver re-enables to receive into the next buffer. See section 4.3 Double Receive Buffer for more information on double buffering.

7.2.15 Register file: 0x0D – System Control Register

field is separately identified and described below. For a general discussion of transmission please refer to section 3 - Message Transmission. The control bits within the system control register are typically automatically cleared. The host controller sets the appropriate bit to invoke an activity and the bit is automatically cleared by the DW1000 as that commanded activity begins.

DW1000 User Manual

Version 2.12

Page 80 of 242

- - - - - - -

HRBPT

- - - - - - - - - - - - -

RXDLYE

RXENAB WAIT4RESP

TRXOFF

CANSFCS

TXDLYS

TXSTRT

SFCST

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 Field

Description of fields within Register file: 0x0D – System Control Register

Bits marked ‘-’ in register 0x0D are reserved and should always be written as zero.

SFCST

reg:0D:00

bit:0

Suppress auto-FCS Transmission (on this next frame). This control works in conjunction with the TXSTRT (Transmit Start) bit below to control whether or not the DW1000 automatically calculates and appends the two Frame-Check-Sequence bytes. It is expected that the host will decide this as transmission is invoked and set SFCST at the same time as TXSTRT is set if FCS suppression is required. Normally SFCST is not set when transmission is started and the DW1000 calculates the FCS on the octets fetched from the TX buffer, and automatically appends the two-byte FCS sequence at the end of the frame. The FCS sequence follows the IEEE 802.15.4 standard polynomial, x16 + x12 + x5 + 1, also known as CRC-16-CCITT or CRC-16 ITU-T. When SFCST is set (as transmission is started) the DW1000 will not append the FCS to the data frame but instead fetches the two bytes from the TX buffer. The frame length is determined by the TFLEN field of Register file: 0x08 – Transmit Frame Control. So, when SFCST is clear, TFLEN-2 (frame length minus two) octets are fetched and sent from the TX buffer, and the final two octets sent are the automatically generated FCS bytes. And, when SFCST is set, TFLEN (frame length) octets are sent from the TX buffer. SFCST may be of use if a nonstandard IEEE 802.15.4 frame protocol is being employed, and can also be of use to induce a FCS error in the remote receiver during testing. The SFCST bit will clear as soon as the DW1000 sees TXSTRT and initiates transmission.

TXSTRT

reg:0D:00

bit:1

Transmit Start. This bit commands the DW1000 to begin transmission. When the DW1000 is in idle mode and the TXSTRT bit is set it the IC will begin transmission of a frame immediately, unless TXDLYS is set (see below). In general it would be expected that the user has a prepared frame in the transmit buffer and has configured the desired transmit mode and set the frame length, in Register file: 0x08 – Transmit Frame Control, before setting TXSTRT to invoke transmission. For a general discussion of transmission see section 3 –Message Transmission. The TXSTRT bit will clear when the frame transmission begins.

DW1000 User Manual

Version 2.12

Page 81 of 242

Field

Description of fields within Register file: 0x0D – System Control Register

TXDLYS

reg:0D:00

bit:2

Transmitter Delayed Sending. This control works in conjunction with TXSTRT and the DX_TIME value specified by Register file: 0x0A – Delayed Send or Receive Time. When the user wants to control the time of sending of a frame, the send time is programmed into DX_TIME, and then both TXDLYS and TXSTRT should be set at the same time to correctly invoke the delayed sending feature. The TXDLYS bit will clear along with the TXSTRT bit when the delay has completed and the frame transmission begins and initiates the delayed transmission.

When delayed sending is used the DW1000 precisely controls the transmission start time so that the internal TX timestamp occurs at the point when SYS_TIME is equal to the DX_TIME value. The actual time of TX then is calculable as DX_TIME plus the TX antenna delay.

TXDLYS has a number of uses: -

 It can be used to give precise control of the transmission time of a response message,

which would allow a receiver that knows this response time to only turn on at the correct time to receive the response, thus saving power.

 In symmetric double-sided two-way ranging, the RX to TX response times at either end

should be the same so that their differences in local clocks correctly cancel out. This may be ensured by setting TXDLYS to a value that is a fixed delta added to the RX timestamp.

 In two-way ranging the TX timestamp of the final message exchange needs to be

communicated to the receiving end to allow the round-trip delay to be calculated. Using TXDLYS allows this time to be predicted, pre-calculated and embedded into the final message itself. This may save the need for an additional message interchange which will give a power saving, and save time too.

 Embedding the TX time in this way may also reduce the number of messages in a

wireless clock synchronisation scheme.

CANSFCS

reg:0D:00

bit:3

Cancel Suppression of auto-FCS transmission (on the current frame). This bit is intended to be used when transmission is kicked off before the data is actually written to the transmit buffer, which can be used to speed response times and/or system data throughput. A general discussion of these techniques may be found in section 3.5 – High Speed Transmission. The general principle is not to send the FCS (marking a good frame) until all the data is written to the TX_BUFFER. So transmission is initiated with SFCST set to suppress the FCS and when all data is written to the TX_BUFFER the FCS transmission is enabled by setting the CANSFCS bit to cancel the suppression, i.e. allow the transmission of the FCS. The DW1000 transmitter includes a circuit to detect the host microprocessor writing to the buffer between the configured TXBOFFS and any address it has already consumed data from, which is taken to mean the HOST has written the data too late for transmission, in which case the setting of CANSFCS will be ignored and the frame will be transmitted with a bad CRC. This condition is signalled by the TXBERR bit in Register file: 0x0F – System Event Status Register. The CANSFCS bit will clear as soon as the DW1000 sees and acts on it.

TRXOFF

reg:0D:00

bit:6

Transceiver Off. When this is set the DW1000 returns to idle mode immediately. Any TX or RX activity that is in progress at that time will be aborted. The TRXOFF bit will clear as soon as the DW1000 sees it and returns the IC to idle mode.

DW1000 User Manual

Version 2.12

Page 82 of 242

Field

Description of fields within Register file: 0x0D – System Control Register

WAIT4RESP

reg:0D:00

bit:7

Wait for Response. The WAIT4RESP control works in conjunction with TXSTRT bit above and the W4R_TIM value in Register file: 0x1A – Acknowledgement time and response time. When WAIT4RESP is set at the same time as the TXSTRT then when the DW1000 has finished transmitting the frame it will automatically turn-around, disabling the transmitter and enabling the receiver, to await a response frame. The W4R_TIM value may be programmed with a delay between TX end and RX enable. Delaying turning on the receiver will save power in cases where the response is known to be a delayed by a certain amount. The WAIT4RESP bit will clear at the time when DW1000 enables the receiver, (or when a TRXOFF is employed). NB: When in use the WAIT4RESP bit must be set at the same time as the TXSTRT bit is set, (i.e. by the same write).

RXENAB

reg:0D:00

bit:8

Enable Receiver. This bit commands the DW1000 to turn on its receiver and begin looking for the configured preamble sequence. It is assumed that the all necessary configurations have been made before turning on the receiver. For a general discussion of reception see section 4

– Message Reception. The RXENAB bit will clear as soon as the DW1000 sees it and initiates

reception. NB: The receiver has a delay of 16 µs after issuing the enable receiver command, after which it will start receiving preamble symbols.

RXDLYE

reg:0D:00

bit:9

Receiver Delayed Enable. This control works in conjunction with RXENAB and the DX_TIME value specified by Register file: 0x0A – Delayed Send or Receive Time. When the user wants to control the time of turning on the receiver, the turn on time is programmed into DX_TIME, and then both RXDLYE and RXENAB should be set to correctly invoke the delayed receiving feature. The DW1000 then precisely controls the RX turn on time so that it is ready to receive the first symbol of preamble at the specified DX_TIME start time. In cases when the received time can be known precisely, for example when a response is expected at a well-defined time, employing RXDLYE will give a power saving as it allows the IC to remain idle until the moment it is required to act for the reception.

HRBPT

reg:0D:00

bit:24

Host Side Receive Buffer Pointer Toggle. In the doubly buffered receiver mode the host uses this bit to change which of the buffer pairs it is reading from. The half being accessed is reported by the HSRBP (Host Side Receive Buffer Pointer) status bit in Register file: 0x0F –

System Event Status Register. See section 4.3 – Double Receive Bufferfor more details.

Length

(octets)

Type

Mnemonic

Description

0x0E

SYS_MASK

System Event Mask Register

7.2.16 Register file: 0x0E – System Event Mask Register

bits in the SYS_STATUS register. Whenever a bit in the SYS_MASK is set (to 1) and the corresponding bit in the SYS_STATUS register is also set, then an interrupt will be generated asserting the hardware IRQ output line. The interrupt condition may be removed by clearing the corresponding bit in this SYS_MASK register (by setting it to 0) or by clearing the corresponding latched bit in the SYS_STATUS register (generally by writing a 1 to the bit – please refer to individual SYS_STATUS register bit definitions for details).

The SYS_STATUS register contains the system event status bits identified and described below:

DW1000 User Manual

Version 2.12

Page 83 of 242

REG:0E:00 – SYS_MASK – System Event Mask

10 9 8 7 6 5 4 3 2 1 0

MAFFREJ

MTXBERR

MHPDWAR

MPLLHILO

MRFPLLLL

MSLP2INIT

MGPIOIRQ

MRXPTO MRXOVRR

MLDEERR

MRXRFTO

MRXRFSL

MRXFCE

MRXFCG

MRXDFR

MRXPHE

MRXPHD MLDEDON

MRXSFDD

MRXPRD

MTXFRS

MTXPHS

MTXPRS

MTXFRB

MAAT MESYNCR

MCPLOCK

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Field

Description of fields within Register file: 0x0E – System Event Mask Register

–

reg:0E:00

bit:0

This bit is reserved.

MCPLOCK

reg:0E:00

bit:1

Mask clock PLL lock event. When MCPLOCK is 0 the CPLOCK event status bit will not generate an interrupt. When MCPLOCK is 1 and the CPLOCK event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MESYNCR

reg0E:00

bit:2

Mask external sync clock reset event. When MESYNCR is 0 the ESYNCR event status bit will not generate an interrupt. When MESYNCR is 1 and the ESYNCR event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MAAT

reg:0E:00

bit:3

Mask automatic acknowledge trigger event. When MAAT is 0 the AAT event status bit will not generate an interrupt. When MAAT is 1 and the AAT event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

AAT should be masked when the automatic acknowledge is not enabled so that spurious interrupts cannot affect system behaviour.

MTXFRB

reg:0E:00

bit:4

Mask transmit frame begins event. When MTXFRB is 0 the TXFRB event status bit will not generate an interrupt. When MTXFRB is 1 and the TXFRB event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MTXPRS

reg:0E:00

bit:5

Mask transmit preamble sent event. When MTXPRS is 0 the TXPRS event status bit will not generate an interrupt. When MTXPRS is 1 and the TXPRS event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MTXPHS

reg:0E:00

bit:6

Mask transmit PHY Header Sent event. When MTXPHS is 0 the TXPHS event status bit will not generate an interrupt. When MTXPHS is 1 and the TXPHS event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MTXFRS

reg:0E:00

bit:7

Mask transmit frame sent event. When MTXFRS is 0 the TXFRS event status bit will not generate an interrupt. When MTXFRS is 1 and the TXFRS event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MRXPRD

reg:0E:00

bit:8

Mask receiver preamble detected event. When MRXPRD is 0 the RXPRD event status bit will not generate an interrupt. When MRXPRD is 1 and the RXPRD event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MRXSFDD

reg:0E:00

bit:9

Mask receiver SFD detected event. When MRXSFDD is 0 the RXSFDD event status bit will not generate an interrupt. When MRXSFDD is 1 and the RXSFDD event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MLDEDONE

reg:0E:00

bit:10

Mask LDE processing done event. When MLDEDONE is 0 the LDEDONE event status bit will not generate an interrupt. When MLDEDONE is 1 and the LDEDONE event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

The system event mask bits of the SYS_MASK register identified above are individually described below:

DW1000 User Manual

Version 2.12

Page 84 of 242

Field

Description of fields within Register file: 0x0E – System Event Mask Register

MRXPHD

reg:0E:00

bit:11

Mask receiver PHY header detect event. When MRXPHD is 0 the RXPHD event status bit will not generate an interrupt. When MRXPHD is 1 and the RXPHD event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MRXPHE

reg:0E:00

bit:12

Mask receiver PHY header error event. When MRXPHE is 0 the RXPHE event status bit will not generate an interrupt. When MRXPHE is 1 and the RXPHE event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MRXDFR

reg:0E:00

bit:13

Mask receiver data frame ready event. When MRXDFR is 0 the RXDFR event status bit will not generate an interrupt. When MRXDFR is 1 and the RXDFR event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MRXFCG

reg:0E:00

bit:14

Mask receiver FCS good event. When MRXFCG is 0 the RXFCG event status bit will not generate an interrupt. When MRXFCG is 1 and the RXFCG event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MRXFCE

reg:0E:00

bit:15

Mask receiver FCS error event. When MRXFCE is 0 the RXFCE event status bit will not generate an interrupt. When MRXFCE is 1 and the RXFCE event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MRXRFSL

reg:0E:00

bit:16

Mask receiver Reed Solomon Frame Sync Loss event. When MRXRFSL is 0 the RXRFSL event status bit will not generate an interrupt. When MRXRFSL is 1 and the RXRFSL event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MRXRFTO

reg:0E:00

bit:17

Mask Receive Frame Wait Timeout event. When MRXRFTO is 0 the RXRFTO event status bit will not generate an interrupt. When MRXRFTO is 1 and the RXRFTO event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MLDEERR

reg:0E:00

bit:18

Mask leading edge detection processing error event. When MLDEERR is 0 the LDEERR event status bit will not generate an interrupt. When MLDEERR is 1 and the LDEERR event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

– reg:0F:00

bit:19

This bit is reserved.

MRXOVRR

reg:0E:00

bit:20

Mask Receiver Overrun event. When MRXOVRR is 0 the RXOVRR event status bit will not generate an interrupt. When MRXOVRR is 1 and the RXOVRR event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MRXPTO

reg:0E:00

bit:21

Mask Preamble detection timeout event. When MRXPTO is 0 the RXPTO event status bit will not generate an interrupt. When MRXPTO is 1 and the RXPTO event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MGPIOIRQ

reg:0E:00

bit:22

Mask GPIO interrupt event. When MGPIOIRQ is 0 the GPIOIRQ event status bit will not generate an interrupt. When MGPIOIRQ is 1 and the GPIOIRQ event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MSLP2INIT

reg:0E:00

bit:23

Mask SLEEP to INIT event. When MSLP2INIT is 0 the SLP2INIT event status bit will not generate an interrupt. When MSLP2INIT is 1 and the SLP2INITevent status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MRFPLLLL

reg:0E:00

bit:24

Mask RF PLL Losing Lock warning event. When MRFPLLLL is 0 the RFPLL_LL event status bit will not generate an interrupt. When MRFPLLLL is 1 and the RFPLL_LL event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MCPLLLL

reg:0E:00

bit:25

Mask Clock PLL Losing Lock warning event. When MCPLLLL is 0 the CLKPLL_LL event status bit will not generate an interrupt. When MCPLLLL is 1 and the CLKPLL_LL event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

DW1000 User Manual

Version 2.12

Page 85 of 242

Field

Description of fields within Register file: 0x0E – System Event Mask Register

MRXSFDTO

reg:0E:00

bit:26

Mask Receive SFD timeout event. When MRXSFDTO is 0 the RXSFDTO event status bit will not generate an interrupt. When MRXSFDTO is 1 and the RXSFDTO event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MHPDWARN

reg:0E:00

bit:27

Mask Half Period Delay Warning event. When MHPDWARN is 0 the HPDWARN event status bit will not generate an interrupt. When MHPDWARN is 1 and the HPDWARN event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MTXBERR

reg:0E:00

bit:28

Mask Transmit Buffer Error event. When MTXBERR is 0 the TXBERR event status bit will not generate an interrupt. When MTXBERR is 1 and the TXBERR event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

MAFFREJ

reg:0E:00

bit:29

Mask Automatic Frame Filtering rejection event. When MAFFREJ is 0 the AFFREJ event status bit will not generate an interrupt. When MAFFREJ is 1 and the AFFREJ event status bit is 1, the hardware IRQ interrupt line will be asserted to generate an interrupt.

– reg:0E:00

bits:30,31

These bits are reserved.

Length

(octets)

Type

Mnemonic

Description

0x0F

SRW

SYS_STATUS

System Event Status Register

REG:0F:00 – SYS_STATUS – System Status Register (octets 0 to 3)

10 9 8 7 6 5 4 3 2 1 0

ICRBP

HSRBP

AFFREJ

TXBERR HPDWARN

RXSFDTO

CLKPLL_LL

RFPLL_LL

SLP2INIT

GPIOIRQ

RXPTO RXOVRR

LDEERR

RXRFTO

RXRFSL

RXFCE

RXFCG

RXDFR

RXPHE

RXPHD LDEDONE

RXSFDD

RXPRD

TXFRS

TXPHS

TXPRS

TXFRB

AAT ESYNCR

CPLOCK

IRQS

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

7.2.17 Register file: 0x0F – System Event Status Register

indicate the occurrence of different system events or status changes. It is possible to enable particular events as interrupt sources, by employing the SYS_MASK, Register file: 0x0E – System Event Mask Register, so that the setting of the event status bit will generate an interrupt, asserting the hardware IRQ output line. This can be used, for example, to allow the host processor to enter a low-power state during frame transmission or reception awaiting an interrupt to wake upon the completion of the TX or RX activity.

Reading the SYS_STATUS register returns the state of the status bits. Generally these event status bits are latched so that the event is captured. Such latched bits need to be explicitly cleared by writing a '1' to the bit position (writing '0' has no effect).

The SYS_STATUS register contains the system event status bits identified and described below:

DW1000 User Manual

Version 2.12

Page 86 of 242

REG:0F:04 – SYS_STATUS – System Status Register (octet 4)

10 9 8 7 6 5 4 3 2 1 0

- - - - -

TXPUTE

RXPREJ

RXRSCS

0 0 0 0 0 0 0

Field

Description of fields within Register file: 0x0F – System Event Status Register

IRQS

reg:0F:00

bit:0

Interrupt Request Status. This is a READ ONLY status flag – it cannot be cleared or overwritten. Whenever a status bit in Register file: 0x0F – System Event Status Register is activated (i.e. has a value of 1) and the corresponding bit in Register file: 0x0E – System Event Mask Register is enabled (i.e. has a value of 1 also) then the IRQ interrupt request line will be driven to its active ON level. If there are no active mask enabled status bits then the IRQ interrupt request line will be set to its inactive OFF level. This IRQS flag reflects the overall status of interrupts. If there are any unmasked interrupt sources active then the IRQS bit will be 1 (and IRQ interrupt request line will be at its active ON level) the otherwise IRQS will be zero (and IRQ interrupt request line at its OFF level). The polarity of the IRQ interrupt request line is controllable via the HIRQ_POL configuration bit in Register file: 0x04 – System Configuration.

CPLOCK

reg:0F:00

bit:1

Clock PLL Lock. The CPLOCK event status bit indicates that the digital clock PLL has locked. This may be used as an interrupt to indicate that the DW1000 clock is operating at full speed, after which the SPI can be run at its maximum rate also. The CPLOCK bit is cleared by writing a 1 to it. The clock PLL lock status is also available via the CPLLLOCK status bit in Sub-Register

0x28:2C – RF_STATUS.

Note: The PLLLDT bit in Register file 0x24:00 –EC_CTRL should be set to ensure reliable operation of this CPLOCK bit.

ESYNCR

reg0F:00

bit:2

External Sync Clock Reset. This event status bit is set when the system counter is reset as a result of the reception of an external synchronisation clock reset signal on the SYNC pin. The ESYNCR flag bit is cleared by writing a 1 to it. Section 6.1 – External Synchronisation describes this feature.

AAT

reg:0F:00

bit:3

Automatic Acknowledge Trigger. This status event status bit is set when frame filtering is enabled and a data frame (or MAC command frame) is received (correctly addressed and with a good CRC) with the acknowledgement request bit set in its frame control field.

If the automatic acknowledgement is enabled (by the AUTOACK bit in Register file: 0x04 –

System Configuration) then the AAT bit can be used during receive interrupt processing to

detect that acknowledgement is in progress and so avoid taking any action until the transmission of the acknowledgement is completed – an event that might be detected by awaiting the TXFRS (Transmit Frame Sent) status interrupt.

If automatic acknowledgement is not enabled, then the AAT status bit must be ignored.

The AAT bit can be cleared explicitly by writing a 1 to it. It is also automatically cleared by the next receiver enable, (including those caused by the RXAUTR auto-re-enable).

TXFRB

reg:0F:00

bit:4

Transmit Frame Begins. This event status bit is set at the start of a frame transmission as the transmitter begins to send preamble. The TXFRB bit is automatically cleared at the next transmitter enable. It can also be cleared explicitly by writing a 1 to it.

The system event status bits of the SYS_STATUS register identified above are individually described below:

DW1000 User Manual

Version 2.12

Page 87 of 242

Field

Description of fields within Register file: 0x0F – System Event Status Register

TXPRS

reg:0F:00

bit:5

Transmit Preamble Sent. This event status bit is set at the end of preamble when SFD sending begins. The TXPRS bit is automatically cleared at the next transmitter enable. It can also be cleared explicitly by writing a 1 to it.

TXPHS

reg:0F:00

bit:6

Transmit PHY Header Sent. This event status bit is set when the PHR has been transmitted. This marks the start of sending the data part of the frame (assuming the frame length is nonzero) at the configured transmit data rate. The TXPHS bit is automatically cleared at the next transmitter enable. It can also be cleared explicitly by writing a 1 to it.

TXFRS

reg:0F:00

bit:7

Transmit Frame Sent. This event status bit is set at the end of sending the data part of the

frame. It is expected that this will be used as the main “Transmit Done” (interrupt) event

signalling the completion of frame transmission. (In the case where frame length is zero the TXFRS bit is set soon after the TXPHS event flag). The TXFRS bit is automatically cleared at the next transmitter enable. It can also be cleared explicitly by writing a 1 to it.

RXPRD

reg:0F:00

bit:8

Receiver Preamble Detected status. This event status bit is set to indicate that the receiver has detected (and confirmed) the presence of the preamble sequence. Preamble reception continues after RXPRD has been set until the SFD is detected as signalled by the RXSFDD event status bit or an SFD timeout occurs as signalled by the RXSFDTO event status bit. Section 4 –

Message Reception gives details of the frame reception process. The RXPRD bit can be cleared

explicitly by writing a 1 to it. It is also automatically cleared by the next receiver enable, including those caused by the RXAUTR auto-re-enable.

RXSFDD

reg:0F:00

bit:9

Receiver SFD Detected. This event status bit is set to indicate that the receiver has detected the SFD sequence and is moving on to decode the PHR. Section 4 – Message Reception gives details of the frame reception process. The RXSFDD bit can be cleared explicitly by writing a 1 to it. It is also automatically cleared by the next receiver enable, including those caused by the RXAUTR auto-re-enable.

LDEDONE

reg:0F:00

bit:10

LDE processing done. This event status bit is set to indicate the completion of the leading edge detection and other adjustments of the receive timestamp information. The resultant adjusted message RX timestamp is then available in Register file: 0x15 – Receive Time Stamp. The detection of SFD as reported by the RXSFDD event status bit marks the end of the SFD and the start of the PHR, which also marks the RMARKER whose arrival at the antenna is the event that defines the frame arrival timestamp. To accurately determine this timestamp the DW1000 employs an internal algorithm to adjust the RMARKER receive time. Among other functions this performs a leading edge detection search on the channel impulse response and subtracts the receive antenna delay as programmed in Sub-Register 0x2E:1804 – LDE_RXANTD. For more information on the LDE and the process on message time-stamping see section 4.1.6

– RX Message timestamp. The LDEDONE event status flag bit is included in the RX double-

buffered swinging-set. It is automatically cleared by the RX enable. It can also be cleared explicitly by writing a 1 to it.

RXPHD

reg:0F:00

bit:11

Receiver PHY Header Detect. This event status bit is set to indicate that the receiver has completed the decoding of the PHR. Section 4 – Message Reception gives details of the frame reception process. The RXPHD bit can be cleared explicitly by writing a 1 to it. It is also automatically cleared by the next receiver enable, including those caused by the RXAUTR autore-enable.

DW1000 User Manual

Version 2.12

Page 88 of 242

Field

Description of fields within Register file: 0x0F – System Event Status Register

RXPHE

reg:0F:00

bit:12

Receiver PHY Header Error. This event status bit is set to indicate that the receiver has found a non-correctable error in the PHR. The PHR includes a SECDED error check sequence (see section 10.4) that can correct a single bit error and detect a double bit error. The double error is not correctable and its detection is the event that the RXPHE event status flag is notifying. Generally this error means that correct frame reception is not possible, and so typically this event will abort frame reception (depending on the DIS_PHE configuration in Register file: 0x04

– System Configuration) after which the receiver may return to preamble search (depending on

the RXAUTR configuration also in Register file: 0x04 – System Configuration). Section4 –

Message Reception gives details of the frame reception process. The RXPHE bit can be cleared

explicitly by writing a 1 to it. It is also automatically cleared by the next receiver enable, including those caused by the RXAUTR auto-re-enable. PHY Header Error events are counted in Sub-Register 0x2F:04 – PHR Error Counter, as long as counting is enabled by the EVC_EN bit in Sub-Register 0x2F:00 – Event Counter Control.

RXDFR

reg:0F:00

bit:13

Receiver Data Frame Ready. This event status bit is set to indicate that the completion of the frame reception process. Section 4 – Message Reception gives details of the frame reception process. It is expected that this will be used as the main “Receive” (interrupt) event signalling the completion of a frame reception, and, that the receive event processing routine will examine the RXFCG and RXFCE to determine whether the frame has been received without error (or not), and also to check the LDEDONE event status flag to validate the receive timestamp information.

In order to ensure that the receive timestamp information is valid before any receive interrupt processing takes place, the setting of RXDFR is delayed until the LDE adjustments of the timestamp have completed, at which time the LDEDONE event status bit will be set (or possibly LDEERR). The RXDFR event status flag bit is included in the RX double-buffered swinging-set. It is automatically cleared by the RX enable. It can also be cleared explicitly by writing a 1 to it.

NOTE: If the RXDFR is set, but neither RXFCG nor RXFCE events have been flagged and also neither LDEDONE nor LDEERR have been flagged then the LDE code has not been loaded correctly and is not running correctly. Please review 2.5.5.10.

RXFCG

reg:0F:00

bit:14

Receiver FCS Good. This event status bit reflects the result of the frame CRC checking. It is set (or not) at the end of frame reception coincidentally with the setting of the RXDFR event status flag. When RXFCG is set to 1 it indicates that the CRC check result generated on the received data matches with the 2-octet FCS sequence at the end of the frame. RXDFR with RXFCG then indicates the correct reception a valid frame. The RXFCG bit is in the RX double-buffered swinging-set. It is automatically cleared by RX enable. It can also be cleared explicitly by writing a 1 to it.

RXFCE

reg:0F:00

bit:15

Receiver FCS Error. This event status bit also reflects the result of the frame CRC checking. It is valid at the end of frame reception coincidentally with the setting of the RXDFR event status flag. When RXFCE is set to 1 it indicates that the CRC check result generated on the received data FAILED to match with the 2-octet FCS sequence at the end of the frame. The RXFCE bit is included in the RX double-buffered swinging-set. It is automatically cleared by RX enable. It can also be cleared explicitly by writing a 1 to it. RXFCE events are also counted in Sub-Register

0x2F:0A – FCS Error Counter, as long as counting is enabled by the EVC_EN bit in Sub-Register 0x2F:00 – Event Counter Control.

DW1000 User Manual

Version 2.12

Page 89 of 242

Field

Description of fields within Register file: 0x0F – System Event Status Register

RXRFSL

reg:0F:00

bit:16

Receiver Reed Solomon Frame Sync Loss. The RXRFSL event status bit is set to indicate that the receiver has found a non-correctable error during the Reed Solomon decoding of the data portion of the frame. Generally this means that correct frame reception is not possible, and so typically this event will abort frame reception (depending on the DIS_RSDE configuration in

search (depending on the RXAUTR configuration also in Register file: 0x04 – System

Configuration). Section 4 – Message Reception gives details of the frame reception process.

The RXRFSL bit can be cleared explicitly by writing a 1 to it. It is also automatically cleared by the next receiver enable, including those caused by the RXAUTR auto-re-enable. Reed Solomon Frame Sync Loss Error events are also counted in Sub-Register 0x2F:06 – RSD Error

Counter, as long as counting is enabled by the EVC_EN bit in Sub-Register 0x2F:00 – Event Counter Control.

RXRFTO

reg:0F:00

bit:17

Receive Frame Wait Timeout. This event status bit is set to indicate that a receive frame wait timeout has occurred. The receive frame wait timeout is enabled by the RXWTOE bit in

Register file: 0x04 – System Configuration, with the timeout being set by Register file: 0x0C – Receive Frame Wait Timeout Period. The receive frame wait timeout starts running when the

receiver is enabled and stops running either when a valid frame is received or when the timeout occurs and is signalled by this RXRFTO event status flag bit. The RXRFTO bit is automatically cleared at the next receiver enable. It can also be cleared explicitly by writing a 1 to it. Receive frame wait timeout events are also counted in Sub-Register 0x2F:14 – RX Frame

Wait Timeout Event Counter, as long as counting is enabled by the EVC_EN bit in Sub-Register 0x2F:00 – Event Counter Control.

LDEERR

reg:0F:00

bit:18

Leading edge detection processing error. A large part of the leading edge detection algorithm is a search in the channel impulse response to find the first arriving ray of the RMARKER. This should be bounded and finish in a reasonably short time, but in case not, the LDE includes a failsafe mechanism of a watchdog timer (60 µs) that is initialized at the start of each LDE search (when a good PHR has been detected). We do not expect DW1000 users to ever see this event, however if the watchdog timer expires before the LDE has completed its RX timestamp adjustments then the LDE search will be aborted and the error will be reported by the LDEERR event status flag. The LDEERR bit is automatically cleared at the next receiver enable. It can also be cleared explicitly by writing a 1 to it.

– reg:0F:00

bit:19

This bit is reserved.

RXOVRR

reg:0F:00

bit:20

Receiver Overrun. This event status bit only applies when double RX buffering is enabled (by clearing the DIS_DRXB bit in Register file: 0x04 – System Configuration). The RXOVRR event flag is set to indicate that an overrun error has occurred in the receiver. See section 4.3.5 –

Overrun for more details of double buffering and the use of this RXOVRR error flag. The

RXOVRR event status bit is a READ ONLY bit. It will clear when HRBPT is used to signal the completion of processing for a receiver buffer, freeing that buffer for data reception. Receiver Overrun events are also counted in Sub-Register 0x2F:0E – RX Overrun Error Counter, assuming that counting is enabled by the EVC_EN bit in Sub-Register 0x2F:00 – Event Counter Control.

DW1000 User Manual

Version 2.12

Page 90 of 242

Field

Description of fields within Register file: 0x0F – System Event Status Register

RXPTO

reg:0F:00

bit:21

Preamble detection timeout. This event status bit is set when the preamble detection timeout occurs. The preamble detection timer is started when the receiver is enabled and begins preamble hunt. This may begin immediately in the case of issuing an RXENAB command or after a delay in the case of issuing a RXDLYE command. The preamble detection timeout value is programmed in Sub-Register 0x27:24 – DRX_PRETOC.

The preamble detection timeout may be useful to save power by turning off the receiver if an expected response frame does not begin. If a response message is expected with a certain fixed timing and preamble is not detected at the appropriate time then this is likely to mean that the response will not come. Reception can thus be aborted early, saving power.

The RXPTO bit is automatically cleared at the next receiver enable. It can also be cleared explicitly by writing a 1 to it.

GPIOIRQ

reg:0F:00

bit:22

GPIO interrupt. The GPIOIRQ event status bit is set when an interrupt condition occurs in the GPIO block. Various configurations are possible to enable interrupts coming from GPIO input lines. The GPIO block may need to be interrogated to determine the source of the interrupt if more than one input line is configured to interrupt. The GPIOIRQ bit is cleared by writing a 1 to it. For details of GPIO programming see Register file: 0x26 – GPIO control and status.

SLP2INIT

reg:0F:00

bit:23

SLEEP to INIT. This event status bit is set is set to indicate that the DW1000 has completed the activities associated with awaking from SLEEP (or DEEPSLEEP) and is now in the INIT state. This status bit will NOT activate if the LDE is configured to automatically download on wake up (by setting the ONW_LLDE bit in Register file 0x2C:00-AON_WCFG ), in this case the CPLOCK status bit should be used to indicate that wake up has occurred and the DW1000 is in the IDLE state.

RFPLL_LL

reg:0F:00

bit:24

RF PLL Losing Lock. This event status bit is set is set to indicate that the RFPLL is having locking issues. This should not happen in healthy devices operating in their normal range. Its occurrence may indicate a bad configuration, a faulty part or a problem in the power or clock inputs to the device. If this bit is set it may be advisable to turn off the transmitter to avoid sending signals that are out of regulation. The RFPLL_LL bit is cleared by writing a 1 to it.

CLKPLL_LL

reg:0F:00

bit:25

Clock PLL Losing Lock. This event status bit is set is set to indicate that the system’s digital clock PLL is having locking issues. This should not happen in healthy devices operating in their normal range. Its occurrence may indicate a bad configuration, a faulty part or a problem in the power or clock inputs to the device. If this bit is set it may be advisable to turn off the transmitter to avoid sending spurious signals. The CLKPLL_LL bit is cleared by writing a 1 to it.

Note: The PLLLDT bit in Register file 0x24:00 –EC_CTRL should be set to ensure reliable operation of this CLKPLL_LL bit.

RXSFDTO

reg:0F:00

bit:26

Receive SFD timeout. This event status bit is set when the SFD detection timeout occurs. The SFD detection timeout starts running as soon as preamble is detected. If the SFD sequence is not detected before the timeout period expires then the timeout will act to abort the reception currently in progress. The period of the SFD detection timeout is in Sub-Register

0x27:20 – DRX_SFDTOC. By default this has a value of 4096+64 representing the longest

possible preamble and SFD. Where it is known that a shorter preamble and SFD are being employed this value can be reduced. The RXSFDTO event status bit can be cleared explicitly by writing a 1 to it. It is also automatically cleared by the next receiver enable, including those caused by the RXAUTR auto-re-enable. SFD timeout events are also counted in Sub-Register

0x2F:10 – SFD Timeout Error Counter, assuming that counting is enabled by the EVC_EN bit in Sub-Register 0x2F:00 – Event Counter Control.

DW1000 User Manual

Version 2.12

Page 91 of 242

Field

Description of fields within Register file: 0x0F – System Event Status Register

HPDWARN

reg:0F:00

bit:27

Half Period Delay Warning. This event status bit relates to the use of delayed transmit and delayed receive functionality. It indicates the delay is more than half a period of the system clock.

For delayed send/receive the send/receive time is programmed into Register file: 0x0A –

Delayed Send or Receive Time and then the delayed sending/receiving is initiated by the

TXDLYS/RXDLYE controls in Register file: 0x0D – System Control Register. The delayed transmit and receive functionality is described in detail in sections 3.3 – Delayed Transmission and 4.2 –

Delayed Receive.

The HPDWARN event status flag gets set if the time left to actually beginning transmission / reception is more than half a period of the system clock (Register file: 0x06 – System Time

Counter) away. Assuming that the intent was not to schedule transmission/reception at a

time that is over 8 seconds in the future, the HPDWARN status flag can be polled after the TXDLYS/RXDLYE is commanded, to check whether the delayed send/ receive invocation was given in time (HPDWARN ==0) or not (HPDWARN == 1).

Typically when the HPDWARN event is detected the host controller will abort the delayed TX/RX by issuing a TRXOFF transceiver off command and then take whatever remedial action is deemed appropriate for the application.

The HPDWARN event status flag is READ ONLY. It will clear when the delayed TX/RX is cancelled or when the delay remaining is no longer greater than half a period of the system clock.

HPDWARN events are counted in Sub-Register 0x2F:18 – Half Period Warning Counter, assuming counting is enabled by the EVC_EN bit in Sub-Register 0x2F:00 – Event Counter

Control.

TXBERR

reg:0F:00

bit:28

Transmit Buffer Error. The TXBERR event status flag bit indicates that a write to a transmitted data buffer location has occurred whilst CRC was suppressed. Section 3.5 – High Speed

Transmission describes the DW1000 features for maximising data throughput. One technique

involves writing the frame data to the TX buffer after initiating the transmission of that frame. During this data writing then, CRC sending is temporarily suppressed to protect against sending the wrong data as a good frame (with good CRC). This CRC suppression is cancelled when all the frame data has been written. If the frame data has been written to the buffer in good time then the frame will be sent and a good CRC will be appended. If the data is written late, (i.e. the host writes to the buffer area that is part of the TX frame after the DW1000 has already consumed data from that area), then this is detected and flagged here in this TXBERR event status flag bit. In this case CRC suppression cannot be cancelled (so no CRC is appended). This will prevent transmission of a “bad” data frame with a good CRC. The TXBERR bit is cleared by writing a 1 to it.

AFFREJ

reg:0F:00

bit:29

Automatic Frame Filtering rejection. The AFFREJ event status flag bit is set to indicate when a frame has been rejected in receiver due to it not passing through the frame filtering. See section 5.2 – Frame filtering for details of the operation of frame filtering. The AFFREJ event status bit can be cleared explicitly by writing a 1 to it. It is also automatically cleared by the next receiver enable, including those caused by the RXAUTR auto-re-enable. Frame Filtering rejection events are also counted in Sub-Register 0x2F:0C – Frame Filter Rejection Counter, assuming counting is enabled by the EVC_EN bit in Sub-Register 0x2F:00 – Event Counter

Control.

DW1000 User Manual

Version 2.12

Page 92 of 242

Field

Description of fields within Register file: 0x0F – System Event Status Register

HSRBP

reg:0F:00

bit:30

Host Side Receive Buffer Pointer. This is status flag relating to the operation of the receiver in double-buffered mode. Section 4.3 – Double Receive Buffer describes this operation in detail. Essentially HSRBP is an index indicating which of the buffer pairs the host side is accessing (reading from currently or awaiting to read from when filled by the IC), while ICRBP is an index indicating which of the buffer pairs the IC is accessing (writing to currently or will write to as soon as a frame data arrives). The HSRBP bit is a READ ONLY status bit, its state is changed by issuing the HRBPT command in Register file: 0x0D – System Control Register.

ICRBP

reg:0F:00

bit:31

IC side Receive Buffer Pointer. This is status flag relating to the operation of the receiver in double-buffered mode. Section 4.3 – Double Receive Buffer describes this operation in detail. Essentially ICRBP is an index indicating which of the buffer pairs the IC is accessing (writing to currently or will write to as soon as a frame data arrives). The ICRBP bit is a READ ONLY status bit.

RXRSCS

reg:0F:04

bit:0

Receiver Reed-Solomon Correction Status. This status bit indicates that the Reed-Solomon has corrected at least one error in the frame being received. This is a low-level event status flag. The RXRSCS bit probably not of interest to the host system. It was used during the verification of the Reed-Solomon implementation. The RXRSCS bit cannot be used as an interrupt source. The RXRSCS status bit can be cleared explicitly by writing a 1 to it. It is also automatically cleared by the next receiver enable, including those caused by the RXAUTR auto-re-enable.

RXPREJ

reg:0F:04

bit:1

Receiver Preamble Rejection. This is a low-level event status flag, which is probably not of interest to the host system. It was used during the IC implementation as part of tuning the preamble detection algorithm. In the DW1000, preamble detection a two stage process where preamble is initially seen and then has to be confirmed as continuing for a number of symbols before the RXSFDD event status bit actually gets set. If the preamble is not confirmed then the RXSFDD event status bit will not be set, but instead this RXPREJ status will be set. The RXPREJ bit cannot be used as an interrupt source. The RXPREJ event status bit can be cleared explicitly by writing a 1 to it. It is also automatically cleared by the next receiver enable, including those caused by the RXAUTR auto-re-enable.

TXPUTE

reg:0F:04

bit:2

Transmit power up time error. This is a low-level event status flag. It applies when delayed transmission is being used. Frame transmission will continue if this condition is detected, and the RMARKER will be sent at the correct time, but that the initial few preamble symbols may not transmit correctly. This may have a performance effect when a short preamble sequence is being employed. The TXPUTE event status flag is READ ONLY. It will clear as soon as the DW1000 begins to send preamble, (or if the DW1000 is returned to idle). Since the TX powerup time is only a few symbol times in duration and because the TXPUTE bit clears at the start of preamble, it is unlikely that the host system will see the TXPUTE bit set. The condition therefore should be detected using the event counted in Sub-Register 0x2F:1A – Transmitter

Power-Up Warning Counter, (when counting is enabled by the EVC_EN bit in Sub-Register 0x2F:00 – Event Counter Control).

The delayed transmit and receive functionality is described in detail in sections 3.3 – Delayed

Transmission and 4.2 – Delayed Receive.

– reg:0F:04

bits:7–3

These bits are reserved

DW1000 User Manual

Version 2.12

Page 93 of 242

7.2.18 Register file: 0x10 – RX Frame Information Register

Length

(octets)

Type

Mnemonic

Description

0x10

ROD

RX_FINFO

RX Frame Information - included in swinging set

REG:10:00 – RX_FINFO – RX Frame Information

10 9 8 7 6 5 4 3 2 1 0

RXPACC

RXPSR

RXPRFR

RNG

RXBR

RXNSPL

RXFLE

RXFLEN

0 0 0 0 0 0 0

Field

Description of fields within Register file: 0x10 – RX Frame Information Register

RXFLEN

reg:10:00

bits:6–0

Receive Frame Length. This value is copied from the PHR of the received frame when a good PHR is detected (when the RXPHD status bit is set). The frame length from the PHR is used in the receiver to know how much data to receive and decode, and where to find the FCS (CRC) to validate the received data. The frame length also tells the host system how much data to read from the RX_BUFFER. This field is 7-bits wide to accommodate the standard IEEE 802.15.4 UWB frames which can be up to 127 bytes long. The DW1000 also supports a non-standard mode of operation with data frame lengths up to 1023 octets, where the frame length reported is extended by the RXFLE field.

RXFLE

reg:10:00

bits:9–7

Receive Frame Length Extension. The DW1000 supports a non-standard mode of operation with data frame lengths up to 1023 bytes. This mode of operation is enabled via the PHR_MODE selection bits of Register file: 0x04 – System Configuration. In this long frame mode RXFLE adds three high-order bits to RXFLEN extending it to 10-bits, and allowing frame lengths from 0 up to 1023 bytes be reported. See also section 3.4 – Extended Length Data

Frames.

This value is updated when a good PHR is detected (when the RXPHD status bit is set).

reg:10:00

bit:10

This bit is reserved.

a good PHR, i.e. PHR where the SECDED has not flagged a non-correctable error (see section 10.4).

4.3 – Double Receive Buffer for more details.

Note: During double buffered operation, a receiver overrun condition results in the corruption of this RX_FINFO register 0x10, please refer to section 4.3.3 Operation of double bufferingfor details of the correct be handling of this condition.

This RX_FINFO register contains a number of fields, separately identified and described below:

The individual sub-fields are described below:

DW1000 User Manual

Version 2.12

Page 94 of 242

Field

Description of fields within Register file: 0x10 – RX Frame Information Register

RXNSPL

reg:10:00

bits:12,11

Receive non-standard preamble length. The DW1000 is able to send non-standard preamble lengths to allow system designers more choice in optimising performance. The RXNSPL field operate in conjunction with the RXPSR field to report the received preamble length. The RXPSR field reports the preamble length as signalled in the PHR (see 10.4 for details). The receiver determines additional information about the transmitted preamble length from the count of preamble accumulation, as reported by the RXPACC field, and uses this to set the RXNSPL value.

Table 17 below lists the preamble lengths that can be reported by considering RXNSPL and the RXPSR fields together:

Table 17: preamble length reporting

Bit 19

Bit 18

Bit 12

Bit 11 RXPSR

RXNSPL

RX Preamble Length

0 1 0

128

0 1 1

256

0 1 1

512

1 0 0

1024

1 0 0

1536

1 0 1

2048

1 1 0

4096

The bit numbers quoted above are the bit numbers in the RX_FINFO register.

Where preamble length is not predetermined and hard coded in the application, the received preamble length information may be used to select the preamble length for any response message, by copying RXNSPL and RXPSR fields into the PE and TXPSR configurations respectively. This value is updated when a good PHR is detected (when the RXPHD status bit is set).

RXBR

reg:10:00

bits:14,13

Receive Bit Rate report. This field reports the received bit rate. This information is signalled in the received frame’s PHR (see 10.4 for details). Expected values supported by the DW1000 are: 00 = 110 kbps, 01 =850 kbps, and 10 = 6.8Mbps This value is updated when a good PHR is detected (when the RXPHD status bit is set).

RNG

reg:10:00

bit:15

Receiver Ranging. This reflects the ranging bit in the received PHY header identifying the frame as a ranging packet. This value is updated when a good PHR is detected (when the RXPHD status bit is set).

RXPRFR

reg:10:00

bits:17,16

RX Pulse Repetition Rate report. This field reports the PRF being employed in the receiver. This is simply a copy of the RXPRF configuration from Register file: 0x1F – Channel Control. The values are: 01 = 16 MHz, 10 = 64 MHz

DW1000 User Manual

Version 2.12

Page 95 of 242

Field

Description of fields within Register file: 0x10 – RX Frame Information Register

RXPSR

reg:10:00

bits:19,18

RX Preamble Repetition. This field reports the received frame preamble length as signalled in the frame’s PHR (see 10.4 for details). The values of these two bits are defined by the standard as:

00 = 16 symbols, 01 = 64 symbols, 10= 1024 symbols, and, 11= 4096 symbols

In addition to these standard preamble lengths, the DW1000 also supports the transmission of non-standard preamble lengths. These non-standard lengths cannot be signalled in the PHR; instead the DW1000 gives an estimate of the preamble length based on the RXPSR from the PHR and the RXPACC value. The estimate is reported using RXPSR and RXNSPL fields together as per Table 17above. This value is updated when a good PHR is detected (when the RXPHD status bit is set).

RXPACC

reg:10:00

bits:31–20

Preamble Accumulation Count. This reports the number of symbols of preamble accumulated.

This may be used to estimate the length of TX preamble received and also during diagnostics as an aid to interpreting the accumulator data.

It is possible for this count to be a little larger than the transmitted preamble length, because of very early detection of preamble and because the accumulation count may include accumulation that continues through the SFD (until the SFD is detected). This value is updated when a good PHR is detected (when the RXPHD status bit is set).

The channel accumulation sometimes includes the SFD symbols, all except the last two. Signal power calculations using RXPACC for the number of symbols sometimes need to be adjusted for the SFD symbols accumulated. See section 4.7 for calculations using RXPACC.

The RXPACC counter will saturate when preamble is found by the receiver and the CIRE will stop accumulating symbols. A debug symbol counter which does not saturate is given in

RXPACC_NOSAT. A comparison of RXPACC and RXPACC_NOSAT will indicate that RXPACC

count needs to be adjusted if the two counts are equal. If they are not equal, then RXPACC has saturated before SFD accumulation and therefore the RXPACC value need not be adjusted before use in signal power calculations.

To adjust the RXPACC count for SFD when RXPACC is equal to RXPACC_NOSAT, subtract the number of SFD symbols from the count. Because the SFD sequences contain positive symbols (normal preamble symbols) and negative symbols (symbols which are inverted versions of preamble symbols) which have been added into the channel estimate, add the number of positive symbols and subtract the number of negative symbols in the SFD sequence from the RXPACC count. The last two symbols in the SFD sequence are always ignored in the channel estimate, so these two symbols should not be counted when making adjustments to RXPACC. See Table 18 below for some examples of how to adjust RXPACC when RXPACC and

RXPACC_NOSAT are equal.

Note that the shorter the preamble length, the more impact the SFD correction to RXPACC will have on signal power calculations.

DW1000 User Manual

Version 2.12

Page 96 of 242

Table 18: RXPACC Adjustments by SFD code

SFD

Sequence

Adjustment

to RXPACC

Standard Short (8symbol)

0+0-+00-

-6+2-1=-5

Standard Long (64symbol)

0+0−+00−0+0−+00–00+0−0+0+000−0−0−00+0–0−+0000++00−−−+−++0000++

-62+14-16=64

Decawavedefined 8symbols SFD

----+-00

-6+1-5=-10

Decawavedefined 16symbols SFD

----+-+--++--+00

-14+5-9=-18

Decawavedefined 64symbols SFD

−−−−−−−+−+−−−−−−+−−+−+−−+−−+−−+−−−++−−−+++−+−+−+−−−+−−+−−−−+++00

-62+21-41=82

Length

(octets)

Type

Mnemonic

Description

0x11

1024

ROD

RX_BUFFER

RX Frame Data Buffer – included in swinging set

Length

(octets)

Type

Mnemonic

Description

0x12

ROD

RX_FQUAL

Rx Frame Quality information – included in swinging set

7.2.19 Register file: 0x11 – RX Frame Buffer

the received buffer. Assuming successful reception of a good frame, the full length of received data (as reported by the RXFLEN and RXFLE fields of Register file: 0x10 – RX Frame Information Register), will be available in the RX_BUFFER beginning at offset 0. Note since the reported length includes the FCS the host system will probably choose not to read these final two octets.

Write operations to the RX_BUFFER are NOT supported; a write operation to the RX_BUFFER will corrupt the buffer contents.

Register file: 0x11 – RX Frame Buffer is part of the RX double-buffered swinging-set. See section 4.3 – Double Receive Buffer for more details.

7.2.20 Register file: 0x12 – Rx Frame Quality Information

DW1000 User Manual

Version 2.12

Page 97 of 242

REG:12:00 – RX_FQUAL – Rx Frame Quality Information (Octets 0 to 3, 2x16-bit values)

10 9 8 7 6 5 4 3 2 1 0

FP_AMPL2

STD_NOISE

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 REG:12:04 – RX_FQUAL – Rx Frame Quality Information (Octets 4 to 7, 2x16-bit values)

10 9 8 7 6 5 4 3 2 1 0

CIR_PWR

PP_AMPL3

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Field

Description of fields within Register file: 0x12 – Rx Frame Quality Information

STD_NOISE

reg:12:00

bits:15–0

Standard Deviation of Noise. This is a 16-bit value reporting the standard deviation of the noise level seen during the LDE algorithm’s analysis of the accumulator data. This value can be used in assessing the quality of the received signal and/or the receive timestamp produced by the LDE. For more details please refer to section 4.7 – Assessing the quality of reception and

the RX timestamp.

FP_AMPL2

reg:12:00

bits:31–16

First Path Amplitude point 2. This is a 16-bit value that is part of reporting the magnitude of the leading edge signal seen in the accumulator data memory during the LDE algorithm’s analysis. The amplitude of the sample reported in the FP_AMPL2 parameter is the magnitude of the accumulator tap at the index 2 beyond the integer portion of the rising edge FP_INDEX reported in Register file: 0x15 – Receive Time Stamp. The FP_AMPL2 amplitude value can be used, in conjunction with the FP_AMPL3 value below and the FP_AMPL1 value reported in

timestamp produced by the LDE algorithm. For more details please refer to section 4.7 –

Assessing the quality of reception and the RX timestamp.

FP_AMPL3

reg:12:04

bits:15–0

First Path Amplitude point 3. This is a 16-bit value that is part of reporting the magnitude of the leading edge signal seen in the accumulator data memory during the LDE algorithm’s analysis. The amplitude of the sample reported in the FP_AMPL3 parameter is the magnitude of the accumulator tap at the index 1 beyond the integer portion of the rising edge FP_INDEX reported in Register file: 0x15 – Receive Time Stamp. This amplitude value can be used in assessing the quality of the received signal and/or the receive timestamp produced by the LDE. For more details please refer to section 4.7 – Assessing the quality of reception and the RX

timestamp.

The FP_AMPL3 amplitude value can be used, in conjunction with the FP_AMPL2 value above and the FP_AMPL1 value reported in Register file: 0x15 – Receive Time Stamp, as part of assessing the quality of the receive timestamp produced by the LDE algorithm. For more details please refer to section 4.7 – Assessing the quality of reception and the RX timestamp.

4.3 – Double Receive Buffer for more details.

The RX_FQUAL register contains the following sub-fields:

The sub-fields of Register file: 0x12 – Rx Frame Quality Information are described below and are updated when the LDE execution has completed successfully (when the LDEDONE status bit is set):

DW1000 User Manual

Version 2.12

Page 98 of 242

Field

Description of fields within Register file: 0x12 – Rx Frame Quality Information

CIR_PWR

reg:12:04

bits:31–16

Channel Impulse Response Power. This is a 16-bit value reporting the sum of the squares of the magnitudes of the accumulator from the estimated highest power portion of the channel, which is related to the receive signal power. This value can be used in assessing the quality of the received signal and/or the receive timestamp produced by the LDE algorithm. For more details please refer to section 4.7 – Assessing the quality of reception and the RX timestamp.

Length

(octets)

Type

Mnemonic

Description

0x13

ROD

RX_TTCKI

Receiver Time Tracking Interval- included in swinging set

REG:13:00 – RX_TTCKI – Receiver Time Tracking Interval

10 9 8 7 6 5 4 3 2 1 0

RXTTCKI

Field

Description of fields within Register file: 0x13 – Receiver Time Tracking Interval

RXTTCKI

reg:13:00

bits:31–0

RX time tracking interval. The value here is the interval over which the timing offset reported in the RXTOFS field of Register file: 0x14 – Receiver Time Tracking Offset is measured. The clock offset is calculated by dividing RXTOFS by RXTTCKI. The value in RXTTCKI will take just one of two values depending on the PRF: 0x01F00000 @ 16 MHz PRF, and 0x01FC0000 @ 64 MHz PRF.

Length

(octets)

Type

Mnemonic

Description

0x14

ROD

RX_TTCKO

Receiver Time Tracking Offset- included in swinging set

7.2.21 Register file: 0x13 – Receiver Time Tracking Interval

measure of the clock offset (or crystal offset) between the local receiver and the remote end transmitter device.

4.3 – Double Receive Buffer for more details.

The RX_TTCKI register contains the following sub-fields which are updated when a frame demodulation is completed successfully:

7.2.22 Register file: 0x14 – Receiver Time Tracking Offset

measure of the clock offset (or crystal offset) between the local receiver and the remote end transmitter device.

DW1000 User Manual

Version 2.12

Page 99 of 242

REG:14:00 – RX_TTCKO – Receiver Time Tracking Offset (Octets 0 to 3, 32-bits)

10 9 8 7 6 5 4 3 2 1 0

RSMPDEL

- - - - -

RXTOFS

- - - - -

REG:14:04 – RX_TTCKO – Receiver Time Tracking Offset (Octet 4, 8-bits)

7 6 5 4 3 2 1

RCPHASE

Field

Description of fields within Register file: 0x14 – Receiver Time Tracking Offset

RXTOFS

reg:14:00

bits:18–0

RX time tracking offset. The value here is the offset measured over the interval reported in the RXTTCKI field of Register file: 0x13 – Receiver Time Tracking Interval. This RXTOFS value is a 19-bit signed quantity. The clock offset is calculated by dividing RXTOFS by RXTTCKI

Example (a): Say RXTOFS is reported as 0x000e4, and RXTTCKI is 0x01f00000 then this gives a clock offset of 228 ÷ 32505856, which is 7.014E-06 or 7 ppm offset. So, the remote transmitter’s clock is running faster than the local receiver’s clock by this 7 ppm amount.

Example (b): Say RXTOFS is reported as 0x7FF5C, and RXTTCKI is 0x01f00000 then this gives a clock offset of -164 ÷ 32505856, which is -5.045E-06 or -5 ppm offset. So, the remote transmitter’s clock is running slower than the local receiver’s clock by this 5 ppm amount.

Bits marked ‘-’ are reserved and should always be written as zero.

RSMPDEL

reg:14:00

bits:31–24

This 8-bit field reports an internal re-sampler delay value. This is not expected to be of any direct use to the host system. It was of interest in the past during the development of the IC receiver and the leading edge determination algorithm.

RCPHASE

reg:14:04

bits:6–0

This 7-bit field reports the receive carrier phase adjustment at time the ranging timestamp is made. This gives the phase (7 bits = 360 degrees) of the internal carrier tracking loop at the time that the RX timestamp is received. This can be used to partially compensate for the phase offset in the CIR’s between two DW1000 devices.

Length

(octets)

Type

Mnemonic

Description

0x15

ROD

RX_TIME

Receive Time Stamp- included in swinging set

4.3 – Double Receive Buffer for more details.

The RX_TTCKO register contains the following sub-fields which are updated when a frame demodulation is completed successfully:

The individual sub-fields are described below:

7.2.23 Register file: 0x15 – Receive Time Stamp

reception the SFD detection event marking the end of the preamble and the start of the PHR is the nominal point which is time-stamped by the IC. The IEEE 802.15.4 UWB standard calls this point the RMARKER.

DW1000 User Manual

Version 2.12

Page 100 of 242

DW1000 takes a coarse timestamp of the symbol in which the RMARKER event occurs and to this adds

REG:15:00 – RX_TIME – Receive Time Stamp (Octets 0 to 3, 32-bits)

10 9 8 7 6 5 4 3 2 1 0

RX_STAMP (low 32 bits of 40-bit value)

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 REG:15:04 – RX_TIME – Receive Time Stamp (Octets 4 to 7, 32-bits)

10 9 8 7 6 5 4 3 2 1 0

FP_AMPL1 (low 8 bits of 16)

FP_INDEX

RX_STAMP (high 8 bits of 40)

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 REG:15:08 – RX_TIME – Receive Time Stamp (Octets 8 to 11, 32-bits)

10 9 8 7 6 5 4 3 2 1 0

RX_RAWST (low 24 bits of 40-bit value)

FP_AMPL1 (high 8-bits of 16)

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 REG:15:0C – RX_TIME – Receive Time Stamp (Octets 12 to 13, 16-bits)

10 9 8 7 6 5 4 3 2 1 0

RX_RAWST (high 16 bits of 40-bit value)

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Field

Description of fields within Register file: 0x15 – Receive Time Stamp

RX_STAMP

reg:15:00

bits:39–0

This 40-bit (5-octet) field reports the. The fully adjusted time of reception. Please refer to section 4.1.6 – RX Message timestamp for more details of the adjustments applied. The units of the low order bit are approximately 15.65 picoseconds. The actual unit may be calculated as 1/ (128*499.2×106) seconds. The value is available here when the leading edge determination and timestamp adjustments are completed (when the LDEDONE status bit is set).

various correction factors to give a resultant time stamp value. Please refer to section 4.1.6 – RX Message

timestamp for more details of the corrections applied.

Register file: 0x15 – Receive Time Stamp is in the RX double-buffered swinging-set. See section 4.3 – Double Receive Buffer for more details.

The RX_TIME register contains the following sub-fields:

The sub fields of Register file: 0x15 – Receive Time Stamp are laid out above in a map that is 32 bits wide, however some parameters are larger than 32 bits. It is possible to read a variable number of bytes any byte index and it is also possible to read the whole register file in a single block SPI read. The individual sub-fields are described below:

decaWave DW1000 User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

List of Figures

List of Tables

1 Introduction

1.1 About the DW1000

1.2 About this document

2 Overview of the DW1000

2.1 Introduction

2.2 Interfacing to the DW1000

2.2.1 The SPI Interface

2.2.1.1 SPI operating modes

2.2.1.2 Transaction formats of the SPI interface

2.2.1.2.1 SPI transaction with a 2-octet header

2.2.1.2.2 SPI transaction with a 3-octet header

2.2.2 Interrupts

2.2.3 General Purpose I/O

2.2.4 The SYNC pin

2.3 DW1000 Operational States

2.3.1 State diagram

2.3.2 Overview of main operational states

2.4 Power On Reset (POR)

2.4.1 SLEEP and DEEPSLEEP

2.4.1.1 Waking from sleep

2.4.1.2 Configuration register preservation

2.4.1.3 Automatically loading LDO calibration data from the OTP

2.4.2 Specific state sequences supported by the DW1000

2.5 Default Configuration on Power Up

2.5.1 Default System Configuration

2.5.2 Default Channel Configuration

2.5.3 Default Transmitter Configuration

2.5.4 Default Receiver Configuration

2.5.5 Default Configurations that should be modified

2.5.5.1 AGC_TUNE1

2.5.5.2 AGC_TUNE2

2.5.5.3 DRX_TUNE2

2.5.5.4 NTM

2.5.5.5 LDE_CFG2

2.5.5.6 TX_POWER

2.5.5.7 RF_TXCTRL

2.5.5.8 TC_PGDELAY

2.5.5.9 FS_PLLTUNE

2.5.5.10 LDELOAD

2.5.5.11 LDOTUNE

3 Message Transmission

3.1 Basic Transmission

3.2 Transmission timestamp

3.3 Delayed Transmission

3.4 Extended Length Data Frames

3.5 High Speed Transmission

3.5.1 TX buffer offset index

3.5.2 TX buffer write while sending or receiving

4 Message Reception

4.1 Basic Reception

4.1.2 Preamble Accumulation

4.1.3 SFD Detection

4.1.4 PHR Demodulation

4.1.5 Data Demodulation

4.1.6 RX Message timestamp

4.2 Delayed Receive

4.3 Double Receive Buffer

4.3.1 Enabling double-buffered operation

4.3.2 Controlling which buffer is being accessed

4.3.3 Operation of double buffering

4.3.4 TRXOFF when using Double Buffering

4.3.5 Overrun

4.4 Low-Power Listening

Figure 16: Low power listening with two sleep times

Figure 17: Power profile for low power listening mode where no frame is received

4.4.1 Configuring low-power listening

4.5 Low-Power SNIFF mode

4.5.1 SNIFF mode

Figure 19: Power profile for SNIFF where a frame is not received

Figure 20: Power profile for SNIFF where a frame is received

4.5.2 Low duty-cycle SNIFF mode

4.6 Diagnostics

4.7 Assessing the quality of reception and the RX timestamp

4.7.1 Estimating the signal power in the first path