ADRV9009 TALISE_programFir: impossible to separate RX1 and RX2?

Moved to ADRV9009 support. API specific questions go here.

-Travis

can you please share the details of the warnings that you get? are you using the ADRV9009 eval board or custom board

I am using a custom board.

In one particular case I got these errors repeated many times (sorry, it is not a warning):
ERROR: 802820: Talise ARM Command not accepted in this state
ERROR: 294: TALISE_waitArmCmdStatus() failed due to thrown ARM error. Is device in correct state for calling command?

Only for the Rx Filters, and only while in Radio Off. I think I have solved this issue by adding a 100 ms delay between TALISE_runInitCals(&talDev, initCalMask) and TALISE_waitInitCals(&talDev, 20000, &errorFlag). So it is no more an issue.

My issues are the following:

• Is it possible to have a different gain_dB for TX1 and TX2?
• Is it possible to have different coefficients (and gain) for RX1 and RX2?

The TX attenuation/gain can be individually controlled for TX1 and TX2. The range is from 0 to -41.95 dB in programmable steps sizes. The nomenclature used here is gain instead of attenuation, so all values are expressed negative.

It is not recommended to change filter coefficients and it's gain, and use as it is from the filter generation wizard, and if it requires you can use different gain table for Rx path to maintain different analog gain for two paths. 

Dear RR4, we know that we can control individually the attenuation for TX1 and TX2, it is working fine.

Until now it is not clear that we could need to program different filters for TX1 and TX2, or different filters for RX1 and RX2, but it seems to me that the transceiver does not conform to the documentation. Did I missed something? (Q1)

By default I use the filter coefficients and gain given by the TES, using attached configuration. Can it be improved ? (Q2)

With OL = 400 MHz, I/Q data = sine/cosine over a period of 50 samples, that is 6.144 MHz (=307.2/50), I get bad results:

By lowering the gain filter, or the level of the I/Q data, one can remove many harmonics, but two are still present.

Now with coefficients that I tried somehow by chance, I get better results:

Why is it ? (Q3)

My coefficients are 8000, 16000, 8000, and all zeros.

tcachat said:

Until now it is not clear that we could need to program different filters for TX1 and TX2, or different filters for RX1 and RX2, but it seems to me that the transceiver does not conform to the documentation. Did I missed something? (Q1)

Sorry, I forgot to attach the configuration from TES. Here it is.

<GUI_Setup>
  <Device>ADRV9009</Device>
  <DeviceClock>153.6MHz</DeviceClock>
  <TxChannel>TX1 and TX2 Enabled</TxChannel>
  <TxProfile>Tx 100/277MHz, IQrate 307.2MHz</TxProfile>
  <ObsProfile>ORX 277MHz, IQrate 307.2MHz, TotalDec 4</ObsProfile>
  <RxChannel>RX1 and RX2 Enabled</RxChannel>
  <RxProfile>Rx 100.00MHz, OutputRate 153.60MHz, TotalDec 8</RxProfile>
  <RxPllFreq>1800</RxPllFreq>
  <RxPllExtLo>NO</RxPllExtLo>
  <Tx1InitAttenuation>0</Tx1InitAttenuation>
  <Tx2InitAttenuation>0</Tx2InitAttenuation>
  <RxFramerSelection>Framer A</RxFramerSelection>
  <TxFramerSelection>Deframer A</TxFramerSelection>
  <ObsRxFramerSelection>Framer B</ObsRxFramerSelection>
  <UseExternalSysRef>True</UseExternalSysRef>
  <FramerALane0>False</FramerALane0>
  <FramerALane1>True</FramerALane1>
  <FramerALane2>False</FramerALane2>
  <FramerALane3>False</FramerALane3>
  <FramerAScrambling>True</FramerAScrambling>
  <FramerARelink>False</FramerARelink>
  <FramerAK>32</FramerAK>
  <FramerAKOffset>31</FramerAKOffset>
  <FramerBLane0>True</FramerBLane0>
  <FramerBLane1>False</FramerBLane1>
  <FramerBLane2>False</FramerBLane2>
  <FramerBLane3>False</FramerBLane3>
  <FramerBScrambling>True</FramerBScrambling>
  <FramerBRelink>False</FramerBRelink>
  <FramerBK>32</FramerBK>
  <FramerBKOffset>31</FramerBKOffset>
  <DeframerALane0>True</DeframerALane0>
  <DeframerALane1>True</DeframerALane1>
  <DeframerALane2>False</DeframerALane2>
  <DeframerALane3>False</DeframerALane3>
  <DeframerAScrambling>True</DeframerAScrambling>
  <DeframerARelink>False</DeframerARelink>
  <DeframerAK>32</DeframerAK>
  <DeframerAKOffset>17</DeframerAKOffset>
  <DeframerBLane0>False</DeframerBLane0>
  <DeframerBLane1>False</DeframerBLane1>
  <DeframerBLane2>True</DeframerBLane2>
  <DeframerBLane3>True</DeframerBLane3>
  <DeframerBScrambling>True</DeframerBScrambling>
  <DeframerBRelink>False</DeframerBRelink>
  <DeframerBK>32</DeframerBK>
  <DeframerBKOffset>17</DeframerBKOffset>
  <RxQECInit>True</RxQECInit>
  <TxQECInit>True</TxQECInit>
  <InternalTxLOLInit>True</InternalTxLOLInit>
  <ExternalTxLOLInit>False</ExternalTxLOLInit>
  <Rx1QECTrack>True</Rx1QECTrack>
  <Rx2QECTrack>True</Rx2QECTrack>
  <Rx1Hd2Track>False</Rx1Hd2Track>
  <Rx2Hd2Track>False</Rx2Hd2Track>
  <Tx1QECTrack>False</Tx1QECTrack>
  <Tx2QECTrack>False</Tx2QECTrack>
  <Tx1LOLTrack>False</Tx1LOLTrack>
  <Tx2LOLTrack>False</Tx2LOLTrack>
  <Orx1QECTrack>False</Orx1QECTrack>
  <Orx2QECTrack>False</Orx2QECTrack>
</GUI_Setup>

Can you please let us know what is the actual problem that you are facing with the ADRV9009 chip?

The problem is that using FIR coefficients provided by TES, I get spurs at +/- 153.6 MHz from my signal of interest.

Can you please share the Rx capture that you observed spurs at +/- 153 MHz? are you facing this issue in Rx and Tx, or only in Rx path?