Blaine and JBM:
I use the Sierra Infinity program. It is simply the one I have, and it agrees quite well with Sierra bullets.
When I have to "fudge" to fit my data I play only with the BCs until I get the predicted come ups to agree with the field tested ones. I try to record accurately the environmental conditions when I shoot and of course take it into consideration.
Normally the resulting G1 BCs do not have a lot of variation and the predicted trajectory is free of any discontinuities, just like the field data.
Is there any other easy way to "fudge" the program to agree with the field data?
TIA

I think changing the BC and atmospheric conditions is all you have. Of course, you have to make sure you have a good velocity measurement, but that's pretty easy.

As for particulars about Sierra's program, I've not seen it so I can't really comment.

<BLOCKQUOTE><font size="1" face="Verdana, Helvetica, sans-serif">quote:</font><HR> I guess I just don't see the point in adding another constant to do the same thing as the BC.
<HR></BLOCKQUOTE>

Let's say that a shooter decides to use Berger bullets. The company publishes a single G1 BC for its bullets. How will the shooter devine the changes to BC necessary to obtain correct data? And what speed regimes will the shooter use? Well, he would have to spend quite a bit of range time to gather the data. Then, if he changed bullet manufacturer (other than Sierra), he'd have to go through the same arduous process. It seems to me that this approach defeats the entire rationale of having a "predictive" program.

Having a simple way to shape the drag curve is very practical. The shooter goes to the range and in one session determines the actual bullet drop at a sufficiently long distance where the bullet is close to transonic. Back at the computer, the shooter uses the single published BC value, the measured MV, ambient atmospheric variables and then matches the actual drop by the appropriate deceleration constant which mathematically shapes the drag curve to match what happens in reality.

In effect, this deceleration constant replicates what Sierra does by using multiple BCs to shape the drag curve, but the advantage is that this single deceleration constant is simple to derive from extremely limited range data.

[JBM - I think we just "highjacked this thread." Maybe we should begin a new thread to discuss the relative merits of the various methods to predict trajectory.]

Does a copper bullet such as a lost river J40 vs a Berger or JLK or SMK lead core play a role in all this? Will the copper fly better or the lead core? JBM could you comment on this as well. Thanks. [img]images/icons/smile.gif[/img]

<BLOCKQUOTE><font size="1" face="Verdana, Helvetica, sans-serif">quote:</font><HR>Let's say that a shooter decides to use Berger bullets. The company publishes a single G1 BC for its bullets. How will the shooter devine the changes to BC necessary to obtain correct data? And what speed regimes will the shooter use? Well, he would have to spend quite a bit of range time to gather the data. Then, if he changed bullet manufacturer (other than Sierra), he'd have to go through the same arduous process. It seems to me that this approach defeats the entire rationale of having a "predictive" program.<HR></BLOCKQUOTE>

True. the problem is that I don't think you can find ONE curve to use with all these bullets (the G7 might be close enough) so you're going to have to vary the curve anyway so for every bullet your going to have at least two constants: one (or more) to say how to vary the curve and one BC. What fun.

Trader, once you have identical BCs then it does not matter what your bullet is made of.

Blaine, that is an interesting system (...and less work than what I do, matching the trajectory at a few points) but this is not as accurate as the other system, because you have only two points in the trajectory that are a true match, say a 100 yds zero and a 1000 yds zero. Maybe I am confused, but changing the decceleration constant seems just like changing your published BC to match your 1000 yds zero.