SPI API control of TX datapath attenuation -- Value discrepancy

The TX attenuation should remain constant throughout the experiment unless changed manually or the board is rebooted which will set the attenuation to the default value.

Are you using custom board or eval board? What are the functionalities that you are running after setting attenuation and before reading it back?

This is a custom board - the hardware is certainly tested however and is functioning properly in all aspects (transmission, receiving, all work). I go through the headless.c algorithm to its completion. Before turning the radio in the ON state, I then set the manual gain / tx attenuation first - then I set the radio in the ON state. Nothing else is being called after I set the tx attenuation.

In summary: headless.c -> set TX attenuation -> radio ON -> get TX attenuation

You should not see this discrepancy.

Without setting Tx attenuation and you read back using get function , what is the attenuation read back. ? have you tried other values like 5db or 10dB ? 

Can you try setting the TX attenuation in radio ON state and then read the Tx attenuation just after setting that using API?

I have done as you suggested and that did not fix the issue. I waited until I used the MYKONOS_radioON SPI command to set the attenuation of the corresponding TX channel, and the value remained off by 2 decibels (15,000 mdB requested vs 17,000 mdB read back). I believe the 'original value' it is set to is 10,000 mdB , prior to me setting it.

Can you share the sequence  that you are using for testing? After radio ON state, you should be able to readback the same attenuation that you had set.

After radio On, can you ensure if the TX attenuation pin control or GPIO mode is not enabled? Use the API MYKONOS_getTx1AttenCtrlPin and share with us the status.

Pls follow the below sequence and share with us the status

Radio on

MYKONOS_getTx1AttenCtrlPin

MYKONOS_setTx1Attenuation

 MYKONOS_getTx1Attenuation

Okay, here are the results of following your specified sequence srimoyi 
In this new scenario, I am setting the attenuation to 9.5 decibels
Radio on,
MYKONOS_getTX1AttenCtrlPin:

stepSize = 0
tx1AttenIncPin = 16
tx1AttenDecPin = 32
enable = 0
useTx1ForTx2 = 0

 At what offset from the RFLO frequency are you sending signal into the TX input?  Have you tried by sending CW signal at some offset from LO, and then set and readback TX attenuation?

When you set the TX attenuation using API from 11500 to 9500, are you seeing the TX output power changing accordingly at the output? If you change the attenuation by 1dB, are you seeing a corresponding change in the output power level? 

In my previous tests I have not been sending a signal into the TX input. We are going to setup a test for this scenario soon with a spectrum analyzer and everything else needed. Please keep this thread open, I will ping again in about two weeks -- unless this issue should be further debugged with a more direct line to your Analog Devices Support. Thank you for the help thus far.

Thank you for your patience leaving the thread open. I have got my application and spectrum analyzer set up to test properly.

At what offset from the RFLO Frequency are you sending signal into the TX input?

In this new application, the CW signal is being transmitted at 1 MHz offset from the LO, the LO is set to 2.45 GHz. The default value being set for the attenuation during the headless.c sequence is 10 dB of attenuation ( MYKONOS_setTx1Attenuation(&device,10000) )

During the application, I turn the radio ON, then I dynamically adjust the Tx1 attenuation. I changed it from 10 dB attenuation to 31.95 dB attenuation and the spectrum analyzer showed no difference in the output signal.

The first picture is the initial control value of the spectrum (10 dB of Tx1 attenuation), the second picture is after I change the value (31.95 dB of Tx1 attenuation). Note - there are other gain blocks in the front end but everything is constant besides Tx1 attenuation value between the two graphs.

 

Appears to be no difference

This should not happen. Can you try checking the TX power directly at the TX output?

Also, can you check the supply? Can you check if you have provided bias to the balun at the TX output?