• If you are being asked to change your password, and unsure how to do it, follow these instructions. Click here

BEWARE, Problems with Exbal and G7 BC's

Bryan, as to LoadBase it does us Mach from what I can gather, from what I've been able to understand LB is not Pejsa only but a proprietary solution, which makes it hard to nail down which is OK.

I guess I have a better idea what to look for when inputting a BC as to which standard I should use, it does seem like a little amount but when shooting at or though transonic and beyond the little things show up, not that I can shoot at that level a lot but I shoot more and more in that range every time out!

I would love to see some guys like you Bryan, Gus, and Gerald in some kinda format like a symposium of type at a college!
Thanks again.
 
Bryan,
It seems to me that the most accurate method of modeling the trajectories of VLD type bullets would be to use velocity banded G7 BC's similiar to the way Sierra provides their G1 BC's. Do you have any comments on this? I am not sure how many of the available software packages even allow it or if it is even worth the effort. Perhaps any accuracy gains are insignificant?

Eric
 
Eric,

That's a good observation. Although the G7 BC varies much less than a G1, it still varies some, more or less depending on the shape of the bullet.

You could splice a multiple G7 together, but since it has so little variance to begin with, the difference between using the multiple G7 BC and an average G7 would be about 1" difference in trajectory at 1000 yards.

Using multiple G1's you can improve significantly compared to a single G1, but the same is not true for G7. Meaning, you can get an improvement, but it's so small as to be insignificant.

-Bryan
 
Hi there,

Just to clarify some points exposed on this very nice thread.

1) LB3 does not use the Pejsa method.

2) It's a propietary algorithm, with many extensions to Dr. Pejsa's method.

3) During the development phase, Dr. Pejsa was very kind to discuss the new algorithm math and that's why he is credited as having provided the original concept.

4) The current algorithm employed in LB3 took over two years to develop, and the only part that has some resemblances is in how to model the Drag curve.

5) Both methods (LB3 and Pejsa) are all abouth MACH when modeling the drag curve. I think this is one of the less understood aspects of how the algorithm actually works.

Please check the following article that shows some differences in the predictions made by some methods.

Ballistics and Predictions

While the article does not discuss the inner aspects of the algorithms and the math behind them (clearly out of scope), the general idea is exposed when comparing their outcome.

The Point Mass (3DOF) method is used by the following free and commercially available ballistics programs: JBM (web), Berger, Litz, RSI, Ballistics FTE (iPhone), iSnipe (iPhone), BulletFlight (iPhone), Shooter (Android), FieldCraft (ex ABC by CheyTac), Balistika, Quick Target Unlimited, JBallistics, BigGameInfo (web) plus many others. The algorithm is well known and free computer code is available to download from the Internet.

The Pejsa method is used by the following free and commercially available ballistics programs: FFS (Field Firing Solutions), BallistiX, Dr. Pejsa's own plus some free spreadsheets like BfX. One of the typical issues that are encountered with most of the usual solutions is that they are limited to supersonic velocity values, something very critical to take into consideration when evaluating these programs. The algorithm can be studied in the books published by the author.

Some graphs of actual Doppler radar data, compared to LoadBase 3.0 (Desktop and Mobile) predictions.


.338 Lapua Magnum (radar data provided by Lapua)


LoadBase3_Doppler_338LM_DROP_DELTA_ALL.jpg


LoadBase3_Doppler_338LM_DROP_DELTA_DETAIL.jpg



.50 BMG (radar data provided by a NATO facility, taken about a month ago)


LoadBase3_Doppler_50BMG_DROP_DELTA.jpg


LoadBase3_Doppler_50BMG_VELOCITY_DELTA.jpg
 
I have found a very strange thing while using nightforce exbal. this only shows up if you use the bullet database for G7 bc's.
If you run a table using standard atmospheric conditions, you get a drop that is close to actual but if you then rerun the table and change only the temperature, the long range drops go the wrong way.

what I mean is that if the temperature drops, you would expect more bullet drop at long range but with this program if you adjust the temperature down, it gives you less bullet drop at long range. Likewise if you set the temp higher, you would expect less drop but the program gives you more drop. I think this may be why your drop values are so far off.
I have run the same charts using the G1 bc.s and it seems to work correctly.

please check and give me your findings.
 
I have found a very strange thing while using nightforce exbal. this only shows up if you use the bullet database for G7 bc's.
If you run a table using standard atmospheric conditions, you get a drop that is close to actual but if you then rerun the table and change only the temperature, the long range drops go the wrong way.

what I mean is that if the temperature drops, you would expect more bullet drop at long range but with this program if you adjust the temperature down, it gives you less bullet drop at long range. Likewise if you set the temp higher, you would expect less drop but the program gives you more drop. I think this may be why your drop values are so far off.
I have run the same charts using the G1 bc.s and it seems to work correctly.

please check and give me your findings.

I've seen the exact same thing when playing with the G7 numbers. This program seems to have a few different glitchs with the G7 BC's, this one and the one the op mentioned are but a couple of them. I am not remembering at the moment what the other one or two were, because I simply quit using the G7 numbers after seeing what it did with relation to temp. Made me wonder, if it's giving errors in the wrong direction when calculating the temp, what else is it doing wrong.?? Seems the other bugs were related to some of the options tools. Trajectory Validation, or Match Sight IN Point or something along those lines, but honestly don't recall for sure. G1 works plenty close enough to 1000 yds IMO without dealing with the bugs of a software program.
 
I got hold of Nightforce and this is the reply I got :

"what you are experiencing stems from how ExBal is designed to function as a solver. The solver/algorithm is set up to use the ASM (Army Metro System) versus the ICAO (International Civil Aviation Organization) system for calculating the affects of temperature? The G7 BC's are compatible with the ICAO system, but not the ASM? So, when using the G7 BC's in ExBal, it will only produce accurate results when using a density altitude, which functions as a "neutral" measurement that is not ICAO or ASM specific.

In summary, the G7 BC's can be used with a density altitude reading, and the G1 BC's are universal, as density altitude and standard atmospherics can be used to get accurate solutions"


so I guess if we use the denisty altitiude setting it should be OK.

cheers

Greg
 
Warning! This thread is more than 13 years ago old.
It's likely that no further discussion is required, in which case we recommend starting a new thread. If however you feel your response is required you can still do so.
Top