TES Setup for clock changes and related questions

Hello Stephen,

In this response I will attempt to answer all of your questions, however many of them have been answered in great detail in other locations. As a result, many of these answers will direct you to other resources that ADI has made publicly available.

a) When in Demo mode this does not matter. The SW is recommending you use a carrier between 3GHz and 6GHz because it defaults to assuming that you're using a high-frequency board. However there are no differences between the silicon on the high frequency Eval Board and the low frequency Eval Board. This is discussed in the User Guide, given how large of a frequency range this device can manage, we couldn't find a single Balun to handle the whole bandwidth, hence we split the bandwidth into 2 and made an Eval board for each split. The APIs do not change from one board to the other, the Silicon is the same. Ignore the error, we're planning on redesigning how this message is portrayed in future versions of TES.

b) They are meant to be the same, sometimes they are used interchangeably. It can be the case that a user would sample the dataport at a rate not equal to their dataport sampling rate (in this case the Datapot Sample Rate would be the setting on the device, the Interface Rate would be a setting on the host platform), however there are very few reasons anyone would do this. I would treat them as being the same thing.

c) The Clk divider is present to assist with noise performance. Your input is your input, you tell TES what Clk frequency you are giving it and what divider you want, it handles the rest.

d) The internal Clk will drive all of the circuitry in the chip, digital and analog. This can be seen in our Datasheet and in our User Guide by inspecting the detailed block diagrams

e) No, the Reference Clk (DEV_CLK_IN, the value you provide to TES) is divided down and given to a Clk PLL, which then drives the chip. This is explained in detail in the Clokc Generation chapter of the User Guide

f) This default value is meaningless, it is simply a safe value to default the chip to.

g) The default value has no impact on the chip's ability to support your application. As stated by M_Bugajski, your application will likely be built off the Fast Frequency Hopping feature supported by the ADRV9003, meaning you are not programming a single carrier, but multiple. Depending on your implementation you may be reprogramming the carrier frequency constantly. The Fast Frequency Hopping feature has been given its own section of the User Guide, I strongly suggest you read this chapter thoroughly.

h) The Intermediate Frequency (IF) is a value used only in particular narrowband setups. Under normal operation, this transceiver operates in Zero IF mode, where the incoming signal is mixed directly with the LO, resulting in a signal centered on 0Hz. However in some Narrowband applications, the LO will be too noisy to mix with directly, so instead you offset the LO by a little, mix the incoming signal down to a Low IF (nearly 0Hz), and then use the Numerically Controlled Oscillator (NCO) in the DFE to mix the signal down the rest of the way to 0Hz.  For your application it won't matter, you will not be using the NCO for anything, so your IF will be 0. 

i) Yes, as per my explanation above. Again, given your application you will not have the NCO in the datapath. It does not contribute to a more sensitive Rx signal chain, better instead to use Fast Frequency Hopping.

j) Yes, as the ADCs have their own PLLs to handle clocking. Review the User Guide and the Datasheet for block diagrams and the relevant chapters: Chapters on Clocking, the Rx Signal Chain, and Synthesizer Configuration and LO Operation

k) For the LPF in the AFE there is not much configuration available besides what you see in TES. I wouldn't worry so much on this, these LPFs don't do any real amount of filtering, they are mere there to convert the current signal from the external AFE into a voltage signal that the DFE can work with.

l) LibIIO is an entirely different toolset from TES. This toolset is managed by the Linux Software Drivers Forum:
https://ez.analog.com/linux-software-drivers/

Their APIs will always lag behind ours, as we are the team developing the APIs for this product family. M_Bugajski suggested you become familiar with TES so that you can get some time to become acquainted with the device's capabilities, to introduce you to our in-house APIs, and also to provide you with a tool with which to generate ARM and Stream Images which you will need for your Eval Platform, given LibIIO does not have any way to generate these binary files for itself.

m) That question is best directed to the Linux SW team, I have no visibility on what LibIIO is capable of doing.

n) Again, review our Fast Frequency Hopping material. You do not need to completely reconfigure the device in order to scan across a frequency range, our part should be capable of supporting your application.

As I mentioned at the beginning of this reply, the vast majority of these questions are answered in our documentation, and indeed in other places across this forum. Do perform a thorough search of the questions already answered on these forums and be sure to have read the applicable content in our documentation before posting questions.

I do hope this explanation has helped you!

Best Regards,
Oisín.

Hello Stephen,

In this response I will attempt to answer all of your questions, however many of them have been answered in great detail in other locations. As a result, many of these answers will direct you to other resources that ADI has made publicly available.

a) When in Demo mode this does not matter. The SW is recommending you use a carrier between 3GHz and 6GHz because it defaults to assuming that you're using a high-frequency board. However there are no differences between the silicon on the high frequency Eval Board and the low frequency Eval Board. This is discussed in the User Guide, given how large of a frequency range this device can manage, we couldn't find a single Balun to handle the whole bandwidth, hence we split the bandwidth into 2 and made an Eval board for each split. The APIs do not change from one board to the other, the Silicon is the same. Ignore the error, we're planning on redesigning how this message is portrayed in future versions of TES.

b) They are meant to be the same, sometimes they are used interchangeably. It can be the case that a user would sample the dataport at a rate not equal to their dataport sampling rate (in this case the Datapot Sample Rate would be the setting on the device, the Interface Rate would be a setting on the host platform), however there are very few reasons anyone would do this. I would treat them as being the same thing.

c) The Clk divider is present to assist with noise performance. Your input is your input, you tell TES what Clk frequency you are giving it and what divider you want, it handles the rest.

d) The internal Clk will drive all of the circuitry in the chip, digital and analog. This can be seen in our Datasheet and in our User Guide by inspecting the detailed block diagrams

e) No, the Reference Clk (DEV_CLK_IN, the value you provide to TES) is divided down and given to a Clk PLL, which then drives the chip. This is explained in detail in the Clokc Generation chapter of the User Guide

f) This default value is meaningless, it is simply a safe value to default the chip to.

g) The default value has no impact on the chip's ability to support your application. As stated by M_Bugajski, your application will likely be built off the Fast Frequency Hopping feature supported by the ADRV9003, meaning you are not programming a single carrier, but multiple. Depending on your implementation you may be reprogramming the carrier frequency constantly. The Fast Frequency Hopping feature has been given its own section of the User Guide, I strongly suggest you read this chapter thoroughly.

h) The Intermediate Frequency (IF) is a value used only in particular narrowband setups. Under normal operation, this transceiver operates in Zero IF mode, where the incoming signal is mixed directly with the LO, resulting in a signal centered on 0Hz. However in some Narrowband applications, the LO will be too noisy to mix with directly, so instead you offset the LO by a little, mix the incoming signal down to a Low IF (nearly 0Hz), and then use the Numerically Controlled Oscillator (NCO) in the DFE to mix the signal down the rest of the way to 0Hz.  For your application it won't matter, you will not be using the NCO for anything, so your IF will be 0. 

i) Yes, as per my explanation above. Again, given your application you will not have the NCO in the datapath. It does not contribute to a more sensitive Rx signal chain, better instead to use Fast Frequency Hopping.

j) Yes, as the ADCs have their own PLLs to handle clocking. Review the User Guide and the Datasheet for block diagrams and the relevant chapters: Chapters on Clocking, the Rx Signal Chain, and Synthesizer Configuration and LO Operation

k) For the LPF in the AFE there is not much configuration available besides what you see in TES. I wouldn't worry so much on this, these LPFs don't do any real amount of filtering, they are mere there to convert the current signal from the external AFE into a voltage signal that the DFE can work with.

l) LibIIO is an entirely different toolset from TES. This toolset is managed by the Linux Software Drivers Forum:
https://ez.analog.com/linux-software-drivers/

Their APIs will always lag behind ours, as we are the team developing the APIs for this product family. M_Bugajski suggested you become familiar with TES so that you can get some time to become acquainted with the device's capabilities, to introduce you to our in-house APIs, and also to provide you with a tool with which to generate ARM and Stream Images which you will need for your Eval Platform, given LibIIO does not have any way to generate these binary files for itself.

m) That question is best directed to the Linux SW team, I have no visibility on what LibIIO is capable of doing.

n) Again, review our Fast Frequency Hopping material. You do not need to completely reconfigure the device in order to scan across a frequency range, our part should be capable of supporting your application.

As I mentioned at the beginning of this reply, the vast majority of these questions are answered in our documentation, and indeed in other places across this forum. Do perform a thorough search of the questions already answered on these forums and be sure to have read the applicable content in our documentation before posting questions.

I do hope this explanation has helped you!

Best Regards,
Oisín.

Oisin;

   Thank you VERY MUCH for your detailed answers and pointers.  I have completed my review of your responses and will continue my investigation.

   Just a quick update:  We have decided to move forward with the ADRV9003 device for our design, replacing the AD9361 device.  Detailed analysis shows that the new device will reach the -174 dBm sensitivity we require.  We have purchased parts, and the board re-spin/redesign is underway to add this new part.  I have submitted a PO for the EVAL board, which we will hook up to our ZED board here for analysis and some initial software bring up.  I am hopeful Santa will bring this in time!

    I will probably have more questions in the New Year.  Thank You again for your time and patience.

Best Regards,

Stephen Beckwith