Re: Introducing "Shooter", ballistics for Android!
<div class="ubbcode-block"><div class="ubbcode-header">Originally Posted By: Lindy</div><div class="ubbcode-body"><rant on>
There is no reason to support density altitude for environmental inputs.
Density altitude is computed from temperature, pressure, and relative humidity. Any source which computes DA, like a Kestrel 4000 or 4500, is reporting those quantities.
Bluetooth sync to a Kestrel is likewise an unnecessary complication. Where will the Kestrel be while it's reporting those quantities?
In your pocket? Wrong temperature.
In the sun? Wrong temperature.
And the other quantities don't change very fast.
While I am an electrical engineer and computer geek, albeit a happily retired one, and I support the concept of density altitude to the point of having written two web pages about it, shooters are advised to think a bit about how they are going to use a ballistic program before they request addition of features to a program.
Every feature you add to a program increases the odds of introducing bugs. In fact, I know of one programmer who added the input of DA to the environmental screen of his ballistic program, and screwed up the program. It took several subsequent releases to get rid of all the bugs.
I have a PDA with a very good ballistic program. Two such programs, actually.
In the field, I mostly use a density altitude dope card, a watch with a pressure sensor, and a cheap zipper-pull thermometer.
In a counter-sniper duel against an opponent with a PDA and a Kestrel, I will kill him while he is turning on his PDA.
It's nice to have the latest and the greatest gadgets. It's nicer to be able to stay alive.
<rant off>
We now return you to your normally scheduled geek frenzy.
</div></div>
Lindy,
Without question I have respected your knowledge and authority around this particular topic and to this point, also carry around dope cards calibrated to density altitude constructed with your online direction.
That said, I would have to disagree with you on this particular point. Yes, having environmental inputs as stands-alone inputs gets the job done, but having the option of entering a single variable to account for altitude, temperature, pressure, and humidity at once only speeds up the process of data input into the PDA, especially when you have that data readable on one screen from a Kestrel. It would only simplify the input and calculation process assuming the DA implementation in the program is done right. There are also times when your dope card doesn't have the granularity that a PDA would have and given a lax time requirement, can dispense with the card and refine the ballistic calculation through the use of the PDA.
Yes, there is always a risk that something is implemented incorrectly and it breaks the program but bugs are only in need of being fixed. We shouldn't limit our capability for fear of bugs otherwise we'd still be in the stone-ages.
Lastly, the bluetooth integration also saves me a step. While I wouldn't suggest streaming bluetooth data from a pocketed Kestrel for the reasons you pointed out, it would be nice to have a "data sync" capability that only requires the push of a single button once the Kestrel is deployed and reading accurately. This would be a nice feature to also speed up the process.
With the discussion revolving around geek-tech, the above would seem more than relevant towards the discussion of feature development on a smartphone with Android software!
