we are using the AD9375 with the Linux Driver by AD. We take advantage of the IIO oscilloscope plug in for AD9371/5 in order to provide manual configuration. We are investigating the Initial Calibration procedure. We made few assumptions and we would like to be sure about it.
1) On UG992, we collected MYKONOS APIs in order to enable and monitor Initial Calibrations. We realized that the MYKONOS library can be used only in a bare metal setup, even if the AD driver takes advantage of it. Is it correct?
2) As suggested by the wiki, in order to use control Initial Calibration procedure, we went here: /sys/bus/iio/devices/iio:device3# so we had the same options guaranteed by the IIO oscilloscope. Is it the correct procedure? Does the driver guarantee a different access to the Initial Calibrations?
3) As from WIKI, we assumed the following were referring to initial calibration procedure. Is it correct?
-rw-rw-rw- 1 root root 4096 May 31 14:49 calibrate
-rw-rw-rw- 1 root root 4096 May 31 14:49 calibrate_rx_qec_en
-rw-rw-rw- 1 root root 4096 May 31 14:49 calibrate_tx_lol_en
-rw-rw-rw- 1 root root 4096 May 31 14:49 calibrate_tx_lol_ext_en
-rw-rw-rw- 1 root root 4096 May 31 14:49 calibrate_tx_qec_en
( wiki page reference: https://wiki.analog.com/resources/tools-software/linux-drivers/iio-transceiver/ad9371#example_linux_device-tree_initialization )
4) We were expecting to have 15 different options of calibration. Are the others performed by the driver only?
We also realized that, at initialization, the driver is providing all the calibrations that are missing from the list, the other 11 points descripted by the mask reported by the UG 992 at page 84 (Table 65). We cannot manually execute the other calibrations.
5) Are the missing calibrations expected to be run only once, at startup, without taking in consideration a subsequent change of configuration?
6) In our system we have the possibility to change configuration parameters of the device in moments other than the startup. Can we do it and consider that the driver initial calibrations could apply?
7) In fact, we were wondering if TX_BB_FILTER, ADC_TUNER and TIA_3DB_CORNER were digital chain config dependent or not. Are they?
8) In this case, is it possible to perform a change of digital chain configuration without restarting the device or, will it compromise the part of the initial calibration performed by the driver?
9) In conclusion, we will always repeat TX_QEC_INT, RX_QC_INT, TX_LO_LEAKAGE_INTERNAL. TX_LO_LEAKAGE_EXTERNAL only, every time the configuration has changed, as permitted by the driver. Is it the correct procedure?
Thank you for the clarification you will be able to provide
1. API's are basic C codes and can be used with Linux and NO-OS bare metal setup. Linux drivers . https://wiki.analog.com/resources/tools-software/linux-drivers/iio-transceiver/ad9371?s=ad9371&s[…
The scheduling operation is done by the ARM. Tracking cals are run in batches of 800usec of data and when sufficient batches of a tracking calibration run, the algorithm then computes its correction based…
1. API's are basic C codes and can be used with Linux and NO-OS bare metal setup. Linux drivers . https://wiki.analog.com/resources/tools-software/linux-drivers/iio-transceiver/ad9371?s=ad9371&s=linux
2. & 3. You can run all the calibrations together by enabling cal mask as required using API MYKONOS_runInitCals(mykonosDevice_t *device, uint32_t calMask) . You can as well run individual cals as mentioned.
4. No All cals are part of cal mask and there are no other cals as such.
5. Some calibrations are only run once during initialization. There are a set of Tracking cals which are run at run time. Like QEC tracking and LOL tracking , user guide has details.
6. As long as profile is not changing , you can change frequency and do few required cals like , VCO cal , QEC and LOL cal depending on performance requirement.
7. They are digital path dependent and if you change profile , you need to re initialise the chip with those parameters.
8. Device restart is not required , but re initialisation is required. Data Link has to go down.
9. Yes , as long as profile doesn't change as explained above.
thank you for you reply. We are in need of further clarification:
1. We have tried to use the APIs with Linux, our attempt was to use them in user space, but we realized the SPI is used by the AD9371 driver and it doesn’t allow us to write the SPI HAL layer inside the Mykonos library. We suspect we should use the spidev driver instead of the AD9371 one in case we want to use the Mykonos library in user space. Are we doing something wrong?
4. The documentation made us assume we could run with the mask all the following:
Tx BB filter cal, ADC tuner cal, RX TIA filter cal, RX DC offset cal, TX att delay, RX gain delay, ADC Flash calib, Path Delay cal, TX LOL INT init cal, TX LOL EXT init cal, TX QEC init cal, Loopback Orx LO delay, Loopback RxQEC init cal, RX LO delay, RX QEC init cal
So, if I got your point, most of these are run at the initialization of the driver, that is automatically initialized every time we load a profile. Is it correct?
5. We know about Tracking calibrations. We assumed we cannot use them in FFD working mode. Is a correct assumption?
Thank you in advance for your answers.
Thank you, we posted in Linux Software driver the API question.
About Tracking Calibrations, we assumed we couldn't perform them since we had to allocate time slots to allow the scheduler to perform the different phases. In FDD we have a continuous transmission, no time slots are available. So, how can the tracking calibrations be managed? Could you suggest further documentation on the topic other than the User Guide (UG992) ?
Thank you Best regards
Once the chip is in Radio on state, the ARM scheduler performs the tracking calibrations on a periodic basis. It performs the tracking calibrations in batches, where the Tx data is observed in chunks of 800 μs. Tracking calibration runs on the transmit and receive data in both TDD and FDD mode. Refer to the TRACKING CALIBRATION SCHEDULER section in UG for a better understanding.
Thank you for your reply.We went through the UG, we just don't understand how the scheduler is supposed to reserve chuncks of 800 μs on TX with continuous transmission.
The scheduling operation is done by the ARM. Tracking cals are run in batches of 800usec of data and when sufficient batches of a tracking calibration run, the algorithm then computes its correction based on the observed data across all the batches. So it is recommended to assign the ORX path to cals for at least 800usec or multiples of that. The final requirement is that the ORx path must be assigned to internal calibrations for 400 ms of transmit time every 2 sec.
But since you are working in FDD mode and the ORX path is always assigned to TX for running cals and also the TX path is continuously transmitting,so no need of worrying about the above two requirements.
Thank you, everything is clear now.