TES Setup for clock changes and related questions

Question

Greetings; 
 Point of Reference: Developed a custom application based upon the ad9361_iiostream.c application to run on a Linux based setup (ZED Board + RFCOMMS4 Eval Board). Our application is for "test and measurement", receive only, where we are using this device to check for very low power emissions from electronic devices. We will collect I/Q samples from a specific frequency, with a specified bandwidth (very narrow). We are checking a number (> 20) specific frequencies ni a loop, storing the information for later analysis, rinse and repeat. For each different frequency we are collecting data from, the only changes we make to the chip on each pass are: bandwidth and RX_LO settings, everything else is a constant. 
 We are migrating this design to use the ADRV9003, for a number of reasons. I was provided a pointer to the ADRV9002-iiostream.c as a similar reference. This seems to be very similar to what was used for the AD9364. 
 In a recent post answered by M_Bugajski, he suggested I use TES to generate configuration information for our proposed setup, wich has a different REF CLK. I installed the TES and did some poking around. Based upon this, I have the following questions below. 
 From the main.c: /* */ /* Silicon Revision: Presumed C0*/ /* */ /* Tx / Rx optimal carrier frequencies: 3 GHz to 6 GHz*/ /* External LO optimal frequencies: 6 GHz to 12 GHz*/ /* */ /* FPGA: v0.0.0*/ /* Device Driver API: v0.0.0*/ /* Device Driver Client: v48.34.4*/ /* Firmware: v0.18.1.4*/ /* Profile Generator: v0.47.0.0*/ /* Stream Generator Assembly: v0.7.8.0*/ /* Transceiver Evaluation Software: v0.18.1*/ /* ADRV9001 Plugin: v0.18.1*/ 
 Connection Tab: a) TES is set for Tx/Rx Optimal Carrier Frequencies between 3GHz to 6 GHz. Does this possibly cause some issues when trying to configure for a setup/system that will operate only between 30MHz and 1.1GHz? - A couple of times I got an error dialog saying the value was not recommended below 3GHz. 
 Device Configuration: b) Dataport Sample Rate vs. Interface Rate? Are these the same? Can they be different? Why would one do this? 
 Clocks: c) Set the Device clock Input to 49.152 MHz. The Clock Output has a /2 setup, does this matter?? d) Processor Clock Divisor: for the internal ARM-M4?? e) does it run at the Device Clock Input rate? if yes, how does this affect overall system performance? 
 Carriers: - when designing a radio, I can see where this would be applicable. However, for our application, we are tuning to different RX frequencies (i.e. carriers). f) What does this default value of 900 MHz represent inside the chip? g) Does it affect the ability to tune from 30MHz to 1.1GHz? Is this different than the Local Oscillator setting? h) Intermediate Frequency - what is this 490KHz default value represent? i) Does this mean that the AFE is only down-converting to this IF frequency? Rather than baseband (0 Hz)?? 
 Radio: j) The ADC rate (defalts to LOW) - is this independent from the other clocking in the system? k) What is the lowest possible frequency for the Filter? - Second Order can be set to 4.74MHz for -1dB freq, 6.70 for -3dB freq 
 General: l) output from TES seems to be using the underlying SDK API's. If one is using libiio, would alot of this be hidden "under the hood"? m) are there libiio call specifically for updating these configuration structures? Or would code need to be added to call the Linux Driver API's using the higher level structures? n) is this initialization a "one time" setup for the part? if the Carrier Frequency has no bearing, then I would say yes, if not, then there maybe a problem with how we plan to use this device, if we need to continually do this level of configuration for each scanned frequency. 
 Thank you for your time and expertise. 
 Regards, 
 Stephen Beckwith

ADIApproved · Accepted Answer

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&iacute;n.)

Popular Forums

Product Forums

Application Forums

Design Center Forums

Highlighted Webinar

Places

Libraries

Latest Webinars

Challenge Yourself!

What's Brewing

Places

Resources

Highlighted Blogs

Latest Blogs

ADI Blogs

Visit ContentZone

Featured Content

View Content By Industry

View Content By Technology

Products Mentioned

Thread Details

TES Setup for clock changes and related questions

Thread Summary

Thread Notes