Ballistic Program

[Kilmore]

damoncali nailed it. Corrected math and doppler data. I can direct you to a thread of postings on this forum that address the fact that many programs' solutions don't match the actuals. This software works, enter the data, get a accurate solution. Insult me all you want. It means nothing to me. I didn't start this string. I merely answered the question posted by excaliber. What continues to baffle the hell out of me is: how can anyone declare something doesn't work without ever having tried it first?

 

[Kilmore]

Addendum: I have requested Surgeon Rifles consider building a .408 rifle for evaluation. That horse is still up and running. Timber Wolf, EDM and Barker Machine are also in the loop. DTA should have a .408 out soon we hope to purchase and test.

 

[damoncali]

Just to be clear, the correct math was figured out many decades ago. It is the data that is the hard part.

 

[Lowlight]

Doppler has been available, it's merely a case of paying for it, which some have.

i have posted this a dozen times, from years back, Patagonia when it was LoadBase, with G1 / G7 / Doppler comparisons done by Lapua.

I think the bigger insult, is insulting people's intelligence, as if nobody else knows about any of this, yet it appears to be much more widespread then one would imagine.

 

[damoncali]

Are those Pejsa calculations? I'd be surprised if point mass with standard drag functions matched up that well with doppler (or each other), but I've been surprised before.

 

[Lowlight]

Yes Modified Pesja using Patagonia Ballistics... that is actual output. Gus is a helluva guy to talk to and being from South America doesn't fall under the politics of the US ballistic community, so you find welcome deviations from what is being sold here.

This data was forwarded to me Back when Patagonia was Loadbase 3, it is now ColdBore but same engine. It was tested in Europe by the Spanish when this data was captured.

FFS also has doppler data, as Ashbury got that put inside.

 

[damoncali]

So let me ask, what in your opinion are the shortcommings of the state of the art (as you choose define it)? I'm curious, because I'm obviously interested in this stuff (and write software for a living/hobby). But much of the software out there seems clunky, for lack of a better word. Or do you view this as a solved problem? What is the next improvement around the bend?

 

[Lowlight]

A lot is clunky, the user interface needs to be streamlined for sure. The data is solid, there is only so much you can do with an App or PDA, you can't run 6 DOF calculations with an iPhone. This why I don't like when they go heavy on stuff like Spindrift. If it tells me I need 1 MOA, (remember I inputted the bare minimum of data) for a 1000 yard shot and then I change the zero range to 600 yards and it says I still need 1 MOA, that is very misleading to people. Next thing you know you have guys seeing that and wanting to add SD at 400 yards. The buzzword is "truncated 6 DOF Calculations" ... ok, is like a flat rate average we used based off a single sampling ? Cause that is what it looks like. How does my 1/10 rifle going 2600fps have the same value as your 1-12 going 2775fps ? TOF, Spin, all different yet the answer is the same... 1MOA. So I turn that stuff off, or use the FFS that doesn't even include it.

A better UI would be nice, standardizing device connections like FFS and Patagonia do would be a great start. Getting the iPhone to talk to a Kestrel, or manufacturers to start adding bluetooth to more lasers. Both FFS & CB1 talk to a host of devices, this is awesome. One button solutions are out there, so why is it not more widespread ? You tap your laser on target, your base data is pre-set before, and when the laser fires a solution is instantly there, no work on the user's part after setting it up. FFS does this already... If you're gonna work with a PDA, why not let the PDA do the work. Along with your other tools, as we all have Kestrels and Lasers already they should talk as a standard feature.

The battle for G superiority is hurting this, when you have people invested in a G curve they overlook the end user, who cares as long as I have the right answer. I need access to the data. Or I need the data in there already. That is the number one question of people, which one to use. FFS only uses G1, Patagonia both, with the results above, so if they can do it, it can be done. I was using Shooter yesterday and noted they have added BC banding in that App, (G7) which is great, I think it should be automatic. Like JBM does with a 175gr SMK using G1, it auto bands. Why not auto band them all, both values, it;s a better representation of the flight, starts out fast, ends slower. When people have to guess at a value, you have garbage being put in so you get garbage out. If you have a bullet library, include the proper banding values like JBM does but on a larger scale, let it auto load and move on. You're MV is not an issue, you include that later. Just pick the bullet, it auto bands 3 BC values, you add in your actual MV, done.

There is more I would do, but that is enough to chew on, clearly I am handicapped in these conversions, as been noted on several occasions, so my opinion is just the odd ravings of a poorly thought out mind. Or as they say back home, "whadda I know", I just a guy with a website.

 

[Kilmore]

The math from the 1950's is flawed. Reason most ballistic programs blow up at 2000 yards. Lyman figured out the error and corrected it. What is clearly so poetic about this shitstorm is that the biggest supporters of AIM-E are the Marine Snipers from Quantico, followed closely by devgru. They funded and organized the eval for JSOC, they are the assigned liasion for the purchase, and they have tested it and know it works. This from the finest marksmen on the face of the planet. Hammer me all you want. But to smack talk you own people? Now que that music. Taps seems appropriate.

 

[Lowlight]

You're The one motherfucking people, I never said a word about the Marines or Devgru...
Why are you even hear again ? We're a bunch of never was right...

We are simply talking about the black ops side of things, how YOU Present it, not the end user.

Oddly enough, I agree, PM has a flaw beyond distances, Pesja based programs, not so much. So while yes there is a flaw, it's not the only solution, so claiming things blanket is the issue

Ask DTA about FFS why don't cha.

Nice attempt to spin it back on me, this way you can go back to the Marines and say, "See SH is bullshit they were attacking you" hence, message lost that you're not the only game in town. Maybe they need a broader demo to compare it too. Instead of one person's opinion.

 

[Lowlight]

Remember I am not the one looking to "sell" them anything... you can't say the same.

I am sure if they were shown more than one solution side by side, what we ARE saying would become abundantly clear to them.

Want to set up a head to head, I have access to 2685m here, 1 hour from DIA, there is a 100 pieces of steel on the range. No secrets spilled just a simple comparison of features. Feature Set by Feature Set of what something like FFS or CB1 can do alongside side AIM-E, really simple. You can run AIME and nobody ever had to see anything beyond a, can or cannot doing something.

 

[damoncali]

The math from the 1950's is flawed. Reason most ballistic programs blow up at 2000 yards. Lyman figured out the error and corrected it. What is clearly so poetic about this shitstorm is that the biggest supporters of AIM-E are the Marine Snipers from Quantico, followed closely by devgru. They funded and organized the eval for JSOC, they are the assigned liasion for the purchase, and they have tested it and know it works. This from the finest marksmen on the face of the planet. Hammer me all you want. But to smack talk you own people? Now que that music. Taps seems appropriate.

I'm confused. First you say point mass + doppler = win, then you say 50's math is flawed. 50's math *is* point mass. And it's so simple I'm not sure where the flaw would be outside of it not accounting for spin, and those effects are pretty well understood. Can you elaborate? What is the flaw?

 

[damoncali]

A lot is clunky, the user interface needs to be streamlined for sure. The data is solid, there is only so much you can do with an App or PDA, you can't run 6 DOF calculations with an iPhone. This why I don't like when they go heavy on stuff like Spindrift. If it tells me I need 1 MOA, (remember I inputted the bare minimum of data) for a 1000 yard shot and then I change the zero range to 600 yards and it says I still need 1 MOA, that is very misleading to people. Next thing you know you have guys seeing that and wanting to add SD at 400 yards. The buzzword is "truncated 6 DOF Calculations" ... ok, is like a flat rate average we used based off a single sampling ? Cause that is what it looks like. How does my 1/10 rifle going 2600fps have the same value as your 1-12 going 2775fps ? TOF, Spin, all different yet the answer is the same... 1MOA. So I turn that stuff off, or use the FFS that doesn't even include it.

A better UI would be nice, standardizing device connections like FFS and Patagonia do would be a great start. Getting the iPhone to talk to a Kestrel, or manufacturers to start adding bluetooth to more lasers. Both FFS & CB1 talk to a host of devices, this is awesome. One button solutions are out there, so why is it not more widespread ? You tap your laser on target, your base data is pre-set before, and when the laser fires a solution is instantly there, no work on the user's part after setting it up. FFS does this already... If you're gonna work with a PDA, why not let the PDA do the work. Along with your other tools, as we all have Kestrels and Lasers already they should talk as a standard feature.

The battle for G superiority is hurting this, when you have people invested in a G curve they overlook the end user, who cares as long as I have the right answer. I need access to the data. Or I need the data in there already. That is the number one question of people, which one to use. FFS only uses G1, Patagonia both, with the results above, so if they can do it, it can be done. I was using Shooter yesterday and noted they have added BC banding in that App, (G7) which is great, I think it should be automatic. Like JBM does with a 175gr SMK using G1, it auto bands. Why not auto band them all, both values, it;s a better representation of the flight, starts out fast, ends slower. When people have to guess at a value, you have garbage being put in so you get garbage out. If you have a bullet library, include the proper banding values like JBM does but on a larger scale, let it auto load and move on. You're MV is not an issue, you include that later. Just pick the bullet, it auto bands 3 BC values, you add in your actual MV, done.

There is more I would do, but that is enough to chew on, clearly I am handicapped in these conversions, as been noted on several occasions, so my opinion is just the odd ravings of a poorly thought out mind. Or as they say back home, "whadda I know", I just a guy with a website.

That makes a lot of sense. I agree that much of this stuff should not be exposed to the user. There is never a case where a user should be choosing a drag function in an ideal world - that's the approach I took with my meager free calculator. User picks a bullet, computer picks a drag function. I don't auto-band yet, but if I had that part written, I'd do that too. No need to drown the user in detail they may or may not understand, and frankly, don't need to. That's what computers are for.

I think the issue with device interaction is that most shooters simply don't have the devices, and therefore there's not much demand to build out the software to interface with them. (That is, the number of people with this gear is pretty small, where the number of people who are perfectly served by JBM is much bigger).

 

[HobbyShooter]

I'm fairly new to all this and can tell I have a lot of reading to do, but I do have a question. Is there something out there that acts as both a log book and a ballistic calculator?

I've been using shooter and strelok and it seems both apps rely on some critical guesses. MV, which varies from shot to shot and temp correction/sensitivity factor to name a couple. If I'm going to be logging my MV, ambient temp, altitude, wind speed/direction, etc., why not make all that history accessible to the ballistic calculator so it can create a firing solution based on logged data instead of my guesses?

 

[Bigwheels]

Recently I had the Shooter app update on my droid, & it apparently changed everything. I had to figure out how to work it again, but it is now tracking in sync with my FFS solutions out to 1800 yds, where before past about 1000 it did not. Don't know what they did but I'm glad.

 

[LastShot300]

The math from the 1950's is flawed. Reason most ballistic programs blow up at 2000 yards. Lyman figured out the error and corrected it. What is clearly so poetic about this shitstorm is that the biggest supporters of AIM-E are the Marine Snipers from Quantico, followed closely by devgru. They funded and organized the eval for JSOC, they are the assigned liasion for the purchase, and they have tested it and know it works. This from the finest marksmen on the face of the planet. Hammer me all you want. But to smack talk you own people? Now que that music. Taps seems appropriate.

I think you are outdated, Point Mass is, as pointed out by Damoncali, the math of the 50s to start...and there is no inherent "flaw" since all it does it so solve the XYZ position of a "particle" in motion.

The greatest issues with Point Mass are twofold : being "G-dependent" and how the different sonic zones are approximated by the relation between the Mach Number (squared, not squared, proportional, etc)...so under that light, yes it's not the best solution out there for sure. Those are the main reasons why PM based programs start to show the inaccuracies mentioned when approaching truly long range.

Programs like FFS and Patagonia's CB1 are so robust because the math is extremely different. The only possible thing Lyman could have done about it is to enhance (not improve) the numerical treatment of the solution, that's it and no big deal at all. Try not to confuse yourself with any "NASA" thing...because that's 100% hype.

 

[LastShot300]

A lot is clunky, the user interface needs to be streamlined for sure. The data is solid, there is only so much you can do with an App or PDA, you can't run 6 DOF calculations with an iPhone. This why I don't like when they go heavy on stuff like Spindrift. If it tells me I need 1 MOA, (remember I inputted the bare minimum of data) for a 1000 yard shot and then I change the zero range to 600 yards and it says I still need 1 MOA, that is very misleading to people. Next thing you know you have guys seeing that and wanting to add SD at 400 yards. The buzzword is "truncated 6 DOF Calculations" ... ok, is like a flat rate average we used based off a single sampling ? Cause that is what it looks like. How does my 1/10 rifle going 2600fps have the same value as your 1-12 going 2775fps ? TOF, Spin, all different yet the answer is the same... 1MOA. So I turn that stuff off, or use the FFS that doesn't even include it.

A better UI would be nice, standardizing device connections like FFS and Patagonia do would be a great start. Getting the iPhone to talk to a Kestrel, or manufacturers to start adding bluetooth to more lasers. Both FFS & CB1 talk to a host of devices, this is awesome. One button solutions are out there, so why is it not more widespread ? You tap your laser on target, your base data is pre-set before, and when the laser fires a solution is instantly there, no work on the user's part after setting it up. FFS does this already... If you're gonna work with a PDA, why not let the PDA do the work. Along with your other tools, as we all have Kestrels and Lasers already they should talk as a standard feature.

The battle for G superiority is hurting this, when you have people invested in a G curve they overlook the end user, who cares as long as I have the right answer. I need access to the data. Or I need the data in there already. That is the number one question of people, which one to use. FFS only uses G1, Patagonia both, with the results above, so if they can do it, it can be done. I was using Shooter yesterday and noted they have added BC banding in that App, (G7) which is great, I think it should be automatic. Like JBM does with a 175gr SMK using G1, it auto bands. Why not auto band them all, both values, it;s a better representation of the flight, starts out fast, ends slower. When people have to guess at a value, you have garbage being put in so you get garbage out. If you have a bullet library, include the proper banding values like JBM does but on a larger scale, let it auto load and move on. You're MV is not an issue, you include that later. Just pick the bullet, it auto bands 3 BC values, you add in your actual MV, done.

There is more I would do, but that is enough to chew on, clearly I am handicapped in these conversions, as been noted on several occasions, so my opinion is just the odd ravings of a poorly thought out mind. Or as they say back home, "whadda I know", I just a guy with a website.

Thanks for the great explanation. Right to the point.

 

[Lowlight]

Kilmore, One question, easy, yes or no... Today, as in, right now, does the AIME interface with Lasers & Kestrels ? Can you use the Vectronix cable for a one button solution ? Or does it work via Bluetooth like with the PLRF-25c BT ? I know FFS does, on both counts, I believe CB1 works with several Laser Brands also. I gave Vectronix my Trimble and they tested it on the 25c BT model so that works with theirs.

For ELR / XLR the emphasis I see on mil ranging is ridiculous as you cannot mil a target like that at distance. .05 mils on human sized targets beyond 800-1000 yards is a miss and I don't know anyone working that tight ranging wise with a reticle ? So for a ballistic software who's emphasis is beyond 1500m, system integration is essential. It really should be priority one. There are at least a dozen bullet points on "Mil reticle Ranging" in the brochure, now that might be historical, but even so, the time it was written, that is crazy. It would be like giving a solution for the BDC off the MST-100 and then pointing to pictures of Marines using it. Non-laser ranging at ELR distances is best with triangulation and not the reticle.

So does it work ?

 

[damoncali]

I think you are outdated, Point Mass is, as pointed out by Damoncali, the math of the 50s to start...and there is no inherent "flaw" since all it does it so solve the XYZ position of a "particle" in motion.

The greatest issues with Point Mass are twofold : being "G-dependent" and how the different sonic zones are approximated by the relation between the Mach Number (squared, not squared, proportional, etc)...so under that light, yes it's not the best solution out there for sure. Those are the main reasons why PM based programs start to show the inaccuracies mentioned when approaching truly long range.

Programs like FFS and Patagonia's CB1 are so robust because the math is extremely different. The only possible thing Lyman could have done about it is to enhance (not improve) the numerical treatment of the solution, that's it and no big deal at all. Try not to confuse yourself with any "NASA" thing...because that's 100% hype.

I have a minor quibble with this - point mass is not technically "G-dependent"- it's just that most point mass solvers out there (mine included) are implemented in a way to that is G-dependent. It's just very convenient, works well for mid range, and there is lots of decent data available via the industry. But you don't have to do that. I believe Bryan Litz updated his to use custom, bullet-specific drag profiles for some rounds, for example. So be careful not to blame the point mass method, which is quite good, for the problems created by poor data quality/availability, as they're totally separable things. The point mass method is very good at solving the equations. But you've got to give it good data for that solution to be correct. Same deal with Pejsa-based solvers.

 

[LastShot300]

I have a minor quibble with this - point mass is not technically "G-dependent"- it's just that most point mass solvers out there (mine included) are implemented in a way to that is G-dependent. It's just very convenient, works well for mid range, and there is lots of decent data available via the industry. But you don't have to do that. I believe Bryan Litz updated his to use custom, bullet-specific drag profiles for some rounds, for example. So be careful not to blame the point mass method, which is quite good, for the problems created by poor data quality/availability, as they're totally separable things. The point mass method is very good at solving the equations. But you've got to give it good data for that solution to be correct. Same deal with Pejsa-based solvers.

My fault, fast typing and not clear enough. I meant by "G-dependent" that the Point Mass method will require an appropiate G-function, as we all know, but the outcome is so tigthly coupled to the G-function that the method itself cannot be improved upon. In contrast a truly PEJSA implementation does not show that coupling. I know, most people don't get it because the books are so bad written...but the magic is there.

 

[damoncali]

My fault, fast typing and not clear enough. I meant by "G-dependent" that the Point Mass method will require an appropiate G-function, as we all know, but the outcome is so tigthly coupled to the G-function that the method itself cannot be improved upon. In contrast a truly PEJSA implementation does not show that coupling. I know, most people don't get it because the books are so bad written...but the magic is there.

I see it the other way around. (Forgive the impending geek out...) With Pejsa, the data required is tied to the solution method. It's very clever, and obviously works, but it's hard to think about things in terms of physics - it's all about coefficients with unclear physical meaning.

Point mass, on the other hand is totally decoupled from the data. You can feed it any data table of cd vs mach number you want, and it will not know or care where that came from. You can calculate it from a G1 and a BC, some other standard drag function, come up with your own closed-form drag function, use doppler data, or let a monkey pound the keyboard for a bit. It allows you to see what changes in the physical data do the trajectory. If you shift the drag curve a little, you'll know what effect that has on the results. I think that clear relationship to the physical world is an advantage when trying to figure things out - it helps build intuition that can be useful when looking at new bullets.

Of course, if you just want to push a button and get the answer, either will work if you put the right inputs in.

On another note, there are probably dozens of ways to solve the point mass equations. That's why I'm eager to hear what this so-called flaw is. I've compared my solver with JBM and Litz's. All three produce very similar numbers and all three use *different* methods of solving the point mass equations. Mine steps over distance, Litz's over time, and JBM uses a variable step algorithm (if memory serves). As you said, point mass is just three simple F=ma equations. Hard to see what's wrong with that (outside of the obvious missing three DOF). And since three people independently came up with solutions that match, that's quite a high hurdle to say point mass is flawed in some novel way...

 

[LastShot300]

I see it the other way around. (Forgive the impending geek out...) With Pejsa, the data required is tied to the solution method. It's very clever, and obviously works, but it's hard to think about things in terms of physics - it's all about coefficients with unclear physical meaning.

Point mass, on the other hand is totally decoupled from the data. You can feed it any data table of cd vs mach number you want, and it will not know or care where that came from. You can calculate it from a G1 and a BC, some other standard drag function, come up with your own closed-form drag function, use doppler data, or let a monkey pound the keyboard for a bit. It allows you to see what changes in the physical data do the trajectory. If you shift the drag curve a little, you'll know what effect that has on the results. I think that clear relationship to the physical world is an advantage when trying to figure things out - it helps build intuition that can be useful when looking at new bullets.

Of course, if you just want to push a button and get the answer, either will work if you put the right inputs in.

On another note, there are probably dozens of ways to solve the point mass equations. That's why I'm eager to hear what this so-called flaw is. I've compared my solver with JBM and Litz's. All three produce very similar numbers and all three use *different* methods of solving the point mass equations. Mine steps over distance, Litz's over time, and JBM uses a variable step algorithm (if memory serves). As you said, point mass is just three simple F=ma equations. Hard to see what's wrong with that (outside of the obvious missing three DOF). And since three people independently came up with solutions that match, that's quite a high hurdle to say point mass is flawed in some novel way...

Sorry, but I don't see where is the coupling in Pejsa? Sometime ago I read Litz saying something similar until he correcthed himself on this, because that's simply not true. It's the same way with PM and a BC or Cd curve. In contrast, PM is tightly coupled to the G-function whereas Pejsa is not. As Lowlight showed before you can feed it any G-function with no ill effect. There is a norwegian physicist who also demonstrated something similar. IMHO, the point we are missign here is which method provides us (the shooters) with the very best solution. If you have to resort to "banded data" then you are in trouble, because the method itself is flexible, (as you pointed out) but at the same time it is so dependent on the Mach/Cd relationship that in the end it's a mess up. Solving the motion equations is not an issue, indeed is just a decision on how to integrate the numerical solution and of course no flaw in that.

 

[damoncali]

I think we may be using different definitions of "decoupled", or at least different contexts.

I've certainly been wrong before, and I'm admittedly not super familiar with Pejsa, but I thought the idea was you needed a retardation coefficient in order to calculate the next step in the trajectory - in a sense, the drag is modeled into the method and distilled down to a BC/Drag Function of some sort and then modified/corrected by a retardation coefficient, and and an optional slope constant. You can't calculate a trajectory without those things. Is that not correct?

With point mass, you need none of those - just a table of drag coefficients produced by whatever means are at hand. That's what I mean by decoupled. If you read Bob McCoy's book, I think you'll find the chapter on point mass does not even mention BC's or drag functions. In fact, I'm not sure he mentions BC's anywhere in the book.

 

[Dogtown]

I agree that much of this stuff should not be exposed to the user. There is never a case where a user should be choosing a drag function in an ideal world - that's the approach I took with my meager free calculator. User picks a bullet, computer picks a drag function. I don't auto-band yet, but if I had that part written, I'd do that too. No need to drown the user in detail they may or may not understand, and frankly, don't need to. That's what computers are for.

My post Army years have been spent working with CFD simulation software and it's a constant struggle to find the right balance within an abstraction layer. Expose too much to the user and you're more likely to confuse and overwhelm them or allow them to create a parameter situation that is sub-optimal; expose too little and you constrain them too much and prevent them from getting the most out of the solver. The most successful methodology I've found is to have a solid core solver that's packaged in modes that contain fine tuned parameters that best support the end goal of that mode. On my current project I'm dealing a lot with waterfalls and river flows, both of which take similar inputs however the core solver parameters are optimized for each differently, and the details of that optimization is hidden from the average user. We expose the basic inputs and common parameters with "reasonable bounds" that we've determine converge well in 90% of situations that mode is designed for. Exposing too much leads to situations where people don't understand what a CFL Condition is and start adjusting it to the detriment of their efforts. Yet there are always situations where that kind of default setup isn't going to work or isn't well optimized, so we have an advanced mode of sorts that lets power users tweak the underlying high level parameters. So it's basically two levels of abstraction: one for the average user that prevents them from swerving too wildly off course and another for power users that opens those bounds quite a bit and allows them to highly optimize the solver for that situation.

With a ballistic computer, a similar level of abstraction is desirable I think. Simple works for a lot of shooters, with a limited amount of inputs and much of the finer details of the solver left to a reasonable default or constrained by a reasonable range. Of course, defining "reasonable" can be extremely difficult. But the further out we shoot, the more important it becomes to adjust those fine details to get an accurate solution. At those distances "good enough" doesn't cut it so it's unrealistic to expect a simple solution to converge on a solution with the required level of accuracy; it's basically like undersampling at that point. So it's nice when you see more advanced packages allow for all kinds of tweaks to the parameters to help true a solution, but this should never be a default mode for any ballistic computer - it's got to be a second level of abstraction.

Anyway, my $0.02

 

[LastShot300]

I think we may be using different definitions of "decoupled", or at least different contexts.

I've certainly been wrong before, and I'm admittedly not super familiar with Pejsa, but I thought the idea was you needed a retardation coefficient in order to calculate the next step in the trajectory - in a sense, the drag is modeled into the method and distilled down to a BC/Drag Function of some sort and then modified/corrected by a retardation coefficient, and and an optional slope constant. You can't calculate a trajectory without those things. Is that not correct?

With point mass, you need none of those - just a table of drag coefficients produced by whatever means are at hand. That's what I mean by decoupled. If you read Bob McCoy's book, I think you'll find the chapter on point mass does not even mention BC's or drag functions. In fact, I'm not sure he mentions BC's anywhere in the book.

I said coupling from a mathematics point of view, call me a classical guy! To avoid hijacking the thread I propose to stop here this PM/Pejsa discussion or I'm afraid some guys will miss the OP...Regarding McCoy (last time I browsed the book was about 8 years ago so I need to grab it again), well, you are right, but PM derives from the very concept of a Drag Force thus requiring a Cd, I mean when you start to look at a particle in motion with full dynamics. In Pejsa that's not the same approach. Your description of how Pejsa proceeds is not entirely true I'm afraid to say, since the general idea is not related to a BC or Cd pairs. The retard coeff is important, yes, but it's not the heart of the concept. I think that if you check the mathematical treatment you'll follow it with great confidence.

 

[damoncali]

Yes - apologies to all for getting way into the weeds (again). I'm on the lookout for Pejsa's book at a reasonable price - I've only ever read pieces about the method here and there, never the original work cover to cover...

 

[Kilmore]

For your consideration: http://stevereichert.com/wp-content/uploads/LRS-Advanced-Shooting-Applications-Course.pdf For information purposes only. Not soliciting attendance at this course of instruction.

 

[Kilmore]

It's been done already.

Remember I am not the one looking to "sell" them anything... you can't say the same.

I am sure if they were shown more than one solution side by side, what we ARE saying would become abundantly clear to them.

Want to set up a head to head, I have access to 2685m here, 1 hour from DIA, there is a 100 pieces of steel on the range. No secrets spilled just a simple comparison of features. Feature Set by Feature Set of what something like FFS or CB1 can do alongside side AIM-E, really simple. You can run AIME and nobody ever had to see anything beyond a, can or cannot doing something.

The comparison was done last month by JSOC using the technology currently in use by the US Military. "Run what you brung".

 

[LastShot300]

For your consideration: http://stevereichert.com/wp-content/uploads/LRS-Advanced-Shooting-Applications-Course.pdf For information purposes only. Not soliciting attendance at this course of instruction.

I don't get why a course on exterior ballistics by Lyman is so "secret"...come on! or is the "expert systems" tech (years ago abandoned as a paradigm) that is so special?

The problem I see with your answer to Lowlight is that you are not taking any chance to do a side-by-side comparison, if AIM-E is so good, why not? You have nothing lo lose.

 

[Kilmore]

Too little, too late...

I do not make those kinds of decisions. I am retained for business development and security, and only showed the technology to Mil/Gov't for consideration. I did get the system into the hands of JSOC/SOCOM using their protocols, for their own testing criteria, which was the plan all along. There was never any intention of marketing AIM-E to the public or completing with existing ballistic technologies. Further, the training calendar is full. Lastly, we have a potential buyer and any further testing by outside entities is no longer possible. In retrospect, Lowlight could have taken a closer look at AIM-E when he came across it at the trade show. And given his credentials, I am certain he would have had the opportunity to field test the technology at that juncture.

 

[MilDot1960]

Geeezz you boys are hard work, after listening to you lot I think I now have the ability to build a space shuttle, so thanks for that.

So from my ballistic apps which to me seem very hot data builders how does this new system compare with accuracy to the ones we use and unless we feed in the wrong data then we are the only weak link, 1) most of these apps only round off the data you enter that burns my ass, 2) if we could enter 3 digits after the decimal point and they would apply those 3 digits then that in its self would bring us closer, 3) With this type of shooting you have time on your hand to enter the data your self although using BT would be nicer But most of use have seen T'Rex on youtube shoot the Beer can at around 1270yds and he seems to go very very deep into his ballistic tables with tempretures to .01 etc and although we all have this type of kit to measure everything, How is this newer system going to change things when the Guy on YT shoots using old ways of doing it and he has had a fair bit of success, I think the part of this is people dont like is being told we cant have it But the truth is most of you have the Skills to achieve this type of Accuracy, Maybe .05mil Turrets might help but apart from that if you have the data in your PDA or Tablet/Phone NOT forgetting those .3 digit after the decimal point just to make the APP take up any slack what else is there???


John

 

[InkedIan]

I find this stuff all kind of funny... When they come out with a Ballistic calculator that can predict wind gusts, cross wind variations, target movement, ammunition inconsistencies, and human error i'll be super duper impressed. Until then most of the popular free-$20 apps will get you damn close and your abilities as a shooter will make the difference.

 

[mdslammer]

Had good luck with Applied Ballistics on my Droid:
http://appliedballisticsllc.com/AB_app.htm

 

[MilDot1960]

I find this stuff all kind of funny... When they come out with a Ballistic calculator that can predict wind gusts, cross wind variations, target movement, ammunition inconsistencies, and human error i'll be super duper impressed. Until then most of the popular free-$20 apps will get you damn close and your abilities as a shooter will make the difference.

Thats the sort of thinking I was going towards, Its not hard to pull a shot or blink at the wrong time, As humans we are the weak link.

John

 

[Tango down]

When shooting past 1000 to a mile what do you guys think is the most accurate Ballistics program?

Data log book and lots of practice (in all conditions); it does not require batteries...but I am kind of old school by choice. These ballistic programs are the way of the future, they can be impressive, will get even better and I respect the ones with the knowledge but we should never forget the basics.
Got Ballistic AE, may be one day I should use it to see how it actually compare to the real stuff.
Good shooting to all.

 

[MilDot1960]

Data log book and lots of practice (in all conditions); it does not require batteries...but I am kind of old school by choice. These ballistic programs are the way of the future, they can be impressive, will get even better and I respect the ones with the knowledge but we should never forget the basics.
Got Ballistic AE, may be one day I should use it to see how it actually compare to the real stuff.
Good shooting to all.

Hello mate, I made a discovery yesterday doing the Math with the old wind constants, and I am still doing tests but the constants dont just give you the wind.

john

 

[Tango down]

Hello mate, I made a discovery yesterday doing the Math with the old wind constants, and I am still doing tests but the constants dont just give you the wind.

john

John

Check this out and have fun.
http://www.snipershide.com/shooting...rksmanship/137303-wind-formula-constants.html

 

[MilDot1960]

John

Check this out and have fun.
http://www.snipershide.com/shooting...rksmanship/137303-wind-formula-constants.html

Thanks Mate,

I'm just going to post on that thread so I can explain what I found.

John

 

[K2Ballistics]

I use GuPoint 2.15. It is a point mass solver without any of this G crap. It uses custom drag functions. Tested out to 1600 yards on multiple bullets. Works for me.

 

[MilDot1960]

I use GuPoint 2.15. It is a point mass solver without any of this G crap. It uses custom drag functions. Tested out to 1600 yards on multiple bullets. Works for me.

where do you find this App??

thanks, John

 

[K2Ballistics]

where do you find this App??

thanks, John

Sorry, John been traveling lately...

I wrote it myself, so I guess that wasn't very nice. I forgot my tongue-in-cheek icon.

It is not an app per se as it only runs on a pc, so I just run it on a small ruggedized laptop for feld use. I do not have plans to put it into the public domain as of yet. Maybe someday.....

 

[MilDot1960]

Sorry, John been traveling lately...

I wrote it myself, so I guess that wasn't very nice. I forgot my tongue-in-cheek icon.

It is not an app per se as it only runs on a pc, so I just run it on a small ruggedized laptop for feld use. I do not have plans to put it into the public domain as of yet. Maybe someday.....

No no no no, That could be your Retirement Fund or his and hers matching NF 5-25s,

Seriously though thats pretty cool when you can do that, the apps I have seem to have glitches in and Im starting to loose the faith although they work well some things on them dont,,

Thanks again, john

 

[K2Ballistics]

No no no no, That could be your Retirement Fund or his and hers matching NF 5-25s,

Seriously though thats pretty cool when you can do that, the apps I have seem to have glitches in and Im starting to loose the faith although they work well some things on them dont,,

Thanks again, john

Believe me, I have thought about it. I'm just not sure I want the headache. If you peruse the various gun forums, it is really tragic what some of the developers, etc. have to deal with.

 

[MilDot1960]

Believe me, I have thought about it. I'm just not sure I want the headache. If you peruse the various gun forums, it is really tragic what some of the developers, etc. have to deal with.

Yes I am sure it is, But contact with the people/users and working together is the key, I am still waiting for answers on one topic here, But It is that lack of contact that is giving me the Hump, I am sure that is all it takes to keep folks happy, But I wish you luck in what ever you decide, Tomorrows another day,

Blessins John

 

[mouse07410]

I use GuPoint 2.15. It is a point mass solver without any of this G crap. It uses custom drag functions. Tested out to 1600 yards on multiple bullets. Works for me.

1. In your opinion, why would it matter all that much whether you create a custom drag function from scratch for a specific bullet, or apply modifiers to one of the standard drag functions to adjust it to that specific bullet? It appears that for a custom drag function you need a lot more data...?

2. How/where from do you get all the data on those bullets that you're creating custom drag functions for, and what parameters do you include/need? And out of curiosity, how many bullets did you put in so far?

3. How do you compare the trajectory GuPoint predicts with what other well-known calculators, such as JBM, or Litz's AB (or Shooter - same ballistic engine as AB)? How close to/far from each other were they? And how close did GuPoint get compared to the actual dope?

 

[K2Ballistics]

Yes I am sure it is, But contact with the people/users and working together is the key, I am still waiting for answers on one topic here, But It is that lack of contact that is giving me the Hump, I am sure that is all it takes to keep folks happy, But I wish you luck in what ever you decide, Tomorrows another day,

Blessins John

He he.....I really wasn't referring to this thread. Please don't take it that way. And, I deal with clients everyday. That's not what worries me.

For me, it would be the constant battle of overcoming a lot of misinformation and misconceptions that have been put out there and have now become gospel in the long range community. Without a horse in the race, I can walk away when the debate takes a turn for the silly.

 

[K2Ballistics]

1. In your opinion, why would it matter all that much whether you create a custom drag function from scratch for a specific bullet, or apply modifiers to one of the standard drag functions to adjust it to that specific bullet? It appears that for a custom drag function you need a lot more data...?

You can certainly modify standard drag functions and get pretty close to where you want to be. In a sense this is what Sierra has done with banded BC's. It depends on the specific bullet, really. A lot of my testing indicates that most bullets used by long range shooters fall into a g5 or g7 style profile. (G5 is similar to G1 except when you go subsonic.) BUT almost all would require some modifcation in the upper mach numbers and trans/sub sonic region to be truly representative drag functions. So, now you do not have a constant mulitpler and thus have a custom function anyway.

G functions are a great starting point, escpecially if you can't create your own drag functions. But, they are generic, and as such have their limitations. How much, is dependent on your specific bullet/application. Also, without some type of testing (real world dope or drag function) how do you know which G function to use? I have had some very pointy VLD bullets turn out to be more G5- like in their profile than G7.

To your point, none of this matters at 600 yards. It does start to matter a 1000 yards and beyond.

2. How/where from do you get all the data on those bullets that you're creating custom drag functions for, and what parameters do you include/need? And out of curiosity, how many bullets did you put in so far?

I have an acoustic chronograph (multiple) setup downrange as well as a triple IR chronograph setup at the muzzle to perform my own bullet testing and to create my own drag functions. So, this gives me MV and time of flight at known distances..i.e.downrange velocities. A drag function is now some simple math away from being a known.

The IR chronos are modified PVM'S and CED M2's. All in a black box, with the same exact center point, all with extended sensor distances and custom supports, and elevated properly to match actual bullet path. If it is one thing I know, it is MV...but at great monetary,welding and time expense.

I have tested most Sierras in .223, .284, .308 and .338, some Hornady in .223, .284 and .338 and some Nosler and Remington in .308.

3. How do you compare the trajectory GuPoint predicts with what other well-known calculators, such as JBM, or Litz's AB (or Shooter - same ballistic engine as AB)? How close to/far from each other were they? And how close did GuPoint get compared to the actual dope?

Well written PM solutions should always match JBM, especially if you are using a Runge Kutta 4 Num Int. as I am. His is a properly written solver. With JBM as a resource, I have not bothered to compare to other solvers. I just haven't had time.

If I use the same inputs for both solvers, including drag (or in this case BC) GuPoint matches JBM exactly (that is within rounding error). Where we differ, is when I venture off into using my own drag function, and as we should. We are now using different inputs. These comments are for the super and trans sonic regions. We do differ a bit in the subsonic regions. Minorly, but different. I have not put enough time in testing-wise or math-wise to determine why the differences exist. Maybe I will someday, but from previous lives I know that the subsonic zone is a chaotic place to be and I only venture there (math or real world) when I absolutely have had too much coffee to drink.

The real test of a solver are first round hits and GuPoint is really good at this. It is the driver we are struggling with ....meaning my actual dope and solver are right on as long as I do my part. That said, I do have to go back to the drawing board often. When I am not matching dope, I have always traced it back to MV (prior to my present setup) or something went awry in my drag testing. This has happened three times, now, and admittedly it can be a real pain to go back a redo drag testing. I'm a good and dedicated experimenter, not a perfect one! Occasionally, I have issues with zero or scope height, but these always manifest themselves as constant downrange differences and are easliy identified as input error, not solver or drag function issues.

I will also admit, that I currently have a certain Sierra .284 bullet giving me some testing fits right now. The dope and solver are not converging as I would like at some mid ranges and so I am looking for a low wind day to re-test, but it is all good fun or me.

 

[mouse07410]

First, thank you for such a great and thoughtful answer!

You can certainly modify standard drag functions and get pretty close to where you want to be. In a sense this is what Sierra has done with banded BC's. It depends on the specific bullet, really. A lot of my testing indicates that most bullets used by long range shooters fall into a g5 or g7 style profile. (G5 is similar to G1 except when you go subsonic.) BUT almost all would require some modifcation in the upper mach numbers and trans/sub sonic region to be truly representative drag functions. So, now you do not have a constant mulitpler and thus have a custom function anyway.

I interpret it as "no single BC would adequately define the drag function, this is why banded BC are a-must to model the trajectory with a good degree of accuracy". Correct?

G functions are a great starting point, escpecially if you can't create your own drag functions. But, they are generic, and as such have their limitations. How much, is dependent on your specific bullet/application. Also, without some type of testing (real world dope or drag function) how do you know which G function to use? I have had some very pointy VLD bullets turn out to be more G5- like in their profile than G7.

Well, for projectiles like SMK or AMAX I'd certainly choose a G7-like profile because it's the closest one shape-wise (so of all the standard curves, G7 theoretically should need the minimal amount of tweaking, and significantly less than that of other profiles, like G1 or G5).

What surprises me here is the amount of tweaking that a G7-based profile seems to still require for accurate modeling, considering how close a bullet like SMK comes to the standard G7 projectile. Perhaps you could share your opinion on the cause of this?

I have an acoustic chronograph (multiple) setup downrange as well as a triple IR chronograph setup at the muzzle to perform my own bullet testing and to create my own drag functions. So, this gives me MV and time of flight at known distances..i.e.downrange velocities. A drag function is now some simple math away from being a known.

Wow!! That does answer my question alright... I'm impressed, and not surprised any more that you could get enough data for your custom curves.

Well written PM solutions should always match JBM, especially if you are using a Runge Kutta 4 Num Int. as I am. His is a properly written solver. With JBM as a resource, I have not bothered to compare to other solvers. I just haven't had time.

Understand.

If I use the same inputs for both solvers, including drag (or in this case BC) GuPoint matches JBM exactly (that is within rounding error). Where we differ, is when I venture off into using my own drag function, and as we should. We are now using different inputs. These comments are for the super and trans sonic regions. We do differ a bit in the subsonic regions. Minorly, but different.

Do GuPoint and JBM produce the same output for super- and transonic when you use your custom drag functions (if not - what wan the ballpark difference)? And what was the ballpark difference between the two in subsonic?

The real test of a solver are first round hits and GuPoint is really good at this. It is the driver we are struggling with ....

I certainly can relate to that.

Out of curiosity, were you able to get first round hits from JBM for supersonic and transonic?

When I am not matching dope, I have always traced it back to MV (prior to my present setup) or something went awry in my drag testing.

I think this observation is nothing short of profound, for me at least. I will make a note to make sure I expect MV to vary, and to keep track of SD/ES...

I will also admit, that I currently have a certain Sierra .284 bullet giving me some testing fits right now. The dope and solver are not converging as I would like at some mid ranges and so I am looking for a low wind day to re-test, but it is all good fun or me.

I wish you to solve this quickly - unless you'd rather prolong the fun?

And I'd love to see your curves for SMK (175gr, 250gr, 300gr) and AMAX (168gr, 178gr, 285gr).

 

[damoncali]

Well written PM solutions should always match JBM, especially if you are using a Runge Kutta 4 Num Int. as I am. His is a properly written solver. With JBM as a resource, I have not bothered to compare to other solvers. I just haven't had time.

A while back, Bryan Litz did a comparison of his solver, JBM, and the one I wrote (link in my sig), but the post might have gotten nuked when the forum software was upgraded. As expected, they were all pretty darn close because we all use the point mass method. However, all three of us used a slightly different method of integration - I stepped through distance, Litz stepped through time, and JBM used a variable step algorithm. Nonetheless, the differences were pretty small.

I have also written (though it's not available publicly because it's a garish hack at the moment) a point mass solver that uses arbitrary drag functions. I think it is the simplest, most direct method possible. You seem to have gone a step beyond and actually tested some bullets, so here's a question: Given that we often see deviation from the standard drag functions at high velocity and near mach 1, is there a new standard drag function out there that will be a good enough approximation to real bullets so that we don't need custom drag functions for each bullet? G7 already comes very close - is a custom drag function for each bullet overkill?

 

[K2Ballistics]

First, thank you for such a great and thoughtful answer!

Thanks to you as well

I interpret it as "no single BC would adequately define the drag function, this is why banded BC are a-must to model the trajectory with a good degree of accuracy". Correct?

I would agree with this most of the time, especially ELR. I have found some bullets that were modeled just fine with a single BC, meaning that the standard G function with a single multiplier was just fine. The opposite is true often enough that I put the work in to find custom functions.

Well, for projectiles like SMK or AMAX I'd certainly choose a G7-like profile because it's the closest one shape-wise (so of all the standard curves, G7 theoretically should need the minimal amount of tweaking, and significantly less than that of other profiles, like G1 or G5).

What surprises me here is the amount of tweaking that a G7-based profile seems to still require for accurate modeling, considering how close a bullet like SMK comes to the standard G7 projectile. Perhaps you could share your opinion on the cause of this?

I am suprised too. I find a lot of SGK's have a G5 like profile, but not always. I have had a mixed bag with SMK's. A lot are G7 like, but others have turned put to be more G5 like....hope that make sense.

Do GuPoint and JBM produce the same output for super- and transonic when you use your custom drag functions (if not - what wan the ballpark difference)? And what was the ballpark difference between the two in subsonic?

Well I can't run JBM with my drag functions so it is hard to get an apples to apples on this one. When I do comparison testing, I do so by putting a standard drag function into my engine with a modifier such that GuPoint and JBM are using simalar drag modeling. My goal here is to proof my solver by using the same inputs in both models. This accomplished, I use real world dope to proof my drag functions.

Off the cuff, I can absolutely say that I agree very closely with JBM in the supersonic annd starting phaes of transonic when using the same inputs. We start to differ in late trans and subsonic when still using same inputs. We can start do differ quite a bit if I use my drag models compared to keeping a standard model in JBM. This does not always occur and is bullet dependent, of course.

Out of curiosity, were you able to get first round hits from JBM for supersonic and transonic?

Dunno, as per above, I only do rigid real world dope testing with my solver. I really kinda have my hands full with that.

I wish you to solve this quickly - unless you'd rather prolong the fun?

I'm working on it! And yes, having some fun with it as well. Fairly certain this is going to be another DF tweak.

And I'd love to see your curves for SMK (175gr, 250gr, 300gr) and AMAX (168gr, 178gr, 285gr).

Still considering how to share results/data. I am not as hesitant about this as I am building software for the public. I just want to make sure whatever I release is absolutely correct...at least within the capablities of my equipment and processes. I also would make you sign a waiver never to attend the same competition as me! LOL!