LabRadar: Great Data - Terrible Implementation. (partial solution inside)

[entoptics]

As I've mentioned numerous times, the LabRadar algorithm (and interface) is horrific. This device is technological marvel, but with a user interface and internal calculator which appears to have been designed by Elmer Fudd and Foghorn Leghorn.

A few folks have questioned my observations on the veracity of the LabRadar's canned output (i.e. set distance velocities), so I figured I'd go ahead and demonstrate the problems, and more importantly, offer a solution.

The bad news? It's not convenient.
The good news? The data the unit collects is outstanding, and with some work, can be rescued.

The issue I've documented below is spurious readings at set distances, and particularly the "V0" velocity. The unit clearly is not using the entire shot tracking record to calculate the velocity at each of the 5 distances the user can manually select. Worse, it's strongly biasing the calculation based on a couple of readings near the set distance.

To summarize the problem: The unit ignores a wealth of data, has no filters for clearly bad data, and blithely spits out a number based on a tiny fraction of the information it has at hand. This is a grievous example of "Can't see the forest for the trees", and an embarrassing "software" failure for otherwise outstanding hardware.

So...What do I mean...? See the following graphs for examples. In each graph, I've plotted the tracking information for the shot, regressed a line through the data, then used that regression to calculate the muzzle velocity (V0). As you'll see, my simple Excel spreadsheet is far superior to the built in software (firmware?) on the LabRadar unit. I took it a step further, and set up an algorithm for culling the bad readings, which cleans up the shot track and produces a robust equation for calculating the velocity at any distance along the path.

Example 1.
LabRadar V0 = 7684. Note the first bad reading has biased the idiotic LabRadar algorithm.
Unculled Regression V0 = 2828
Culled Regression V0 = 2833
Though I've renamed my rifle to 300 Win Mag Creedmoor, I'm not sure even adding Creedmoor to the name will get me 7 times the speed of sound.

Example 2.
This is where things get a little more insidious. Nobody will believe a 7700 fps V0, but if the V0 is reasonable, even if wrong, then it's far more likely to be believed.

Labradar V0 = 2864
Unculled Regression V0 = 2870
Culled Regression V0 = 2870
Difference = 6 fps
The discrepancy is due to the second reading the LabRadar got. Note that my raw and culled regression gave the same value. That's due to data density. One bad point has little effect on 100 good points. For some reason, LabRadar engineers don't seem to know this basic statistical fact...

Example 3.
Labradar V0 = 2834 fps
Regression V0 = 2865 fps
Culled Regression V0 = 2867 fps
Difference = 31 fps

For load development I put each and every shot track through my spreadsheet. Here's a summary of the last several. As you can see, in almost all cases the LabRadar overestimates ES/SD. Sometimes more nearly triple.

The firmware/software implementation for the LabRadar is a freaking war crime. How is it possible that a company that is capable of making a portable doppler chronograph couldn't put a simple linear regression algorithm into the calculation?

That being said, I freely offer my spreadsheet to anyone who wants to use it. You can open each track log (requires SD card data), and with a couple clicks and keyboard shortcuts, you can cull and view the data, and get the regressed value. It's tedious, but if you want to get all the information the LabRadar unit can provide, it's the only way I know of, short of an email/go-fund-me campaign to get the people at LabRadar to fix their product.

If demand is sufficient, I will make a video tutorial of how to use my spreadsheet. It may be a month out, as I will be traveling for the next 3 weeks.

 

[milanuk]

The info provided looks pretty solid... what kind of response have you gotten from the folks @ LabRadar about the matter?

And I'd definitely be interested in seeing how you work thru the process shown above. I have a fair idea how I'd go about it, but having a reference to go off of is always a little easier

 

[ShtrRdy]

Thanks for sorting all this out. This helps convince me to not buy a Labradar yet.

 

[entoptics]

The info provided looks pretty solid... what kind of response have you gotten from the folks @ LabRadar about the matter?

And I'd definitely be interested in seeing how you work thru the process shown above. I have a fair idea how I'd go about it, but having a reference to go off of is always a little easier

I haven't contacted LabRadar. I'm not sure what use that would be, as they're surely aware of what the unit does. They don't provide an actual email, only a "contact us" form, so I can't attach the graphs. My above post is a bit harsh, so I'm not sure I want to link them to it either, but I suppose I could edit it to be a little more neutral.

As for the spreadsheet, Here's a google drive link. Probably safe to assume you'll need to download the spreadsheet to use it.

Here's a screen capture movie of my spreadsheet in use.



1) At 30 seconds in, the data from the LabRadar tracking file magically moves into the spreadsheet. I created a Macro to do this. The keyboard shortcut for a Mac is command+option+e. For a PC it's probably control+e. YOU MUST NOT RENAME THE SPREADSHEET TO USE THE MACRO. It relies on the name "Lab Radar Rescue" to know where to paste the data from the tracking file. If the Macro doesn't work, you can simply copy columns A, B, C, and D into the same spot in my spreadsheet.

2) Unless the tracking data is completely wonky, it's usually not really necessary to sort/cull the data, as the regression will usually be "close enough" as long as there are a few dozen well behaved data points. Data points highlighted pink are outside an arbitrary tolerance, and represent poor tracking and/or spurious results. If you do want to cull the data, for very short tracks or a few really nasty points that are throwing off the line, you can manually clear them. Select each bad point individually, or click the "Sort By Variance" button, which will sort the data, so you can scrap all the bad points at once by scrolling down.

3) The green cells are the calculated velocity (using the intercept formula for the regressed line). One cell uses the time data, and one cell uses the distance data, and there's generally hardly any difference between the two.

4) The yellow cells are for calculating ballistic coefficients. They take the nearest and furthest readings in the shot tracking, calculate the regressed velocity at each, then subtract the two distances to give you the "delta distance" for input into a calculator such as JBM. Be aware that precise atmospheric data must be input into the calculator to get a meaningful result. If you intend to calculate accurate BC's from LabRadar data, you must collect readings of station pressure, temperature, and humidity at the time you took the shot.

Hope this is useful to someone. Based on the lukewarm reception so far, I may be wasting my time, but oh well.

 

[Bob Wright]

If your spreadsheet is providing statistical data that calls into question Labradar software/hardware they should at least entertain it. I paid a lot of money and sold my Chrony. Keep pushing.

 

[kiwikid]

entoptics when I had issues with my LabRadar I was able to send them files at this email address
[email protected]

 

[jareese]

Hope this is useful to someone. Based on the lukewarm reception so far, I may be wasting my time, but oh well.

I think the reason is most people are that computer savvy. I'm game to give it a try. Thank you, and I too think you should approach LabRadar with this.

 

[JTComfort]

Reach out to LabRadar by phone - Tom answers the phone in Wichita, KS. I just got my unit back from a repair and found the customer service excellent. And I would be very intereste to learn more.

 

[sea2summit]

I emailed with an issue and had a response in less than an hour. Then I had a second person who I assume was more of a tech respond the next morning because the first wasn't able to solve my problem. I would say their customer service is above average. I just used the "contact us" form on their site.

 

[brotherbear67]

Thanks for sorting all this out. This helps convince me to not buy a Labradar yet.

I'm with ya on that....

 

[Pro2A]

As I've mentioned numerous times, the LabRadar algorithm (and interface) is horrific. This device is technological marvel, but with a user interface and internal calculator which appears to have been designed by Elmer Fudd and Foghorn Leghorn.

A few folks have questioned my observations on the veracity of the LabRadar's canned output (i.e. set distance velocities), so I figured I'd go ahead and demonstrate the problems, and more importantly, offer a solution.

The bad news? It's not convenient.
The good news? The data the unit collects is outstanding, and with some work, can be rescued.

The issue I've documented below is spurious readings at set distances, and particularly the "V0" velocity. The unit clearly is not using the entire shot tracking record to calculate the velocity at each of the 5 distances the user can manually select. Worse, it's strongly biasing the calculation based on a couple of readings near the set distance.

To summarize the problem: The unit ignores a wealth of data, has no filters for clearly bad data, and blithely spits out a number based on a tiny fraction of the information it has at hand. This is a grievous example of "Can't see the forest for the trees", and an embarrassing "software" failure for otherwise outstanding hardware.

So...What do I mean...? See the following graphs for examples. In each graph, I've plotted the tracking information for the shot, regressed a line through the data, then used that regression to calculate the muzzle velocity (V0). As you'll see, my simple Excel spreadsheet is far superior to the built in software (firmware?) on the LabRadar unit. I took it a step further, and set up an algorithm for culling the bad readings, which cleans up the shot track and produces a robust equation for calculating the velocity at any distance along the path.

Example 1.
LabRadar V0 = 7684. Note the first bad reading has biased the idiotic LabRadar algorithm.
Unculled Regression V0 = 2828
Culled Regression V0 = 2833
Though I've renamed my rifle to 300 Win Mag Creedmoor, I'm not sure even adding Creedmoor to the name will get me 7 times the speed of sound.

View attachment 137924

View attachment 137925

Example 2.
This is where things get a little more insidious. Nobody will believe a 7700 fps V0, but if the V0 is reasonable, even if wrong, then it's far more likely to be believed.

Labradar V0 = 2864
Unculled Regression V0 = 2870
Culled Regression V0 = 2870
Difference = 6 fps
The discrepancy is due to the second reading the LabRadar got. Note that my raw and culled regression gave the same value. That's due to data density. One bad point has little effect on 100 good points. For some reason, LabRadar engineers don't seem to know this basic statistical fact...

View attachment 137926

View attachment 137927

Example 3.
Labradar V0 = 2834 fps
Regression V0 = 2865 fps
Culled Regression V0 = 2867 fps
Difference = 31 fps


View attachment 137928

View attachment 137929

For load development I put each and every shot track through my spreadsheet. Here's a summary of the last several. As you can see, in almost all cases the LabRadar overestimates ES/SD. Sometimes more nearly triple.

View attachment 137930



The firmware/software implementation for the LabRadar is a freaking war crime. How is it possible that a company that is capable of making a portable doppler chronograph couldn't put a simple linear regression algorithm into the calculation?

That being said, I freely offer my spreadsheet to anyone who wants to use it. You can open each track log (requires SD card data), and with a couple clicks and keyboard shortcuts, you can cull and view the data, and get the regressed value. It's tedious, but if you want to get all the information the LabRadar unit can provide, it's the only way I know of, short of an email/go-fund-me campaign to get the people at LabRadar to fix their product.

If demand is sufficient, I will make a video tutorial of how to use my spreadsheet. It may be a month out, as I will be traveling for the next 3 weeks.

I would enjoy and appreciate the tutorial. Always interested in learning from more experienced individuals. Thank you for your effort.

 

[Dr. Vette]

If you can then convince them to get a high schooler to update their app, we'd all appreciate that. It's easily 10 years behind even though it's only a year old.

 

[MLN1963]

If you can then convince them to get a high schooler to update their app, we'd all appreciate that. It's easily 10 years behind even though it's only a year old.

It's better than nothing, but I agree, it needs help. Mine loses the connection quite often and is probably my biggest gripe.

 

[An Idahoan]

entoptics,

Thank you for this. The sport needs more of this. I for one am grateful that my LabRadar just got better!

Paul