Open Source AAD

[df8m1 19]

There seems to be interest in the subject so I thought I would start a thread for an Open Source AAD.

My understanding of the concept (and please correct me if I am wrong) is to create an AAD that can be acquired for less than say $200.00. For the record, I have been designing AADs for the military and soon Sport Jumpers. I shake my head every time someone says "there is less then $200 in parts, there is no reason it should cost $1500"... But, I may just be greedy..

Well here is a platform for all the coders and engineers out there who want to make AADs available to everyone at an "affordable" cost.

Please do not misinterpret how I have said anything as being sarcastic or negative in any way. It is more of... OK... Lets see if it can be done.... kind of thing lol

The only "requirements" for an AAD here in the USA, (as fare as I can tell) is "that they be maintained in accordance with the manufacturer", and given the collective would be the designer / manufacturer, the collective can specify what maintenance, if any, it needs, what parts are approved or not, (cutters from another AAD which have been already approved by container manufacturers for example)...

Here is a chance to "share" source code that everyone wants to see so badly... How will this turn out in the end?... There is one way to find out!

I will offer this toward the effort, if someone as a proof of concept that they want to drop, if I am drop testing, I am offering to pitch a "dummy" for them but only in a "passive" state, meaning the AAD will not have the ability to deploy a parachute and take down the plane. It can light up a light, or do something else, but not be in control of parachute deployment.

I am at the least, anticipating some good technical discussions, and lets keep it polite. There will be different opinions and that is part of the process, no taking personal offence if someone does not like an idea or how something was done..

Lets have fun with this experiment!!!

[mxk 1]

df8m1

Well here is a platform for all the coders and engineers out there who want to make AADs available to everyone at an "affordable" cost.

Please do not misinterpret how I have said anything as being sarcastic or negative in any way. It is more of... OK... Lets see if it can be done.... kind of thing lol

Well, you would know better than any of us whether it can be done, especially since you already have the manufacturing capability. I'm a software guy with zero hardware design experience. As soon as someone gives me a device that I can program (or makes one available for sale), I'll get to work, but until then, I can't be of much help. Personally, I don't think "affordable" should be the main goal, especially at the beginning.

Correct me if I'm wrong, but I imagine that the battery run time of 4-10 years determines the rest of the design for all current sport AADs. That design is about as simple as possible, especially on the software side. There is simply no power to run anything sophisticated. If we want to start by developing a data acquisition system that has a bunch of sensors, can be programmed, can be mounted somewhere outside of the container, and has enough battery power to last at least one weekend of jumping, that would be one thing. Whether it can then be turned into an actual AAD that can function for at least 180 days between repacks, never mind several years, would be a totally different matter.

To Michael's point regarding upfront costs for standards, tools, software licenses, etc. Do we have any evidence that existing AAD manufacturers follow such practices? There are no regulations that would require them to conform to any C coding standards, no external audits, nothing that would require an initial investment beyond what it takes to design and manufacture the hardware.

[peek 20]

df8m1

There seems to be interest in the subject so I thought I would start a thread for an Open Source AAD.

Just my opinions on where we would need to start:

Someone would need to specify what sensors would be available. I think we can assume a pressure sensor, temperature sensor (only for pressure sensor corrections), and perhaps a 3 axis accelerometer if the microprocessor has enough computing power. I don't think an AAD needs anything else.

Someone could choose a flowchart editing program, perhaps an online one, and then have flowcharts go through some kind of review process, where one or more program flows would be the current or "preferred" program.

[wmw999 2,123]

The Astra used AA batteries; even the battery life might not be a problem with AA's that are replaced at each repack (or else externally mounted). Some periodic testing would seem to be in order, with the requirements and parameters being established and reviewed regularly by both the manufacturer and possibly an external source.

You'd want to define the level of redundancy needed ahead of time, and build that into both the code, and the testing. I.E. test the code as written first, then a more vigorous test to requirements. I'd see it as being a bad thing if a unit does more than anticipated. In other words, failure mode is to fail, and not to do something weird (eg fire when in a descending airplane)

Wendy P.

There is nothing more dangerous than breaking a basic safety rule and getting away with it. It removes fear of the consequences and builds false confidence. (tbrown)

[hackish 8]

mxk

To Michael's point regarding upfront costs for standards, tools, software licenses, etc. Do we have any evidence that existing AAD manufacturers follow such practices? There are no regulations that would require them to conform to any C coding standards, no external audits, nothing that would require an initial investment beyond what it takes to design and manufacture the hardware.

I don't think you'll find a legal requirement but it's the technical norm for devices of this nature. There are specific types of failure analysis, testing and even parts tracking that go into designs. For example there was a recall once from Airtec that affected certain Cypres units. They knew that a specific batch of pressure sensors could have been affected by a defect. AAD also published some details about the issue. That alone demonstrates that our AAD manufacturers do have QA and traceability systems in place on the hardware side.

What if a software bug pops the AAD in the door and leaves a smouldering hole in the local schoolyard? It wouldn't be the first time an accident/incident is traced to a software bug. Ariane 5? Toyota's unintended acceleration? How difficult is it for a lawyer to show negligence if the designers didn't even follow industry standard norms for quality assurance?

I think that the costs of a commercially produced AAD are justified. The per unit cost of the components and casting is quite low but the IP and management costs are huge. A couple of hobbyists hacking together a unit, bypassing all the expensive safety and design checks and distributing it as an AAD platform would be doing the entire industry a big disservice.

-Michael

[hackish 8]

peek

Someone would need to specify what sensors would be available. I think we can assume a pressure sensor, temperature sensor (only for pressure sensor corrections), and perhaps a 3 axis accelerometer if the microprocessor has enough computing power. I don't think an AAD needs anything else.

There is a MEMS pressure sensor. SCP1000. I've used it before and it has reasonable sample rate, digital processing and temperature compensation inside already.

Using an accelerometer, you'd have to make sure it doesn't infringe on existing AAD patents.

The micro doesn't need to be complicated. A small bit of flash, RAM and eeprom inside. You need good current drivers to fire the cutter and usually a storage cap. AAD had a good solution they designed and patented for this. You probably need/want an external EEPROM/flash to store flight data. Then a small LCD unit with a button and maybe IR transciever and small micro to communicate with the AAD processor.

-Michael

[peek 20]

You got into a lot of detail very quickly! I am suggesting that the program flow (hence the flowchart suggestion) should be considered first. The hardware can be selected later, and there are a lot of choices. We would just need to know whether to include accelerometers at all when writing the program flow.

From what I can tell, many of the "issues" with current AADs have been because of "exceptions" in the operation that were not provided for. Or to put it another way, I think the firmware is a larger consideration than the hardware.

[uer16 1]

I've used the MPL3115A2 with great success, has internal temperature compensation and altitude calculation, simplifies firmware a bit. The SCP1000 seems obsolete as of now.

And +1 to whatever Gary said, implementation details like what exact hardware to use aren't that important.

There's also no point in limiting the amount of sensors for the initial device for data acquisition. I'd go with a gyro, an accelerometer, magnetometer, an altimeter or 2 (which includes a temp. sensor internally), and perhaps even GPS, although this one would severely constrain a bunch of stuff like battery and case size.

And also slap a microSD holder for logging all the stuff, since eeprom/flash or whatever ICs have worse byte/$ ratio than an SD card and are easier to use. And data can be retrieved from a broken device this way too.

Something like an N3 with all of the above sounds pretty interesting.

[Unstable 8]

Quote

And also slap a microSD holder for logging all the stuff

Wouldn't the MicroSD port make the unit very susceptible to water damage?

=========Shaun ==========

[uer16 1]

Quote

Wouldn't the MicroSD port make the unit very susceptible to water damage?

I meant a hinge-type microSD holder inside the device (i.e. you can't take the card out without taking the device apart). Basically as an alternative to on-board memories.

The bigger issue with making it water-resistant is probably the membrane for the pressure sensor(s).

[BrianM 1]

wmw999

The Astra used AA batteries

No it doesn't. It uses a custom battery pack which, I believe, contains CR123A's.

"It's amazing what you can learn while you're not talking." - Skydivesg

[wmw999 2,123]

Thanks -- I'd been told it used AA, but either I was mistold, or I misheard.

Wendy P.

There is nothing more dangerous than breaking a basic safety rule and getting away with it. It removes fear of the consequences and builds false confidence. (tbrown)

[df8m1 19]

peek

You got into a lot of detail very quickly! I am suggesting that the program flow (hence the flowchart suggestion) should be considered first. The hardware can be selected later, and there are a lot of choices. We would just need to know whether to include accelerometers at all when writing the program flow.

From what I can tell, many of the "issues" with current AADs have been because of "exceptions" in the operation that were not provided for. Or to put it another way, I think the firmware is a larger consideration than the hardware.

I agree that hardware is the last thing that needs to be delt with as you can have the perfect platform, but without a good program to run on it it is a paper weight....

Just a suggestion as to were to start...

Define the Scope of the Effort... (what is the end goal functionality wise? Will it only work for RW jumpers? Will it only work for WingSuiters or Swoopers? Will it work for all of the above? Where will the AAD be located? Battery lifespan? How much interaction do you want the user to be able to have with it and how will the user interface with the AAD? Gona have user accessible data collection? What should the AGL accuracy of the activation be? Will the activation altitude be user adjustable? if so by how much? What is the end goal end user cost target?)


There are more considerations to be considered before starting to figure out how to go about accomplishing the goals. Once there is a solid plan with defined performance requirements, then hardware can be selected that complements those requirements.

Just some thoughts

[hackish 8]

Pluggable micro SDs won't tolerate the vibration. There is also no QC, traceability or anything for a corner store micro sd. If you wanted to charge onboard batteries and/or download data then put a sealable micro USB connector on the head unit. On many rigs that would be convenient.

It also doesn't make sense to try and jam a ton of sensors in there that do not help you. If there is a patent that prevents you from using an accelerometer then you're wasting your time adding one. For simple data acquisition to develop the algorithm and filters, check out the ardupilot project as they have prepared boards

-Michael

[df8m1 19]

I am curious to see if there ends up being any truly "shared" information in the end regardless of if anything reaches even a proof of concept level or not.

It is easy for a programmer to think that the code should be made public for all to scrutinize, even though there are very few that might be qualified to do so...

I bet that if someone really gets into it, and figures out a way to handle a problem better than is currently being done, they will want to keep it to themselves, as there could be value in it...

Another poster put it well, basically saying the value is in the process, not the parts... I have a in house machine shop, electrical and mechanical design capabilities, short run electronic assembly, custom made testing capabilities, and custom software capability... Some one once told me that because I could do 90% of a project in house that it really doesn't cost me anything to take a project from concept to prototype.. I just smiled...

This project development concept (based on a collective) would probably only work in an academic context, like a college engineering class where teams are assigned a project to see it from start to end. There would still be costs involved, but there are usually budgets assigned to the teams to cover things like materials and services not available on campus..

An AAD is fully capable of killing everyone on a plane and possibly anyone that parts of the plane land on.. The level of risk with and AAD is up there with Air Bag Deployment Systems and Weapon Control Systems, were hardware and software safety interlocks need to be in place to ward against an unintended firing.. Sometimes it is hard to reach the level of built in safety without negatively affecting the intended operation of the device..

I have many 3ft X 4ft flow charts on my walls and rolled up in the archives that you have to be no more than 1 ft away in order to read them they are so complex. It is easy to create a "dead end" that is not obvious, (like Peek was talking about), that can cause an unpredictable result in just the right circumstances.. A perfect example of an unobvous dead end is an AAD firing in a trunk...

I think because AADs are associated with "potentially" saving the life of someone who, did not / could not, save themselves, emotion gets mixed in and you get calls for mandating the use of AADs and demands for "AADs that everyone can afford". Not that there is anything wrong with those thoughts as there are equally apposing thoughts as well.

As doubtful as an Openly Developed AAD sounds, lots of great things have resulted from similar efforts, so I think it is truly something worth while.... Nothing ventured, nothing gained..

[mxk 1]

df8m1

It is easy for a programmer to think that the code should be made public for all to scrutinize, even though there are very few that might be qualified to do so...

I bet that if someone really gets into it, and figures out a way to handle a problem better than is currently being done, they will want to keep it to themselves, as there could be value in it...

So that's why no one ever developed an open source operating system and then distributed it for free! Oh, wait... I think you just described every piece of open source software ever written.
As I said in my previous post, give me the hardware and I'll start coding. Everything will be on GitHub. Handling this particular problem "better" (relatively speaking) is easy. The issue is battery power, computational power, and memory. Given current Vigil or CYPRES hardware, I'm not sure that I would be able to write software that is significantly better due to inherent hardware limitations. Add more sensors and/or give me more processing power, without severely compromising battery runtime, and now there is significant room for improvement.

I'm really puzzled by people saying that hardware is a secondary consideration. Hardware determines what is possible to do in software. I can implement a machine learning algorithm on my PC (well, I could if I had any training data) that could tell you whether you are climbing, in free fall, wingsuiting, under canopy, swooping, etc. What are the chances that it be possible to run it in an embedded system in real time?

The hardware must come first. A low power system is going to be limited in its performance. We need to know that limit before a single line of code is written. Until someone here volunteers to design and manufacture a physical device, this project will go nowhere. It doesn't have to be final hardware or even AAD hardware, just something that can be characterized so that we know what the computational and power limits are.

Data must come second. To develop a better algorithm, you need data from as many sensors as possible over hundreds of different types of jumps. How do we use the information from an accelerometer, gyro, or any other sensor to improve the performance of our firing logic? The collected data must be examined for patterns to figure out what useful information each sensor gives us in every phase of the jump. The fact is we have no idea which sensors may be useful. Perhaps, after analyzing the collected data, we decide that a magnetometer doesn't add any value. Great, then we can take it out, but we don't know this right now.

Software, many iterations of it, is third. There is no point in creating flow charts until we know what all the inputs are, how each input can be used to improve our understanding of the true system state, what type of algorithms can actually run on our hardware in real time, and so on...

Legal issues are way down the road. It makes no sense to worry about patents and liabilities now when we don't have anything. Also, I wouldn't worry about potential for water damage at this stage.

[df8m1 19]

You are absolutely right that the you have to know what hardware you are using before the operating system can be created. And you can't make a decision regarding which sensor is needed or would be the best until a decision has been made as to what the device is going to be capable of.

I mean if it is desired that the end product will have WiFi, then we know a WiFi module is needed, but the performance requirements of that module still need to be agreed upon. Do you want to be able to calculate density altitude? Then temp and humidity is needed, if not, then they aren't.. How long do you want the batteries to last? As you said, processing power kills batteries faster, so a processor with low power consumption is needed, etc...

You are looking at it from the programmer's perspective, saying "give me a black box", but there is a process to create that "black box".

Scope (what does the customer want)... Ideas / concepts how to do it (what might work).... Make it work... With an AAD, software is the make it work part. The objective / scope (what does the customer want), and design concepts (what might work / what it will take to do it) need to be flushed out first.

You could use a Gunstick with a baro transducer brake out board to get started with a lot of processing power, or if you want lower power processors, there are plenty of other development environments that are inexpensive and available from many sources. If you want to add an Accelerometer, add another brake out broad.

Enclosures of all shapes and sizes are available from the same sources, so a complete proof of concept can be ordered from one on line store for less than $200 ( as is often cited), and assembled in a matter of hours. Heck even the code needed to run the instruments is already generated and available...

It is interesting to see the opinions as to what is the priority in this "hypothetical" design effort. Hardware guys say it is the hardware, software guys say it is the software, I am sure the marketing guys and legal guys have their opinions, (I am using the term "guy" generically, not intending to imply, directly or indirectly, that "gals" would not equally apply as an applicable / acceptable reference for those who do).

Maybe I am starting to understand what someone says to me that $1,500 or $1,700 is to much for $200 in hardware and a case... But then at the same time, they are not assigning that value to their work either so that is interesting.. I would expect a software guy/gal to say, yes, there is $200 in hardware and $1,500 in software development value, and equally, a hardware guy/gal would say the design and development of the hardware is worth the $1,500 and the Software is $200....

The reality is, a support system has to be able to stay in business to support the product at lest throughout it's life span... otherwise you will have made another Argus... I guess that is what the Business Development guy/gal says lol...

[peek 20]

mxk

I'm really puzzled by people saying that hardware is a secondary consideration.

Well, to clarify, in post #7 I mentioned a pressure/temperature sensor and asked if an accelerometer would be available. Those 3 sensors only, which I think is all that is needed for simplicity. If we wanted more sensors, then yes, I think the hardware might need to be more defined before the software.

[councilman24 36]

I wouldn't assume any of the current aad manuf. would approve use of their cutters, except maybe you. In the USA they may be able to hang their hats on the reg. statement maintain according to the manufacturer's instructions. Patents may also apply. In other coutries I don't know the regs. I don't recall if the connectors are proprietary or not. Availability of the connector may be an issue. I certainly would not want the liabilty of being drawn into a lawsuit based on an issue on when used on someone else's controller.

Also just because an aad might be approved in a specific rig I wouldn't assume that a manufacturer would approve another complete assembly using that cutter. It's one thing to do this development with a device that can't kill some else but aad's can.

If you can get by cutter, regulatory, patent etc. issues that leaves you with the few manufacturers that neither approve or ban AAD's.

I'm old for my age.
Terry Urban
D-8631
FAA DPRE

[ufk22 32]

Assuming you are correct ($200 parts) you then have manufacturing (small lots), assembly (also small lots) and QC.
Add a reliable cutter (not like Argus)
Add liability insurance and where are you at?
$1200?
open sourse/
A device that can be reprogrammed by anyone with an interest?
Sorry, don't want that guy on the same airplane or in the same sky as me.
Open source development for "normal" software is one thing.
A glitch in an AAD that fires when it shouldn't could kill the owner and others.

This is the paradox of skydiving. We do something very dangerous, expose ourselves to a totally unnecesary risk, and then spend our time trying to make it safer.

[df8m1 19]

ufk22

Assuming you are correct ($200 parts) you then have manufacturing (small lots), assembly (also small lots) and QC.
Add a reliable cutter (not like Argus)
Add liability insurance and where are you at?
$1200?
open sourse/
A device that can be reprogrammed by anyone with an interest?
Sorry, don't want that guy on the same airplane or in the same sky as me.
Open source development for "normal" software is one thing.
A glitch in an AAD that fires when it shouldn't could kill the owner and others.

I totally agree... In reality there is no chance in hell that an actually jumpable device would ever come as a result of an open source concept, where the electrical design and software were openly available for any one to have made.

An agreement can't even be arrived at as to the design process lol... That being said, the idea that the "AADs should be mandated and affordable to everyone" group could use this approach to design an AAD without any labor costs, all the design information would be available for a group of jumpers to have batches made by proper manufacturers at only the cost to do so, and with out any profit from the design and development of it... Even then they would cost over $500 ea so at that point why not just go and get a M2.

I keep hearing an implication that by charging more for and AAD than it takes to make it, that I am denying a jumper access to an AAD and should they go in that the AAD manufacturers would have blood on their hands... No one has come right out and said that, but I have heard some come close.

Sometimes the unexpected can happen with this kind of effort lets call it... Like lets say that a team of electrical, mechanical , and software people were able to get together and create enough of something that a legitimate company might become interested in it and it becomes a real product produced by a real company that can produce the required quality level at a lower price than the M2... You never know who is watching what boards, or who is looking for an opportunity...

The bottom line is money will have to be spent and that will be the wall that stops the effort. There is actually a lot that can be done without spending any money or risking any lives.

[df8m1 19]

councilman24

I wouldn't assume any of the current aad manuf. would approve use of their cutters, except maybe you. In the USA they may be able to hang their hats on the reg. statement maintain according to the manufacturer's instructions. Patents may also apply. In other coutries I don't know the regs. I don't recall if the connectors are proprietary or not. Availability of the connector may be an issue. I certainly would not want the liabilty of being drawn into a lawsuit based on an issue on when used on someone else's controller.

Also just because an aad might be approved in a specific rig I wouldn't assume that a manufacturer would approve another complete assembly using that cutter. It's one thing to do this development with a device that can't kill some else but aad's can.

If you can get by cutter, regulatory, patent etc. issues that leaves you with the few manufacturers that neither approve or ban AAD's.

My understanding is that container manufacturers do not approve of an AAD, but approve the cutter as that is what they are testing to see if it interferes with the normal operation of the reserve. If a container manufacturer approved the AAD specifically, they would be aligning themselves with that AAD manufacturer and possibly liability should it fail.

Container manufacturers make containers, they are not in the position to evaluate the Black Box, no more than the AAD company is in the position to evaluate the container, it is not what they do, and they do not want the others liability.

What the Container manufacturer can do is evaluate how the presence of a cutter affects the operation of the reserve, both when manually and cutter activated.

As for "maintaining according to manufacturers instructions", the manufacture of the AAD would dictate what those instructions were, and to take it a step further, one could argue that the Cutter manufacturer has set a 12 year lifespan on the cutter, so any other AAD manufacture that were to use that off the shelf cutter would have to also limit its life to 12 years.

Of course the manufacturer of the cutter would not approve of the user of their cutter with a competing AAD, but because it was not used with their AAD, they would be out of the picture, unless it was found that the cutter was defective, like missing a blade or some such thing. It is an interesting topic to debate for sure..

As for patents... There have been 4 different electronic AADs that have all been patented at least once.. they are all using the same sensors which are not novel to a person having ordinary skill in the art. The patent office does not refund the cost of a patent if it looses a challenge later on, and it is well known that electronic and software patents are widely over issued. Just because a patent has been issued does not mean 100% of the claims will hold up to a challenge.

Using an accelerometer to measure acceleration is not novel, however the algorithms that were created to convert the acceleration into a specific action may very well be novel. Again a very interesting topic for discussion..

[df8m1 19]

hackish

Pluggable micro SDs won't tolerate the vibration. There is also no QC, traceability or anything for a corner store micro sd. If you wanted to charge onboard batteries and/or download data then put a sealable micro USB connector on the head unit. On many rigs that would be convenient.
-Michael

I was rereading the thread and must have missed this post.

We have actually been using Micro SD-Cards for several years now with excellent success. I have attached a pic of one prototype with the card in it. It is all black so it is hard to see, but it is there.

I also see you mentioned a USB connector in the interface.. Been there, done that lol.. We can reprogram the AAD and download the data without opening the reserve..

[hackish 8]

Some years ago these were used on model rocketry type stuff but upon impact they would frequently not maintain contact and data would be lost even if the logger continued to operate. In the case of an AAD I think it's important that data be logged even if it impacts with terra firma.

On the topic of open source stuff, one thing I have frequently observed is that commercial enterprises frequently would borrow code and ideas from open source products and projects and use it as a cheap way to develop their own. 99% of intellectual property ownership is obscuring it from theft. The other 1% involves costly litigation.

I'm a little conflicted with those who feel that the high AAD price means they're being denied something they rightfully should have. Y'know there is only a few hundred dollars of fabric in a canopy too...

-Michael

[df8m1 19]

hackish

Some years ago these were used on model rocketry type stuff but upon impact they would frequently not maintain contact and data would be lost even if the logger continued to operate. In the case of an AAD I think it's important that data be logged even if it impacts with terra firma.

On the topic of open source stuff, one thing I have frequently observed is that commercial enterprises frequently would borrow code and ideas from open source products and projects and use it as a cheap way to develop their own. 99% of intellectual property ownership is obscuring it from theft. The other 1% involves costly litigation.

I'm a little conflicted with those who feel that the high AAD price means they're being denied something they rightfully should have. Y'know there is only a few hundred dollars of fabric in a canopy too...

-Michael

That is a good point. We have not seen problem with that, (and we have buried several bundles) Where we have seen issues with data loss at the point of impact, we have traced to a loss of power (the unit shutting down) most likely from the LyPo battery pack we were using in the data recorder.

Rest assured that we will be impact testing all our AADs to make sure there are not any problems from excessive Gs, although as far as the AAD operation is concerned, the data at the point of impact isn't of much help in regards to what happened with in the deployment altitude window.

I too do not understand the philosophy that some jumpers have... I agree with your canopy reference...

Lets see if I can string something together here... You can't jump more than once with out a canopy, and jumping puts the life of the jumper at risk.... an AAD can help reduce that risk, and because a jumper paid $4000 for a container with all the bells and whistles, and 2 canopies, they can't afford the AAD at a price that allows the manufacture to remain in business and support the AAD throughout its life span.

Now given that the AAD manufacturers know how much a new rig costs, (which one can not jump more than once without, and the jumper did pay for somehow), and knowing that the risk to the jumper's life "could" be reduced with an AAD, it could be argued that the AAD manufacturers have decided that profit is more valuable than a jumpers life.

The philosophy of profit over reduced risk would not apply to a canopy specifically, because without a canopy, one can not make more than one jump, or in other words, a jumper needs to buy a canopy in order to put him or her at the very risk that the AAD “could “ reduce. So because a jumper has decided to spend all their money buying the basic equipment required to put themselves at risk, it almost seems predatory that a manufacturer of a product that could reduce some risk would seek a profit from such a device, which they developed and have to support for several years after the sale.

I imagine I have probably offended some, but that was not my intention. I truly am fascinated with different philosophical positions and the reasoning behind them. I had a fantastic conversation with a jumper in another country about mandatory AADs. There is a lot of passion with that subject and the reasoning for ones position (either way) is intriguing to me, and helps me better understand the world I live in.

Not everyone can “argue” a position in a civilized and logical manner, which is unfortunate, and why I think many people get angry or offended. It is very frustrating not being able to convey a thought in a manner that can be understood in the intended context.