Super Chrono Data Log

Problems FALL 2015

Here are some of the finding I’ve had based on different test criteria. I like to explore the limits of everything I own so that I better understand how to get the best possible use out of the device. The Super chrono is no different. I set out to find its limitations so that I could extract the best possible data from it for reloading purposes……

First test was to see if you can offset of the device left or right. Shock wave goes out in a conical shape and should be detectable at strange angles. Thus, I setup as per instructions, with the imposed error of setting it about 2 feet to the left of the bullet path. I was surprised that this was enough to get no data. However moving it over to within a foot of the bullet path picked up the next shot.
Lesson: The bullet must pass close to directly over top of the sensor. Which is good because this means is should NOT pick-up your buddies shots next to you.
Next I tested the height of the window, which is claimed to be 51″. For this test I set the tripod to max height and rotated the super chrono sideways. Not supposed to do this as you may pick-up bounced shock waves from the ground, but the test actually worked well. I found that at 1,2,3 and 4 feet distance the super chrono gave numbers. Once I hit the 5-6 foot mark it lost the shots.
Lesson: The described window height seems be correct. Lots of room to play with.
I conducted 4 rapid fire shot tests with an AR-180B,  rate of fire ranged from 5 shots in 1.5 seconds, to 5 shots in 1.25 seconds. The Super Chono captured all shots.
The display is nice and bright, but you cannot read it from a distance due to the LCDs being at a sharp angle, not tilted enough. Thus you must get up to gather your data. It would be nice to have the LCD tilted more, or perhaps a second readout on the bottom so that you can read the data from your rifle position.
I wanted to see what kinds of support you could use and still capture good data. So I tried some different mounts…other than a tripod.
  • Placing the device on the ground gave an extremely high velocity
  • Placing the device on a chair gave data that was lower than normal, as the chair back bounced a shock wave.
  • Placing the device on a small table gave an extremely high velocity.
Unfortunately the Super Chrono seems to favor being suspended in mid air, away from the ground and all things that may cast a reflected sound wave. This becomes important when placing near a target or other things that could cause faulty readings.
Velocity readings FPS compared to MPS
Here is the FPS raw data from one of my load testing days:
2893/2903/2903/2893/2906    2903/2916/2910/2910/2887   2903/2910/2906/2910/2923   2913/2890/2900/2890/2913   2906/2890/2906/2900/2913   2906/2890/2890/2900/2893
Wow look at those repeating numbers. I cannot load consistently enough to get number that fall into a couple predetermined buckets. This leads me to the conclusion that the algorithm inside the device is only calculating MPS to the nearest meter, then converting directly to FPS and rounding off the number. Which would explain the gap of about 3 fps between groups.
Put it another way, lets count how many times each number shows up. (I left a couple out at the top and bottom of the list.)
2890 -iiiii
2891 –
2892 –
2893 -iii
2894 –
2895 –
2896 –
2897 –
2898 –
2899 –
2900 -iii
2901 –
2902 –
2903 -iiii
2904 –
2905 –
2906 -iiii
2907 –
2908 –
2909 –
2910 -ii
2911 –
2912 –
2913 -iii
This visualization demonstrate my point perfectly. For getting an average velocity to create a ballistics table, great no harm. But for a competitive shooter, this data is questionable.
Still working on….THE UGLY
I went out to the range to do more testing with the superchrono today. First things first….The purpose of my testing is to gain trust in this product. I want a device that I can setup quick and easy and get CONSISTENT results from. I need to be able to trust the data I am pulling from the device, as I use that data to determine where to go with my hand loads as I develop them.
In response to their response:

The velocity data rounding is NOT 1/2 a foot at a time. The rounding must be by 1/2 a meter. It then converts the whole number m/s it created, into f/s, which then has gaps of 3-4 fps between data points. The shot variance with my testing so far shows this to be true. There are velocity nodes when looking at fps. I know that it is statistically impossible for my hand loads to give results such as 2903/2903/2906/2910/2906/2903/2910/2900/2903. There should be a 2904 and a 2905 in there somewhere. So the only plausible answer I can come up with is its a software problem within the device.

Now, is it a really big deal? No.
But it is sloppy on the development / software side of this device. Basics of math, there are 3.28 feet in every meter, thus f/s is more precise than m/s. They should consider changing their algorithm to calculate to f/s first, and then round off to the nearest m/s.  Or calculate m/s to tenths and become more precise than f/s. After all, most loads will be shooting less than 1000 m/s, so they have the extra digit to use for tenths anyways.
For american sharp shooters this will be an annoying flaw in the product. Unless by chance the unit I am using is somehow different than the others, I would at least suggest they look into this and validate for them selves the f/s readouts during a 20-50 shot string with precision hand loads. I am confident they will also run into the nodes we have been seeing in the data.
Next. I know they are aware of the following problem in some respects, but I don’t think the little calculation thing on the website addresses the problem correctly…..its merely a band-aid fix.
I have now confirmed the extreme sensitivity of the device when it comes to alignment with the trajectory. An imposed error of only 1 degree forward tilt creates approximately 100 f/s (30 m/s) slower value, while 1 degree of backwards tilt will create approximately 100 f/s (30 m/s) faster value. This kind of “aiming” error means you will never get consistent read-outs between uses of the device. I was using the superchrono while shooting at 50, 100, and 600 yards today. Every time I changed targets, my average velocity changed as well. And yes I spent extra time trying to ensure I had proper alignment of the device as per the instructions.
I can understand a slight change in velocity at the longer ranges due to increased bullet drop at range. (hence the website calculation fix) But the 50/100 values should have been nearly identical….and they were not.
Back to alignment. Tilting back only 15 degrees gave me a velocity reading of 7391 f/s, and I calculate that at 20 degrees tilt…it will read infinite or 9999. In the other direction, when I tilt forward 15 degrees the velocity is half of the expected value.
Now, obviously this is not how its intended to be used. We should be aiming at the target proper of course. Again I am looking to build trust. What I am trying to show here with this kind of testing, is the flaw we get from using speed of sound as our detection method. 15 degrees down angle to 15 degrees up angle gives us only 30 degrees worth of travel, which translates into a logarithmic scale from half velocity (-15) up through true velocity (0) and on to infinity (+15). As I have said above, this chrono is extremely sensitive to aiming errors.
Now a light/shadow gate type chronograph will be subject to similar angular aiming errors. But because they are using the speed of light for the detection method, we can pretty much eliminate the error down to the change in dimension between gates. This should follow a typical Sine wave form in terms of drop off, meaning a 1 degree aiming error will be negligible in the end calculation result.
As the example goes:
1 degree of tilt will effectively shrink our measuring distance from 200mm down to only 199.97mm which will be a .00015% error.
That would work out to 1 f/s error for my rifle shooting at about 2935 f/s
15 degrees of tilt will effectively shrink our measuring distance from 200mm down to only 193.2mm which will be a 3.4% error.
That would work out to 100 f/s error for my rifle shooting at about 2935 f/s
all chronographs will be prone to this type of angular error.
So where does all the extra 99 f/s error come from when we tilt only 1 degree off center? Speed of sound my friends….which is slow.
Why would we get infinite speed 9999 f/s at 20 degrees of upward tilt?
Well it takes a bit of time for the shock wave to hit our sensors. Not much, but alot more time than light takes to get there. With a 2935 f/s projectile crossing the two gates, the first shock wave above sensor A has only traveled 68 mm down when the shockwave above sensor B starts its journey. This means that at some angle (20 degrees for me) the two sensors will have a 68mm offset that will create a scenario where the shock wave hits both sensors at the exact same time, thus the chrono calculates an infinite velocity.
In the revers direction, tilting forward 20 degrees will increase the distance the shockwave travels down to the second sensor, such that it has to travel twice as far, thus it will calculate about half velocity.
With that I leave you with TODAY’S RAW DATA:
Test data #1, New Savage 6.5-284
Norma Match grade ammo speced to 3200 fps
Aim as per instructions 50 yards
Aim as per instructions 100 yards
Tilt slightly forward (not measured)
Tilt slightly back (not measured)
Aim as per instructions
Test data #2, 308WIN F-class Target hand loads.
155 Gr. Lapua Scenar seated 0.005″ off the lands
44.5 Gr. varget = Shooting Chrony average velocity 2935 f/s during load developement
Lapua Brass, neck size only, weight sorted
CCI BR2 primers
600 yards
clineometer setup
Aim as per instructions
Tilt back 1 degree
Tilt foreward 1 degree
Tilt back 15 degrees
Tilt foreward 15 degrees
Tilt foreward 39 degrees – trying to double the 20 degrees I calculated before hand
Aim as per instructions
Bump aim tilted up, less than 1 degree. I’ll call this trying to mimic poor practice.