Chronographs Best Suited for Sabot Projectiles

Status
Not open for further replies.

Matt304

Member
Joined
Sep 19, 2006
Messages
653
Location
Utica, IL
Hey guys, here's my latest issue; I'm sure many have run into this same issue when using sabots or projectiles with wadding behind them.

It goes like this:

I have a Chrony Beta Master chronograph which uses typical twin optic sensors like many. I try to put the chrono far enough away to achieve some separation time between wad/gas seal and bullet or sabot and bullet, but not so far as to have the sabot stray off and strike the unit. Anyways, what happens sometimes is that I get a really high velocity reading, for example 500fps faster than the load is capable of, or in other instances I simply get an error message. I can't be for sure about the error cause without knowing if something is actually detected by the sensors, but I have an idea of why high velocity readings might occur. Let's pretend that the bullet is reaching the first sensor plane with a gas seal following behind it (I have watched my own videos where I have shot targets at 15 yards or so and have witnessed the gas seal bouncing off the target very close to where the bullet impacted). In this theoretical scenario, maybe the bullet passes the first sensor plane and is or isn't detected (not sure how the logic programmed into the unit uses the sensor data) and then while the bullet is in between the two optical sensors the gas seal is detected by the first sensor plane, restarting the timing sequence. Next the bullet reaches the second sensor plane to be detected, the gas seal possibly isn't detected at this plane, and the time frame between detections is thus shorter than if only one object had passed between sensors. Obviously the shortened timing creates a higher velocity reading and voila, incorrect bullet velocity is reported. That's a theory I have which may create the problem, at least.

If the logic of the chronograph calculation only allowed 1 event or object passing the first sensor to begin the timing, then "threw out" a second detection immediately following at the first plane, taking the next detection at plane 2 as the prominent figure for the calculation of velocity, it seems this type of error could not occur. If they want to make their chrono suitable for fully-automatic fire or something (let's see how long it takes for the chrono to get hit!), at least have some sort of non-detection delay built in of 15ms or so--right?

The problem for me currently is, no mfg is posting the sensor logic their chrono uses for final velocity calculation in the unit specs (not like I actually expect this from them). My fastest method to getting help would be to email each mfg of a chrono and possibly getting a generic reply from someone who may not actually know (like, "Sure it will work fine with sabots!"), or asking the many possible shooters here with actual chrono experiences to note upon.

My immediate thought was, well duh, I'll just use a magneto chrono to solve the problem! Then I quickly remembered that the rifle being tested will absolutely rip any attached device off the barrel. It has the recoil of firing 12x 30-06s from a typical sporter weight rifle at the same time (this is not an exaggeration or joke--the rifle reaches >45fps recoil velocity in the time it takes the bullet to travel the barrel length).

A magneto chrono is basically out of the question, then.

I now aim my faith at the forum members for possible help choosing a better chrono or method to advance upon.

Thanks for any help, it is much appreciated.

Happy shooting!
 
That's an interesting situation you describe. I don't really have an answer to your question. I have chronographed slugs though. I didn't think about the slug and gas seal separating and causing errors. I had my chronograph set up at closer to seven yards and managed to get reasonably consistent readings. My guess is the gas seal hadn't separated yet. Have you tried moving the chrony closer?
 
I suspect despite the recoil magneto speed would work, I have used one on some very heavy recoiling rifles.

But the best answer is a Labradar. It's a consumer grade radar for measuring projectile velocity. It won't even see your sabot unless it's metallic. Does allot more than a typical light gate or magnetic chronograph does too.

https://mylabradar.com/
 
That’s what I was wondering.
An expensive solution, more so than shooting more rounds and throwing aside obvious outliers.

I don't know given the recoil levels the OP is claiming I suspect ammunition for whatever this beast of a gun he is shooting will make the investment in the Labradar pretty reasonable. I just hope he is not actually shoulder firing it.
 
I've run 12 ga. sabot slugs over my Shooting Chrony with no problems. But that was years ago and I can't recall the details other than the chrony wasn't that far from the muzzle. Too close will get errors from muzzle blast and I believe it was just far enough away to avoid an error message but not far enough that a sabot will hit the chrony while the slug continues down range. At close range the slug and sabot probably haven't separated enough yet to cause false readings as long as its not within muzzle blast distance. That's my only experience chronographing saboted projectiles.
 
I use mine for shotgun loads; same basic principle. Mine is set @5' from the muzzle and my readings are spot on. The shot is still in the cup while passing over the sensors.
 
First off what you shooting that has 12x of recoil of .30-06?
Second, could some type of netting be used to catch the sabot before it makes it to the chrono? Stretch out a piece of fabric a couple feet in front of the chrono and the bullet will shoot through it but stop the sabot...
 
  • Like
Reactions: mcb
No need to catch the sabot; set the skyscreens at 5' like I said (and the chrono instructions say) and record your fps.
 
First off what you shooting that has 12x of recoil of .30-06?

It is a cartridge known as the 12GA From Hell (or just 12GA F.H.). It is effectively a .73 caliber rifle rather than a shotgun, as it is uses a full-length heavy-wall brass case, a really big bullet on top of a lot of powder, and a fully rifled barrel. It is fired from a Savage bolt-action, their biggest action--the 210 version.

The best idea I can come up with so far is to move the chronograph much further away than usual, say 20–25 yards, then strap the gun down as I do for proof testing and take some practice shots. I will cut out a square in a piece of polycarbonate plexiglass to put in front of the chronograph to block it from being hit by any gas seals, then take some practice shots to be sure the setup is far enough away so that the gas seals at least end up striking outside of the entrance hole in the plexiglass to permit the accurate capture of velocity. This seems to be my best option at this point.

Here is a picture of the fireball seen during daylight from the round. For some reason the photo errors when I try to use the forum photo link to show it, so here is the direct link:
https://i.imgur.com/ObTuAEy_d.webp?maxwidth=640&shape=thumb&fidelity=medium
 
I suspect despite the recoil magneto speed would work, I have used one on some very heavy recoiling rifles.

But the best answer is a Labradar. It's a consumer grade radar for measuring projectile velocity. It won't even see your sabot unless it's metallic. Does allot more than a typical light gate or magnetic chronograph does too.

https://mylabradar.com/
That’s what I was wondering.
An expensive solution, more so than shooting more rounds and throwing aside obvious outliers.
Radar will pick up plastic at this short a range. However, simple software tricks will allow the unit to distinguish between the projectile and the sabot. The same software that will allow the unit to tell your bullets from other people shooting near you and within the radar's sight.
 
Radar will pick up plastic at this short a range. However, simple software tricks will allow the unit to distinguish between the projectile and the sabot. The same software that will allow the unit to tell your bullets from other people shooting near you and within the radar's sight.

I don't think any software tricks are needed at these low power levels. Only some very unusual and dense polymers (or polymers dope/filled with non-polymer fills) have any chance of reflecting a strong enough signal to be detected by this simple radar system. There is a reason polymers are sometimes used as radome material for radar systems. Most common plastics are nearly transparent to radar. The LabRadar transmits and receiver its own signal though its ABS case.

Maybe if were are talking about a real high power radar typically used in aircraft tracking and similar applications it probably could detect some plastics at moderate ranges but were are talking about a radar powered by 6xAA batteries. It has only slightly more transmission power than the Bluetooth radio in your mobile phone and a fair piece less than the WIFI radio in your laptop. None of the polymers used for small arms sabots or gas seals are going to reflect anywhere close to enough power for the little LabRadar receiver to pick up. I have tried it with several different slugs and never had an issue with getting good readings despite a variety of wadding and gas seals fly with the slug.
 
Last edited:
The earliest devices to measure projectile speed used 4 electricity isolated foil sheets. The tip of the object ran into the first sheet and because of its close proximity to the 2nd sheet, made them contact each other, starting the chronograph. Some distance later were the other two sheets, that when hit, stopped the timer. Then velocity was calculated.

Same concept, used to activate a flash when a light bulb is struck with a hammer, could capture neat images long before everyone had a high speed camera.

10BABB90-F3B5-4F57-B677-19D77B06D590.jpeg

In any case, that style would work. Doesn’t matter what follows the bullet, it just had to be first.
 
I can't be for sure about the error cause without knowing if something is actually detected by the sensors, but I have an idea of why high velocity readings might occur. Let's pretend that the bullet is reaching the first sensor plane with a gas seal following behind it (I have watched my own videos where I have shot targets at 15 yards or so and have witnessed the gas seal bouncing off the target very close to where the bullet impacted). In this theoretical scenario, maybe the bullet passes the first sensor plane and is or isn't detected (not sure how the logic programmed into the unit uses the sensor data) and then while the bullet is in between the two optical sensors the gas seal is detected by the first sensor plane, restarting the timing sequence. Next the bullet reaches the second sensor plane to be detected, the gas seal possibly isn't detected at this plane, and the time frame between detections is thus shorter than if only one object had passed between sensors. Obviously the shortened timing creates a higher velocity reading and voila, incorrect bullet velocity is reported. That's a theory I have which may create the problem, at least.
I think your explanation for the incorrect (over speed) readings makes sense. The bullet is missed by the first sensor, the sabot/seal is picked up by the first sensor, then the bullet is picked up by the second sensor.

Without knowing exactly how the chrono operates, I'd say that the actual "Error" readings result from one of the following situations:

1. The chrono picks up a different number of items at first sensor compared to the second.
2. The chrono picks up more than one item at either of the sensors.

If I designed a system like that, I would design it to wait for the first sensor to trigger, and only then have it start looking for a trigger on the second sensor. Once it started looking at the second sensor, it would stop watching the first sensor and would only watch the second sensor for a certain timeframe before giving up. After seeing something on the second sensor (or timing out on the second sensor), it would stop looking at either sensor for awhile and just display the reading (velocity or error) for an interval before resetting.

The only error condition with that design would be picking up something with the first sensor and then not seeing anything on the second sensor within the allowable timeframe.
 
Status
Not open for further replies.
Back
Top