ARM, Single-Chip PC, or other architectures for audio stuff?

In aviation there's a situation that happens routinely, when a new design idea emerges in the experimental aircraft community (where what you can fly is only lightly regulated, as long as you don't take passengers), then makes its way into commercial planes. E.g. some new tailfin shape gets tried out and evolved by folks doing stuff by experiment using tools from Home Depot. Later on when the commercial guys want to adopt it, *that's* when the finite element analysis and wind tunnel tests happen. The prior evolution, successful and failed experiments, crash landings, etc. are all forgotten or unknown.

Is it not the case that medical stuff can come from e.g. two radiologists meeting in a bar, complaining about their crappy X-ray machines? They compare the good and bad features of existing machines, including the ones one of them remembers seeing in a visit to the Czech Republic (completely outside FDA purview), then introduce some new ideas of their own, etc. The initial "documentation" is napkin drawings made at the bar, that are lost when they get used to wipe up a spilled drink, but reconstructed afterwards. You get the picture.

Reply to
Paul Rubin
Loading thread data ...

Analogies are dangerous, and obscure as much as they reveal :) Many of the commercial aviation innovations were introduced and proven on gliders/sailplanes - and they definitely use finite element analysis. Two classic examples are composite construction (e.g. glass and carbon fibre) and winglets.

I've also known of cases where aviation companies have tried to patent something that had been used in gliders for decades! Proving prior art consisted merely of taking a photograph!

Graphic illustrations of why FE analysis is necessary during design are:

short:

formatting link

longer, eek at 0:18 to 0:30, then repetitive but beautiful

formatting link

Yup, high performance gliders are higher tech than many light aircraft.

Reply to
Tom Gardner

Of course, they lost an Eta during spin test (pilots bailed out safely)...

FE, spin, and especially flutter analysis on the ground needs confirmation by real world tests, which often show that the analysis techniques are, um, not quite there yet. Real-world testing then requires iterative rework of the models, retest...

May your high-speed passes be safe, Best Regards, Dave "YO"

formatting link

Reply to
Dave Nadler

It can be ok that way if _everything_ gets repeated and tested. Miss one part, assuming it's going to be ok because it always was on the prototype and then something bad happens, the Federales will be all over the place.

"Dr.So-and-so had this idea while we had a beer at the Hardrock Cafe" can be ok but must be followed by a proper review that is documented. After that the design process must be fully controlled.

Can't see either. Since 1-2 weeks I am having trouble loading such videaos. Does anyone know whether AT&T has started censoring this stuff a bit?

And usually have a well-documented and controlled design process.

At my last employer (med tech) we had regular training sessions about this design control stuff. When I hired several aerospace engineers and they attended they later said "Pretty much the same kind of procedures we always followed". It wasn't new to them.

Anyhow, when the time comes for me to look for a programmer to collaborate with then this is a requirement because the project is med tech. Either the programmer adheres to those rules or we will not work together.

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg
[...]

that's not what Tim described, please stay on track.

I can start also from "not well documented work", even things I remember only vaguely etc. as long as I verify it in the design process.

I'm still sure that you are wrong in Message-ID: "I believe that is not legit".

Oliver

--
Oliver Betz, Munich http://oliverbetz.de/
Reply to
Oliver Betz

Quote "Then all the design files (that would never, ever pass FDA inspection) get backed up to a CD and wiped from the network".

That's what I said, as long as you re-verify absolutely everything you can be ok. In reality that is not practical. Engineers usually work under schedule pressure and I have seen time and again where snippets of work from the past were used verbatim. It's a risk. The Therac 25 accidents are a perfect example of the worst case outcome.

I do believe this is not legit. So did the authorities in some cases, one being a large competitor of ours. Again, it does not matter what we think, what matters is what the agency thinks. Because they have the power and also the padlocks.

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

The first sentence above seems to answer the second. You archive the old stuff to CD (i.e. for historical or forensic purposes) and then get it out of the live system, to make sure that the old code doesn't find its way into the new.

Reply to
Paul Rubin

If it truly works, that is. Especially in software there is a tendency to keep all kinds of stuff in various places, including in the gray matter up there in our noggins. As I said before, if the team absolutely positively guarantees that nothing whatsoever is used from that undocumented past project then it's all fine. IME that often isn't guaranteed in practice.

The same applies if you wanted to use an existing commercial product from other markets that has not been designed per FDA rules and redesign it for, say, medical. That is a dicey walk and I can only recommend to have an experienced pilot on board for that. Either an engineer with lots of med devices design under the belt or a hands-on (engineering-type) QA/QC person.

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

I'd be interested in seeing some description of the FDA processes if there's one online. The stuff I've heard about medical software (remote takeovers of pacemakers, etc.) frankly isn't that impressive.

I was just at a drugstore and noticed that a lot of the medical gadgets there (blood pressure monitors, glucose testers, etc) are made overseas, far from FDA scrutiny. I wonder how that type of thing is managed. Maybe the stuff in doctors' offices is different.

Reply to
Paul Rubin

It's a very boring read, just like most bureaucratic paperwork:

formatting link

Software is essentially treated similar to hardware, as it should. They also mention the Therac case I brought up, under Risk Management and Design Controls. Without names but to everyone in the trade it was immediately clear.

In the end much of it is common sense. I have always worked in a similar fashion so not much change for me. One should always think "Would I release this product if my mom would be on the operating table next month and they used this machine?".

I've heard of the pacemaker issues but can't comment without studying in detail. Regardless, just like cops can't be anywhere and the guys with the lowriders keep speeding through the neighborhood there will always be cases in medical where procedures weren't followed. However, just as with the NTSB after an airplane crash, there will be a thorough investigation once a serious incident has happened. And usually consequences.

You'd be surprised how much scrutiny there is. Part of my consulting work is helping foreign companies with agency compliance in the US and US companies with compliance in Europe (partly because I've lived there).

Some gear for household use may not be so critical. However, a glucose tester that constantly reads low or high can become a serious problem. If an importer snuck in a device that didn't pass muster and something happens they may also go after the importer. Or the drugstore.

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

That's actually interesting, but reads more like an informal hints/guideline than a specification. It refers to a bunch of ANSI specs that I haven't looked at though.

It doesn't say much about software, compared to something like CMMI.

Heh, neat. I wouldn't have recognized it but I'm not in that biz.

Basically there's a huge amount of gear in medical and other public safety applications (like power plants) where the developers didn't anticipate the gear being connected to a network and exposed to attackers. It's all designed and programmed with the expectation that only friendly, authorized users would be able to communicate with it. So it's full of security holes, oops. STUXnet was the most famous exploit against this situation, but there's tons of low hanging fruit. Search terms to try are SCADA and security, or pacemaker and security. What's worse, they aren't even allowed to fix the bugs or install updates, so medical devices are overrun with malware:

formatting link

Reply to
Paul Rubin

Or read comp.risks (the newsgroup with the highest SNR of all) or search it at

formatting link

Reply to
Tom Gardner

Guidance != Informal Guideline :-)

It is more a document that explains stuff so we non-bureaucrat guys have a chance to understand what the agency expects from us. Best to adhere to their wishes because the've got the bigger guns and, most of all, because it makes sense.

Software and hardware should not be treated differently too much when it comes to things such as a hazard analysis. They have to be seen in conjunction, something they failed to do in the Therac case.

Then it should not be connected to the outside world. That's like leaving the keys in the new Lincoln when buying something in a supermarket.

Some of this should be taken with a grain of salt, there is a lot of sensationalism going on in that field. Bottomline, if a device is not well enough protected against malicious access its design is flawed. Some of the med devices I have designed parts of are networkable but they are very well protected and I've never heard of a case where someone successfully hacked in. For example, competitors could have a serious motivation to do that, to glean what our software does.

Then there is prosecutable criminal intent. If devices such as implantable defibrillators that can only be controlled from a few feet away are purposely hacked into to harm a patient "just because it's possible" then this is a criminal offense. Just like switching off someone's oxygen generator they drag behind them on a cart would be. Typically you can't hack into someone's implanted device from the far lands of Hackistan or something.

But regardless of all the above, one should protect against illegal access as far as possible. Without hampering necessary access by EMTs, and that is sometimes a problem.

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

I know boardmakers like

formatting link
have 'boilerplate' contracts that shifts the burden of liability onto the medical equipment manufacturer. You may need to get a law firm involved.

Reply to
1 Lucky Texan
[...]

So do I. My consulting agreements also contain a liability waiver and must be signed before I will work for a client. If you do med device and aerospace like I do there is no underwriter in the US that will write a decent insurance policy.

I check out their boards but those look seriously overkill. Up to 25W of power consumption and very powerful, even the small single-core version:

formatting link

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

Gee, that's a lot of power for supposedly low power ARM.

If size is not super critical, get a small laptop motherboard for $30:

formatting link

I am running the 1.6GHz Atom for 10w including the hard drive.

Size: approx. 6" x 10"

Reply to
edward.ming.lee

Size isn't super critical but it should fit in the space of 2-3 cigarette packs, without the power supply. It cannot have more than a few watts of power consumption and definitely no fans.

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

So, you are looking for pocket size PC. The mini 311 board would be too bi g, but the Atom chip could work. The chip draws perhaps 3W to 5W, but you also need supporting chips. Atom needs external memory, perhaps a flash+sd ram stacked die (Micron?). With single memory package, most of the PCB tra ces are between the CPU and memory chip. Of course, you need I/Os and the best way is a PCIe bridge.

Since you mension multiple audio codec (16 to 20) in another thread, i assu me this is what you want to do. You can get an FPGA with PCIe transceiver and hook it up with multiple audio chips. I can see this as a two boards s olution connected with a PCIe connector.

Sacramento is not too far away, but distance is an inverse function of comp ensation. For the right price, i will commute to the moon.

Reply to
edward.ming.lee

A 1st generation Atom is what I am using for this right now. It works nicely but the fan does come on occasionally and we can't have fans in this application. Partially this may be due to the operating system (Windows XP) although according to the performance monitor that does not take much in processor resources.

Thios is a case that is more geared towards a very low horsepower single-chip PC or ARM. A DSP could do it as well but there you often have similar issues as with the PC architecture, a lack of integrated peripherals.

That one is a totally different project.

Same here :-)

But this project really requires someone who lives here. Where we can quickly get together at the spur of them moment even after weeks of silence because of other tests.

How does one go about finding local experts without getting burned? For example, right now I am looking for an ATMega expert in the Houston area (and at some point possibly east of Sarcamento as well) who is good at finding bugs in existing code.

--
Regards, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

I am running Linux on the 1.6GHz Atom. There is no fan on this laptop. In fact, this is the coolest laptop i have seen. The hp mini 311 came with a poorly supported broadcom Wifi, but i replaced it with an Atherons Wifi. Everything else works out of the tar balls. Linux Mint works as well as Wi n 7, with the exception of suspend mode. My HP 311/Mint draws much less po wer active, but Fujisu 2010/Win 7 (my other laptop) can suspend forever (ju st close the lid). The Linux kernel might not be supporting suspend mode f or Atom properly.

You might need high performance burst occasionally, but low horsepower on a verage. Linux/Atom would be ideal in this case.

Reply to
edward.ming.lee

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.