Closed ryan-summers closed 4 years ago
I wonder whether this is not easier done in firmware, just according to the datasheet:
tune_bias(I_DS_desired = 50 mA)
@hartytp ?
(NB neither the hardware nor the software are following the datasheet of the power amplifier: with V_DS = 0, V_GS should be set to 0 V and not -3.3 V. The gate current due to that is probably not too stressful though).
(NB neither the hardware nor the software are following the datasheet of the power amplifier: with V_DS = 0, V_GS should be set to 0 V and not -3.3 V. The gate current due to that is probably not too stressful though).
I believe that's correct (I asked @gkasprow about this in one of the Booster issues a while back, and he had a reason for this slight deviation from the datasheet sequence).
Greg's nominal sequence (can't remember if the FW actually implements this at present) is
Elaborating for my own benefit...
channel rf signal off
= switch open = ON_OFF_n
LOW
I assume we'll also start here with PWR_ON
low?
start with pinch off
DAC to max, EN_BIAS
will be low since PWR_ON
is low at this point
channel power on
PWR_ON
high which, in order:
EN_BISA
ondecrease by 1 mV
1LSB = 0.8mV, so this basically means tune it in 1LSB steps.
return V_GS and I_DS
or an error if I_DS can't reach the set value?
Anyway, yes, that all looks correct from my end.
A couple of probably obvious points...
command is something like: tune_bias(I_DS_desired = 50 mA)
Agreed. From our end it would be nicer to do this via the main remote interface (I assume CTI/TS are happy with this).
I assume this wouldn't be something that runs at startup each time (as that would lead to gain variations between boots), but only at requests -- although, checking that the currents are correct each time the channels are enabled would be nice.
Also assuming that we'll have some input sanitizing to limit the set current to within the range on the FET datasheet?
I assume we'll also start here with PWR_ON low?
It doesn't matter for this procedure.
From our end it would be nicer to do this via the main remote interface (I assume CTI/TS are happy with this).
IME it's easy and better to move this algorithm into the firmware. You can still set/override V_GS.
as that would lead to gain variations between boots
Pretty sure that not doing it regularly leads to gain variation. The gain scales more with the quiescent current than with the gate voltage. The relation between the IDS and VGS is pretty temperature dependent which you'd rely on then.
IME it's easy and better to move this algorithm into the firmware. You can still set/override V_GS.
I think we mean the same thing here?
Pretty sure that not doing it regularly leads to gain variation. The gain scales more with the quiescent current than with the gate voltage. The relation between the IDS and VGS is pretty temperature dependent which you'd rely on then.
A specific example of what I'd be concerned with here...
I would want the bias current to be the same in both cases after warm up (I'm less sensitive to exactly what value that current). If we calibrate the gate voltage each time the firmware starts then I expect case 1 and case 2 to give different steady-state currents, however if we calibrate once and then load from flash then they should give the same current.
IME it's easy and better to move this algorithm into the firmware. You can still set/override V_GS.
I think we mean the same thing here?
That wasn't clear to me.
A specific example of what I'd be concerned with here...
Sure. As long as you ensure the temperature is stable, V_GS=constant gives you stable gain without any jumps from to I_DS tuning. As soon as the temperature changes you'll get either jumps from I_DS tuning or gain changes because you don't tune. I agree that in labs people tend to just overload all these onto temperature stability and don't tune.
As soon as the temperature changes you'll get either jumps from I_DS tuning
Do you mean if you implemented software feedback on V_GS to stabilize I_DS? I don't think that's a realistic option because of the I_DS dependence on input RF.
gain changes because you don't tune. I agree that in labs people tend to just overload all these onto temperature stability and don't tune.
Indeed. That would be my preference here. I've measured the gain stability of Booster in our labs and the variations over temperature/time were tiny. So, my preference would be to store V_DS in non-volatile memory, but provide a remote command to allow it to be calibrated to give a given current at a given moment in time, accepting that the steady-state current will depend slightly on the unit temperature when it was calibrated.
Do you mean if you implemented software feedback on V_GS to stabilize I_DS? I don't think that's a realistic option because of the I_DS dependence on input RF.
You'd do it each time the channel is turned on. During that sequence there is no RF.
accepting that the steady-state current will depend slightly on the unit temperature when it was calibrated.
I think we are saying the same thing. It will depend on the current unit temperature and on the calibration temperature. In the other case it would depend on the current temperature and on the temperatures during channel enable.
It will depend on the current unit temperature and on the calibration temperature. In the other case it would depend on the current temperature and on the temperatures during channel enable.
Indeed. My preference here would be to depend on the calibration temperature rather than the boot temperature.
Develop a method for calibrating an output channel to a desired output power.
The intended algorithm for this involves the user specifying a desired output power and booster then performs a search of the correct output bias setting to achieve the desired output power.
The configuration values after the calibration routine then need to be stored in non-volatile memory for retrieval upon boot.
This process should be supported over the network interface.