ADRV9002 ENSM mode

With the IIO driver, the ENSM is generally managed for you when performing calibrations and will be overridden when necessary. It's more like the powerdown controls from the user's perspective. You can use it to help save power, stop transmitting/receiver useful data, or debugging. However, since you cannot intercept the calibration routines it has limited usefulness in Linux.

Just make sure you are in rf_enabled on the correct channel if you want to send or receive data correctly.

-Travis

Okay thank you,

So just to be clear, once a write_profile/write_stream is loaded onto the ADRV9002 and some of the controllable parameters are set via Pyadi-iio commands (i.e. tx0_lo, tx_hardwaregain_chan0, atten_control_mode_chan0, etc...) , tx_ensm_mode_chan0 just needs to be set to "rf_enabled" and it has already been successfully "calibrated"/"primed" via the iio drivers and is fully ready for new samples to be transmitted via the tx() command? 

Does changing the tx_lo/tx_hardwaregain_chan0 parameters after tx_hardwaregain_chan0 is changed to "primed" once a tx() is finished transmitting require a "recalibration" before switching to "rf_enabled" again or is this automatically done.

Thanks,

-NT

So when you load a profile the driver will move back to some default state. The attributes will reflect this default state when you read them out. So the recommend flow if you want a specific LO or runtime tracking calibrations is to enable/apply them after loading a profile. This is true for ENSM as well. For FDD profiles ENSM will default to rf_enabled after the profile is loaded, and primed in the TDD case.

-Travis

Hello, as a follow up,

I am using Pyadi-iio however, I noticed that in the TES generated python code on Zcu706 set up, every time the LO rx carrier is changed the device needs to run the initiliaze.py followed by a calibrate.py/configure.py. 

In pyadi-iio, once a profile/stream is configured, it seems you can change the rx LO via the rx0_lo command on the fly without "recalibrating" as it is done in the TES (unless it is happening under the hood). Does this produce inaccurate results when running tests where the rx0_lo is changed without "recalibrating" the device every time like is done via the TES generated python code?

Thanks

The driver follows the routine described on page 86 of UG-1828. I'm not really sure why TES does that entire process. My guess is that the auto-generated code always assumes you start at ground zero. The driver understands the state of the chip so it can do the runtime path.

-Travis

Okay great, this is helpful. 

Thank you!