Hi,
I am interested in using ad9361 to conduct frequency hopping for our application. Based on the ad9361 reference manual, it stated that for fast hopping rate, it is recommended to use fast lock method. Upon trying the fast lock functions, I stumbled across this function "ad9361_fastlock_recall()" which takes up a lot of processing time. Inside this function, I see notice this weird process. This process only occur if the new value for FORCE ALC register is the same for the previous TX/RX FORCE ALC register value. Based on the comment, it stated that this is a workaround for locked process.
I tried looking into the ad9361 register map documents, it also didn't explained much. Is it possible to explain what this FORCE ALC register does, what this process is really doing and what problem will it caused if I comment away this workaround process? Will it cause the LO synthesizer to be unable to lock at that frequency? I am trying to cut down on the processing time used on this function Please kindly get back to me.
The project reference version I am using is based on 2016_R1 branch.
Regards
Selwyn.
Please see this thread here:
https://ez.analog.com/linux-device-drivers/linux-software-drivers/f/q-a/87062/ad9361---some-estimate-on-tuning-time-standard-and-fastlock/80338#80338
It also talks about the ALC ...
-Michael
Hi Michael,
Based on what I understood from the above thread, it is mentioned that to get the maximum settling time, the ALC word should be different and to achieve that is by toggling the LSB of the ALC word. Am I right? And what do you mean by maximum settling time? Is it suppose to be the fastest or slowest , just to be confirmed?
Lastly, if the ALC is the same throughout, does it also means the settling time will be deterministic ?
Regards,
Selwyn
It has been a long time ago when I looked into this. Let's summarize it with undesired behavior will occur when the ALC word is the same between two consecutive profiles. If you recall them by the SW API, the driver will make sure to apply the workaround. However if you recall profiles by PIN CONTROL. You need to make sure that you invoke profiles in a sequence such that this condition it true.
Thanks for the explanation. Just to have more clarity on how the workaround function. Does it just toggle the lsb of the ALC value if it detect the current ALC value is the same as previous?
Basically Yes -
The synthesizer lock can break if the current and next fast lock profiles have the same ALC word (address F [7:1]). When this happens it confuses the digital control in the synthesizer and actually makes it take much longer to lock than even a normal calibration. The work around is to just add 2 to address F (which increments ALC word by 1), this avoids the lock problem, and has no effect on performance.
There are two ways to implement, 1) you can do a check on address F each time a profile is called and increment if needed. Or 2) you can check all of the profiles stored in the part and increment any that are needed to avoid conflicts. Option 1 takes more real time SPI writes, but it only changes the ALC when its definitely needed. Option 2 is easier during real time operation since the increments are done during initialization, but it make increment ALC values that don’t need to be changed.