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.
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.
Gives an overview of the DW1000, describes how to interface
to the device and details its various operating modes
3
Message Transmission
Describes the functionality and use of the DW1000 transmitter
4
Message Reception
Describes the functionality and use of the DW1000 receiver
5
Media Access Control (MAC)
hardware features
Describes the MAC level functionality provided in hardware by
the DW1000.
6
Other features of the DW1000
Describes other features supported by the DW1000
7
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.
8
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: -
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
10
APPENDIX 1: The IEEE 802.15.4
UWB physical layer
Provides background information on the UWB PHY layer of the
IEEE802.15.4 standard
11
APPENDIX 2: The IEEE 802.15.4
MAC layer
Provides background information on the MAC layer of the
IEEE802.15.4 standard
12
APPENDIX 3: Two-Way Ranging
Gives an introduction to the use of the DW1000 in two-way
ranging proximity systems
13
APPENDIX 4: Abbreviations and
acronyms
Provides a list and explanation of abbreviations and acronyms
used in the rest of the document
14
APPENDIX 5: References
Lists the documents referred to in this user manual
15
Document History
Gives the revision history of this document
16
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.
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
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
Host should ignore
MOSI
MISO
Write
Transaction Body
–
read data output by DW
1000
ignored by DW
1000
SPICSn
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.
Figure 2: Single octet header of the non-indexed SPI transaction
76543210
Operation:
0 = Read
1 = Write
Bit = 0, says
sub-index is
not present
Register file ID – Range 0x00 to 0x3F (64 locations)
Bit number:
Meaning:
Transaction Header
Octet
76543210
Operation:
0 = Read
1 = Write
Bit = 1, says
sub-index is
present
Register file ID – Range 0x00 to 0x3F (64 locations)
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
0x00
0x300x
010xCA
0
xDE
Non sub indexed read from register
file ID
0x00
,
this
32-bit register
contains the Device ID
,
the4-
octet
result is
0
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.
Register file ID – Range 0x00 to 0x3F (64 locations)
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
0
xC90
xB60x020xA
5
Long sub indexed write of octet value
0
xA
5
to the transmit buffer
(
Reg ID
0x09
)
at index
310
(0x
136
in hex
)
MOSI
MISO
SPICSn
0x400x
02
0
xCA
0
xDE
Short sub
-
indexed read
2-octets beginning at
index
2
in register file ID
0x00
.
This reads the
high two octets of this
32-bit register
,
the
result is
0
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
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.
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.
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
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.
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 WAKEUPpin 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-
Register 0x2C:06 – AON_CFG0 along with an appropriate SLEEP_TIM).
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 mustnot be set.
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
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). Further details of this mode are given in
section 4.5.2 – Low duty-cycle SNIFF.
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
16
128
12
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
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
Register.
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.
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.
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.
Table 4: Register accesses required to load LDE microcode
Step
Number
Instruction
Register
Address
Data
Length
(Bytes)
Data
(Write/Read)
L-1
Write Sub-Register
0x36:00 (PMSC_CTRL0)
2
0x0301
L-2
Write Sub-Register
0x2D:06 (OTP_CTRL)
2
0x8000
Wait 150 µs
L-3
Write Sub-Register
0x36:00 (PMSC_CTRL0)
2
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
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
Register. After transmission has been requested, the DW1000
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
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
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
Register file: 0x0D – System Control Register.
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
operating with standard frame encoding because the SECDED error check sequence of the PHR in long frame
P0
Preamble length for
BPM-BPSK modulation
mode
0
64 to 1024 symbols
1
1536 to 4096 symbols
Bit
0
123456789101112131414161718
R1R0L9L8L7L6L5L4L3L2L1L0P0 S5S4S3S2S1S0
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
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 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
Register).
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
Register file: 0x0D – System Control Register to initiate the transmission. This will kick off preamble
transmission.
(c) Write the frame data to the TX_BUFFER as fast as possible.
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
Register file: 0x0D – System Control Register. Assuming that the host has written every octet of data
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).
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
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
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
RXSFDTO (SFD timeout). For details on how to apply a receiver-only reset see SOFTRESET field ofSub-
Register 0x36:00 – PMSC_CTRL0.
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.
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 FrameBuffer
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
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.
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
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
not return to sleep but continues to receive preamble and the data frame, and after successful reception can
PreambleSFD PHR DATA
IFS
PreambleSFD PHR DATA
IFS
PreambleSFD
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
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,
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)
Y
N
N
This loop will continue
until preamble
detection or an RX
end event occurs
RX
(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
should always be 1 less than the desired total. The off duration is programmed in units of 1 µs. When both
RX
IDLE
INIT
GO2SLP
Sample Wakeup Event:
Sleep counter expires
SLEEPSLEEP
Frame Wait Timeout,
Host RX End.
WAKEUP
CLKPLL locked
Crystal stable,
RSTn=1
RXRX
IDLEIDLEIDLE
Configure RX Sniff Mode
Sniff On Time
(in PACs)
Sniff Off Time
(in uS)
RX
IDLE
INIT
Sample Wakeup Event:
Sleep counter expires
SLEEP
Interrupt Set
RX OK
WAKEUP
CLKPLL locked
Crystal stable,
RSTn=1
RX
(demod)
IDLE
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.
NOTE: In the INIT state the 125 MHz digital PLL clock is not running, instead the system is clocked at the raw
RX
IDLE
INIT
GO2SLP
Sample Wakeup Event:
Sleep counter expires
SLEEPSLEEP
Frame Wait Timeout,
Host RX End.
WAKEUP
CLKPLL locked
Crystal stable,
RSTn=1
RX
Configure RX Sniff Mode
Sniff On Time
(in PACs)
Sniff Off Time
(in 19.2MHz cycles)
INIT
IDLE
INIT
RX
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.
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.
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.
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:
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
oOr 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
Register file: 0x03 – PAN Identifier and Short Address, (or be 0xFFFF)
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.
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
Register.
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
Register file: 0x10 – RX Frame Information Register). This only covers preamble lengths defined in the IEEE
802.14.4 standard, but the DW1000 supports other preamble lengths. To cope with this the DW1000 selects
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
64
Less than 65
64
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
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.
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,
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.
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
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
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).
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.
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:
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.
2
is the time in ns reported by EC_GOLP in the OFFSET_EXT field, see Sub-Register 0x24:08
1
EC_GOLP.
T
the leading path delay, calculated by subtracting the raw receive timestamp from the
3
receive timestamp, the difference between these will give the leading path delay, see
Register file: 0x15 – Receive Time Stamp.
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.
(These 64 bits get automatically copied over to Register File 0x01:EUI on each reset.)
Customer
0x001
4
0x002
4
Alternative 64bit EUID
Customer
0x003
4
0x004
4
40 bit LDOTUNE_CAL
(These 40 bits can be automatically copied over to Sub Register File 0x28:30 LDOTUNE
on wakeup)
Decawave Test
0x005
1
0x006
4
{“0001,0000,0000“, "CHIP ID (20 bits)"}
Decawave Test
0x007
4
{“0001”“, "LOT ID (28 bits)"}
DecawaveTest
0x008 2 -
-
V
meas
@ 3.7 V
V
meas
@ 3.3 V
DecawaveTest
0x009
1 / 1 - -
T
meas
@ Ant Cal
T
meas
@ 23 °C
Customer / Deca-
wave Test
0x00A
0
-
Reserved
0x00B
4
-
Reserved
0x00C
2
-
Reserved
0x00D
4
-
Reserved
0x00E
4
-
Reserved
0x00F
4
-
Reserved
0x010
4
CH1 TX Power Level PRF 16
Customer
0x011
4
CH1 TX Power Level PRF 64
Customer
0x012
4
CH2 TX Power Level PRF 16
Customer
0x013
4
CH2 TX Power Level PRF 64
Customer
0x014
4
CH3 TX Power Level PRF 16
Customer
0x015
4
CH3 TX Power Level PRF 64
Customer
0x016
4
CH4 TX Power Level PRF 16
Customer
0x017
4
CH4 TX Power Level PRF 64
Customer
0x018
4
CH5 TX Power Level PRF 16
Customer
0x019
4
CH5 TX Power Level PRF 64
Customer
0x01A
4
CH7 TX Power Level PRF 16
Customer
0x01B
4
CH7 TX Power Level PRF 64
Customer
0x01C
4
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
4
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.
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.
2
Reserved. Defaults to “0”. If programming the OTP_SRDATA register these bits must be set to “0”
1
SPI_SR_PH. Set SPI Phase mode to this value if bits [4:3] are set to “01”
0
SPI_SR_POL. Set SPI Polarity mode to this value if bits [4:3] are set to “01”
Step
Number
Instruction
Register
Address
Data
Length
(Bytes)
Data
(Write/Read)
Configure OTP for Programming – Stage 1:
C-1
Write Sub-Register
0x36:00 (PMSC_CTRL0)
1
0x01
C-2
Write Sub-Register
0x2D:07 (OTP_CTRL+1)
1
0x03
C-3
Write Sub-Register
0x2D:00 (OTP_WDAT)
2
0x9220
C-4
Write Sub-Register
0x2D:06 (OTP_CTRL)
1
0x08
Wait 1ms C-5
Write Sub-Register
0x2D.07 (OTP_CTRL+1)
1
0x02
C-6
Write Sub-Register
0x2D:06 (OTP_CTRL)
1
0x88
C-7
Write Sub-Register
0x2D:06 (OTP_CTRL)
1
0x80
C-8
Write Sub-Register
0x2D:06 (OTP_CTRL)
1
0x00
Configure OTP for Programming – Stage 2:
C-9
Write Sub-Register
0x2D:07 (OTP_CTRL+1)
1
0x05
C-10
Write Sub-Register
0x2D:00 (OTP_WDAT)
2
0x000E
C-11
Write Sub-Register
0x2D:06 (OTP_CTRL)
1
0x08
Wait 1ms
C-12
Write Sub-Register
0x2D.07 (OTP_CTRL+1)
1
0x04
C-13
Write Sub-Register
0x2D:06 (OTP_CTRL)
1
0x88
C-14
Write Sub-Register
0x2D:06 (OTP_CTRL)
1
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
Programming a single 32 bit word <DATA> to address <ADDR>:
P-1
Write Sub-Register
0x2D:06 (OTP_CTRL)
1
0x00
P-2
Write Sub-Register
0x2D:00 (OTP_WDAT)
4
<DATA[31:0]>
P-3
Write Sub-Register
0x2D:04 (OTP_ADR)
2
<ADDR[10:0]>
P-4
Write Sub-Register
0x2D:06 (OTP_CTRL)
1
0x40
P-5
Write Sub-Register
0x2D:06 (OTP_CTRL)
1
0x00
Wait 1 ms before reading back to verify
Step
Number
Instruction
Register
Address
Data
Length
(Bytes)
Data
(Write/Read)
1
Write Register
0x2D:04 (OTP_ADDR)
2
OTP Address
2
Write Sub-Register
0x2D:06 (OTP_CTRL)
1
0x03
3
Write Sub-Register
0x2D:06 (OTP_CTRL)
1
0x00
4
Read Register
0x2D:0A (OTP_RDAT)
4
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
power supply input. These readings can be manually run under host control, or they can be configured to be
Step
Number
Instruction
Register
Address
Data Length
(Bytes)
Data
(Write/Read)
1
Write Sub-Register
28:11
1
0x80
2
Write Sub-Register
28:12
1
0x0A
3
Write Sub-Register
28:12
1
0x0F
4
Write Register
2A:00
1
0x01
5
Write Register
2A:00
1
0x00
6
Read Register
2A:03
1
8-bit Voltage reading
7
Read Register
2A:04
1
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:
Device Identifier – includes device type and revision info
0x01
8
RW
EUI
Extended Unique Identifier
0x02 - - - Reserved
0x03
4
RW
PANADR
PAN Identifier and Short Address
0x04
4
RW
SYS_CFG
System Configuration bitmap
0x05 - - - Reserved
0x06
5
RO
SYS_TIME
System Time Counter (40-bit)
0x07 - - - Reserved
0x08
5
RW
TX_FCTRL
Transmit Frame Control
0x09
1024
WO
TX_BUFFER
Transmit Data Buffer
0x0A
5
RW
DX_TIME
Delayed Send or Receive Time (40-bit)
0x0B - - - Reserved
0x0C
2
RW
RX_FWTO
Receive Frame Wait Timeout Period
0x0D
4
SRW
SYS_CTRL
System Control Register
0x0E
4
RW
SYS_MASK
System Event Mask Register
0x0F
5
SRW
SYS_STATUS
System Event Status Register
0x10
4
ROD
RX_FINFO
RX Frame Information
(in double buffer set)
0x11
1024
ROD
RX_BUFFER
Receive Data
(in double buffer set)
0x12
8
ROD
RX_FQUAL
Rx Frame Quality information
(in double buffer set)
0x13
4
ROD
RX_TTCKI
Receiver Time Tracking Interval
(in double buffer set)
0x14
5
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.
<bits or bit-fields identified by a quoted mnemonic>
<default power-on-reset values are quoted as bits or values>
ID
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 map register file 0x00 is the device identifier. This is hard-coded into the silicon. The value in this
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.
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.
Extended Unique Identifier – the 64-bit IEEE device address
REG:01:00 – EUI – Extended Unique Identifier
7 6 5 4 3 2 1
0
Octet Index
Description
0xHH
0
Bits 7 to 0 of the extension identifier
0xHH
1
Bits 15 to 8 of the extension identifier
0xHH
2
Bits 23 to 16 of the extension identifier
0xHH
3
Bits 31 to 24 of the extension identifier
0xHH
4
Bits 39 to 32 of the extension identifier
0xNN
5
Bits 7 to 0 of the OUI (manufacturer company ID)
0xNN
6
Bits 15 to 8 of the OUI (manufacturer company ID)
0xNN
7
Bits 23 to 16 of the OUI (manufacturer company ID)
Register map register file 0x01 is the Extended Unique Identifier register. For IEEE 802.15.4 compliance
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:
Register file: 0x2D – OTP Memory Interface overview gives an overview of OTP contents and addresses.
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:
The ordering of octets read from the Extended Unique Identifier register is designed to be directly
ID
Length
(octets)
Type
Mnemonic
Description
0x02 - - - Reserved – this register file is reserved
ID
Length
(octets)
Type
Mnemonic
Description
0x03
4
RW
PANADR
PAN Identifier and Short Address
REG:03:00 –PANADR – PAN Identifier and Short Address
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10 9 8 7 6 5 4 3 2 1 0
PAN_ID
SHORT_ADDR
0xFFFF
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
Register map register file 0x02 is reserved for future use. Please take care not to write to this register as
doing so may cause the DW1000 to malfunction.
7.2.5 Register file: 0x03 – PAN Identifier and Short Address
Register map register file 0x03 contains two 16-bit parameters, the PAN Identifier and the 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:
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.
ID
Length
(octets)
Type
Mnemonic
Description
0x04
4
RW
SYS_CFG
System Configuration bitmap
REG:04:00 – SYS_CFG – System Configuration bit map
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
Register map register file 0x04 is the system configuration register. This is a bitmapped register. Each bit
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: -
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.
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.
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.
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.
ID
Length
(octets)
Type
Mnemonic
Description
0x05 - - - Reserved – this register file is reserved
7.2.7 Register file: 0x05 – Reserved
Register map register file 0x05 is reserved for future use. Please take care not to write to this register as
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.
ID
Length
(octets)
Type
Mnemonic
Description
0x07 - - - Reserved – this register file is reserved
ID
Length
(octets)
Type
Mnemonic
Description
0x08
5
RW
TX_FCTRL
Transmit Frame Control
REG:08:00 – TX_FCTRL – Transmit Frame Control (Octets 0 to 3, 32-bits)
Register map register file 0x06 is the System Time Counter register. System time and time stamps are
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
Register map register file 0x07 is reserved for future use. Please take care not to write to this register as
doing so may cause the DW1000 to malfunction.
7.2.10 Register file: 0x08 – Transmit Frame Control
Register map register file 0x08, the transmit frame control register, contains a number of TX control fields.
Each field is separately identified and described below. (For a general discussion of transmission please refer
to section 3 – Message Transmission.
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.
R
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
TR
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.
(c) The DW1000 receiver does not support the 4 MHz PRF.
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.
PE
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
PE
Preamble Length
0 1 0
0
64
0 1 0
1
128
0 1 1
0
256
0 1 1
1
512
1 0 0
0
1024
1 0 0
1
1536
1 0 1
0
2048
1 1 0
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.
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.
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.
ID
Length
(octets)
Type
Mnemonic
Description
0x09
1024
WO
TX_BUFFER
Transmit Data Buffer
ID
Length
(octets)
Type
Mnemonic
Description
0x0A
5
RW
DX_TIME
Delayed Send or Receive Time (40-bit)
7.2.11 Register file: 0x09 – Transmit Data Buffer
Register map register file 0x09 is the transmit data buffer. Data from the transmit buffer is transmitted
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
Register file: 0x0D – System Control Register.
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
Register map register file 0x0A, the Delayed Send or Receive Time, is used to specify a time in the future to
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
Refer to the TX_PSTM field of Sub-Register 0x2F:24 – Digital Diagnostics Test Mode Control for details of
ID
Length
(octets)
Type
Mnemonic
Description
0x0B - - - Reserved – this register file is reserved
ID
Length
(octets)
Type
Mnemonic
Description
0x0C
2
RW
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
Register map register file 0x0B is reserved for future use. Please take care not to write to this register as
doing so may cause the DW1000 to malfunction.
7.2.14 Register file: 0x0C – Receive Frame Wait Timeout Period
Register map register file 0x0C is the receive frame wait timeout period. The receive frame wait timeout
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.
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.
ID
Length
(octets)
Type
Mnemonic
Description
0x0D
4
SRW
SYS_CTRL
System Control Register
REG:0D:00 – SYS_CTRL – System Control
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
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
Register file: 0x0C – Receive Frame Wait Timeout Period contains the following fields:
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
Register map register file 0x0D is the system control register and contains a number of TX control fields. Each
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.
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.
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.
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.
ID
Length
(octets)
Type
Mnemonic
Description
0x0E
4
RW
SYS_MASK
System Event Mask Register
7.2.16 Register file: 0x0E – System Event Mask Register
Register map register file 0x0E is the system event mask register. These are aligned with the event status
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:
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:
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.
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.
ID
Length
(octets)
Type
Mnemonic
Description
0x0F
5
SRW
SYS_STATUS
System Event Status Register
REG:0F:00 – SYS_STATUS – System Status Register (octets 0 to 3)
7.2.17 Register file: 0x0F – System Event Status Register
Register map register file 0x0F is the system event status register, SYS_STATUS. It contains status bits that
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:
REG:0F:04 – SYS_STATUS – System Status Register (octet 4)
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10 9 8 7 6 5 4 3 2 1 0
- - - - -
TXPUTE
RXPREJ
RXRSCS
0 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:
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.
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.
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
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). 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.
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.
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
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
7.2.18 Register file: 0x10 – RX Frame Information Register
ID
Length
(octets)
Type
Mnemonic
Description
0x10
4
ROD
RX_FINFO
RX Frame Information - included in swinging set
REG:10:00 – RX_FINFO – RX Frame Information
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
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 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.
Register map register file 0x10 gives information on the received frame. It is updated after the reception of
a good PHR, i.e. PHR where the SECDED has not flagged a non-correctable error (see section 10.4).
Register file: 0x10 – RX Frame Information Register is in the RX double-buffered swinging-set. See section
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:
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
0
64
0 1 0
1
128
0 1 1
0
256
0 1 1
1
512
1 0 0
0
1024
1 0 0
1
1536
1 0 1
0
2048
1 1 0
0
4096
The bit numbers quoted above are the bit numbers in the RX_FINFOregister.
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
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:
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.
Rx Frame Quality information – included in swinging set
7.2.19 Register file: 0x11 – RX Frame Buffer
Register map register file 0x11 is the receive data buffer. The data from the received frame is available in
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
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
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.
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.
register consists of a number of sub-fields separately identified and described below:
Register file: 0x12 – Rx Frame Quality Information is in the RX double-buffered swinging-set. See section
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):
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.
ID
Length
(octets)
Type
Mnemonic
Description
0x13
4
ROD
RX_TTCKI
Receiver Time Tracking Interval- included in swinging set
REG:13:00 – RX_TTCKI – Receiver Time Tracking Interval
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10 9 8 7 6 5 4 3 2 1 0
RXTTCKI
0
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.
ID
Length
(octets)
Type
Mnemonic
Description
0x14
5
ROD
RX_TTCKO
Receiver Time Tracking Offset- included in swinging set
7.2.21 Register file: 0x13 – Receiver Time Tracking Interval
Register map register file 0x13 operates with Register file: 0x14 – Receiver Time Tracking Offset to give a
measure of the clock offset (or crystal offset) between the local receiver and the remote end transmitter
device.
Register file: 0x13 – Receiver Time Tracking Interval is in the RX double-buffered swinging-set. See section
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
Register map register file: 0x14 operates with Register file: 0x13 – Receiver Time Tracking Interval to give a
measure of the clock offset (or crystal offset) between the local receiver and the remote end transmitter
device.
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.
ID
Length
(octets)
Type
Mnemonic
Description
0x15
14
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
Register map register file 0x15 reports the receive time stamp and related information. 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 calls this point the RMARKER.
0 REG:15:0C – RX_TIME – Receive Time Stamp (Octets 12 to 13, 16-bits)
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
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
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:
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.