The basic issue is setting phi_3db to degrees, but there may also be a problem with the basic definition of phi_3db (more on that shortly). The conversion is not
phi_3db = 2*atan(cell_radius(i)/HAP_altitude*pi/180)
with the conversion factor in the argument of atan, but rather
phi_3db = (180/pi)*2*atan(cell_radius(i)/HAP_altitude)
with the conversion factor outside. (Also, conversion to dB requires log10, not log).
Rather than having a bunch of factors of 180/pi floating around, the code below uses the sind and atand functions.
I don't have the mapminmax function (Deep Learning Toolbox) so I just normalized G in the usual way and didn't worry about mapping the minimum to zero.
Major functionality in toolboxes is is one thing, that's what toolboxes are for. But Mathworks has gotten good at creating simple, short 'convenience' toolbox functions that actually make things a lot less less convenient for people who want to run some vanilla piece of code and don't have all the toolboxes. Is it a ploy to force people to buy more toolboxes? Probably not. The effect is the same, though.
The plot looks a lot better after converting to degrees in eqn (2)
phi_3db = 2*atand(cell_radius(i)/HAP_altitude) (2) original
But eqn (2) does not quite reproduce the figure. Interestingly, the equation
phi_3db = atand(2*cell_radius(i)/HAP_altitude) (3) modified
does reproduce the figure. So now we have the choice, is eqn (2) correct and the figure incorrect? Or are both eqn (3) and the figure correct, and eqn (2) incorrect?
theta = (-100:.01:100);
cell_radius = [10 5 2]
HAP_altitude = 20;
phi_3db = atand(2*cell_radius(i)/HAP_altitude)
Gain(i,:) = 0.7*(2*besselj(1,(70*pi/phi_3db)*sind(theta))./sind(theta)).^2;