DW3000 USER MANUAL

DW3000 FAMILY USER MANUAL

HOW TO USE, CONFIGURE AND CONTROL THE DW3000 UWB TRANSCEIVER

This document is subject to change without notice

Table of Contents

ABOUT DECAWAVE ........................................255

List of Figures

List of Tables

DOCUMENT INFORMATION

Disclaimer

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

Copyright © 2019 Decawave Ltd

LIFE SUPPORT POLICY

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

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

REGULATORY APPROVALS

The DW3000, 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 DW3000 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.

1 Introduction

1.1 About the DW3000

The DW3000 is a family of fully integrated low power, single chip CMOS radio transceivers IC implementing HRP UWB PHY as specified by the IEEE802.15.4 standard [1], including the BPRF mode specified by the IEEE802.15.4z amendment [2]. There are currently two versions a non-PDoA and an PDoA device with 0xDECA0302 and 0xDECA0312 device identifiers respectively.

• Supports UWB channels 5 and 9 (6489.6 MHz and 7987.2 MHz)
• Supports 2-way ranging, TDoA and optionally PDoA location schemes
• Low external component count
• Supports enhanced Time-of-Flight security modes
• Integrated AES CCM* and AES GCM 128/192/256 functionality
• Worldwide UWB Radio Regulatory compliance
• Low power consumption (suitable for coin cell battery powered applications)
• Data rates of 850 kb/s, and 6.8 Mb/s.
• Packet length from zero to 1023 octets.
• Integrated MAC support features
• Up to 38 MHz SPI interface to host MCU
• Provides precision location and data transfer simultaneously
• Asset location to an accuracy of 10 cm
• High multipath fading immunity
• Supports high tag densities in RTLS
• • QFN40 (5mm x 5 mm) and WLCSP52 (3.1 mm x 3.5 mm) package options

Table 1: DW3000 variants

1.2 About this document

This user manual describes the operation and programming of the DW3000 and discusses some of the design choices to be considered when implementing systems using it. Information already contained in the DW3000 Datasheet is not reproduced here and it is intended that the reader should use this user manual in conjunction with the DW3000 Datasheet. The document is divided into a number of sections each of which deals with a particular aspect of the DW3000 as follows: -

Table 2: Brief description of document sections

Decawave also provides DW3000 device driver software as source code. This source code includes a set of API functions to initialise, configure and control the DW3000. It provides API functions for transmission and reception, and for driving the functionalities of the IC. The DW3000 driver source code is targeted for the ARM Cortex-M but is readily portable to other microprocessor systems. The API code comes with a number of simple examples that exercise the API and show how to use various features of the DW3000, including an example of two-way ranging [3].

2 Overview of the DW3000

2.1 Introduction

The DW3000 consists of an analog front-end (both RF and baseband) containing a receiver and transmitter and a digital back-end. The latter 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.

2.2 Comparison and compatibility with DW1000

The main differences to DW1000 are that the DW3000 has:

• Reduced peak and mean power consumption figures
• Addition of channel 9 (with 8 GHz centre frequency)
• Reduced bill of materials for the full UWB solution by integrating the balun and filters on die
• Reduced external component count
• Increased ease of use for the end user via simplified software interface
• A family variant that optionally allows for a single chip PDoA measurement
• Support for enhanced Time-of-Flight security modes using STS
• Integrated hardware AES (GCM and CCM*) 128/192/256 for data confidentiality and authenticity
• No support of the 110 kb/s data rate
• No support of channels 1, 2, 3, 4, 7
• No support for Smart Tx, this must be implemented on the host instead
• •

Backwards compatibility with DW1000

DW3000 is backwards compatible with DW1000 for a sub-set of use case configurations. As DW3000 has a reduced channel set, the only common channel is channel 5 (6.5 GHz). Both 16 and 64 MHz PRFs are supported as well as the 850 kb/s and 6.81 Mb/s data rates.

Although the DW3000 is operationally backwards compatible with DW1000 on channel 5, modified software is needed since the DW3000 control register interface is different to that of the DW1000. Decawave provides an easy-to adopt DW3000 device driver and API for backwards compatibilit y [3].

2.3 Interfacing to the DW3000

The SPI interface

The DW3000 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 DW3000.

The host system controls the DW3000 via the SPI, reading and writing configuration and status registers, data buffers and issuing commands. This section describes the general format of the SPI transactions. For details of the SPI bus signals, their voltage levels, operational mode configuration and timing parameters please refer to the DW3000 Datasheet [5]. The SPI-accessible buffers and registers of the DW3000 are detailed in section 8 – The DW3000 register set , and the commands are detailed in section 9 – Fast Commands .

2.3.1.1 SPI operating modes

The operating mode of the SPI is determined when the DW3000 is initialised as a result of a device reset or is woken up from a sleep state. At this time GPIO lines 5 and 6 are sampled, (see Figure 8) , and their values used to select the SPI polarity and phase mode respectively. Please refer to the IC Datasheet [5] section "SPI Operating Modes" for details of the operation resulting from this.

It is possible to set the SPI mode within the DW3000's one-time programmable (OTP) 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 thus care must be taken to ensure that the desired SPI mode is correctly set if this method is used. Please refer to section 7.3 – Using the on-chip OTP memory for more details of OTP configuration.

For full details of the SPI operating modes and their configuration, please refer to the DW3000 Datasheet.

2.3.1.2 Transaction formats of the SPI interface

Each SPI transaction starts with a one or two octet transaction header followed by a variable number of octets making up the transaction data. The size of an SPI transfer is not limited, however when writing to any of the DW3000 registers care must be taken not to write extra data beyond the published length of the selected register (see section 8 – The DW3000 register set ) as doing so may cause the IC to malfunction.

Figure 1: SPI transaction header and transaction data

Physically the SPI interface is full duplex in that every transaction shifts bits both into and out of the DW3000. Logically however each transaction is either reading data from the DW3000 or writing data to it. All SPI communication shown here is from the SPI-Master (host microprocessor) point of view. Thus an SPI read means reading data from DW3000 and an SPI write means writing data into DW3000. As shown in Figure 1, for a read transaction all octets beyond the transaction header are ignored by the DW3000, and for a write transaction all octets output by the DW3000 should be ignored by the host system. The SPI transaction header selects the SPI transaction format, shown i n Figure 2:

Note: The octets are physically presented on the SPI interface data lines with the high-order bit sent first in time (MSB first). The first bit in the transaction sequence determines the direction of the communication, which is 0 for the SPI read and 1 for the SPI write operation.

Table 3: SPI transaction types

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 DW3000 interprets the next octet(s) as a new transaction header. The low-to-high de-assertion of SPICSn ends the SPI transaction.

The SPI accessible parameters of the DW3000 are organised into 32 separate register files which are further detailed in sectio n 8 – The DW3000 register set . Every SPI read or write transaction header includes a 5-bit register file ID – 5-bit base address – as shown in Figure 2, that identifies the register file is being accessed by the transaction. Sub-addressing within the selected register file allows efficient access to all the parameters within the DW3000. Depending on the sub-addressing being used, the transaction header is either one or two octets long. These three types of transaction are described in the sub-sections below.

Figure 2: SPI command formatting

2.3.1.2.1 SPI transaction with a 1-octet header – fast command

Figure 3 shows the fields within the one octet transaction header of a fast command SPI transaction. The 5 bit fast command hex code is encapsulated by control bits which specify this SPI header as fast command type. In Figure 3 the fast command is a start transmission command ( CMD_TX , hex code 0x1),

Figure 3: Single octet fast command (start TX) SPI transaction

2.3.1.2.2 SPI transaction with a 1-octet header

Figure 4 shows the fields within the one octet transaction header read/write command. The 5-bit register file ID is encapsulated by control bits which specify this header as a read/write transaction with a single octet header. This example is accessing th e DEV_ID register (0x00:00). Only the first octet read from the 32-bit DEV_ID register is shown with value of 0x12. Note this value may be different depending on the IC version see § 8.2.2.1 – Sub-register 0x00:00 – Device Identifier.

Figure 4: Reading first octet from DEV_ID register of the IC

2.3.1.2.3 SPI write transaction with a two-octet header

Figure 5 shows the fields within the two-octet transaction header of an extended address write SPI transaction. The 5-bit base address (0x2) and 7-bit sub address (0x1C) are encapsulated by control bits which specify this SPI header as an extended address write type. Figure 5 shows the octets sent to the device to write 2 bytes to register STS_IV (reg ID 0x2 sub address 0x1C). As this is a write type the mode bits (M1 and M0) are set to 0.

Figure 5: Writing two octets to register 0x2 subaddress 0x1C

2.3.1.3 SPI CRC mode

The SPI CRC mode when enabled provides the ability for SPI transactions to have the added protection of a Cyclic Redundancy Check sequence. This mode of operation is disabled by default, but may be enabled (and disabled) via the SPI_CRCEN bit in the SYS_CFG register.

Note: The SPI interface is a local digital interface which should never experience error, so the enabling of SPI CRC checking is generally unwarranted. While SPI CRC checking has a penalty in terms of the added software overhead of the host microprocessor having to calculate a CRC for every SPI write and read transaction, it may be useful for extra reliability reasons, for example where the design has long SPI lines with a possibility of interference, or in the case of design debugging where SPI integrity has not been proven.

When SPI CRC mode is enabled, the DW3000 behaves as follows:

2.3.1.3.1 SPI writes in SPI CRC mode

For SPI writes from the host to the DW3000 when SPI CRC mode is enabled, the IC assumes that each SPI transaction ends with an 8-bit CRC calculated over all the preceding bytes written during the SPI transaction, i.e. from the falling edge of SPICSn. When SPICSn is de-asserted the final CRC byte of the SPI transaction is checked by the IC against a CRC it has generated for the transaction. If the CRC from the host does not match a CRC the IC generates internally, then this is considered to be an error, and the error is signalled to the host via the SPICRCE event bit in the system event status register, SYS_STATUS. This event flag may be used to generate an interrupt if the event is unmasked via the SPICRCE_EN bit in the SYS_ENABLE register.

Note: The write command will complete irrespective of the CRC error check status, which means that the data may be written to the wrong register location, and/or the data may be written incorrectly. The 8-bit CRC itself is not written to the addressed location,

The recommend recovery from a write CRC error is to reset the DW3000 completely, reinitialising and reconfiguring it into the desired operating mode for the application.

2.3.1.3.2 SPI reads in SPI CRC mode

For host SPI reads of DW3000 registers when SPI CRC mode is enabled, the IC calculates an 8-bit CRC over the whole the SPI transaction, i.e. from the falling edge of SPICSn at the start of reading to its de-assertion at the end of the read. The CRC thus covers the 1 to 3 header bytes written by the host to initiate the read, and all the subsequent bytes output as the host continues the read transaction. The resultant CRC value is placed into th e SPI_RD_CRC register in Sub-register 0x00:18 – SPI CRC read status.

A host wishing to validate the CRC of an SPI read transaction, must calculate its own CRC value across the header bytes it writes and all the data bytes it subsequently reads for the transaction, and then must read the IC calculated CRC from the SPI_RD_CRC register, and compare it to the host calculated CRC. If these don't match then the host has detected an error in the SPI read.

In the event of an SPI read error, the read can just be repeated, except in the unlikely case that the error changed the read into a write. In that case a write CRC error will be triggered and this can be handled as before by resetting the DW3000 and reinitialising/reconfiguring it into the desired operating mode.

2.3.1.3.3 The SPI CRC polynomial / implementation

The CRC is 8-bits long, based on the CRC-8-ATM which has generator polynomial:

$$G(x)\; =\; x^8\; +\; x^2\; +\; x\; +\; 1$$

and has a typical implementation as shown in Figure 6, where the circle operator is an exclusive-OR.

Figure 6: SPI CRC polynomial implementation

In the DW3000 the shift register ( r ⁰ to r7 ) is initialised, at the start of each read or write SPI, with the value specified in th e SPICRCINIT register, which by default is all zeros.

Note: The source code of the DW3000 device driver and API [3] includes functions to generate and check the SPI CRC along with a simple example that demonstrates their use. The maximum SPI rate supported by DW3000 when the SPI CRC mode is enable is 20 MHz.

Interrupts

The DW3000 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 handle the event.

The polarity of the IRQ pin may be configured via the HIRQ_POL bit in the Sub-register 0x0F:24 – Digital diagnostics test mode control. By default, on power up the IRQ polarity is active high. This is the recommended polarity to ensure lowest power operation of the DW3000 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 SYS_STATUS register may assert the IRQ pin depending on the setting of the corresponding bit in the SYS_ENABLE register.

By default, on power-up, the SPIRDY interrupt generating event enable SPIRDY_EN is set to 1 so that the interrupt enabled.

General purpose I/O

The DW3000 provides a number of GPIO pins as listed in the DW3000 Datasheet [5]. 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 by 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 DW3000 Datasheet.

The configuration and operation of the GPIO pins is controlled via GPIO_CTRL register. By default, on powerup, all GPIOs are configured as inputs.

The SYNC pin

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

2.4 DW3000 operational states

State diagram

The DW3000 has a number of different operational states. These are listed and described in Table 4 below and the transitions between them are illustrated i n Figure 7.

Overview of main operational states

Table 4: Main DW3000 operational states / modes

Clock periods and frequencies

The chipping rate specified for the HRP UWB PHY by the IEEE 802.15.4 standard [1] is 499.2 MHz, and all IC system clocks are referenced to this frequency. Where the system clock frequency is quoted as 125 MHz, this is an approximation to the actual 124.8 MHz system clock frequency (crystal 38.4 MHz × 13 ÷ 4). Similarly, where the system clock period is quoted as 8 ns, this is an approximation to the actual period of 1/(124.8×10 ⁶ ) 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 IEEE802.15.4 standar d [1], where a 15.65 picosecond time period is referred to, it is an approximation to the period of this clock.

Pulse repetition frequency (PRF)

The PRF values of 16 MHz and 64 MHz quoted in this document are approximations to the values dictated by the IEEE802.15.4 standard [1]. PRF mean values are slightly higher fo r SHR compared to the PHR and data parts of the packet. Please refer t o [1] for full details of peak and mea n PRFs .

Data rate

Where a data rate of 6.8 Mb/s is referred to, this is equivalent to the 6.81 Mb/s data rate in [1]. Note that the data rates quoted are (rounded) nominal values based on the data symbol rate multiplied by the Reed-Solomon (RS) coding rate, 0.87 which is 330/378 because the RS coding adds 48 parity bits for every 330 bits data (or part thereof). Please refer t o [1] for more details.

2.5 Power On Reset (POR)

When the external power source is applied to the DW3000 for the first time (cold power up), the internal Power On Reset (POR) circuit compares the externally applied supply voltage (VDD1) to an internal power-on threshold (approximately 1.5 V), and once this threshold is passed the AON block is released from reset and the external device enable pin EXTON is asserted. This is shown in Figure 8.

Then the VDD2a and VDD3 supplies are monitored and once they are above the required voltage as specified in the Datasheet (2.2 V and 1.4 V respectively), the fast RC oscillator (FAST_RC) and crystal (XTAL Oscillator) will come on within 500 µs and 1 ms respectively. However if time for VDD2a or VDD3 exceeds 10 ms then the device will need to be reset once these supplies are up. Please refer to the Datasheet [5] for more details.

The DW3000 digital core will be held in reset until the crystal oscillator is stable. Once the digital reset is deasserted the digital core wakes up and enters the INIT_RC state, (see Figure 7 an d Figure 8) . Then once the configurations stored in AON and OTP have been restored (into the configuration registers) the device will enter the IDLE_RC state IDLE_RC . Then the host can set the AINIT2IDLE configuration bit i n SEQ_CTRL and the IC will enable the CLKPLL and wait for it to lock before entering the IDLE_PLL state.

Figure 8: Timing diagram for cold start POR

SLEEP and DEEPSLEEP

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

The DW3000 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 (see 8.2.11.6.1 for sleep timer configuration) that is running from a lowpowered oscillator internal to the DW3000 IC. In this SLEEP state the power drain is approximately 1 µA. The IC will wake from the SLEEP state when the sleep timer elapses, or the WAKE_UP or SPICSn inputs may be used to wake the device before the timer elapses.

The frequency of the low power oscillator is dependent on process variations within the IC, but is typically around 20 kHz. There are facilities within the IC to measure the frequency of this LP oscillator and also to trim it.

Figure 9: Timing diagram for warm start (@ VDD = 3V)

2.5.1.1 Waking from sleep

Waking from SLEEP and DEEPSLEEP states can happen in following ways:

• Driving the WAKEUP pin high for approximately 500 μs, (assuming WAKE_WUP configuration bit is set in AON_CFG) .

• Driving the SPICSn pin low for approximately 500 μs, (assuming th e WAKE_CSN configuration bit is set i n AON_CFG) . 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 bit is set in AON_CFG along with an appropriate SLEEP_TIM value).

In all three wake up cases the device is returned to the IDLE_PLL state if the AINIT2IDLE configuration bit in SEQ_CTRL register was set when the device configuration was uploaded prior to entering sleep state, otherwise the device will stay in IDLE_RC . Additional state transitions can be automatically enacted thereafter depending on configurations.

Asserting the RSTn pin (hardware reset) will also take the IC out of SLEEP or DEEPSLEEP states, however device will be fully reset in that case.

2.5.1.2 Configuration register preservation

Prior to entering the SLEEP or DEEPSLEEP states the main DW3000 configuration register values are saved (copied) into the Always-On (AON) memory, and upon waking, prior to exiting the INIT_RC state the saved values are restored from the AON memory.

Power is maintained to the AON memory at all times, even in SLEEP and DEEPSLEEP states. The copying of configuration data (saving or restoring) and boot up time of the OTP takes ~85 µs to complete (when restoring from SLEEP and DEEPSLEEP states, se e Figure 9). Restoration of configurations during the WAKE_UP state is only done if the ONW_AON_DLD configuration bit is set in AON_DIG_CFG.

Note: The host should wait for the restoration of configurations to be completed before using SPI to avoid internal IC conflicts that may lead to the corruption of the configuration values. The preffered option is to wait for the assertion of the SPIRDY interrupt.

2.5.1.3 Loading LDO calibration data from the OTP

When waking from SLEEP or DEEPSLEEP it is necessary to load the LDOTUNE_CAL value that is programmed into OTP during IC production test calibration.Default configuration on power up and after a reset

DW3000 is a highly configurable transceiver with many features. The register default (reset) values have been selected with the intention of minimising the amount of user configuration required. The default configuration is summarised in Table 6.

Table 6: Default DW3000 operational configuration

Channel numbers and preamble codes are as specified in the standard, IEEE802.15.4 standar d [1]. Some further details are given below on the specifics of the default device configuration. For full details please refer to the register map where the default value of each register is given, § 8 – The DW3000 register set .

Note: the above default configuration needs to be modified in oder for the DW3000 to correctly interoperate with the DW1000 on CH5.

Default system configuration

Much of the system configuration is configured in the SYS_CFG register, please see section Sub-register 0x00:10 – 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 HIRQ_POL in th e DIAG_TMC register for interrupt polarity and the SYS_ENABLE and SYS_STATUS registers for interrupt configuration and information, see sections Sub-register 0x00:3C – System event enable mask and Sub-register 0x00:44 – System event status .

GPIOs are all set to mode 0 (as defined in the GPIO_MODE register), their default function is shown i n Table 7.

Table 7: GPIO default functions

Frame wait timeout (see SYS_CFG register bi t RXWTOE and Sub-register 0x00:34 – Receive frame wait timeout period ) and preamble detection timeout (see Sub-register 0x06:04 – Preamble detection timeout count) are off, whilst SFD detection timeout (see Sub-register 0x06:02 – SFD detection timout count) is on.

Othe r 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 (AUTO_ACK) are all off by default. Automatic CRC generation in the MAC frame data is on (DIS_FCS_TX) .

External synchronisation and the use of external power amplifiers are deactivated by default, see sections 7.1 – External Synchronisation and 7.2 – External power amplification .

Default channel configuration

Channel 5, preamble code 9 and 64 MHz PRF are set by default in th e CHAN_CTRL register, see Sub-register 0x01:14 – Channel control for more information.

The transmit data rate is set to 6.8 Mb/s in the TX_FCTRL register, see TXBR field in Sub-register 0x00:24 – Transmit frame control . The receive data rate is never set it can be decoded from the PHR bits.

Default transmitter configuration

Transmit RF channel configurations are set for channel 5 by default – see Sub-register 0x07:1C – RF TX control register 2. The transmit preamble symbol repetition length is 64 symbols, see Sub-register 0x00:24 – Transmit frame control, TXPSR field for configuration details.

Default receiver configuration

Receiver RF channel configurations are set for channel 5 by default, to match the transmitter.

Digital receiver tuning registers are configured by default for 64 MHz PRF, 6.8 Mb/s data rate and a preamble symbol repetition of length 64. See Sub-register 0x06:00 – Digital RX tuning register for programming details.

The CIARUNE bit (CIA run enable) is enabled by default, which means that th e CIA algorithm will execute on every packet reception, which in turn will calculate accurate time-of-arrival. If the running the CIA is not required then th e CIARUNE control in Sub-register 0x11:08 – Sequencing control can be turned off (set to zero). This may be useful in a data communications only application, to save power and time.

2.6 UWB channels and preamble codes

The IEEE802.15.4 standar d [1] has 16 defined channel/bands for the HRP UWB PHY. The DW3000 supports the subset of these listed i n Table 8 below. Depending on the channel and the pulse repetition frequency (PRF) the IEEE802.15.4 standard [1] HRP UWB PHY defines a choice of two or four preamble codes. The standard defined preamble code options are also listed i n Table 8. The combination of channel number and preamble code is what the standard terms a complex channel .

Table 8: DW3000 supported UWB channels and recommended preamble codes

The preamble codes specified by the standard for use on a particular channel were chosen to have a low cross correlation factor with each other with the intention that the complex channels could to operate independently from each other as separate networks. In practice, as there is still some cross correlation, there will be some break-through between different codes especially in conditions of close proximity with long preambles.

The IEEE802.15.4 standar d [1] includes a feature called dynamic preamble select (DPS) , where devices switch to using one of th e DPS specific preamble codes for the ranging exchange, and perhaps a different one for each direction of communication. The idea is to make it more difficult to eavesdrop or spoof, by randomly changing the DPS preamble codes in a mutually agreed sequence only known to the valid participants. This is supported by the DW3000 where at 64 MHz PRF the preamble codes additionally available for DPS are: 13, 14, 15, 16, 21, 22, 23 and 24.

2.7 Data modulation scheme

The UWB specified in the IEEE802.15.4 standar d [1] is sometimes called impulse radio UWB because it is based on high speed pulses of RF energy. During the PHR and Data parts of the packet, information bits are signalled by the position of the burst, in a modulation scheme termed burst position modulation (BPM).

Each data bit passes through a convolution encoder to generate a "parity" bit used to set the phase of the burst as either positive or negative, this component of the modulation is termed binary phase-shift keying (BPSK). Figure 10 shows how the convolutional encoder contributes to this BPM/BPSK modulation. A coherent receiver (i.e. one tracking carrier timing and phase) such as the one in the DW3000 can determine this burst phase and use it in a Viterbi decoder to get an additional 3 dB of coding gain, thereby extending the operational range of the modulation.

Figure 10: BPM/BPSK data and PHR modulation

In addition the quarter symbol interval is sub-divided into 2, 4, or 8 sub-intervals and a pseudo random sequence used to determine both the burst shape and which of the sub-intervals are actually used for the burst transmission. This gives more immunity to interference and whitens the output spectrum allowing a higher signal power to be used in the transmitter.

Forward error correction (FEC) is also included in the PHR and Data parts of the packet. The 19-bit PHR includes a 6-bit single-error-correct double-error-detect (SECDED) code and the data part of the packet has a Reed Solomon (RS) code applied. Both SECDED and RS codes are termed "systematic" meaning that the data can be recovered without using the codes (and of course not benefitting from them in that case), e.g. by a non-coherent receiver. The 850 kb/s and 6.8 Mb/s user data rates quoted, include allowance for the 0.87 average RS coding rate. The PHR is not RS coded so for example at the 850 kb/s nominal rate the PHR is actually sent at 975 kb/s.

2.8 Synchronisation header modulation scheme

The Synchronisation Header (SHR) consists of the preamble sequence and the SFD (start of frame delimiter). In contrast to the BPM/BPSK modulation used for the PHR and data, the synchronisation header is made up of single pulses. The preamble symbol period is divided into approximately 500 "chip" time intervals, (496/508 depending on 16/64 MHz PRF ¹ ), in which either a negative or a positive pulse may be sent, or no pulse. The "chip" interval is 499.2 MHz, a fundamental frequency within the UWB PHY, and so the resultant symbol times are thus ⁴⁹⁶ /499.2 µs for 16 MHz PRF, and ⁵⁰⁸ /499.2 µs for 64 MHz PRF, (see Table 9 below).

The sequence of pulses sent during the preamble symbol interval is determined by the preamble code. The standard defines 8 preamble codes of length-31 for use at 16 MHz PRF and 16 preamble codes of length-127 for use at 64 MHz PRF. The standard nominates particular codes for particular channels so that at 16 MHz PRF there are just two to choose from per channel, while at 64 MHz PRF there is a choice of four codes per channel. The length-31 codes are spread by inserting 15 zeros after each pulse to give the 496 chip times per symbol while the length-127 codes are spread by inserting 3 zeros after each pulse to give the 508 chip times per symbol. The preamble length and duration is defined by how many times (i.e. for how many

¹ The DW3000 supports average pulse repetition frequencies of 16 MHz and 64 MHz

^© Decawave Ltd 2019 Version 1.1 Page 29 of 255

symbols) the sequence is repeated. This is determined by the configuration of the number of preamble symbol repetitions (PSR).

Table 9: Preamble parameters

The standard defines PSR settings of 16, 64, 1024 and 4096. The DW3000 supports these (although it will not receive packets with preamble length below 32 symbols) and in addition supports PSR settings of 128, 256, 512, 1536 and 2048.

The preamble sequence has a property of perfect periodic autocorrelation ² which in essence allows a coherent receiver to determine the exact impulse response of the RF channel between transmitter and receiver. This brings two important benefits. Firstly, it allows the receiver make use of the received energy from multiple paths, turning multipath from an interference source into a positive affect extending operating range. Secondly, it lets the receiver resolve the channel in detail and determine the arrival time of the first (most direct) path, even when attenuated, which brings precision advantages for RTLS applications.

Note: The DW3000 includes a packet format specified by new IEEE802.15.4z amendment [2] which incorporates a cryptographically generated scrambled timestamp sequence (STS) that can be used to obtain an RX timestamp that has improved integrity in terms of its robust to accidental or deliberate interference, e.g. as a result of packet collisions, for more details of this please refer to sectio n 6 below. The SFD marks the end of the preamble and the precise start of the switch into the BPM/BPSK modulation of the PHR. The time-stamping of this event is deterministic in terms of symbol times and it is this in conjunction with determining the first arriving ray within that symbol time that allows the accurate timestamping needed for precision RTLS applications. The standard specifies the SFD, which consists of the preamble symbols either not sent, or sent as normal or sent inverted (i.e. positive and negative pulses reversed) in a defined pattern 8 symbol times long for 850 kb/s and 6.81 Mb/s data rates. The length-8 SFD sequence is: 0, +1, 0, -1, +1, 0, 0, -1. The IEEE802.15.4z amendment also specifies length-8 SDF without zeros, ( -1, -1, -1, +1, -1, -1, +1, -1), which gives improved performance in a coherent receiver such as the DW3000 that supports it.

2.9 PHY header: standard data frame length

The PHY header (PHR) is modulated using the BPM/BPSK modulation scheme defined in section 2.7 above, but it does not employ the Reed Solomon code used for data, instead is employs a 6-bit SECDED parity check sequence as part of its 19-bit length.

² V. P. Ipatov, "Ternary sequences with ideal autocorrelation properties," Radio Eng. Electron. Phys., vol. 24, pp. 75–79, 1979

Figure 11: PHR bit assignment

Figure 11 above shows the bits of the PHR. These are transmitted bit-0 first in time. The DW3000 fills in the Data Rate, Frame Length, Ranging frame, and Preamble Duration fields of the PHR based on the user configuration of the appropriate parameters in TX_FCTRL and generates th e SECDED sequence accordingly. The Header Extension bit of the PHR is always zero and is reserved by IEEE for future extensions.

2.10 Extended PHY header: extended data frame length

Standard IEEE 802.15.4-2020 UWB packets can carry up to 127 bytes of payload, se e Figure 11: PHR bit assignment. The DW3000 also supports a mode of operation with frame lengths up to 1023 bytes. This mode of operation is enabled via the PHR_MODE selection bits of Sub-register 0x00:10 – System configuration , which changes the defifinition of the PHR bits. While this makes the PHR non-compliant with IEEE 802.15.4 this PHR format is actually defined as an option in the IEEE 802.15.8 standard.

In this mode the PHY header (PHR) is redefined to carry the 3 extra bits of frame length. In order to communicate extended length frames between two DW3000 devices both ends must be set to the long frame PHY header mode via the PHR_MODE selection bits of Sub-register 0x00:10 – 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 this long frame mode is selected, the DW3000 will be unable to successfully communicate with any device operating with the IEEE 802.15.4 standard frame encoding, and because the SECDED error check sequence of the PHR in this long frame mode is inverted this will cause PHR error events in advance of any attempt to receive the payload.

Note 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 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 TX_FCTRL is sent in the PHR and reported in the RXPSR value in RX_FINFO.

The PHR encoding for the extended length frames is shown below i n Figure 15:

Figure 12: PHR bit assignment extended length frames

The Data Rate field has the same encoding as used for the IEEE802.15.4 standard 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 11.

The preamble duration field, TXPSR, may be used by a receiver to set the value of the preamble duration for an ACK frame to 64, 128, 256, 512, 1024, 1536, 2048 and 4096 symbols. Alternatively, the FINE_PLEN field may be used to set any multiple of 8 as a preamble length from 32 to 2048. The application may use the count of received preamble symbols, as reported i n IP_DIAG12 register, to additionally inform the choice of preamble length for any response frames.

The SECDED 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 IEEE802.15.4 standard [1] 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) and S5 = NOT (C5) This is as specified in the IEEE 802.15.8 standard for frames up to 1023 octets.

3 Message transmission

3.1 Basic transmission

The transmission of packets is one of the basic functions of the DW3000 transceiver. The packets can be sent both with and without data payload. The DW3000 supports four packet formats, the IEEE802.15.4 standard [1] packet format, and three new IEEE802.15.4z amendment [2] defined formats where a scrambled timestamp sequence (STS) is introduced into the packet as shown in Figure 13. When the STS modes are enabled the DW3000 transmitter will insert the STS in the position shown, and the receiver will expect it to be present accordingly. The packet begins with a synchronisation header consisting of the preamble and the SFD (start of frame delimiter). The PHY header (PHR) defines the length (and data rate) of the data payload part of the packet. The STS when inserted allows for secure timestamping, and ranging, see § 6.

The DW3000 basic transmit sequence is as shown in Figure 14, beginning in the IDLE_PLL state awaiting instruction from the host controller.

In order to transmit, the host controller must write data for transmission to TX_BUFFER, and select the preamble length, frame length, data rate and PRF in the Transmit Frame Control and Channel Control registers, TX_FCTRL and CHAN_CTRL. The PRF will be set according to the chosen preamble code (TX_PCODE) . Assuming all other relevant configurations have already been made, the host controller initiates the transmission by issuing a TX command (e.g. CMD_TX ). Once transmission is initiated, the DW3000 sends the complete packet of preamble , SFD, PHR and the PHY Payload (MAC Frame). The STS will be included optionally depending on the configured packet format (se e Figure 13) . In the STS packet configuration 3 (SP3) the PHR and PHY Payload is omitted.

As an aid to MAC layer framing, the IC calculates the FCS (CRC) during the transmission of the (MAC) data from th e TX_BUFFER based on the frame length (TXFLEN) and automatically appends it.

The end of transmission is signalled to the host via the TXFRS event status bit in SYS_STATUS, and the DW3000 returns to IDLE_PLL mode to await new instructions.

Figure 14: Basic transmit sequence

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 .

3.2 Transmission timestamp

During packet transmission the event nominated to time-stamp termed the RMARKER, where the RMARKER is defined in the IEEE standard to be the time when the beginning of the first symbol following th e SFD is at the local antenna, or more precisely the peak pulse location associated with the first chip following the SFD.

The DW3000 digital transmit circuitry takes note of the system clock counter as the RAW transmit timestamp at the point when it begins sending the first chip following th e SFD. It then adds to this the transmit antenna delay (configured in TX_ANTD) to get the antenna adjusted transmit time-stamp that it writes to th e TX_STAMP field of TX_TIME.

See also section 10.3 – IC calibration – antenna delay.

3.3 Delayed transmission

For delayed transmission, the transmit time is programmed into DX_TIME and then the delayed transmission is initiated by issuing the CMD_DTX command. Alternatively a delayed transmission can be achieved by programming a "reference time" into the DREF_TIME and an offset into th e DX_TIME, after which delayed transmission command , CMD_DTX_REF, is issued instead.

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 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 value programmed into DX_TIME (and in DREF_TIME) is in time units of 4 ns, or more precisely 2 ÷ (499.2×10 ⁶ ). To calculate the time of transmission of th e RMARKER at the antenna, the low 9 bits of the delayed TX time should be zeroed before adding the TX antenna delay, and the high 32-bits of the 40-bit result written int o DX_TIME, (or a reference time programmed into DREF_TIME and an offset into the DX_TIME) . Note: the least significant bit of DX_TIME is ignored so its effective resolution of is really 4 ÷ (499.2×10 ⁶ ) or approximately 8 ns.

In performing a delayed transmission, i.e., after the CMD_DTX is issued, the DW3000 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 DW3000 then remains in TX_WAIT state until the system time (SYS_TIME) reaches the correct point to turn on the transmitter and begin preamble.

One use of delayed transmission (and reception), is to control the response times in two-way ranging, (described in APPENDIX 1: Two-way ranging), and especially to allow the prediction and embedding of the TX timestamp (or response delay) into the transmitted message to reduce the number of messages necessary for a ToF measurement. Delayed transmission (and reception) also helps to minimise the response times to save power, however in working towards this the host microprocessor may sometimes be late invoking the delayed TX, i.e., where the system clock has passed the specified start time (i.e. internal start time mentioned above) and then the IC would have to complete almost a whole clock count period before the start time is reached. The HPDWARN event status flag in SYS_STATUS 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 in the near future, the HPDWARN event flag will not be set. If a long delay was intended then 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 transceiver off command CMD_TXRXOFF .

3.4 Extended length data frames

Standard IEEE 802.15.4-2015 UWB packets can carry up to 127 bytes of payload. The DW3000 also supports a mode of operation with frame lengths up to 1023 bytes. This mode of operation is enabled via the PHR_MODE selection bits of Sub-register 0x00:10 – System configuration , which changes the defifinition of the PHR bits. While this makes the PHR non-compliant with IEEE 802.15.4 this PHR format is actually defined as an option in the IEEE 802.15.8 standard.

In this mode the PHY header (PHR) is redefined to carry the 3 extra bits of frame length. In order to communicate extended length frames between two DW3000 devices both ends must be set to the long frame PHY header mode via the PHR_MODE selection bits of Sub-register 0x00:10 – 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 this long frame mode is selected, the DW3000 will be unable to successfully communicate with any device operating with the IEEE 802.15.4 standard frame encoding, and because the SECDED error check sequence of the PHR in this long frame mode is inverted this will cause PHR error events in advance of any attempt to receive the data payload.

Note 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 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 TX_FCTRL is sent in the PHR and reported in the RXPSR value in RX_FINFO.

The PHR encoding for the extended length frames is shown below i n Figure 15:

Figure 15: PHR encoding extended length frames

The Data Rate field has the same encoding as used for the IEEE802.15.4 standard [1] 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 11.

Table 11: Preamble duration field values in extended length frame PHR

The preamble duration field, TXPSR, may be used by a receiver to set the value of the preamble duration for an ACK frame to 64, 128, 256, 512, 1024, 1536, 2048 and 4096 symbols. Alternatively, the FINE_PLEN field may be used to set any multiple of 8 as a preamble length from 32 to 2048. The application may use the count of received preamble symbols, as reported i n IP_DIAG12 register, to additionally inform the choice of preamble length for any response frames.

The SECDED 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 IEEE802.15.4 standard [1] 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) and S5 = NOT (C5) This is as specified in the IEEE 802.15.8 standard for frames up to 1023 octets.

4 Message reception

4.1 PHY reception

The reception of a packet is enabled by a host request enabling of the receiver. This can be done while the device is in either IDLE_RC or IDLE_PLL state. If the device was in IDLE_RC it will firstly clalibrate, enable PLL and switch to IDLE_PLL state and then goin into RX state. However, prior to the first RX enable following device power up, the receiver needs to be calibrated. This is done by performing RX calibration, for more details on this see the dwt_pgf_cal() API [3] an d RX_CAL register. The RX calibration is automatically done on wakeup as long a s ONW_PGFCAL bit is set. It is also recommended that the receiver is re-calibrated if the operating temperature changes by 20 °C.

Figure 16: Receive sequence

To enable the receiver, the host issues an RX start command (see section on Fast Commands) . The receiver will start by searching for preamble continually until preamble has been detected or acquired, then 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 (which is programmable i n PRE_TOC) . A receive sequence is shown in Figure 16.

Preamble detection

The preamble sequence is detected by cross-correlating in preamble acquisition chunks (PACs ) which are a number of preamble symbols long. The size of chunk used is selected by the PAC configuration in DTUNE0. 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 the receiver performance will be impaired, or fail to work at the extremes – (e.g. a PAC of 32 will never receive packets with just 32 preamble symbols). Table 12 gives the recommended PAC size configuration to use in the receiver depending on the preamble length being used in the transmitter.

Aborting reception with use of preamble detection timeout (PRE_TOC) is very useful following 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.

Preamble accumulation

Once the preamble sequence is detected, the receiver begins accumulating correlated preamble symbols and building a channel impulse response (CIR) , while in parallel looking for th e SFD sequence (a particular sequence of preamble symbols, see § 2.8 – Synchronisation header modulation scheme for details).

SFD detection

The detection of SFD is a key event in the reception of a packet, because it marks th e RMARKER, which is time-stamped (see section 4.1.7 – RX message timestamp ), and it marks the change from preamble demodulation to the BPM /BPSK demodulation of th e PHR and data or STS demodulation if enabled.

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 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 65 symbol times (to match the default preamble length of 64 symbols and a PAC size of 8). It is not recommended to disable the SFD detection timeout.

The SFD sequence is either 8 or 16 symbols long for the supported data rates of 6.8 Mb/s or 850 kb/s. The type of the SFD sequence used is defined by SFD_TYPE configuration bits i n CHAN_CTRL register, and are described in Table 22.

STS reception

If the STS is enabled, see Figure 13, the receiver will construct another CIR from that. The time-of-arrival (ToA) can also be derived from this CIR estimate.

The STS itself consists of a series of equally spaced pulses whose polarity is derived from an AES128 based cryptographically secure pseudo random number generator as specified in the IEEE802.15.4z amendment.

This can help when constructing a secure ranging environment (see 6 Secure ranging / timestamping) and it also improves immunity to packet collisions on the air.

PHR demodulation

The main role of the PHY Header (PHR) is to convey the length of the data portion of the packet, and to indicate the data rate being employed for data demodulation. See paragraph 2.9 - PHY header and paragrap h 2.10 for details of the PHY header. For data rates of 850 kb/s and 6.8 Mb/s th e PHR is modulated / demodulated as per the 850 kb/s data rate (note that because Reed Solomon encoding is not applied to the PHR, its bit rate is approximately 1 Mb/s). If th e PHR is indicating 850 kb/s then the data demodulation continues at this rate, but if th e PHR is indicating 6.8 Mb/s then the demodulation changes to this rate at the end of the PHR as data demodulation begins.

It is also possible to configure the PHR rate to be the same as the data rate, i.e. to use 6.8 Mbit/s with PHR_6M8 configuration bit i n SYS_CFG, 8.2.2.4.

Data demodulation

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

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

Successful reception of a frame is signalled to the host via th e RXFR an d RXFCG event status bits in SYS_STATUS. 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), RXSTO (SFD timeout) , RXPHE (PHY Header Error), RXFSL (Reed Solomon error), RXFTO (Frame wait timeout), etc.

RX message timestamp

The IEEE802.15.4 standar d [1] nominates the time when the RMARKER arrives at the antenna as the significant event that is time-stamped, also shown i n Figure 13.

The DW3000 digital receiver circuitry takes a coarse timestamp of the symbol in which th e RMARKER event occurs and adds in 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 the RXANTD register (i n CIA_CONF) and adding the correction factor determined by the first path (leading edge) detection algorithm embedded in the DW3000. The resulting fully adjusted RX timestamp is written into RX_STAMP, IP_TOA an d STS_TOA registers .

See also section 10.3 – IC calibration – antenna delay , and section 6 – Secure ranging / timestamping .

4.2 TDoA and PDoA support

The two-antenna port variants of DW3000 chip can measure the phase of incoming signal. This information can be used to help determine the direction of arrival and location of the transmission when combined with knowledge of the antenna response. More details of how this is performed will be given in an associated application note. This section will focus on the information provided by the device itself.

Depending on the variant of th e device there will be one or two antenna ports. Devices with two antenna ports are referred to as PDoA parts while the others are non-PDoA parts (see Table 1) . The two variants have different capabilities when it comes to Phase Difference of Arrival (PDoA) support.

For the "PDoA" parts, if the packet contains an STS then, depending on the configured mode, the device can compute the PDoA. There are two methods for computing the PDoA: PDoA Mode 1 and PDoA Mode 3.

PDoA Mode 1 functions with any packet containing an STS but is less accurate than PDoA Mode 3. On another side PDoA Mode 3 requires the STS length (in units of 512 chips, ~1 μs) to be an integer multiple of 128 (128, 256, 512). It is more accurate than Mode 1 but the packets will be longer (se e PDOA_MODE in SYS_CFG register on how to configure the required mode).

In either of the PDoA modes the chip will also compute the Time Difference Of Arrival (TDoA) between the two channel estimates that are used to determine the PDoA. If this TDoA is large, e.g. greater than 1 ns, then the PDoA should be considered to be untrustworthy. This is probably due to harsh channel conditions resulting in an ambiguous first ray estimate.

4.3 Delayed receive

In delayed receive operation the receiver turn-on time is programmed into DX_TIME and then the delayed receiving is initiated by issuing CMD_DRX command. . Otherwise a delayed reception can be achieved by programming a "reference time" into the DREF_TIME and an offset into th e DX_TIME, after which delayed reception command, CMD_DRX_REF, is issued instead.

The DW3000 remains in IDLE_PLL state until the system time (SYS_TIME) reaches the value programmed in DX_TIME (or time programmed into DREF_TIME plus an offset into th e DX_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 b y PRE_TOC) and the frame wait timeout (which is enabled by the RXWTOE configuration bit in Sub-register 0x00:10 – System configuration , and whose period is programmed in RX_FWTO) .

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 DW3000 employing delayed transmit to send the response message at a precise time. This saves power because the IDLE_PLL state power consumption while counting down to the time to perform the RX enable is significantly less than the RX state power consumption while waiting and searching for the preamble of a packet reception.

One use of delayed receive, and especially delayed transmission, is in two-way ranging, (described i n APPENDIX 1: Two-way ranging), to control the response times. On the receive side turning on the receiver just in time to receive the response message helps save power since the IC will remain in IDLE_PLL state until it is time to turn on the receiver. Minimising the response time and time spent in IDLE_PLL state also saves power. 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 would have to complete almost a whole clock count period before the specified start time is reached. The HPDWARN event status flag in SYS_STATUS 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.4 Double receive buffer

The DW3000 has a pair of receive buffers (RX_BUFFER_0 an d RX_BUFFER_1) 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. For example, this is useful in a TDoA RTLS anchor node application where it is desired to have the receiver turned on for as much time 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" (SET_1 and SET_2) and are listed in Table 44. To enable logging of data to these diagnostic sets , RDB_DMODE must be set to at least 1 to log minimal set of registers.

Note that double buffering can also be used with th e SP3 packets, configured via the CP_SPC field in Sub register 0x00:10 – System configuration , where even though the packet contains no payload, the receive timestamp and other diagnostic information is doubly buffered.

Enabling double-buffered operation

By default the DW3000 operates in a single buffered mode that is appropriate for many applications. Double-buffered receiving is enabled by setting th e DIS_DRXB bit to zero, (in Sub-register 0x00:10 – System configuration ).

The DW3000 is operated in double buffered mode without possibility of the automatic re-enabling of the receiver, in which case the host needs to manually re-enable the receiver. However the receiver can be enabled in advance of processing the previously received frame. This operation reduces the amount of time for which the receiver is actively listening for frames on the air, but prevents both buffers being full (at the

same time) and prevents overflows. This simplifies the double-buffer operation, see sections 4.4.2 and 4.4.3 and, with a combination with a high-speed SPI enables reception of back-to-back frames.

Operation of double buffering

In non-double buffer mode the DW3000 will write the received frame data into RX_BUFFER_0. When the double buffer mode is enabled the DW3000 will alternate writing frames t o RX_BUFFER_0 and RX_BUFFER_1. The associated RX_FINFO and diagnostic data is stored in two register sets : SET_1 and SET_2 as listed in Table 44. The RDB_STATUS register informs the host which register set is ready and available. For example, whe n RX_BUFFER_0 frame reception is complete the IC will set the RXFR0 with RXFCG0 in RDB_STATUS register interrupting the host and the IC will move on to receive into the other buffer of the double-buffered swinging-set. Once the host has finished accessing a register set is should issue toggle buffer command, CMD_DB_TOGGLE , to let the IC know that the particular buffer is "free" again and that it can be used for the next received frame. The host should also clear th e RDB_STATUS register bits relating to the processed buffer. Figure 17 below is a flow chart showing the operation of double buffering in the receiver.

Reception of a frame with good CRC will set the relevan t RDB_STATUS register bits. The host will need to respond to the RX error events as usual (by reading the SYS_STATUS register and clearing any events) and reenable the receiver.

Overrun

As in the DW3000 the double buffered mode is used without the automatic re-enabling of the receiver, in which case the overrun should never happen. The host needs manually re-enables the receiver, it should process the previously received frame before enabling receiver following the reception of the current frame.

In case of the overrun condition, it will be cleared as soon as the host issues the CMD_DB_TOGGLE command. Following which the host should clear the RXOVRR status bit. Receiver overrun events are also counted in Sub-register 0x0F:0E – RX overrun error counter, assuming that counting is enabled by the EVC_EN bit in Sub-register 0x0F:00 – Event counter control .

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 8.2.15.6 Sub-register 0x11:1A – SNIFF mode and have default values of zero, disabling the feature. Using SNIFF mode causes a reduction in sensitivity depending on the ratio and durations of the on and off periods.

In SNIFF mode the DW3000 alternates between the RX state (on) and the IDLE_PLL (off) stat e Figure 18 shows a simplified view of the state transitions during SNIFF mode.

Figure 18: State transitions during SNIFF mode

SNIFF mode power profiles

In SNIFF mode the DW3000 alternates between the RX (on) and the IDLE_PLL (off) states. To enable SNIFF mode two parameters SNIFF_ON (sniff on time) an d SNIFF_OFF (the off time) need to be configured in Sub register 0x11:1A – 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. Th e SNIFF_ON 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 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_ON to its minimum of 2 PAC intervals (by programming the counter with a value of 1) and the SNIFF_OFF to a value of 16 µs.

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

Figure 19 Power profile for SNIFF where a packet is not received

Figure 20 below, shows a power profile fo r SNIFF mode, similar to figure 19 except in this case preamble is detected on the second period of RX sampling, and the DW3000 completes the reception of the packet.

4.6 Diagnostics

The DW3000 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 Register file: 0x05 – GPIO control and status. 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: 0x15 – Accumulator CIR memory. Please refer to its description for details.

• RX packet 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 the diagnostics registers of Register files: 0x0C, 0x0D, 0x0E – CIA Interface. Please refer to section 4.7 – Assessing the quality of reception and the RX timestamp for details.

4.7 Assessing the quality of reception and the RX timestamp

The DW3000 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.

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

Note: These items use diagnostics provided by the channel impulse analyser (CIA) algorithm, which operates on the accumulated correlation of the repeated symbols preamble sequence and/or the accumulated correlation of the scrambled timestamp sequence (STS) used for secure timestamping, see § 6 – Secure ranging / timestamping . The timestamps based on preamble and STS sequences can be assessed following these rules:

• Each ToA has an associated status word, see section 8.2.13. This word contains the results of several confidence tests on the first path estimate. If any of the bits in the status word is set, then the corresponding confidence test has failed and so the conditions may have resulted in lower confidence in the ToA.
• It is possible to compute an estimated receive power figure for the purposes of this discussion this will be called RX_POWER (see section 4.7.2) . It is also possible to compute an estimated power for just the first path signal – for the purposes of this discussion this will be called FP_POWER (see sectio n 4.7.1) . Using these two calculations it may be possible to say whether the channel is line-ofsight (LOS) or non-line-of-sight signal (NLOS) .
• It is possible to compare the locations of the first path and the peak path in the CIR estimate. In LOS channels the peak path will be close to the first path.
• Where possible the system should use a scrambled time sequence (STS). This allows the DW3000 produce at least 2 estimates of the CIR and so compute 2 independent ToA estimates. As both are measuring the same physical parameter, they should be very close to each other. The CIA algorithm will compute the difference between these estimates and test it against a predefined threshold. If the difference is too great, then an error flag will be raised, and the ToA should not be trusted.

Estimating the signal power in the first path

An estimate of the power in the first path signal may be calculated (in dBm). Depending on the receiver configuration two different formulae are used to do this.

If the RX_TUNE_EN bit is set in DGC_CFG register, described in 8.2.4.1 (DGC):

First Path Power Level = $$10\; \backslash times\; \backslash log\_\{10\}\; \backslash left(\; \backslash frac\{F\_1^2\; +\; F\_2^2\; +\; F\_3^2\}\{N^2\}\; \backslash right)\; +\; (6\; \backslash times\; D)\; -\; A\; \backslash ,\; dBm$$

If the RX_TUNE_EN bit is not set in DGC_CFG register, described i n 8.2.4.1 (No DGC):

First Path Power Level = $$10\; \backslash times\; \backslash log\_\{10\}\; \backslash left(\; \backslash frac\{F\_1^2\; +\; F\_2^2\; +\; F\_3^2\}\{N^2\}\; \backslash right)\; -\; A\; \backslash \; dBm$$

Where:

F ¹ = the First Path Amplitude (point 1) magnitude value (it has 2 fractional bits),

F ² = the First Path Amplitude (point 2) magnitude value (it has 2 fractional bits),

F ³ = the First Path Amplitude (point 3) magnitude value (it has 2 fractional bits),

N = the number of preamble symbols accumulated, or accumulated STS length

• D = th e DGC_DECISION, treated as an unsigned integer in range 0 to 7
• A = is the constant:
  • 113.8 for a PRF of 16 MHz, or
  • 121.7 for a PRF of 64 MHz Ipatov preamble or
  • 120.7 for a PRF of 64 MHz STS.

The values for F1, F2, F3 and N can be read from the register file described i n 8.2.13. F1, F2 and F3 can be read from IP_DIAG_2, IP_DIAG_3, IP_DIAG_4, o r STS_DIAG_2, STS_DIAG_3, STS_DIAG_4, or STS1_DIAG_2, STS1_DIAG_3, STS1_DIAG_4, and N can be read from: IP_DIAG_12 , STS_DIAG_12 or STS1_DIAG_12, depending on th e CIR used. D is read from DGC_DECISION described in DGC_DBG register, see section 8.2.4.2.

Note: These readings will not be available if the CIA is configured to compute minimal diagnostics, see MINDIAG bit in CIA_CONF register.

Estimating the receive signal power

It is possible to calculate an estimate of the receive power level (in dBm). Depending on the receiver configuration two different formulae are used to do this.

If the RX_TUNE_EN bit is set in DGC_CFG register, described in 8.2.4.1 (DGC):

$$RX\; \backslash text\{\; Level\}\; =\; 10\; \backslash times\; \backslash log\_\{10\}\; \backslash left(\; \backslash frac\{C\; \backslash times\; 2^\{21\}\}\{N^2\}\; \backslash right)\; +\; (6\; \backslash times\; D)\; -\; A\; \backslash text\{\; dBm\}$$

If the RX_TUNE_EN bit is not set in DGC_CFG register, described i n 8.2.4.1 (no DGC):

$$RX\; \backslash text\{\; Level\}\; =\; 10\; \backslash times\; \backslash log\_\{10\}\; \backslash left(\; \backslash frac\{C\; \backslash times\; 2^\{21\}\}\{N^2\}\; \backslash right)\; -\; A\; \backslash text\{\; dBm\}$$

Where:

C = the Channel Impulse Response Power value,

• N = the Preamble Accumulation Count value,
• D = th e DGC_DECISION, treated as an unsigned integer in range 0 to 7
• A = is the constant:
  • 113.8 for a PRF of 16 MHz, or
  • 121.7 for a PRF of 64 MHz Ipatov preamble or
  • 120.7 for a PRF of 64 MHz STS.

The values for C and N can be read from the register file described in 8.2.13. C can be found in : IP_DIAG_1, STS_DIAG_1, or STS1_DIAG_1, and N can be read from: IP_DIAG_12 , STS_DIAG_12 or STS1_DIAG_12, depending on th e CIR used. D is read from DGC_DECISION described in DGC_DBG register, see section 8.2.4.2.

Figure 21 shows the typical relationship between the actual receive power and the power estimated by this technique.

Note: Received signal power is sometimes referred by the term received signal strength indication (RSSI)

Figure 21: Estimated RX level versus actual RX level

5 Media Access Control (MAC) hardware features

The DW3000 has an incorporated MAC features on a transmitter and a receiver side to free the host processor from unnecessary interrupts. This helps to increase the overall performance of the system built with DW3000. The sections below describe the features for media access control (MAC) that have been implemented in the DW3000.

5.1 MAC level processing in the DW3000

The DW3000 transmits data from the TX_BUFFER in a frame with data length as specified in the TXFLEN field of the TX_FCTRL, inserting the 2-octe t FCS as the last two octets of the data payload. The DW3000 will not do any other MAC level transmit processing. It is up to the host system software to prepare the correctly formatted frame conforming to the IEEE802.15.4 standard [1] MAC if this is required.

On the receive side, the DW3000 will validate the FCS of the received frame, and can parse frames complying with IEEE802.15.4 standar d [1] to validate and accept only those as configured by the frame filtering configuration bits in the FF_CFG register (as described in sectio n 5.4 below). The DW3000 can also optionally respond to the acknowledgement request bit set in the frame control field, of correctly addressed Data Frames or MAC Command frames, by sending an IEEE802.15.4 standar d [1] acknowledgement frame (as described in section 5.5 below). Note: This only applies to the immediate acknowledgment (Imm-Ack) used to acknowledge Data frames or MAC command frames with the Frame Version field set to 0b00 or 0b01.

The DW3000 will deliver the received data frame in th e RX_BUFFER_0 with its data length reported by the RXFLEN field of the RX_FINFO, and other than the RX activities mentioned in the paragraph above the DW3000 will not do any additional MAC level receive processing. It is up to the host system software to correctly parse the received frame according to the IEEE802.15.4 standar d [1] MAC definition and take whatever additional action is prescribed by the standard, if this is required.

5.2 General MAC message format

The MAC message occupies the PHY Payload portion of the UWB packet as shown in Figure 13. This may be up to 127 octets in length according to the standard, and up to 1023 octets when employing the DW3000's long frame mode, see section 3.4 – Extended length data frames . The general structure of a MAC message consists of a header that identifies the frame, followed by a variable length (possibly zero) payload typically from the upper layers but sometimes (as in the case of MAC command frames) generated within the MAC itself, and finally ended by the MAC footer which is th e FCS (Frame Checking Sequence ) CRC used to detect transmission errors. Figure 22 shows the components of the MAC message frame in more detail, indicating the number of octets in each component.

The MAC header is parsed by the DW3000 as part of the frame filtering function to determine if the destination address matches the IC's address information programmed in Sub-register 0x00:04 – Extended Unique Identifier and Sub-register 0x00:0C – PAN Identifier and Short Address (or if the frame is a broadcast message). This parsing of receive frame is based on the contents of the Frame Control field (at the start of the MAC header).

Figure 22: General MAC message format

5.3 Cyclic redundancy check

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

The DW3000 also includes a CRC checking function capable of automatically calculating the 16-bi t CRC frame check sequence (FCS) during frame reception and comparing this calculate d CRC with the final two octets of the received frame to check that the calculate d CRC matches wit h 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 RXFR event status bit, the result of th e CRC comparison is reported by eithe r RXFCG or the RXFCE status bit being set, i.e. depending on whether or not th e CRCs matched. These three status bits are SYS_STATUS.

Where a CRC is not required it is possible to disable the CRC transmission by employing the setting DIS_FCS_TX (disable FCS transmission) bit in SYS_CFG. This might be done when using a different MAC layer protocol.

5.4 Frame filtering

Frame filtering is a feature of the DW3000 IC that can parse the received data of frame types defined in the IEEE802.15.4 standar d [1], (and also listed i n Table 13 below) 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.

Table 13: Frame type field values

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 RXFR an d RXFCG event status bits are set i n SYS_STATUS) . 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 PHY reception for general details of reception.

Frame filtering is enabled by the FFEN configuration bit in SYS_CFG register. The frame filter is further configured by the various configuration bits in th e FF_CFG register. This register contains ten additional configuration bits (FFAB, FFAD, FFAA, FFAM, FFAR, FFAMP, FFAF, FFAE, FFBC and FFIB) for fine filtering control of the frame types.

Frame filtering rules

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

• The particular frame type must be allowed for reception:
  • o The FFAB configuration bit must be set to allow a Beacon frame to be received.
  • o The FFAD configuration bit must be set to allow a Data frame to be received.
  • o The FFAA configuration bit must be set to allow an Acknowledgment frame to be received.
  • o The FFAM configuration bit must be set to allow a MAC command frame to be received.
  • o The FFAR configuration bit must be set to allow Reserved frames to be received, only a FCS check is performed on these.
  • o The FFAMP configuration bit must be set to allow Multipurpose frames to be received.
  • o The FFAF configuration bit must be set to allow Fragmented/Frak frames to be received, only a FCS check is performed on these.
  • o The FFAE configuration bit must be set to allow Extended frames to be received, only a FCS check is performed on these
• The frame version field must be 0x00, 0x01 or 0x02
• The Destination PAN ID if present must:
  • o Be the broadcast PAN ID (0xFFFF)
  • o Or match th e PAN_ID programmed in PANADR register.
• The Destination Address if present must:
  • o Be the (short 16-bit) broadcast address (0xFFFF)
  • o Or be a short (16-bit) address matching th e SHORTADDR programmed in PANADR register.
  • o Or be a long (64-bit) address matching the EUI_64. Note that long (64-bit) broadcast addresses are not supported.
• If the frame is a Beacon frame then the Source PAN ID must match th e PAN_ID programmed in PANADR register, (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 FF_CFG) and the Source PAN ID matches the PAN_ID programmed in PANADR register.
• If frame has no destination PAN ID and destination address, if will only be accepted (treated as though it is addressed to the broadcast PAN ID and broadcast short (16-bit) address) if the device is configured to allow implicit broadcast (via the FFIB configuration bit in FF_CFG) .
• The FCS (CRC) must be correct for the frame to be accepted.

Frame filtering notes

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

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 i n SYS_STATUS register.

While frame filtering can save some work on the part of the host system, prolonged listening with the DW3000 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 found in FF_CFG register.

Once the FFAA configuration bit is set, all acknowledgement frames are accepted, and the IC does not make any distinction between the 5-octet Imm-Ack (with frame version of 0 or 1) or the more complex Enh-Ack (with frame version of 2). It is up to the host software expecting an Enh-Ack to parse the received frame to identify the Enh-Ack and validate its addressing and other fields accordingly.

When enhanced beacon frames are used, they will be accepted even if the beacon's source PANID does not match the one programmed in the device.

NOTE: For Multipurpose frames the IEEE standard [1] says that Frame version field values other than 0x00 are reserved. The DW3000 does not correctly check the Frame version field of received Multipurpose frames. The host software MAC should validate the version of any Multipurpose frames received and handle the frame accordingly.

5.5 Automatic acknowledgement

The automatic acknowledgement functionality of the DW3000 allows the IC to automatically send an acknowledgement frame 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.4 – Frame filtering for 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 AUTO_ACK configuration bit i n SYS_CFG register.
• The received frame is an Data frames or a MAC command frame with the Frame Version field set to 0b00 or 0b01; the destination address and PAN ID matches the programmed PANID and programmed short address or exrended addess; and, AR (Acknowledgement Request) bit is set.

When these conditions are met the DW3000 will at the end of the reception automatically transition into transmit mode to send the 5-octet immediate acknowledgment (Imm-Ack) frame as defined by IEEE802.15.4 standard [1].

The enhanced acknowledgment (Enh-Ack) when called for by Data or a MAC command frames with the Frame Version field set to 0b02, is not automatically generated. The host software is responsible for decoding/desecuring these frame version 2 frames, interpreting any Information Elements (IEs), and generating the Enh-Ack enhanced with any IEs necessary and securing it before transmission. The AAT bit will not be set.

Automatic ACK turnaround time

The IEEE802.15.4 standar d [1] specifies a 12 symbol +/- 0.5 symbols turnaround time for ACK transmission. In the DW3000 this period is configurable via the ACK_TIM parameter in ACK_RESP_T. It should also be noted that running th e CIA analysis will delay ACK response. To speed up ACK transmission FAST_AAT bit can be set or where the RX timestamp is not required, the CIA analysis may be disabled by clearing both CIA_IPATOV and CIA_STS configuration bits in Sub-register 0x00:10 – System configuration

Frame pending bit

The standard IEEE802.15.4 standard [1] MAC includes a frame pending bit in the frame control at the start of each frame. This bit can be set to indicate more data is coming or in the case of acknowledging a Data Request MAC command frame to indicate that the responding node has data to send to the node soliciting the ACK. Please refer to the standar d [1] for details of this. The DW3000 will automatically determine whether to set the frame pending bit in the automatically-generated ACK frames based on:

• the received frame being a Data Request MAC command frame.
• the address of the device sending the MAC command (Data Request) frame matches one of the four 16-bit addresses programmed into LE_PEND_01 or LE_PEND_23 registers and the data pending bits are set in FF_CFG register : LE0_PEND – LE3_PEND.
• the address of the device sending the MAC command is 16-bits and SSADRAPE bit is set
• the address of the device sending the MAC command is 64-bits and LSADRAPE bit is set
• security bit is not set in Frame Control and frame version is 0 or 1

Host notification

The AAT status bit (SYS_STATUS) indicates that an acknowledgement has been requested. When the FAST_AAT bit is disabled the AAT bit is set at the same time as the RXFCG status event (indicating a good CRC at the end of frame reception). However if FAST_AAT bit is enabled th e AAT bit is set at the same time as the RXFR status event.

If automatic acknowledgement is enabled then the AAT bit can be used during receive interrupt processing to detect that acknowledgement is in progress and thus 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 should be ignored.

5.6 Transmit and automatically wait for response

The DW3000 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 any of the TX and wait-4-response commands (TXW4R, TXW4RCCA, TXW4RDLY, TXW4RDLYREF, TXW4RDLYTS, and TXW4RDLYRS) and the W4R_TIM parameter in the Sub-register 0x01:08 – Acknowledgement time and response time.

Note: If the response that is received is a correctly addressed data (or MAC command) frame requesting an acknowledgement, and assuming frame filtering and automatic acknowledgement are enabled, then the DW3000 will transmit the ACK before it transitions into IDLE_PLL state.

5.7 Pseudo Clear Channel Assessment (CCA) mechanism

For Wireless Sensor Networks application, many of the MAC protocols rely on Clear Channel Assessment (CCA) to avoid collisions with other packets in the air. This consists in sampling the air for a short period to see if the medium is idle before transmitting. For most radios this involves looking for the RF carrier, but for UWB where this is not possible, one approach is to look for preamble to avoid conflicting transmissions, since any sending of preamble during data will typically not disturb those receivers who are demodulating in data mode.

DW3000 has a simple Clear Channel Assessment (CCA) mechanism feature that can be employed before a packet transmission. It works by sample the air for a small amount of time (as configured b y PRE_TOC) to see if preamble can be detected, then if preamble is not seen the transmission is initiated, otherwise a failed transmission is reported with CCA_FAIL event and the host can then defer the transmission typically for a random back-off period after which transmission is again attempted with CCA.

DW3000 will return to IDLE_PLL for the back-off period and do not receive the packet whose preamble was detected, since the MAC (and upper layer) wants to transmit and not receive at this time.

To transmit a packet with CCA check CMD_CCA_TX command is used. If the device has detected a clear channel, the packet will be sent and TXFRS event reported. Although the detection of clear channel is as a result of preamble timeout counter expiring, the RXPTO event will not be raised in this case.

Although the CCA can be used to avoid collisions with other packets on the air, the mechanism is only looking for preamble thus will not detect PHR or data phases of the packet.

This CCA mechanism may have little benefit, but costs energy drain by turning on the receiver for a period before every transmission. The aloha CCA mechanism of simply sending may be more efficient, since even in collision cases message delivery can succeed. It is recommended that careful analysis and experimentation be undertaken for the target use cases to decide on this point.

5.8 Data confidentiality and authenticity

IEEE802.15.4 standar d [1] supports the following security services: data confidentiality, data authenticity and replay protection. DW3000 has an advanced encryption standard (AES) engine that can perform cryptographic transformation on received frames or prior to transmission of frames. For this purpose the AES engine can use a TX Buffer, Rx Buffer or a separate scratch buffer as shown in Figure 23.

The AES engine performs encryption/decryption and authentication of data and can either perform the operation within the same buffer or transfer the data (during the process) from one buffer to another (e.g. from RX to TX, or from scratch buffer to TX o r STS_KEY register).

The AES engine can also decrypt key data (i.e. an encrypte d STS_KEY) into the STS_KEY register. This means that the host can write encrypte d STS_KEY over SPI into scratch RAM memory and then run the DW3000 AES engine to decryp this into the STS_KEY register prior to use of the secure ranging modes (se e6 Secure ranging / timestamping) .

The AES-DMA engine is fully configurable by the host from a source/destination/sub-address/burst-size point of view. The completion of the AES operation (AES_DONE event) as well as error conditions such as an AES decrypt tag error or DMA error (AES_ERR event) are signalled in the system status register (SYS_STATUS) . There is also an AES status register (AES_STS) which gives more details about the performed AES operation.

Figure 23: AES engine source/destination buffers

AES Configuration

Before the encryption or decryption of the data, the AES engine needs to be configured with:

• the MIC size (TAG_SIZE) , which can be 0, 4, 6, 8, 10, 12, 14 or 16 bytes
• the KEY size (128, 192 or 256-bits) and location (KEY can be stored in DW3000 registers, or OTP, or AES KEY RAM) . If a KEY from DW3000 registers or AES KEY RAM is used then it needs to be written to AES_KEY register or AES KEY RAM location.
• the type of operation (encryption or decryption)
• the type of AES core to use: GCM or CCM*

General TX Encryption flow

The following steps are taken to transmit an encrypted data (assuming above configuration steps are already done):

• Write the IV value in the AES_IV registers : AES_IV0, AES_IV1, AES_IV2, an d AES_IV3. GCM uses 96-bit IV value and CCM* 128-bit.
• Specify source buffer (SRC_PORT) from which the plaintext data is taken and destination buffer (DST_PORT) into which the encrypted data is placed.
• Load the selected AES key. When using CCM* mode, AES key must be loaded each time prior to starting of AES engine. This key update is needed even if the key remains the same.
• Start the AES process (DMA + encryption) by setting the AES_START bit. Wait for AES_DONE or AES_ERR status events.

• Repeat the above steps to encrypt more data, e.g. when using the scratch buffer the max amount of data that can be processed at a time is 127 bytes.
• Once complete, issue start TX command to transmit the encrypted data frame.

General RX Decryption flow

The following steps are taken to decrypt received encrypted data (assuming above configuration steps are already done):

• Write the IV value in the AES_IV registers : AES_IV0, AES_IV1, AES_IV2, an d AES_IV3. GCM uses 96-bit IV value and CCM* 128-bit.
• Specify source buffer (SRC_PORT) from which the encrypted data is taken and destination buffer (DST_PORT) into which the plain text data is placed. For example encrypted RX data is available in RX buffer, which can then be decrypted into the same RX buffer.
• Load the selected AES key. When using CCM* mode, AES key must be loaded each time prior to starting of AES engine. This key update is needed even if the key remains the same.
• Start the AES process (DMA + decryption) by setting the AES_START bit. Wait for AES_DONE or AES_ERR status events.
• Read resulting plaintext RX data from the buffer
• Repeat the above steps to decrypt more data, e.g. when using the scratch buffer then the max amount of data that can be processed at a time is 127 bytes.

Sample use cases

5.8.4.1 Encrypt TX data prior to transmission

These are the steps to encrypt TX data prior to transmission:

• Configure the AES KEY, e.g. the host writes the desired AES KEY into the AES_KEY register.
• Configure the AES core type (CCM* or GCM), source and size of the KEY,
• Select encryption mode and MIC size
• Construct the nonce, and set up header and payload buffer pointers (source (SRC_PORT) and destination (DST_PORT) ). For example host can write plaintext data into the TX buffer and then select the destination as the TX buffer and the data will be encrypted into the same buffer. Otherwise host could write the plaintext data into the scratch memory and then instruct the AES engine to encrypt it into the TX buffer.
• Run the AES engine and check status
• Transmit the encrypted packet

5.8.4.2 Decrypt RX data after packet reception

These are the steps to decrypt RX data following a packet reception:

• Following good packet reception, the host needs to read the received data and check the frame format, security and then configure the AES engine to decrypt the payload.
• Configure the AES KEY, e.g. the host writes the desired AES KEY into the AES_KEY register.
• Configure the AES core type (CCM* or GCM), source and size of the KEY,
• Select encryption mode and MIC size
• Construct the nonce, and set up header and payload buffer pointers (source (SRC_PORT) and destination (DST_PORT) ). For example host can set the destination to be the same as the source, i.e.

the same RX buffer. This allows the encrypted data in the buffer to be overwritten by the decrypted (plaintext) data.

• Run the AES engine and check status
• Read out the decrypted data

5.8.4.3 Decrypt STS KEY into STS KEY registers

These are the steps to decrypt encrypted STS KEY (transferred over SPI into the scratch buffer) into the STS_KEY register e.g. prior to transmission or reception of packets with STS:

• The host and DW3000 should have same AES KEYs programmed (they should be paired). The DW3000 KEY is stored in OTP.
• The host would then encrypt the STS KEY and transfer it over SPI into the scratch buffer, there should be no header but the MIC should be present
• Configure the AES core type (CCM* or GCM), source and size of the KEY, and the MIC size
• Construct the nonce, and set up header and payload buffer pointers (source and destination). The source (SRC_PORT) is the scratch buffer and destination (DST_PORT) STS_KEY register.
• Run the AES engine and check AES status events (AES_DONE, AES_ERR)

Note on STS KEY decryption

Consider a following example. A Secure Element host (SE) which derives STS KEY (prior to encryption) as: sts_key[16] = { 0xaa , 0xbb, 0xcc, 0xdd, 0x11, 0x22, 0x33, 0x44 …. 0x55, 0x66, 0x77, 0x88}, i.e. the 128-bit STS_KEY = 0x aa bbcc.....667788.

The SE encrypts this STS_KEY (with STS KEY encryption KEY (STS_KEK)) and writes it into the device (scratch buffer), then the device needs to decrypt it with a matching STS_KEK from e.g. OTP and write the decrypted STS KEY into STS KEY registers (STS_KEY) .

The DMA engine inside AES block can be configured as either big endian (CP_END_SEL = 0) or little endian (CP_END_SEL = 1), se e DMA_CFG register. When big endian is used, the MSB of the STS KEY is in the lowest address otherwise the MSB is the highest address.

Considering, as an example, if sts_enc = { 0xaa , 0xbb, 0xcc, 0xdd, 0x11, 0x22, 0x33, 0x44 …. 0x55, 0x66, 0x77, 0x88}, 0xaa is sent first to AES engine. Thus the data is with big endian format and is decrypted into STS_KEY register as shown i n Table 14 ( 0xaa is in the lowest address location):

Table 14: Decrypted STS KEY bytes (with big endian format)

For the little endian format, the STS KEY data will look like, as shown i n Table 15 ( 0xdd is in the lowest address location):

Table 15: Decrypted STS KEY bytes (with little endian format)

But what wis actually required is that the STS KEY data looks like, as shown in Table 16:

Table 16: Decrypted STS KEY bytes (with little endian format and swapped by SE prior to encyption)

Thus the SE must re-arrange the data before encryption, the bytes (of the derived STS KEY) need to be swapped: byte[15]=byte[0]; byte[14]=byte[1] etc... prior to encryption with STS KEK.

Note on source and destination buffers

When specifying a source and destination buffer address (and offset within the buffer) the buffer size should be sufficient for the DMA transfer. If the size is smaller than the transfer, the DMA transfer error (AES_ERR) may not be correctly flagged by the device. In some circumstances the internal AES block can lock up and the only way to recover is to perform a reset of the device (soft or hard)).

To avoid such errors it is require to always ensure that the buffers and sizes of transfers should be properly configured, i.e.:

Header length + Payload length + MIC length < Total buffer size.

6 Secure ranging / timestamping

One of the main features of the DW3000 (differentiating it from the DW1000) is its secure timestamping ability.

The timestamping ability of the DW1000 is based on accumulated correlation of the repeated symbols of the 802.15.4 standard preamble sequence. Please refer to the IEEE 802.15.4 standar d [1], for more details of the packet format. When th e SFD is detected a coarse receive timestamp is taken and then the accumulator state, which essentially provides the radio channel impulse response , CIR, is used to find the first arriving ray of RF energy and adjust the RX timestamp to give the sub-nanosecond precision achieved by the IC.

Since the CIR accumulation is based on a repeated symbol of a known sequence of pulses defined by preamble code, it is possible for an attacker to send this same symbol (set of pulses) with a time offset which makes it appear like an earlier arriving ray in the CIR, and thus confuse the IC into reporting an earlier arrival time for the message. This could, for instance, foreshorten a ranging result, thus fooling an access system into thinking the user is closer than he actually is.

To remove the possibility of such an attack the DW3000 has the ability to include a scrambled sequence in the packet, which can be used to obtain an RX timestamp that cannot be attacked in this way. This scrambled timestamp sequence (STS) is generated in accordance with the IEEE 802.15.4z amendment [2] , and consists of a sequence of randomised pulses generated by an AES-128 CPRNG (cryptographic pseudorandom number generator) block in counter mode. This is also termed a deterministic random bit generator (DRBG). Only valid transmitters and receivers know the correct seed (i.e., key and data) to generate the sequence for transmission and for reception to cross correlate and accumulate to produce a CIR estimate from which to determine the RX timestamp.

When the STS modes are enabled the DW3000 transmitter will insert the STS in the position shown in Figure 13, and the receiver will expect it to be present accordingly. The STS is generated by the AES-128 block output and is determined by a seed consisting of a 128-bit key, and a 128-bit nonce (a number that should only be used once). The nonce is updated during the STS generation by incrementing the counter once for every 128 pulses produced. When transmitting and receiving devices are using aligned seeds (i.e., same key and nonce) with the counter values aligned, the receiver generates a secure version of the CIR by correlating with the matching scrambled pulse sequence. The resultant timestamp is thus secure against attack.

As shown in Figure 24, the STS consists of an active segment bracketed at either end by a gap (of 512 chips or approx. 1 μs). The length of the STS (active segment) is specified in units of 512 chips (~1 μs). In BPRF mode, where the STS pulse spacing is 8 chips, the mandatory STS length of 64 units has an active segment of 4096 pulses. For convenience we sometimes call this 512-chip (~1 μs) period an STS symbol .

To contrast the three STS packet configuration options:

• STS Packet Configuration mode 1 has the STS directly after the SFD which means it is early (and in a deterministic position). This allows the CIA to start processing th e STS CIR earlier (assuming it is not processing the preamble CIR) , while the IC continues to receive the PHR and the data payload. This mode saves time and energy (as compared to configuration mode 2). However data reception performance may be poorer when there is a misalignment of the STS sequences, i.e., where the transmitter's seed info (including counter) does not match the receiver's giving poor correlation.
• STS Packet Configuration mode 2 has the STS at the end of the packet. This has the benefit that the receiver can receive the data as normal even if it has misalignment of the STS sequence generation seeds between the transmitter and the receiver. Also the packets by a device using this mode can be received by a device employing the original IEEE802.15.4 standard [1] UWB packet structure, which might be an advantage in some circumstances. In using STS Packet Configuration mode 2 the frame payload can carry information allowing the receiving node to determine the correct alignment of the STS generation seed (key + nonce data) that it can use to achieve alignment for future messages. Obviously, transmission of sensitive information like the STS key and nonce counter state needs to be encrypted/protected so that an attacker cannot learn this secret. N.B. In this mode, for correct operation it is required that the data length is non-zero.

Note: This mode can potentially be attacked. The mechanism has the attacker corrupting the true PHR to signal a longer data payload than the true payload, adding data payload after the true payload making sure that the CRC of the longer frame is correct, while also recording the true STS of the valid transmitter and playing it at the end of the longer payload but altering its alignment so that it appears to arrive earlier in time resulting in a shorter time-of-flight estimate than would otherwise be the case. This attack can be easily thwarted by: (a) ensuring that the true message length always known, i.e. the length is either a constant or is included securely encrypted in the frame data payload, and then (b) having the receiver discard and ignore frames of the wrong length. Simply encrypting the data payload should also be sufficient to thwart this attack, because, since the attacker does not know the encryption key, it will be unable to generate a valid MIC (message integrity check code) for the longer data payload, and then the receiver's incoming security processing should simply discard and ignore the invalid frame.

• STS Packet Configuration mode 3 has STS directly after th e SFD (similar to configuration mode 1), however in this mode the UWB packet ends with STS and there is no PHR or PHY payload (MAC frame) following. This could save time and energy (as compared to configuration modes 1 and 2).

The STS packet configuration is configured via th e CP_SPC field in Sub-register 0x00:10 – System configuration .

The STS length is configured via the CPS_LEN field in th e STS_CFG register. The STS length is programmable in steps of 8 units (i.e., each step is ~8 µs, or 8 x 512 chips). The minimum length supported is 32 and the maximum supported length is 2048. The IEEE 802.15.4z mandates only a single length of 64 x 512 chips, (or 64 x 64 pulses @ 64 MHz PRF), which is approximately 64 µs duration. As noted the equivalent PRF during STS is 64 MHz.

The 128-bit STS key is programmed into STS_KEY, while the 128-bit initial value for the nonce is loaded into the device via STS_IV.

When the DW3000 is enabled to transmit or receive a packet incorporating an STS, the AES-128 block generates a randomised set of pulses of positive and negative polarity, the CPRGN is shown in Figure 25 below, advancing the counter by one step for every 128 pulses generated. The counter would thus advance by 32 for each completed transmission, or reception, of the IEEE 802.15.4z mandated 64 x 64 pulse BPRF mode STS.

To achieve secure ranging/timestamping both parties of a two-way ranging exchange should be configured the same way, i.e. to use the same STS length and the same key and nonce values for the generation of their STS sequences.

Figure 25: AES in counter mode based CPRNG

Since the counter automatically advances as the STS is generated in the transmitter and receiver, the counter state in two units can remain aligned as messages are sent and received in a typical two-way ranging exchange. Where alignment is lost, or to maintain alignment in multi-node systems the counter state should be reprogrammed by the setting the new value into the STS_IV register. Optionally, the counter state could be sent from one device to another to update the STS_IV register. Clearly any communication of the seed (key and/or IV) would have to be done securely to avoid them becoming known to an attacker. Note also that during transmission and reception of the STS the state of the counter may be in flux as it generates the scrambled sequence, so before any reading or writing of the STS_IV register, it is recommended that the DW3000 is not active with any transmission and reception activities.

When STS is included in the packet there are two separate accumulations of CIR in the receiver. The first accumulation occurs during the preamble reception and the second occurs during the STS reception. Both these CIR may be read through Register file: 0x15 – Accumulator CIR memory. Access to th e CIR data is not needed for ranging measurements, however this ACC_MEM may be of interest to the system design engineers to visualise the radio channel for diagnostic purposes.

The accurate receive timestamp for a received packet is computed by finding the first arriving path or ray within the accumulated CIR, which is the function of the leading edge algorithm, also called the channel

impulse analyser (CIA) algorithm. This algorithm processes the CIR (in the accumulator) to find the leading edge and estimate the RX timestamp for a received packet. Th e CIA may be applied t o CIR resulting from preamble and/or STS sequences. Th e CIA is configured and controlled through the Sub-registers in CP_CONF0, CP_CONF1, IP_CONF0 and IP_CONF1.

Assuming it is enabled, once both the preamble and STS CIRs have been received, the CIA begins running on the preamble first followed by the analysis of the STS CIR. The CIA delivers the receive timestamp for a received packet through the RX_STAMP field in Sub-register 0x00:64 – Receive time stamp. To ensure the integrity of the receive timestamp based on th e STS, the user must check that the CP_TOAST quality status indicator (in CP_TS) is not indicating any issues with the STS CIR analysis.

NB: The host should not attempt to read ACC_MEM until the CIA has finished its processing, (as signalled by the CIADONE event status flag), since this may give rise to a conflict with the CIA accesses to the CIR memory which may interfere with the generation of a good RX timestamp result.

Note : It is also very important to assess that quality of the STS accumulation before accepting that a receive timestamp CP_TOA value is sufficiently good enough to be trusted in a two-way ranging exchange. This is a unitless value that summarizes the results of the STS quality algorithm that is monitoring the reception of the STS. For high signal levels this measurement should be very high but its value will reduce as the signal level reduces. A n ACC_QUAL value (in STS_STS) that is <60% of the STS length indicates that the reception of the STS was too poor for the first path analysis to obtain a reliable ToA and so the received timestamp based on STS should not be trusted.

For example for a preamble sequence using 64 MHz PRF (i.e. TX_PCODE is in range 9-12) and an STS length of 128 (i.e. CPS_LEN is set to 15), the STS based receive timestamp (CP_TOA) value should only be trusted when the STS accumulation quality (CPS_ACCQUAL) value is greater than ≥ 77 (i.e. 60 % of 128).

As mentioned above STS uses a continually varying sequence. This means that a colliding packet will not line up with the desired signal. As a result, the ToA will be unaffected. If security is not a concern, then overhead of key management and counter control is undesirable. For this reason, the DW3000 includes a special STS mode that uses a code optimized for ToA performance. This is known as the Super Deterministic Code (SDC). If SDC is enabled (by CP_SDC bit), then the STS will be populated with the SDC code. Since it is a time varying sequence optimized for ToA performance it will better tolerate packet collisions without requiring any key management.

It is important to remember that the SDC mode does not provide security but will increase confidence in the ToA when the on-air packet density is high. For this reason, we would recommend that an SDC based STS is used when security is not a requirement.

7 Other features of the IC

7.1 External Synchronisation

This feature is used to synchronise DW3000 with external clocks, events or with other DW3000's. For example, it allows for TDoA RTLS systems employing wired clock synchronisation of the anchor nodes.

The DW3000 external synchronisation feature allows 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 packet in a deterministic way with respect to the assertion of the SYNC input pin and an external 38.4 MHz clock supplied on the EXTCLK pin.
• c) The ability to synchronise receive time stamping to an external counter.

Figure 26: DW3000 External Synchronisation Interface

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

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 DW3000 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 DW3000s are driven by the same reference clock and an 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 DW3000 for OSTR mode, the OSTR_M bit in th e EC_CTRL register is set and th e OSTS_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 th e OSTS_WAIT programmed value, the DW3000 timebase counter will be reset. See Register file: 0x04 – External sync control and RX calibration for register details.

At the time the SYNC signal is asserted, the clock PLL dividers generating the DW3000 124.8 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 OSTS_WAIT value programmed will dictate the phase relationship and should be chosen to give the desired phase relationship, as given b y OSTS_WAIT modulo 4. An OSTS_WAIT value of 33 decimal is recommended, but if a different value is chosen it should be chosen so that OSTS_WAIT modulo 4 is equal to 1, i.e. 29, 37, and so on.

7.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 +20 dB above the normal UWB regulation levels. To achieve this with the DW3000 it is necessary to employ external amplification of the transmitted signal. The DW3000 provides signals (using the GPIO lines in a special mode) to control the turn-on of an external power amplifier and to control an external analog switching of the transmitter and receiver signal paths appropriately. This mode of operation utilises the DW3000 pin s EXTPA, EXTTXE and EXTRXE as configured via the fields of the GPIO_MODE register.

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.

7.3 Using the on-chip OTP memory

The DW3000 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 DW3000 testing, while othe r 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 EUI_64 as the IC comes out of reset (see EUI_64 for details of the EUI functionality).

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

OTP memory map

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

Table 17: OTP memory map

The QSR ("Special function register") is a 32-bit segment of OTP that is directly readable via the register interface upon power up. To program the SR register follow the normal OTP programming method but set the OTP address to 0x60. As this is part of OTP boot sequence the new value will be present in the QSR register following the next boot up sequence.

The various tune values (LDOTUNE_CAL, BIASTUNE_CAL etc.) can be automatically loaded from OTP into the respective registers. This will ensure the device is using optimal calibration and tuning parameters for given configurations. The automatic loading (kicking) of these values is described insection 8.2.12.3 Sub-register 0x0B:08 – OTP configuration.

It is left up to the customer, but in Decawave's evaluation kits which have been calibrated, the XTAL_Trim and OTP Revision values are programmed into OTP memory addresses 0x1e and 0x1f. Then in the dwt_initialise() AP I [3] the XTAL trim value is copied to XTAL_TRIM.

Programming a value into OTP memory

The programming of the OTP requires a sequence of steps please see API functions [3].

Reading a value from OTP memory

The reading of an OTP memory address consists of a number of steps. Please see the API function [3]: dwt_otpread(uint16 address, uint32 *array, uint8 length) of how to read OTP memory.

7.4 Measuring IC temperature and voltage

The DW3000 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 from a battery voltage monitor on the VDD1 power supply input. These readings can be manually run under host control or they can be configured to be run automatically each time the DW3000 enters the WAKE_UP state. This automatic mode allows the temperature and voltage to be read while the device is in a low power state, which allows to read the temperature without internal heat up and the unloaded battery voltage. More details can be found in Register file: 0x08 – Transmitter calibration block section and the description of the ONW_RUN_SAR bit of Sub-register 0x0A:00 – AON on wake configuration.

7.5 The brownout detector

The DW3000 incorporates a brownout detection feature to warn the system about the condition of the IC supply voltage dropping below a pre-set brownout threshold of approx. 1.5 volts, which will reset the IC. The role of the brownout detector is to detect drops in the supply during the higher current TX or RX modes. This should not happen in normal operation when there is sufficient power supply current and capacitance available, but could happen in a battery powered design with insufficient remaining charge or insufficient capacitance available to supply the current needs of the device. A brownout means that the IC circuits have insufficient supply for correct operation likely to result in poor performance or operational issues.

The elements involved in the brownout detection feature are:

• The VWARN event flag bit in SYS_STATUS . If a brownout event is detected this bit will get set and it will remain set until it is explicitly cleared by writing a 1 to it, or the IC is reset.
• The VWARN event can also be used to trigger an interrupt to the host microprocessor if the corresponding mask bit, VWARN_EN, is set in Sub-register 0x00:3C – System event enable mask.

Enabling the voltage comparator will set the VWARN event flag bit in SYS_STATUS register. This initial VWARN event should be ignored and the event flag should be cleared (by writing 1 to VWARN) . Subsequent VWARN events will signal drop in the supply voltage.

8 The DW3000 register set

The DW3000 is controlled by an associated host microcontroller system using the SPI interface to access a series of registers within the device. The DW3000 register set includes configuration registers, status registers, control registers, data buffer registers, and diagnostic registers. Section 8.1 – Register map overview gives an overview of the register layout and then section 8.2 – Detailed register description describes each individual parameter in detail. There is also a set of single octet commands to initiate certain IC activities (e.g. TX, RX, etc) which are described in secion 9 – Fast Commands . The SPI transaction formats are described in section 2.3 – The SPI interface .

8.1 Register map overview

The register map overview is given in Table 18. This lists the registers in address order, by register file ID and it gives a brief high level description of the register. Section 8.2 gives a detailed description of each register.

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

Table 18: Register map overview

8.2 Detailed register description

Terminology

Sectio n 8.1 gives an overview of the DW3000 register set presenting all top level register file addresses in Table 18. This section describes in detail the contents and functionality of these register files and their subregisters in separate sub sections. In each case the row fro m Table 18 is reproduced with a hexadecimal register 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 (5-bits) and SS (7-bits) 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 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 to.

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:

Register file: 0x00-0x1 – General configuration registers and AES

Register map register files 0x00 and 0x01 are concerned with the use of the various device configurations and AES block configuration. It contains a number of sub-registers. An overview of these is given by Table 19. Each of these sub-registers is separately described in the sub-sections below.

Table 19: Register file: 0x00-0x1 – General configuration registers overview

8.2.2.1 Sub-register 0x00:00 – Device Identifier

Register file: 0x00-0x1 – General configuration registers, sub-register 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. 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. The DEV_ID register contains the following sub-fields:

The fields of th e DEV_ID register identified above are individually described below:

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

8.2.2.2 Sub-register 0x00:04 – Extended Unique Identifier

Register file: 0x00-0x1 – General configuration registers, sub-register 0x04 of register file 0x00 is the Extended Unique Identifier register. For IEEE802.15.4 standard [1] 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, (se e 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 DW3000 or as an alternative the DW3000 has a one-timeprogrammable memory area that may be programmed with the EUI during product manufacturing. Please refer to section 7.3 – Using the on-chip OTP memory for details of programming values into OTP.

If needed the host can read the value from the OTP and program it into this EUI register.

Certain IEEE802.15.4 standar d [1] 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 DW3000's transmit buffer.

The EUI register is used by the Receive Frame Filtering function, see sectio n 5.4 details. When frame filtering is operational the DW3000 decodes each received frame according to the IEEE802.15.4 standar d [1] 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 compatible with the octet ordering of the 64-bit source address fields of IEEE802.15.4 standard [1] MAC frames easing the task of inserting it into a frame for transmission.

8.2.2.3 Sub-register 0x00:0C – PAN Identifier and Short Address

Register file: 0x00-0x1 – General configuration registers, sub-register 0x0C of register file 0x00 contains two 16-bit parameters, the PAN Identifier and the Short Address . When the DW3000 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 DW3000's receive frame filtering or automatic acknowledgement generation functions.

In an IEEE802.15.4 standard [1] 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 DW3000 decodes each received frame according to the IEEE802.15.4 standard [1] MAC specification and when it determines that a 16-bit destination address is present in the frame, the DW3000 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 section s 5.4 an d 5.5 for details of the frame filtering and automatic acknowledgement functionality.

The PANADR register contains the following sub-fields:

The host software (MAC) only needs to program this register if it is using the DW3000's receive frame filtering and automatic acknowledgement generation functions. The sub-fields are:

8.2.2.4 Sub-register 0x00:10 – System configuration

Register file: 0x00-0x1 – General configuration registers, sub-register 0x10 of register file 0x00 is the system configuration register. This is a bitmapped register. Each bit field is separately identified and described below. The SYS_CFG register contains the following bitmapped sub-fields:

The fields of th e SYS_CFG register identified above are individually described below:

8.2.2.5 Sub-register 0x00:14 – Frame filter configuration

Register file: 0x00-0x1 – General configuration registers, sub-register 0x14 of register file 0x00 is the IEEE802.15.4 standar d [1] MAC frame address filter configuration register. This is a bitmapped register. Each bit field is separately identified and described below. The FF_CFG register contains the following bitmapped sub-fields:

Note: For any of these bits to apply FFEN bit i n SYS_CFG must also be set.

Definition of the bit fields within FF_CFG bitmap: -

8.2.2.6 Sub-register 0x00:18 – SPI CRC read status

Register file: 0x00-0x1 – General configuration registers, sub-register 0x18 of register file 0x00 is the status register for the SPI read CRC value of the SPI CRC function. This is the CRC value resulting from each SPI read when SPI CRC mode is enabled via the SPI_CRCEN bit in Sub-register 0x00:10 – System configuration . For more details of SPI CRC operation please refer to § 2.3.1.3 – SPI CRC mode .

8.2.2.7 Sub-register 0x00:1C – System time counter

Register file: 0x00-0x1 – General configuration registers, sub-register 0x1C of register file 0x00 is the System Time Counter register. The device's 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 = 63.8976 GHz.

The SYS_TIME register only counts in the IDLE_PLL , RX and TX states (were the digital PLL enabled), and it only contains the 32 most significant bits of the device's system time. In all other states the system time counter is disabled and this register is not updated. When it is active the SYS_TIME register is incremented at a rate of 125 MHz and in units of 2. The least significant bit o f SYS_TIME is always zero. The internal device's counter wrap period is 2 ⁴⁰ ÷ (128×499.2 MHz) = 17.2074 seconds.

Note: once this register is read the system time value is latched and any subsequent read will return the same value. To clear the current value in the register an SPI write transaction is necessary, the following read of the SYS_TIME register will return a new value.

8.2.2.8 Sub-register 0x00:24 – Transmit frame control

Register file: 0x00-0x1 – General configuration registers, sub-register 0x24 of register file 0x00, 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 th e TX_FCTRL register identified above are individually described below:

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

8.2.2.9 Sub-register 0x00:2C – Delayed send or receive time

Register file: 0x00-0x1 – General configuration registers and AES, sub-register 0x2C of register file 0x00, 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 packet, or to turn on the transmitter and send a packet. The units are one half of the 499.2 MHz fundamental frequency, (~ 4 ns). The least significant bit of this register is ignored, i.e. the smallest value that can be specified is 2, i.e. 8 ns. Delayed send can be initiated by any of the following commands: CMD_DTX , CMD_DTX_TS, CMD_DTX_RS, CMD_DTX_W4R, CMD_DTX_TS_W4R or CMD_DTX_RS_W4R similarly the delayed receive can be initiated by any of the following commands: CMD_DRX, CMD_DRX_TS o r CMD_DRX_RS. For more information see sections 3.3 Delayed transmission and 4.3 Delayed receive

8.2.2.10 Sub-register 0x00:30 – Delayed send or receive reference time

Register file: 0x00-0x1 – General configuration registers and AES, sub-register 0x30, the Delayed Send or Receive Reference Time, is used to specify a time (at which an an event happened, e.g. Beacon was sent) and any value in DX_TIME is added to this register before either the receiver or transmitter are turned on. The unit is one half of the 499.2 MHz fundamental frequency, (~ 4 ns). The least significant bit of this register is ignored, i.e. the smallest value that can be specified is 2, i.e. ~ 8 ns. Delayed send with respect to reference time is initiated by CMD_DTX_REF or CMD_DTX_REF_W4R. Delayed receive with respect to reference time is initiated by CMD_DRX_REF. For more information see section 3.3 Delayed transmission and 4.3 Delayed receive .

8.2.2.11 Sub-register 0x00:34 – Receive frame wait timeout period

Register file: 0x00-0x1 – General configuration registers, sub-register 0x34 of register file 0x00 is the receive frame wait timeout period. It is a 20-bit wide register with a unit of 512/499.2 MHZ (~ 1.0256 µs). The receive frame wait timeout function is provided to allow the host processor to enter a low power state awaiting a valid receive frame and be woken up by the DW3000 when either a frame is received or the programmed timeout has elapsed. While many host systems like microcontrollers have timers that might be used for this purpose, including this RX timeout functionality in the DW3000 allows additional flexibility to the system designer in selecting the microcontroller to optimise the solution. The frame wait timeout is enabled by the RXWTOE in Sub-register 0x00:10 – System configuration .

When the receiver is enabled (and begins hunting for the preamble sequence) an d 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 RXFTO (Receiver Frame Wait Timeout) bit in the status register, (and resets the counter).
• b) A valid receive frame arrives and sets the RXFR an d RXFCG bits in the status register. This stops the receive frame wait timer counter so RXFTO will not be set.
• c) Host can issue transceiver off command (CMD_TRXOFF) at anytime to stop the RX and disable RXFTO.

The RX frame wait timeout period should only be programmed when the IC is in IDLE_PLL state, before the receiver is enabled. Programming the RXFTO at other times (e.g. in RX state) is not prevented but may result in unpredictable behaviour.

8.2.2.12 Sub-register 0x00:38 – System control

Register file: 0x00-0x1 – General configuration registers, sub-register 0x38 of register file 0x00 is the system control register. This register is used when testing Continuous Frame test mode (se e TX_PSTM) , to start the transmissions. Bit 0 needs to be set to 1 to start the transmissions.

8.2.2.13 Sub-register 0x00:3C – System event enable mask

Register file: 0x00-0x1 – General configuration registers, sub-register 0x3C of register file 0x00 is the system event mask register. These are aligned with the event status bits in the SYS_STATUS register. Whenever a bit in th e SYS_ENABLE 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 thi s SYS_ENABLE 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_ENABLE register contains the system event mask bits identified and described below:

The system event mask bits of the SYS_ENABLE register identified above are individually described below:

8.2.2.14 Sub-register 0x00:44 – System event status

Register file: 0x00-0x1 – General configuration registers, sub-register 0x44 of register file 0x00 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_ENABLE, Sub-register 0x00:3C – System event enable mask, 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 packet 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 '1' to the bit position (writing '0' has no effect).

The SYS_STATUS register contains the system event status bits identified and described below:

The system event status bits of the SYS_STATUS register identified above are individually described below: