Using Leon "BADBOY" Smiths data, I had a little chat with ChatGPT and came up with this....
"Turn Radius Plotter" Check it out!
Thanks for putting this together and for crediting my original turn-performance data.
I've had a look at the source code on your web page because I noticed that the turn radii being plotted don't agree with the radii in my original table. I think I've found exactly where the discrepancy is coming from.
The source code calculates the radius using:
const rate = Number(fs.sustainedTurnRateDegSec);
const speedMph = Number(fs.cornerVelocityMph);
const speedFtS = speedMph * 1.46667;
const omegaRad = rate * Math.PI / 180;
const radiusFt = speedFtS / omegaRad;
The problem is that this combines two quantities which belong to different flight conditions:
1. Sustained turn rate
2. Corner velocity
They cannot be used together to calculate a turn radius.
For example, for the Yak-3 with flaps up, my table gives:
Sustained turn rate = 21.5 deg/sec
Sustained turn radius = 665 ft
Corner velocity = 238 mph
Turn rate at corner = 31.3 deg/sec
Turn radius at corner = 637 ft
The webpage instead combines the corner velocity of 238 mph with the sustained turn rate of 21.5 deg/sec.
That gives:
238 mph = 349.1 ft/sec
21.5 deg/sec = 0.37525 rad/sec
Therefore:
R = V / omega
= 349.1 / 0.37525
= 930.2 ft
which is exactly why the webpage displays 930 ft.
So the 930 ft isn't a unit-conversion or rounding error. It is the radius of a fictitious condition produced by combining the corner velocity with the sustained turn rate.
The same issue also affects the plotted 8-second paths. The code calculates distance travelled using corner velocity:
const travelDistanceFt = speedFtS * TRAVEL_TIME_SECONDS;
but calculates the heading change using sustained turn rate:
const turnAngleDeg = rate * TRAVEL_TIME_SECONDS;
So the plotted aircraft is effectively flying at corner velocity while simultaneously turning at the sustained turn rate. Those two values do not describe the same operating point.
There are two valid ways the graph could be done.
If the intention is to plot CORNER performance, use:
Corner velocity
Turn rate at corner
Turn radius at corner
For the Yak-3 that would be:
238 mph
31.3 deg/sec
637 ft
If the intention is to plot SUSTAINED performance, use:
Sustained turn rate
Sustained turn radius
and the corresponding sustained-turn velocity
For the Yak-3 that would give:
21.5 deg/sec
665 ft
The important thing is simply not to mix the sustained-turn-rate column with the corner-velocity column.
There is actually a sentence on the webpage which describes the same mistaken assumption:
"Turn radius is derived from sustained turn rate (deg/sec) and corner velocity: r = v / omega."
That is the fundamental source of the error.
I hope that helps identify it. The underlying data themselves appear to have been read correctly; it is the combination of the sustained and corner quantities in the calculation that is producing the wrong radii.
Lastly, one thing I am slightly puzzled by is why the turn radius is being recalculated in the first place. The original chart already contains a “Turn Radius at Corner” column, so if the purpose is to plot corner-turn performance, those radius values can simply be taken directly from the table. For example, the Yak-3 value is already given as 637 ft. There is therefore no need to derive it from velocity and turn rate.
Recalculating it from the corner velocity and the turn rate at corner should of course give essentially the same result, apart from small differences caused by the displayed values being rounded. But using the chart “Turn Radius at Corner” value directly would both avoid that rounding issue and, more importantly, avoid accidentally combining quantities from two different flight conditions.
Either way it looks like a simple fix.
Hope that helps
Badboy
