LoadBase 3.0 Mobile w/G7 BC Test Results

[jrs]

The thing that's been keeping me from going commercial with this has been the $800/each cost (to me) of the Pan/Zoom/Tilt Mega-Pixel camera that is the MINIMUM necessary for seeing itty-bitty holes in great big black targets under a wide range of lighting conditions.

Strangely enough the network link part is what I call dirt cheap by comparison; about $100 including my time to test and confgure two 1000mw transmitters to setup a Local Area Network (LAN) that spans the distance between firing point and target. The target end can be connected to a cheap network switch that then can connect the LAN to all sorts of stuff. One of those things would be a notebook (or desktop if you have a small generator or AC power available) that has a USB 2.0 port, which connects to a webcam (about $30 should get one that can resolve and LCD display on a chronograph).

My plan was to build complete systems including all of the hardware and configure/test it prior to delivery so it becomes a plug and play system. Was trying to keep cost under $1000 then under $1,500 ... I'm almost there, but the camera/resolution problem is the killer.

Using a 12V 7AH battery the radio links will run for DAYS without recharge - solar panels could make the LAN work round the clock for years. Problem is the additional equipment will need more power than that - but a 1KW generator could power a whole lot of equipment for a very long day of shooting.

The idea of having a cronograph at the target end got me to thinking that having the high res camera positioned at the exact point where your scope will be would allow you to be downrange adjusting while watching what it looks like from the firing point ... have to either have two cameras/computers or make one trip back and forth to switch the camera to the target end. Might be worth it in time saving? The camera has a 22:1 zoom ratio so the telephoto view would be (subjectively) about like a 6x or 8x scope in terms of magnification.

We can talk specifics if you want to email me.

[email protected]

 

[BryanLitz]

The purpose of integrating a downrange chronograph is to be able to measure BC (obviously). There's an easier way to do this, with acoustic sensors.

Using a chrono and mic at the muzzle in conjunction with a mic downrange gives you enough information (MV and tof) to calculate BC. The advantage of this set-up is that you don't have to shoot thru a small window on the chrono because the range of the acoustic sensor (microphone) is tens of feet and is omni-directional. If you could add the sound that the downrange camera hears to the sound recorded by a mic placed with the muzzle chronograph, you can gather:
MV (useful in-and-of itself for testing purposes)
tof (used in conjunction with MV to get BC)
video (to see the group forming)

This is just about everything there is to be interested in for an external ballistics test.

The system I use to measure BC's uses a chrono at the muzzle and several mics along the range. This allows the calculation of a velocity dependent BC, and lets you identify which standard is a better match for a particular bullet (usually G7). The set-up is very much simplified if you only have one downrange mic to deal with. Sounds like you already have all the hardware required with the exception of a mic at the muzzle chronograph, it's just a matter of integration.

BTW (phorwath) glad to hear you got such good results with the G7 BC and the 7mm 168 VLD in your test with LoadBase. Question: did you have to monkey with the ****** coefficient at all, or did you leave it at the default value?

-Bryan

 

[groper]

sorry i cant help myself, but i gotta say this.... Phorwarth, just think of all the time, effort and money (not to mention blood, sweat and tears) you could have saved by just reading the G7 BC values off the berger website...

 

[Pdvdh]

The set-up is very much simplified if you only have one downrange mic to deal with. Sounds like you already have all the hardware required with the exception of a mic at the muzzle chronograph, it's just a matter of integration.

BTW (phorwath) glad to hear you got such good results with the G7 BC and the 7mm 168 VLD in your test with LoadBase. Question: did you have to monkey with the ****** coefficient at all, or did you leave it at the default value?

-Bryan

Very interesting to learn some of what I don't know. How much cost in hardware to integrate a mic(s) with the equipment I already have? All I have now is two chrono's run in tandem with skyscreens mounted on a single rail system. Plus the AR 500 protective plate to protect my distant skyscreens.

My bad for not providing the LoadBase 3.0 drag coefficient (what you refer to as ****** coefficient is termed as Drag Coefficient with LoadBase 3.0 ballistic software). No tweaking or modification of the drag coefficient. The predicted down range velocity of 1571 fps was based on the default drag coefficient value of 0.5

 

[Pdvdh]

sorry i cant help myself, but i gotta say this.... Phorwath, just think of all the time, effort and money (not to mention blood, sweat and tears) you could have saved by just reading the G7 BC values off the berger website...

Ha! Always a spoiler in any crowd!

To be honest, I have to prove my loads and equipment at long range anyhow. Incorporating the down range chrono data collection after I've selected a test load for proofing at long range is just one added task that provides confidence and peace of mind. Now that I own the equipment, I enjoy adding this additional level of data collection and validation into my LRH preparation process. Once I chronograph the down range velocity, if I don't get a good match (I did in this instance) to ballistic software predicted velocity, then I tweak the drag or ****** coefficient in my ballistic software until my predicted down range velocity matches my chronographed down range velocity. In this manner I know I'm inputting BC related information that's dead nutz 'on the mark' for that specific bullet and load in my specific rifle. Then when I'm hunting in other atmospheric conditions at widely differing ranges, elevations (station pressure), and temperatures, I have every reason to believe that the LoadBase 3.0 predicted dope will also be dead nutz on the money.

Most everyone develops drop charts, which are only good under the set of atmospheric conditions at which the drop chart shooting was performed. My method enables the creation of accurate real time drop charts for any set of atmospheric conditions, altitudes, latitudes, angle of shot, and direction of aim. Chances are good you already knew most all of this. But that's where I'm coming from in case you or others are wondering why all the fuss. If all else fails, sometimes I just tell folks "I'm an engineer" and they seem to understand - or else give up.

However... if it wasn't interesting, enjoyable, useful to my needs, and rewarding I wouldn't force it on myself.

 

[jrs]

Brian and all,

The microphone downrange is an excellent idea, but getting the real time of arrival of the bullet downrange via a TCP/IP based LAN is somewhat problematical as the protocol is likely to add a variable delay. (Now I've got to go figure out if the delay variability is significant!)

I'm thinking I would need to sync up a pair of clocks using NTP and then read microseconds between events from the clocks on each end, but I may be over-engineering for the scale of events. Would require dedicated equipment that I can design and build but don't have 'off the shelf' at this point ... unless the clock in the downrange router will do it ... hummm

Brian, how do you account for network delays? Do you get resolution greater than millisecond?

Shouldn't we start a new thread for this discussion? Call it something like range instrumentation ?

John Snell
[email protected]

 

[Eaglet]

BTW (phorwath) glad to hear you got such good results with the G7 BC and the 7mm 168 VLD in your test with LoadBase. Question: did you have to monkey with the ****** coefficient at all, or did you leave it at the default value?
-Bryan

Eglet answering. Phorwath please check if I'm right on the DC.

Yes, those predictions are based on the default value of the DC, which is 0.500.

The DC is a very good indicator of how well the BC was determined, among other aspects of the Drag Curve itself. (Your work is awesome!)

BTW, Berger's program overpredicts by 30 feet/sec.

 

[Pdvdh]

Eaglet answering. Phorwath please check if I'm right on the DC.

Yes, those predictions are based on the default value of the DC, which is 0.500.

The DC is a very good indicator of how well the BC was determined, among other aspects of the Drag Curve itself. (Your work is awesome!)

BTW, Berger's program overpredicts by 30 feet/sec.

10-4 Eaglet. My LoadBase 3.0 predicted 981 yard velocity of 1571fps was indeed based on the LoadBase 3.0 default DC of 0.500

Which is why I stated Dang! when I reported on the correlation between my chrono'd velocity versus predicted velocity.

 

[Eaglet]

Sorry, phorwath, my bad. I did not realize you had already answered

that for Bryan.

 

[BryanLitz]

Brian, how do you account for network delays? Do you get resolution greater than millisecond?

jrs,

It's good to think of these things. I tested my system for delays with the following approach:
1) On my desk I placed the transmitter and receiver, as well as the 'muzzle' mic and ran both signals into an audio mixer.
2) I then generated a tone from my PC speakers of a known frequency.
3) By viewing the wave-form of the added signal (from both mics) I was able to determine the delay that's caused by the transmitter/receiver pair.

The delay was way less than 1 millisecond.

The only thing the above test doesn't account for is the time delay it takes for the signal to travel the distance from transmitter to receiver in the field. A few calculations with the speed of light will convince you this is negligible too. I know nothing about TCP/IP LAN protocols, so you would probably have to perform a similar test to see what the delays are using your equipment. My transmitters and receivers are simply modified walkie-talkies.

Another delay you'll have to account for (not in the electronics, but in the math) is the time it takes for the sound to travel from the bullet to the mic as it passes. This is a simple calculation with the speed of sound, but you have to make it part of the process. A bullet that passes 5 feet from a mic will add 4.5 ms to the instrumental tof which you have to subtract out. Same is true on the muzzle end, but if you afix the mic to the chrono, the distance is only a few inches.

-Bryan

 

[Pdvdh]

Brian and all,

The microphone downrange is an excellent idea, but getting the real time of arrival of the bullet downrange via a TCP/IP based LAN is somewhat problematical as the protocol is likely to add a variable delay. (Now I've got to go figure out if the delay variability is significant!)

I'm thinking I would need to sync up a pair of clocks using NTP and then read microseconds between events from the clocks on each end, but I may be over-engineering for the scale of events. Would require dedicated equipment that I can design and build but don't have 'off the shelf' at this point ... unless the clock in the downrange router will do it ... hummm

Brian, how do you account for network delays? Do you get resolution greater than millisecond?

Shouldn't we start a new thread for this discussion? Call it something like range instrumentation ?

John Snell
[email protected]

Don't worry about hi-jacking this thread. Part of the theme to this thread is recording extreme distance down-range velocity, and it sounds like that's a feat that's right up your alley. If you're able to provide the techno wizardry that would allow me to obtain 1000 yd time-of-flights so that I can determine BCs and 1000 yd velocities, at a cost comparable to purchasing an additional chronograph (or a tad more), then I would be very interested. I don't really need to see the impacts on target remotely with the video gear.

I'm an engineer but I'm not schooled in electronics and would rather pay someone else for the research, design, development & construction/instruction. Then simply purchase something that will make the collection of 1000 yd time-of-flight & BC/velocity less of the ultra-marksmanship task of having to place my bullets through a ~4" X 9" chronograph skyscreen window at 1000 yds. PM me or post here if you think you're on to something. Bryan makes it sound relatively straightforward, but that's the way technical stuff is - after you've spent the time and research to thoroughly understand it. Prior to doing the research and development, it seems pretty mystical!

PS: If you do start another thread, please let me know so I can follow your work effort!

 

[jrs]

Well, since you feel that way I'll keep on natering about with this for a bit.

Got into a discussion on the subject with a co-worker who has vast experience in time functions of networks and operating systems (was involved in nuclear reactors and petro-cracking tower ops). In his opinion only a certain extinct propretary real-time operating system is deterministic enough to do the job.

I think that there must be a cost effective way to get there from here using a digital network.

I was just reading some of the Sierra discussion about their instrumentation and see that they are much more accurate than that, and end up at about +/- 2% on the BC. Fron what I gather they have a very long wire between crono screens, and a custom cronograph ... but what the don't have is 1,000 yards.

I suppose a plain old analog radio could substitue for the long wire, but I'm more interested in finding a way to use a digital network.

I'm going to keep working on it and I'll put a post here when I get an idea I think might work.

If anyone has an idea or time to look on-line for a device that can get time of flight accurately and post back here I'll see what I can do to integrate it with what I already have.

jrs

 

[Pdvdh]

Re: Another LoadBase 3.0 w/G7 BC Test _ Range = 985 Yds

Here's the lowdown on my latest field test with the Hornady 162gr A-MAX. Comparison of Patagonia Ballistics' LoadBase 3.0 predicted 985 yard velocity (using Bryan Litz's G7 BC = 0.307) versus measured 985 yard velocity.

Cartridge is .280 RCBS Improved with 28" 1:9" twist Brux barrel. I captured two (2) 985 yd velocities over my chronographs; 1) 1580.9 fps, and 2) 1582 fps. This yields a two-shot chronographed 985 yd average velocity = 1581.4 fps.

Environmental Conditions = 29.43 in/Hg, 47F, 48%RH
60.4 degrees North Latitude
50 degree direction-of-fire Azimuth
Muzzle Velocity = 2948 fps
Stability Factor = 1.64 with the 162 A-Max in my 1:9 twist Brux.
Default Drag Coefficient = 0.500

LoadBase 3.0 (with coriolis and spin drift features activated) predicted 985 yd velocity = 1590.2 fps versus the chronographed 985 yd velocity = 1581.4 fps. A difference of 8.8 fps @ 985 yds, for another very good correlation between predicted velocity (using the G7 BC and the default LoadBase 3.0 Drag Coefficient of 0.500) versus measured velocity.

I'll tweak the G7 BC in my LoadBase 3.0 saved "Track" from 0.307 to 0.305 in order to obtain a better predicted match to my measured 985 yd velocity. Gus would probably tell me to tweak the Drag Coefficient, but this is such a small modification to Bryan's G7 BC that I think it matters little which is tweaked.

The 1/2" AR500 protective plate prevented bullet destruction to 4 skyscreens today. The AR500 steel is tough stuff. I can't see or feel any surface deformation where the bullet impacted. Nothing more than a surface splash on the white paint.

Photo of my chronograph setup showing the 4 skyscreens that survived the "near-death" experience. I don't install the orange and white skyscreen shades at distances past 300 yds.

 

[rhouser]

Phorworth, your work is phenominal. Please continue to post your results and the comparisons. I am fascinated by the fact that the Loadbase is producing predictions that are as close as your work indicates. GREAT WORK. rc