AFE7920EVM: How to use the opcodes to update system after initial configuration

Hi Florian, 

Is there a reason you are wanting to use the macro calls for these actions? My recommendation is to complete these actions using the C API, which will write to the macros in the back end. I've included the script for the C API functions, as well as the documentation. You can find the C API documentation in the .chm file that is installed with Latte, similar to the file path below.

“C:\...\Documents\Texas Instruments\AFE79xxLatte\lib\Afe79xxLibraries\AFE79xxLibraryPG1p0\Docs\afe79xxCLibsDocumentation.chm”

##Update RX NCO
afeInst = 0    #AFE Instance of AFE79_INST_TYPE type. If using the EVM this should be 0.
rxChSel = 0 #Value to select the RX chain.Value 0 for RXA to 3 for RXD.
bandNo = 0 #Band number. 0-band0, 1-band1.
ncoNo = 0 #NCO number. 0-NCO0, 1-NCO1.
ncoFreq = 9600#NCO frequency to set the NCO to in MHz.
if sysParams.ncoFreqMode == '1KHz':
	mixer = ncoFreq*1e3 #Should pass value in KHz in 1KHz ncoFreqMode and the frequency word value in FCW mode. The Mode is determined by the ncoFreqMode set in Latte while generating the bringup script.In FCW mode, the value can be calculate using the equation: mixer =  (uint32_t) (2^32*mixerFrequency/FadcRx).
elif sysParams.ncoFreqMode == 'FCW':
	mixer = int(round(2**32*ncoFreq/sysParams.FadcRx)) #Should pass value in KHz in 1KHz ncoFreqMode and the frequency word value in FCW mode. The Mode is determined by the ncoFreqMode set in Latte while generating the bringup script.In FCW mode, the value can be calculate using the equation: mixer =  (uint32_t) (2^32*mixerFrequency/FadcRx).
CAFE.updateRxNco(afeInst,rxChSel,mixer,bandNo,ncoNo)
engine.DDCNCOFreqWord=((ncoFreq)%sysParams.FadcRx)/(sysParams.FadcRx)*2**32 #Updating NCO word in capture window


##Update Tx NCO
afeInst = 0    #AFE Instance of AFE79_INST_TYPE type. If using the EVM this should be 0.
txChSel = 0 #Value to select the TX chain.Value 0 for TXA to 3 for TXD.
ncoNo = 0 #NCO number. 0-NCO0, 1-NCO1.
ncoFreq = 3000#NCO frequency to set the NCO to in MHz.
if sysParams.ncoFreqMode == '1KHz':
	mixer = ncoFreq*1e3 #Should pass value in KHz in 1KHz ncoFreqMode and the frequency word value in FCW mode. The Mode is determined by the ncoFreqMode set in Latte while generating the bringup script.In FCW mode, the value can be calculate using the equation: mixer =  (uint32_t) (2^32*mixerFrequency/FadcRx).
elif sysParams.ncoFreqMode == 'FCW':
	mixer = int(round(2**32*ncoFreq/sysParams.Fdac)) #Should pass value in KHz in 1KHz ncoFreqMode and the frequency word value in FCW mode. The Mode is determined by the ncoFreqMode set in Latte while generating the bringup script.In FCW mode, the value can be calculate using the equation: mixer =  (uint32_t) (2^32*mixerFrequency/FadcFb).
CAFE.updateTxNco(afeInst,txChSel,mixer,ncoNo)

##TDD Override
afeInst = 0    #AFE Instance of AFE79_INST_TYPE type. If using the EVM this should be 0.
rxChSel = 0xf #Override Value of the RX chains. This is Bit wise channel select. Bit0 for RXA to Bit3 for RXD.
fbChSel = 0x3 #Override Value of the FB chains. This is Bit wise channel select. Bit0 for FBAB to Bit1 for FBCD.
txChSel = 0xf #Override Value of the TX chains. This is Bit wise channel select. Bit0 for TXA to Bit3 for TXD.
enableOverride = 1 #Enables the Override. if enableOverride=0, it disables the TDD override; if enableOverride=1, it enables the TDD override && also sets the TDD values; if enableOverride=2, it only sets the TDD values.
CAFE.overrideTdd(afeInst,rxChSel,fbChSel,txChSel,enableOverride) #Function to override and set the TDD values

Thanks! 

Mirana

Hello Mirana,

our first intention was to use the opcodes as they seem to be simple to use ans are well documented in SBAU337. But from what you say and from the various discussions I have read on the forum, it seems using the opcodes is not so simple. Our testing has given no results, event when sending the first init sequence with 17 opcodes, following exactly the example given in SBAU337 "1.4 Example Macro Call Sequence".

We are fine to use the CAFE functions as long as we can get the expected result. Our first concern was to get always the same phase dispersion on Tx as discussed in AFE7920EVM: phase synchronization in Rx & Tx between the 4 channels - RF & microwave forum - RF & microwave - TI E2E support forums

We are currently testing the use of txChainDirectCtrl=1 to see if it solves our issue as advice in the above ticket. Then, with the TDD mode, we should be able to disable the unused channels.

If all the above works, the only issue we will still have will be to change the Nyquist zone in Rx.We need to acquire signals from 1160 to 2500 MHz, and be able to change the frequency dynamically. Since our Rx sample frequency is 2 949,12MHz, the frequency plan is split between Nyquist zone 1 & 2 (the split being at 1 474,56 MHz).

From what I have seen on the forum, changing Nyquist zone is not possible using the CAFE functions, but seemed to be possible using the opcode. What would you advice to do ? We could stand a reconfiguration time of a ~100ms, but not waiting several seconds to completely reinit the chip.

Thanks & regards,

Florian.

Hi Florian, 

Thank you for updating me on the other E2E thread. I have closed it but let me know if any other issues arise. 

Even with opcodes, you will not be able to change the Nyquist zone such that all frequencies from 1.6G-2.5G can be used simultaneously due to the sampling rates of the ADC/DAC. You can use separate ADCs/DACs for different Nyquist zones, but there will be some overlap. I can still explain the process to use the opcodes, but I'm not sure if it will help for your use case. You can utilize frequency planning to help mitigate potential aliasing by grouping bands with similar frequencies/bandwidths on the same channel. Let me know your preferred path forward!

Thanks!

Mirana

Hello Mirana,

actually we do not want to capture the whole band 1.6G-2.5G simultaneously. We need to be able to sample a slice of 150MHz of this band by setting the frequency before performing acquisition. Then we stick to the 150M band until acquisition is finished. Then we want to be able to select another slice of 150M of the band, and do another acquisition. And we want to be able to do than independently on all 4 channels.

What we need is to be able to freely reconfigure each channel between 2 acquisitions, and for that we need to be able to change also the Nyquist band when new frequency is located in another Nyquist band.

So having a way of reconfiguring the AFE without running the full init sequence (which is really long) would be very convenient. Using opcodes for that would be fine if this is possible, so I would appreciate if you could explain how to use them.

Thanks & regards,

Florian.

Hi Florian, 

I'm understanding your use case now. If you use the C API to update the RX NCO, you can move between the Nyquist zones. By changing the NCO, the device will automatically read from the expected Nyquist zone. Please try testing with the C API function below. It works as expected on my setup. Let me know if your setup needs additional debug due to the behavior discussed on the other E2E thread. 

Thanks!

Mirana

Hello Mirana,

thanks for your answer.

I am surprised by what you say about the updateRxNco function, since your colleague David Chaparro said the opposite in this thread : 

https://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1519506/afe7901-change-nyquist-band-and-rx-frequency-after-device-bringup-sequence/5846500?tisearch=e2e-sitesearch&keymatch=AFE%20change%20nyquist%20zone#

And looking at the code of the updateRxNco function v2p6, there is a check that new frequency is in the same Nyquist zone as in the init (this check has been added in v2p6 as it was not present in v2p5).

In addition, in SBAA417 page 14 we can find this information:

RX Mixer frequency for NCO 0 (rxNco0):
This is the array of mixer frequencies (NCOs) for each channel and band. For meeting performance of
the ADC, it is needed to have mixer frequencies of all the bands and NCOs corresponding to that RX
chain to be in same nyquist. The device supports multiple Nyquists programmed for each ADC,
however it may cause performance degradation.

So basically, it is stated there are "performance degradation" if we don't change the Nyquist, but we don't have the details of this degradation.

Looking at the code of updateRxNcoMultiNcoMode, I don't have the impression that Nyquist zone is changed either, only the FCW is updated. So the frequency is actually changed (and this is what we can see on our bench), but there might be "performance degradation" so we don't want to take the risk. This is why we really want to change Nyquist zone.

What are your thoughts about this ?

Thanks & regards,

Florian.

Hi Florian,

I spoke with David and our systems engineer, Jenny, to better understand this. The macros you're referring to are being written to in the backend of the updateRxNco() C API. The macros have the ability to change the Nyquist zone, but you will still see the performance degradation (particularly, the linearity performance or intermodulation distortion performance) David mentioned. We have special circuitry that are Nyquist zone dependent to enhance the non-linearity due to intermodulation distortion (IMD). The special circuitry requires TI factory calibration data estimated during production tests that are designated by Nyquist zone. Because of this, the RX performance may be sub-optimal when the initialized calibration data is configured for one Nyquist zone, but the actual signal is on another Nyquist zone. Changing the calibration data packet for the Nyquist zone requires device re-initialization. 

Thanks! 

Mirana

Hello Mirana,

thanks for the clarification and for the details about the performance degradation. This is not good news but at least we know what we have to do. We will try to optimize the initialization time to make it as short as possible for the user.

Thanks & regards,

Florian.

I have another question regarding the Nyquist zone. I guess that, due to filtering, there is a zone at the edge of the Nyquist zone boundaries in which signal can not be acquired (for example in Rx @2949MHz, we can not record signals @1474MHz).

What is the width of this zone around the Nyquist band edge ? In the above example, if we are configured for Nyquist band 1, can I acquire signal @1454MHz or will it be too close to the edge ?

Thanks,

Florian.

Hi Florian, 

There are a couple things to consider:

1. The analog anti-aliasing filter: What kind of rejection can your anti-aliasing filter provide?

2.The digital filter: At 184.32MSPS I/Q rate, the passband of the Digital Down Converter or Digital Upconverter filter (FIR) is about 80% of the input interface rate (I/Q rate), which is +/-75MHz. The transition band starts around 70MHz. You will need to look at the filter response of the digital filter to see what rejection is acceptable for your system.

Have you signed an NDA with TI previously? 

Thanks!

Mirana