Range Report My new Ballistics Calculator -try to break it!

damoncali

damoncali

Gunny Sergeant
Full Member
Minuteman
Mar 19, 2011
1,375
89
51
Omaha, Nebraska
bisonballistics.com
#1
Hi all -

I wrote a new point mass ballistics calculator and put it on the web. You can find it here (it's free):

Ballistic Calculator

It's got a very basic interface at the moment, but I'd like to get some feedback to see how I can make it better. Feel free to comment here or email me at damon@bisonballistics.com with any questions or suggestions. Also, please let me know if you manage to uncover a bug. As I said, it's brand new, and new software usually has a few issues to iron out.

Also, if you have any reliable specialty bullets with verifiable BC's that you'd like to see added to the library, let me know which ones and I'll consider adding them. For long range bullets, G7 data is strongly preferred.

Thanks!

Damon
 
#3
Re: My new Ballistics Calculator -try to break it!

Great start Damon! Your interface, both input and output is easy and I like all the information you provide on the page. Very good stuff.

I ran the following test case and compared to my point mass solver and JBM:
Berger 155.5 gr FULLBORE bullet (G7 BC = .237)
3000 fps
ICAO sea level conditions (59 deg, 29.92 inHg, 0% RH)
10 mph wind from 9 O'clock
1.5" sight height and 100 yard zero.

Output compares as follows:

velocity at 1000 yards:
Bison: 1305.2 fps
Berger: 1304 fps
JBM: 1304.9 fps

time of flight at 1000 yards:
Bison: 1.52 sec
Berger: 1.5171 sec
JBM: 1.517 sec

drop at 1000 yards:
Bison: 309.5"
Berger: 309.9"
JBM: 309.8"

wind at 1000 yards:
Bison: 90.8"
Berger: 91.07"
JBM: 91.0"

It looks like all the outputs are practically identical compared to other 'properly written' solvers, with minor differences possibly due to how the different computer codes handle rounding.

Out of curiosity, what frequency are you integrating? My PM solver uses a 0.001 second time step. I'm not sure what JBM uses. He may be integrating wrt distance instead of time.

Eventually, to make your program of practical use, it will have to be able to model atmospheric effects. My advise is to be as clear as possible regarding the user interface and how you accept inputs that define air pressure (station pressure, corrected pressure and altitude, etc). Unfortunately this is one of the more confusing aspects of using ballistics programs and a well written interface can curb some error.

Again you've got a great start. Best of luck on your continued development!

-Bryan
 
#6
Re: My new Ballistics Calculator -try to break it!

Bryan,

I'm using distance, not time. It's currently using steps of 1 yard with a 4th order RK. I have not figured out what the optimal step is - 1 yard is just pretty convenient, and the results seemed ok.

The program behind the web page does take atmospheric conditions into account, and is currently using the default of the ICAO atmosphere. (What's the difference between that an Army anyhow? Is one better than the other?).

As you say, user interface is an issue, so I haven't quite worked out the best way to allow the most flexibility without adding confusion. I'll update this over time.

Pat M - the program can do what you ask behind the curtains. I just need to work it into the user interface. Thanks for the suggestion.



 
#7
Re: My new Ballistics Calculator -try to break it!

By the way,

I want to publicly thank Bryan for letting me use his G7 (and a few G1's) data in my bullet library. The work he started with his book is a breakthrough in sporting ballistics, and came at considerable effort and cost, I am sure.
 
#8
Re: My new Ballistics Calculator -try to break it!

<div class="ubbcode-block"><div class="ubbcode-header">Quote:</div><div class="ubbcode-body">What's the difference between that an Army anyhow? Is one better than the other?</div></div>

One is not 'better' than the other, but they are different. You can think of ASM as the 'old' model, and ICAO as the 'new' model. Either can be accurate, but the problem comes in when you mis-match the atmosphere model with what the bullet BC was corrected for.

As an example, all BC's that I provide are corrected to ICAO standard sea level conditions. If you were to use those BC's in a program that assumed ASM standard sea level conditions, there would be a 'mis-match' between what the BC is corrected for, and what the program considers default. The result manifests as an error that corresponds to about 2% error in BC (or air density, depending on how you look at it).

The important thing is to make sure that the BC and program are using the same atmosphere model. The different bullet makers are split on the atmospheres they correct BC's to. Berger and Lapua use ICAO, while Sierra and Hornady use ASM. It's a small subtlety that can cause confusing results if you don't know about ASM vs ICAO.

Take care,
-Bryan
 
#9
Re: My new Ballistics Calculator -try to break it!

That is very good to know, Bryan. The code has both options, but it's using ICAO right now. (All of the BC's are from your data, so that should be ok). I will have to modify it to pick the correct one if I add more bullets to the library.

But I'm really hesitant to add G1 data that really should be G7 (like the velocity dependent stuff Sierra has published) - it was a good effort once upon a time, but G7 is the way forward! I'd like to help that progress in my own small way.
 
#10
Re: My new Ballistics Calculator -try to break it!

<div class="ubbcode-block"><div class="ubbcode-header">Originally Posted By: Bryan Litz</div><div class="ubbcode-body">
Out of curiosity, what frequency are you integrating? My PM solver uses a 0.001 second time step. I'm not sure what JBM uses. He may be integrating wrt distance instead of time.
</div></div>

Almost everything I write uses Runge-Kutta methods with adaptive step size. Generally if you have to integrate to a few hundred yards, a decent solver will make it in a dozen or so steps. This makes it very efficient and much faster. I have code running in 8 bit micro controllers with this kind of solver that will find a solution in under a second. It's also almost always stable.

Damon -- I found that your solver has a common problem. Put in 200 ft/s for a muzzle velocity and you'll find the drag goes negative pretty quickly and then the bullet speeds up as it goes down range. You need to check for velocities near zero. In the case I tried, it started at 200.5 f/s at the muzzle and ended up at 438.6 at 1000 yards.

Also "Calculate" on the button is spelled wrong.

Brad
 
#11
Re: My new Ballistics Calculator -try to break it!

Damon, nice so far. One suggestion I have is to split bullet selection into three parts: caliber, manufacturer, then the particular bullet. I do similar filtering actions using either pre-loaded javascript arrays or AJAX to retrieve the relevant data from the server behind the scenes.
 
#12
Re: My new Ballistics Calculator -try to break it!

Very nice, Damon! I noticed one possible thing, in trying out your calculator, sight height remained fixed at 1.5, regardless of the numerical value I entered. If I left that field blank, an appropriate error message was returned. In any event, thanks for posting the link and info.
 
#13
Re: My new Ballistics Calculator -try to break it!

Brad - thanks for the note on the low velocities. I'll check into that. I'm also a little surprised you can get there in 12 steps - nice work. I'm also a notorious "calculate" mis-typer. I think half the bugs in my code during development came from typing that one word wrong.
 
#17
Re: My new Ballistics Calculator -try to break it!

Brad - one question on the small velocity. I'm scratching my head on this - is this not just what happens when bullets are fired at low velocity but expected to travel long horizontal distances?

I ran some numbers at 200 fps and got a drop of almost a mile at 1000 yards. In real life (as crazy as this is), I'd expect the bullet to hit terminal a terminal velocity of some sort, as it's basically in free fall (somehow I doubt the drag functions we use work well for this case anyhow). So is it so surprising that bullets gain velocity as they go down range? They gain velocity when you drop them (zero velocity).

Or is this an artifact of the numerical solution that I'm missing? In other words, is this "correct" for the point mass method, which is almost certainly inappropriate for these cases, or is it a problem with instability in the solver?

In either case, the practical thing to do is to limit the inputs to reasonable velocities, I suppose.
 
#19
Re: My new Ballistics Calculator -try to break it!

This is not a problem, as the velocity should increase.

The terminal velocity for a projectile is achieved when the drag is equal to it's weight. In the case of a 155 grain .308 caliber bullet, the drag is:

1/2*rho*V^2*S*cd = force of drag in lb.

1/2*.002377*V^2*.000517*.12 = 155/7000

Solving for V: V = 548 fps.

That means that if the bullet starts out at less than 548 fps and is allowed to fall long enough, it's velocity magnitude will approach 548 fps.

Running JBM with an input MV of 500 fps (min allowed), and a range of 3000 yards (max allowed), you can see that the velocity initially drops from 500 fps, down to a min of ~406 fps, then as gravity accelerates the projectile down, it speeds back up to 536 fps at 3000 yards. If max ranges longer than 3000 yards were possible, I'm sure the projectile velocity will asymptotically approach the terminal velocity.

Of course these scenarios are only academic given the absurd amount of drop, and the fact that we're modeling constant atmospheric density for the incredible range of altitude traversed. But it's an interesting discussion none-the-less.

It's not a case of drag going negative, but rather a case of properly written solvers modeling a projectile in virtual free-fall.

-Bryan
 
#20
Re: My new Ballistics Calculator -try to break it!

damoncali, ordinarily, I can tear the horn off an anvil but I couldn't break it.

<div class="ubbcode-block"><div class="ubbcode-header">Originally Posted By: JBM</div><div class="ubbcode-body">...Also "Calculate" on the button is spelled wrong.

Brad </div></div>
Silly me. I thought the button was referring to Dominico Calcualte, the famous Sicilian ballistican.
blush.gif
 
#21
Re: My new Ballistics Calculator -try to break it!

Can we get a complete metric version?

And perhaps add a few more Lapua bullets, like the 123gr Scenar(.264) and the 155gr Scenar?
 
#22
Re: My new Ballistics Calculator -try to break it!

<div class="ubbcode-block"><div class="ubbcode-header">Originally Posted By: Bryan Litz</div><div class="ubbcode-body">This is not a problem, as the velocity should increase.
</div></div>

I stand corrected. I didn't think it would accelerate that much...

I just checked again. If I put in 100 f/s as a muzzle velocity, the terminal velocity is "14,140,785,699,374.8" f/s using defaults and "Berger 70 VLD (0.224)" bullet.

I'm pretty sure that is too high.

I think you have the calculations down, the fun/hard part is what to do when inputs aren't what you expect. That's what I checked. This kind of error is typical of using a fixed step size in numerical integration -- when it starts to hit boundaries, you're going to have mathematical stability problems.

The problem could also be your drag model. If the velocity goes negative in a single step, your drag model may be giving an error or worse, bad values.

Brad
 
#23
Re: My new Ballistics Calculator -try to break it!

<div class="ubbcode-block"><div class="ubbcode-header">Originally Posted By: damoncali</div><div class="ubbcode-body">Brad - one question on the small velocity. I'm scratching my head on this - is this not just what happens when bullets are fired at low velocity but expected to travel long horizontal distances?

I ran some numbers at 200 fps and got a drop of almost a mile at 1000 yards. In real life (as crazy as this is), I'd expect the bullet to hit terminal a terminal velocity of some sort, as it's basically in free fall (somehow I doubt the drag functions we use work well for this case anyhow). So is it so surprising that bullets gain velocity as they go down range? They gain velocity when you drop them (zero velocity).

Or is this an artifact of the numerical solution that I'm missing? In other words, is this "correct" for the point mass method, which is almost certainly inappropriate for these cases, or is it a problem with instability in the solver?

In either case, the practical thing to do is to limit the inputs to reasonable velocities, I suppose. </div></div>

Please see above post.

Brad
 
#24
Re: My new Ballistics Calculator -try to break it!

<div class="ubbcode-block"><div class="ubbcode-header">Originally Posted By: Lill-rambo</div><div class="ubbcode-body">Can we get a complete metric version?</div></div>

What does "complete metric" mean, specifically? Is it a matter of the range in meters and windage/elevation in cm, or is there a need to input bullet weights in grams or BC's in kilograms/m^2 (or whatever it is a metric BC is)? I'm afraid I'm horribly US-centric when it comes to shooting units.
 
#25
Re: My new Ballistics Calculator -try to break it!

<div class="ubbcode-block"><div class="ubbcode-header">Originally Posted By: JBM</div><div class="ubbcode-body">
I just checked again. If I put in 100 f/s as a muzzle velocity, the terminal velocity is "14,140,785,699,374.8" f/s using defaults and "Berger 70 VLD (0.224)" bullet.

I'm pretty sure that is too high.
</div></div>

What makes you say that?
smile.gif


I think a lower bound on allowable velocity is in order. I'm pretty sure there's a point at which the code will blow up before you hit 1000 yards as well, but I haven't tried to find out what that is yet.
 
#27
Re: My new Ballistics Calculator -try to break it!

Thanks for the sight height fix, it's working perfectly. With my specific sight height and MVs for Sierra 168s and 175s, the 600 yd drop is dead on what I have found at the range. Very nice!
 
#28
Re: My new Ballistics Calculator -try to break it!

I don't understand the velocity discussion. How can ever a bullet reach a higher velocity on impact than the muzzle velocity? For the vacuum trajectory the speed is the same. With drag the velocity should always be smaller. Am I missing something?

Regards, tob
 
#29
Re: My new Ballistics Calculator -try to break it!

tob,

It only happens at very low velocity. The bullet's arc is so steep at low velocities, that the bullet winds up pointing and traveling almost straight down. In this position, gravity is increasing the velocity faster than drag is slowing it down. (Note that you have to start out a velocity lower than the bullet's terminal velocity).

The extreme case is a muzzle velocity of zero - you're essentially dropping the bullet. Gravity will accelerate it until the drag force is equal to gravity force. Now if you take that case and imagine a 1 fps nudge down range, you will eventually hit 1000 yards (after miles of drop), and at a total velocity of about the bullet's terminal velocity.

This is a painfully academic discussion, as the drops we're talking about are enormous, and I have no idea what happens to stability at these speeds or what sort of twist you'd need to make it all work. Eventually the bullet could stop spinning as well, which would change everything.

To add another wrinkle, programs like mine step through distance to arrive at an approximate solution to the "true" result. (Some step through time, but it's really the same thing). My program calculates things every yard of down range travel. This works very well for normal bullet trajectories - the error is very small. But if that yard of down range travel encompasses several miles of actual travel (almost all downward), you start to introduce mathematical errors in the numerical solver. That's why my program "blew up" at 100 fps.

Brad's program is solving the same equations as mine, but with a more sophisticated solver that varies the step size intelligently. This method takes far fewer steps without losing accuracy, and it can shrink the step size when things get weird. But even this method will eventually start producing garbage. (I haven't seen is code, so he can correct me if I'm wrong. I suspect he could go to lower velocities without his code blowing up).

With "normal" trajectories, Brad's program will produce very similar results to mine, but his will have done it in 10-30 steps where mine took 1000. This matters a lot if you want to make a portable device that runs on a microchip in a reasonable amount of time.

So the practical thing to do is to make people input velocities that our programs can handle - which is why I cut it off at 500 fps. I'm not even positive that is low enough to maintain accuracy - I just haven't looked into it.
 
#30
Re: My new Ballistics Calculator -try to break it!

<div class="ubbcode-block"><div class="ubbcode-header">Originally Posted By: damoncali</div><div class="ubbcode-body">
The extreme case is a muzzle velocity of zero - you're essentially dropping the bullet.
</div></div>
Dropping from where? The bullet has to go up before it can go down. Sorry, I just don't get it...

<div class="ubbcode-block"><div class="ubbcode-header">Originally Posted By: damoncali</div><div class="ubbcode-body">
Gravity will accelerate it until the drag force is equal to gravity force. Now if you take that case and imagine a 1 fps nudge down range, you will eventually hit 1000 yards (after miles of drop)
</div></div>
Again, how can the bullet drop "miles"? If you stand on a cliff and fire down or let if fall (free fall) I agree with you. Otherwise you have to bring the bullet up (with a certain velocity).

<div class="ubbcode-block"><div class="ubbcode-header">Originally Posted By: damoncali</div><div class="ubbcode-body">
So the practical thing to do is to make people input velocities that our programs can handle - which is why I cut it off at 500 fps. I'm not even positive that is low enough to maintain accuracy - I just haven't looked into it.
</div></div>

Several years ago I wrote a program by myself and never discovered any difficulties with low velocities.

tob
 
#31
Re: My new Ballistics Calculator -try to break it!

Dropping from anywhere. Stand on top of a building and drop a bullet off the edge. It will hit the ground with a certain velocity that is higher than it had when you let go of it (when it would be zero).

The bullet can drop miles only in theory. That's why this is all academic.

If you angle the shot up a little, both gravity and drag will be slowing the bullet. Once it starts heading down, gravity will try to speed it up and drag will try to slow it down. If the bullet is moving at normal speeds, drag will win and the bullet will slow down. If the bullet is moving very slowly (below terminal velocity) gravity wins and the bullet speeds up. In both cases, the final result will be a bullet approaching it's terminal velocity with a hefty downward component to it's velocity.
 
#32
Re: My new Ballistics Calculator -try to break it!

You mention that if you get enough requests for a feature, you'll consider it. I like what I see so far, but temp and pressure would be a couple of things to add.

Your calculator mimics mine at 52.0F and 29.92 InHG.
 
#33
Re: My new Ballistics Calculator -try to break it!

I like the simplicity of it. I'd like to see the Hornady .22 cal. 75gr BTHP Match bullet added. I'd also like to be able to get 25 and 50 yard increments out to 2,000 yards. Being able to input custom distances would be nice so a range card could be made for a certain course such as 235, 450, 590, etc.
 
#34
Re: My new Ballistics Calculator -try to break it!

Another question for everyone: what is your preferred way to enter atmospheric conditions? temp and pressure? altitude? Does anyone care about humidity, or is that too far in the weeds?

Adding that capability and a more refined bullet picker are next on the list, as is the ability to chose a finer interval than 100 yards.
 
#35
Re: My new Ballistics Calculator -try to break it!

To be convenient it should support both metric and imperial. Yes I care for humidity. And make provision for entering Corrected SLP, Absolute Pressure, Pressure Altitude and Density altitude.

And one feature that JBM didn't seem to get right: ability to compute bullet drop when zeroing range is set to 0 (or 1) yard.
 
#36
Re: My new Ballistics Calculator -try to break it!

How do European shooters use units? Meters and cm for drop/deflection? What about BC's and bullet weights? Do they use metric units for those as well?

I don't think there's anything wrong with JBM at a one yard zero. The results match mine, at least, and seem reasonable (at least as reasonable as a one yard zero). And you can't calculate a trajectory with a zero range of zero, because there are an infinite number of trajectories that meet that condition. It also makes the sight height setting problematic.

Or do you mean you want to calculate bullet drop without a zero at all? (JBM does this if you uncheck the one of the boxes, I believe).
 
#37
Re: My new Ballistics Calculator -try to break it!

I would add temperature and altitude, but I haven't played with or know enough about the other variables to say if they are worth adding.
 
#39
Re: My new Ballistics Calculator -try to break it!

<div class="ubbcode-block"><div class="ubbcode-header">Originally Posted By: damoncali</div><div class="ubbcode-body">How do European shooters use units? Meters and cm for drop/deflection? What about BC's and bullet weights? Do they use metric units for those as well?</div></div>
For drop/deflection it's meters, cm and MIL. BC doesn't have units (AFAIK). Bullet weights are in grams and grains, depending (so would be nice to be able to use whatever).

Also, a really nice interface would allow one to "mix-and-match" units for different parameters. Just take a look at Bullet Flight on iPhone to see a good way of doing it. An alternative to Bullet Flight's way is having plenty of config parameters - also doable but not as nice.

<div class="ubbcode-block"><div class="ubbcode-header">Quote:</div><div class="ubbcode-body">I don't think there's anything wrong with JBM at a one yard zero. The results match mine, at least, and seem reasonable (at least as reasonable as a one yard zero). And you can't calculate a trajectory with a zero range of zero, because there are an infinite number of trajectories that meet that condition. It also makes the sight height setting problematic.

Or do you mean you want to calculate bullet drop without a zero at all? (JBM does this if you uncheck the one of the boxes, I believe).
</div></div>
You're right! How could I miss it. Thanks for pointing it out!

<div class="ubbcode-block"><div class="ubbcode-header">Quote:</div><div class="ubbcode-body">I would add temperature and altitude, but I haven't played with or know enough about the other variables to say if they are worth adding.</div></div>
Barometric pressure comes in (basically) two ways - adjusted for Sea Level (relative to what it would be at Sea Level, in which case to be useful for ballistics it must be coupled with altitude) and Absolute (exactly what is measured on the spot). The main reason to for collecting all these measurements is computing the air density because that's what determines how much resistance "this" air offers to the flying object (and computing speed of sound, but that's beyond the scope of this conversation). Air density is directly related to density altitude, which in aviation is usually computed from pressure altitude. Since some devices - like Kestrel - can give you Density Altitude <span style="text-decoration: underline">directly</span>, it would be smart to use it rather than re-doing what it already computed.

If you have density altitude - you're mostly done, just convert it to air density (fixed table). If you have SLP pressure - you need "physical" altitude and temperature, and computations. If you have Absolute Pressure - you don't need altitude, just the temperature (see Air Density). Forgot to add that humidity affects air density, so it has to be taken into account...
 
#40
Re: My new Ballistics Calculator -try to break it!

<div class="ubbcode-block"><div class="ubbcode-header">Originally Posted By: mscott</div><div class="ubbcode-body">I would add temperature and altitude, but I haven't played with or know enough about the other variables to say if they are worth adding. </div></div>

Temperature and pressure have a significant effect. Humidity is getting into hair splitting, but some people seem to like it. All of these are used to calculate air density.
 
#41
Re: My new Ballistics Calculator -try to break it!

<div class="ubbcode-block"><div class="ubbcode-header">Originally Posted By: mouse07410</div><div class="ubbcode-body">
For drop/deflection it's meters, cm and MIL. BC doesn't have units (AFAIK). Bullet weights are in grams and grains, depending (so would be nice to be able to use whatever).

Also, a really nice interface would allow one to "mix-and-match" units for different parameters. Just take a look at Bullet Flight on iPhone to see a good way of doing it. An alternative to Bullet Flight's way is having plenty of config parameters - also doable but not as nice.
</div></div>

Thanks - I will think about the best way to get units in. I just want to make sure I'm putting in units that people actually use. BC does have units, by the way. For some reason, nobody ever mentions them. It's lb/in^2. The metric equivalent would be kg/cm^2, I would think, but I'm not sure if anyone ever does that.
 
#42
Re: My new Ballistics Calculator -try to break it!

Thank you for understanding.

Let me give you one usage example. My scope is MIL/MIL, and I'm "thinking in MILs". So I want mils there. I also think distance as meters, not yards. In this country (US) however ranges are done in yards, and drops - in inches. So to conveniently interoperate, I need to be able to deal e.g. with inches or cm of target size - depending on whether I make the measurement myself for myself or get it from others, inches or cm of bullet drop or deflection - translated to MILs (rather than MOA for the majority of my American colleagues
smile.gif
), pressure in inHg and mBa - depending on where I get the measurements from, density altitude if I input directly what Kestrel told me...

Bullet Flight caters to the above model. Ballistic FTE doesn't - so it introduced a bunch of config parameters to define which values I want to keep metric and which ones - imperial (it's still not granular enough for me, and forces me to have some values in the unit system I'd rather not employ, but it's much better than not being able to set al least those that I can with it)...
 
You must log in or register to reply here.

Similar threads

M
HELP! Point of Impact Doesn't Match Ballistic Calculator (@ Mid-Range)
Replies
3
Views
342
R_A_W
R_A_W
Rbb392
Getting started ballistic calculators
Replies
0
Views
518
Rbb392
Rbb392
DocUSMCRetired
New Applied Ballistics® Quantum™ APP! - & It's Free!
Replies
342
Views
19K
W6SPK
W
T
Truing Ballistic Calculator, Velocity Errors?
Replies
8
Views
491
chevy_man
C
PreciseLoad
New Web-Based Interior Ballistics Calculator – Precise Load
Replies
9
Views
714
biggershooter
B
Top Bottom
Back
Home
Forums
Merch
Alerts
You must be at least 18 years of age to use this site
You confirm that you are at least 18 years of age by continuing to use the site.