What would you like to see in reloading software?

[dloader]

I've been a gun owner for almost 20 years and am new to reloading. I've been doing a lot of reading, watching videos, etc. to come up to speed on the process.

Since I make my living in engineering (software), I'm naturally a bit OCD, but that's not a bad thing when you're talking about the creation of something critical like ammunition. So it should come as no surprise that I've thought about how I could use software to help my reloading efforts.

My first thought was to make the software capable of tracking all the inputs that ultimately result in my completed cartridges, as this would make it practical to search the data for trends or obvious issues (like manufacturer, lot number, etc.). I have also considered designing it to allow both individuals and organizations to share their load data among "subscribers", so this would work for components manufacturers, shooting associations (IDPA, etc.) and even local clubs. This would make it far easier to search load data and share the results of specific cartridges...right down to the specifications (PF, COAL, etc.).

As this is a part-time project my primary goal is to avoid scope creep but it would help to know exactly what new features the average reloader would find helpful during the design phase of the software. Hence the topic of this thread:

If you could use software to track or otherwise help you reload, what features would you like to see? How would you want it to work (i.e. process flow)?

Edited November 28, 2011 by dloader

[dnmccoy]

I would volunteer to be a beta tester if you come up with something. I know alot of people that use excel to track their loads

[Skydiver]

I'd like to see the an inventory system associated with the loading software. It'll let me know how much stuff I have on hand, as well as the rate I'm using up materials, give me a warning when I'm running low, and most importantly, keep a running cost of how much each bullet made costs, as the price of the materials fluctuate (or more likely go up).

As much as having information about PF would be useful, it is only useful if people also fill in the other details as to what gun the bullet is fired out of, barrel length, relative wear of the gun, and what the environmental factors were at the time the PF was measured (eg. temperature, humidity, air pressure, etc.). An additional bit of information needed is whether that PF was a peak value, an average value of 5 (or 10, or 20) shots, a minimum value, etc. Was the data for the averages cleaned by throwing out outliers, or the outliers included in the average? How did the shooter know to throw the data out because it was an outlier and not because it just happened to be on the high end of 2 standard deviations away? In short, if I were to follow the recipe for the cartridge and load it into the same gun, how reliable would the results be to replicate the same claimed PF?

[dloader]

I would volunteer to be a beta tester if you come up with something. I know alot of people that use excel to track their loads

Interesting. That brings up the point of data import/export. I had already planned CSV, JSON, and XML export (since I believe users should always have ready access to the data they enter into any system) but importing could be a challenge simply because I don't know what people typically store in their spreadsheets. Perhaps someone can post one that is popular (as opposed to a one-off that someone made)?

[dloader]

I'd like to see the an inventory system associated with the loading software. It'll let me know how much stuff I have on hand, as well as the rate I'm using up materials, give me a warning when I'm running low, and most importantly, keep a running cost of how much each bullet made costs, as the price of the materials fluctuate (or more likely go up).

The concept of inventory and the resources required to produce a given set of bullets in a reloading "session" was already in the mix. Tracking costs was outside the initial design scope, but once I'm tracking inventory it's not that much additional work.

As much as having information about PF would be useful, it is only useful if people also fill in the other details as to what gun the bullet is fired out of, barrel length, relative wear of the gun, and what the environmental factors were at the time the PF was measured (eg. temperature, humidity, air pressure, etc.). An additional bit of information needed is whether that PF was a peak value, an average value of 5 (or 10, or 20) shots, a minimum value, etc. Was the data for the averages cleaned by throwing out outliers, or the outliers included in the average? How did the shooter know to throw the data out because it was an outlier and not because it just happened to be on the high end of 2 standard deviations away? In short, if I were to follow the recipe for the cartridge and load it into the same gun, how reliable would the results be to replicate the same claimed PF?

I had thought about supporting "specifications" and some statistics / QA information as part of the process...since I know I'll definitely want to produce a batch and then measure N cartridges then do some statistical analysis over the short and long term (within a given batch and across multiple batches)...data that might be helpful to track parts wear or alignment on the press, etc. I'm definitely limited on my understanding on the full scope of statistics that would be helpful, so if anyone has any further info, please volunteer it.

Thanks for the input.

[Babaganoosh]

For pistol reloading I believe you are over thinking it. I know bench rest shooters are huge into data and logs. For pistol I clean em, load em, and then shoot em. That's after I come up with my load though. That is where you need all the data in my opinion. After that though, KISS method.

[dloader]

For pistol reloading I believe you are over thinking it. I know bench rest shooters are huge into data and logs. For pistol I clean em, load em, and then shoot em. That's after I come up with my load though. That is where you need all the data in my opinion. After that though, KISS method.

My design so far allows provisioning of "generic" components (say, for example, you don't bother tracking your batches of brass), so you could define your cartridge merely in terms of caliber, powder brand/wt, and bullet brand/type/wt and negate all the other traceability features. Nice to hear the perspective on the KISS approach.

[Babaganoosh]

For pistol reloading I believe you are over thinking it. I know bench rest shooters are huge into data and logs. For pistol I clean em, load em, and then shoot em. That's after I come up with my load though. That is where you need all the data in my opinion. After that though, KISS method.

My design so far allows provisioning of "generic" components (say, for example, you don't bother tracking your batches of brass), so you could define your cartridge merely in terms of caliber, powder brand/wt, and bullet brand/type/wt and negate all the other traceability features. Nice to hear the perspective on the KISS approach.

Well I tend to get involved in some sort of project and overdo it. I over-think things. I have to knock myself back to reality sometimes and remind myself to keep it simple. Simple is almost always better.

[dloader]

Well I tend to get involved in some sort of project and overdo it. I over-think things. I have to knock myself back to reality sometimes and remind myself to keep it simple. Simple is almost always better.

The one thing that will keep this simple is the lack of time I have to spend on it. But I also want to make sure it's useful to the average reloader, hence the reason I asked for ideas on what is important (and also what is not).

[DyNo!]

Software that prints a picture that looks like my reticule and has yardage marking for my bullet drop reticule.

(There is no program that does this...)

[dloader]

Software that prints a picture that looks like my reticule and has yardage marking for my bullet drop reticule.(There is no program that does this...)

Could have sworn I saw something like this in one of the standalone apps for Windows I saw in my early research. I have to admit that the initial plan (i.e. version 1.0) does not include full ballistics analysis, but it is on the wish list. Thanks for the input.

[AggieMM]

Software that prints a picture that looks like my reticule and has yardage marking for my bullet drop reticule.

Not to hijack the thread, but try this application at Vortex Optics ( http://www.vortexoptics.com/content/lrbc ). One of the tabs is a "ballistic reticle", where you can print out a drop chart with BDC, MOA, or MRAD reticle.

Ryan

[DyNo!]

Software that prints a picture that looks like my reticule and has yardage marking for my bullet drop reticule.

Not to hijack the thread, but try this application at Vortex Optics ( http://www.vortexoptics.com/content/lrbc ). One of the tabs is a "ballistic reticle", where you can print out a drop chart with BDC, MOA, or MRAD reticle.

Ryan

Thanks but the only problem is that I have a Burris XTR and a Elcan SpectreDR (Not available as images).

I make my own but if there were a program that did it for you, one could sell it.

You might run into copyright issues since many companies protect their reticules. (That's probably why that program doesn't exist)

[noylj]

Some real inner ballistics for load develop.

There are already lots of external ballistics software, some built into the sight.