We’ll begin by considering one of the simplest configurations. This configuration is also detailed from another perspective on YouTube Step 1: Configure the device Let’s begin by configuring the device into LTE mode, TDD on only channel 1. The Carriers tab should be acceptable to those using the lower frequency variant of the EVB board. If you’re using the higher frequency EVB variant, adjust these carrier frequencies to suit. Step 2: Confirm your Configuration When developing a configuration such as this it’s always best to confirm the RF signal chains operate as you expect before attempting to handle complex configurations, such as Auto TDD. Here we’ll simply turn on the Tx and the Rx confirm the configuration works as expected. For the Tx, we’ll transmit a single tone at -1dBFS, 2MHz offset from the carrier, as shown below. We can confirm the Tx operation using a spectrum analyzer: For the Rx, we’ll use a signal generator to feed a 902MHz tone into Rx1A at -10dBm. The below image shows the results of a working Rx signal chain. Again, all frequencies listed here must be adjusted if your setup uses the high frequency eval board. Step 3: Plan and Implement your Timings: More than for any other setup possible in TES, Automated TDD benefits from having a clear and concise visualization of the end goal. This guide will go through several key considerations that should be accounted for. For configuration 0, our starting point is a state machine which works like this: For those unfamiliar with common LTE TDD timings, we’ll take some time to elaborate on the diagram above. The “Downlink” (DL) and “Uplink” (UL) frames correspond to the times during which we are Transmitting and Receiving respectively. The “Special Subframe” (SS) is the time set aside for the switch between Tx and Rx operation. In this particular case, each frame is assigned 1ms, giving the entire sequence a length of 5ms. The evaluation platform used with the ADRV9001 Eval Board (either the Xilinx ZC706 or the ZCU102) uses a 5ns clock period, meaning we can count the frame duration in terms of clk cycles. The signals related to the Eval Platform are designated T/Rx Pin and T/Rx DMA. The “Pin” signal refers to the respective channel Enable Pin. The channel DMA (“Direct Memory Access”) signal is a signal which only exists on our FPGA platform. It is used to control access of the internal memory on the FPGA by the SSI ports on the ADRV9002. When Tx DMA is asserted, the respective Tx channel can read data from the FPGA memory. When the Rx DMA is asserted, the respective Rx channel can write to the FPGA memory. When either signal is deasserted, that channel has no access to the FPGA memory. The naïve approach for this setup would be to implement this simplified timing literally, then use trial-and-error tactics to adjust your timings. Certainly trial-and-error will be needed at some point but taking this approach will lead to problems. Let’s explore them briefly. Don’t follow these next images, they are for demonstration purposes only. The Auto TDD tab will be explained in full after this example. Implementing a 5ms frame requires 1,000,000 clock cycles at a 5ns clock period. As per the diagram above, any instance of a signal rising from low to high is regarded as a signal assert. Likewise, any instance of a signal falling from high to low is regarded as a signal deassert. Using the timings (in clk) outlined above, we can simply implement the Up- and Downlink subframes with little effort. The naïve result is shown below. However, this naïve approach takes absolutely nothing into account. There’s no time given to the RF signal chains to power on and calibrate, or for the data to propagate through the signal chain. The Tx signal chain in this example likely won't be affected too badly, as we are only transmitting a single tone (more consideration would be needed if we were transmitting modulated data) however the Rx signal chain will be met with simply unacceptable amounts of distortion. A working Auto TDD setup will see no zeros in the output spectrum, however below we see ~10us of data padded with 0’s: Tx1 Output Power vs Time: Rx1 Input Spectrum (903MHz, -10dBm) So, knowing the penalty for not taking the signal chain timings into account, let’s now detail how to account for them. From this point, follow along with the guide. We’ll begin by inspecting the TDD Enablement Delays tab in TES. This tab houses a collection of estimations to help you account for the delays in your system. There are also some very helpful timing diagrams which we’ll return to later. We’re interested in the Rx1 and Tx1 Channel Enablement Delays, so let’s inspect them and tabulate them: The values listed in the TDD Enablement Delays tab are estimations for each delay based on multiple tests run in Analog Devices labs, so they will suffice for the purpose of getting a setup very close to operational. Only propagation delay needs to be measured on your setup. Under the Microprocessor and System Control chapter of the User Guide, we provide a more fleshed out description of propagation delay. The remaining delays are whatever we want them to be. For example, in this setup a short guard time was desired, so a 15 us guard time was used, but that’s not a measurement. Internal Path Delay, however, is a measured value for your setup, so this value can be trusted from the TDD Enablement Delays tab. Refer to the Timing Parameters Control paragraph under the Microprocessor and System Control section of the User Guide. To avoid signals wrapping around the end of the frame, we’ll start by changing our start point in the frame, as shown: Signals wrapping around the end of the frame isn’t illegal, in fact for certain setups it’s necessary, but for this first setup things will be kept simple. To begin planning the timings of each parameter, we must first inspect the recommended timing constraints found both in the Timing Parameters Control paragraph in the User Guide and in the TDD Enablement Delays tab. Let’s start with Rx: The main signals of note are the RX_ENABLE and RX Framing at BBIC signals. These signals represent the Rx1_Pin and Rx1_DMA signals in the Auto TDD tab respectively. As you can see, the Enable signal precedes the Framing-on-Air marker. This is to provide the signal chain time to power up and calibrate. Likewise, the Frame at BBIC deassert time lags the Frame on Air, accounting for the extra delays incurred by the signal chain. Let’s now apply these principals to our configuration: In these diagrams T0, T1 and T2 represent the timings on air. The delays from this set time tell us when to assert or deassert our timing signals e.g. the Frame at BBIC of the Rx signal is T_RxPD after T0. Also note, these diagrams are not to scale, meaning some delays are exaggerated for visualization purposes. Now let’s inspect the Tx operation: Which translates into our setup as shown: Here, we note that the Enable pin still leads the frame-on-air, however now the Interface also leads. This is to ensure that all relevant Tx data passes through the device in time to be transmitted. Note: T3 = T0 for frame n+1. Combined, the Rx and Tx timings yield a plot like this: Knowing a good estimate for each delay value, and knowing the timing constraints of our LTE setup, our next step is to translate these timing diagrams into Auto TDD signal Assert and Deassert times: The Delay Time in clk cycles is most important for us. Crucially we must always round up any fractional clk period, in order to avoid frames drifting over time. To calculate the timings for the Enable and DMA, we simply take the time on air and add/subtract the delays as per the diagram e.g. The Tx_DMA must be deasserted “T_TxEnaFall2Off” before T2, so the calculation is “T2 - T_TxEnaFall2Off”. To calculate the clock cycles, divide your time by the TDD period. For instance, our frame length is 5ms so the clock cycles (cc) is 5ms/5ns = 1,000,000. This must be a positive whole number. The timings should then be updated in the enablement delay tab: And the timings put into the Automated TDD tab: All that remains now is to implement this timing scheme in TES and test it out. Step 4: Test your Configuration Tx: TES Spectrum: Spectrum Analyzer: Tx Power vs. Time: Rx: Rx1 Spectrum (903MHz tone at -10dBm) As expected, we see a tone 3MHz above DC at roughly -10dBFS. There are no noticeable distortions, and no prevalence of 0’s in the Rx signal. Wrapping Up: This completes the first guide on Automated TDD. We’ve looked at the most basic configuration from the list and implemented it in a manner that accounts for all relevant system delays. In the process we’ve also shown why the naïve approach to Automated TDD setups is ineffective. In the next tutorials we’ll handle more complex setups, and then porting a completed setup into C99 code for use in your end system.

Automated TDD

These guides cover the functionality of the Automated Time Division Duplexing (TDD) tab found in the Transceiver Evaluation Software (TES) package provided with the ADRV9001 product range, as well as provides some starting tips to get Automated TDD setups off the ground. For full context on this guide it’s best to also read the “Produce and Compile Sample C99 Code” guide found on the EngineerZone forum: https://ez.analog.com/wide-band-rf-transceivers/tes-gui-software-support-adrv9001-adrv9007/w/documents/15577/produce-and-compile-sample-c99-code.

A fully working Auto TDD setup can be deployed to either the Evaluation platform or to a customer’s unique platform using the same procedure demonstrated in the “Produce and Compile Sample C99 Code” guide. It’s also best to have read the Automated TDD material provided in the User Guide on https://www.analog.com/en/products/adrv9002.html. For reference, below is provided a block diagram of the setup being used for these coming examples:

Note: certain standards will have issues being captured cleanly on the Spectrum Analyzer without a trigger. A very good trigger for the Tx capture is the Tx_enable signal, which in the case of the ZC706 evaluation platform can be pulled to one of the available SMA connectors. More detail on accessing and directing ADRV9001 signals is provided in each individual chapter.

We’ll begin by connecting to the device. Make certain before beginning that the correct SD Card image revision is loaded on the SD card. There are tutorials available on EngineerZone for:

More information can also be found in the User Guide section on EVB setup.

Certain considerations need to be made here, primarily that only TDD configurations are compatible with Automated TDD functionality. Frequency Division Duplexing (FDD) setups require that any signal chain in use is sending / receiving data constantly, meaning there’s no time during which any signal chain can be powered down.

Always be aware of which version of silicon your setup uses, as well as the variant of evaluation board (W1 / W2). Each version of silicon and variant of eval board will come with constraints on what frequency ranges the board is optimized for and what performances are possible. Adjust your configuration to suit your evaluation board.

Given that there is such a large amount of flexibility provided by the Automated TDD functionality, we’ll use multiple device configurations to go through as many of the configuration options as possible.

To give these examples some context, we’ll attempt to implement some LTE 8 setups normally used in base-stations:

Above are shown 7 common configurations. We will cover enough of these, to show the depth of flexibility our platform provides. For those unfamiliar with the “Uplink” and “Downlink” terminology, here is a diagram which puts up/down link in terms of T/Rx:

As mentioned earlier, these configurations are being implemented from the base-station point of view, meaning the downlink slot will be used for Tx operation, and uplink of Rx operation. These configurations provide a great starting point for any user who is unfamiliar with Automated TDD functionality.

This guide will be broken down into chapters for ease of reading. Each configuration covered will be given its own chapter on this forum.