Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #29764 > unrolled thread

Group Design

Back to article view | Back to comp.arch.embedded

Contents

  Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-07 18:46 -0700
    Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-07-07 19:02 -0700
      Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-07 20:36 -0700
        Re: Group Design David Brown <david.brown@hesbynett.no> - 2020-07-08 09:31 +0200
          Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 07:08 -0700
    Re: Group Design Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-07-08 14:13 +0200
      Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 07:19 -0700
        Re: Group Design Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-07-08 18:57 +0200
          Re: Group Design Theo <theom+news@chiark.greenend.org.uk> - 2020-07-08 18:28 +0100
          Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 11:12 -0700
            Re: Group Design Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-07-08 23:34 +0200
              Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 15:20 -0700
                Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-07-08 23:00 -0700
                Re: Group Design Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-07-10 10:09 +0200
                Re: Group Design Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-08-07 00:01 +0100
                  Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-06 17:37 -0700
                    Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-08-07 03:06 -0700
                  Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-06 21:50 -0400
                    Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-06 19:12 -0700
                      Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-06 22:27 -0400
                        Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-06 19:36 -0700
                          Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-06 23:39 -0400
                    Re: Group Design Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-08-07 12:30 +0100
                      Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-07 09:57 -0400
                        Re: Group Design Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-08-08 00:37 +0100
                          Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-07 20:29 -0400
                          Re: Group Design upsidedown@downunder.com - 2020-08-08 08:59 +0300
                          Re: Group Design David Brown <david.brown@hesbynett.no> - 2020-08-10 15:43 +0200
                            Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-10 09:18 -0700
                      Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-07 07:12 -0700
                        Re: Group Design Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-08-08 00:00 +0100
                          Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-07 20:30 -0400
                            Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-07 17:57 -0700
                          Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-07 17:56 -0700
                        Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-08-07 18:10 -0700
                          Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-07 19:43 -0700
                      Re: Group Design Dimiter_Popoff <dp@tgi-sci.com> - 2020-08-07 20:42 +0300
                        Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-07 13:48 -0700
        Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-07-08 14:11 -0700
        Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-07-09 04:25 -0400
          Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 11:37 -0700
            Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-07-09 11:54 -0700
            Re: Group Design Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-07-09 20:02 +0100
            Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-07-09 15:31 -0400
              Re: Group Design lasselangwadtchristensen@gmail.com - 2020-07-09 15:36 -0700
                Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 18:36 -0700
                  Re: Group Design Clifford Heath <no.spam@please.net> - 2020-07-10 16:17 +1000
                    Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 23:36 -0700
                      Re: Group Design Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-07-10 10:22 +0200
        Re: Group Design David Brown <david.brown@hesbynett.no> - 2020-07-09 14:40 +0200
    Re: Group Design John Speth <johnspeth@yahoo.com> - 2020-07-09 07:59 -0700
    Re: Group Design Don Y <blockedofcourse@foo.invalid> - 2020-07-09 18:33 -0700
      Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 19:01 -0700
        Re: Group Design Don Y <blockedofcourse@foo.invalid> - 2020-07-09 22:32 -0700
        Re: Group Design George Neuner <gneuner2@comcast.net> - 2020-07-10 17:36 -0400
          Re: Group Design Ed Prochak <edprochak@gmail.com> - 2020-07-14 11:09 -0700
            Re: Group Design George Neuner <gneuner2@comcast.net> - 2020-07-16 00:26 -0400
    Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 22:48 -0700
      Re: Group Design Don Y <blockedofcourse@foo.invalid> - 2020-07-09 23:53 -0700
        Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-10 01:15 -0700
          Re: Group Design Don Y <blockedofcourse@foo.invalid> - 2020-07-10 02:22 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#29764 — Group Design

Wow!  Designing in a group is strange.  I'm helping with the design of a ventilator and it is a unique experience.  We have people of many skill levels and talents, many I don't even know.  The design seems to ping pong around based on the hot button issue of the day.  They already have someone to do board level design, but he has a day job, so the work gets done a bit helter skelter.  I mostly try to identify potential bugs.  

Most of the people are in the UK with a couple in the EU.  I'm in the US along with one other person.  

We have semiweekly meetings on zoom or other sites.  There is no strong organization.  

I'm surprised as much is getting done as it has been.  The original design used an Arduino and once the lack of I/Os became a hindrance we are switching to an ARM, but nothing remotely like a proper spec was generated and the processor initially picked is now out of pins.  The first rev of the main board has many issues including the isolation of the heat sink tabs by thermal relief connections.  

I literally have no idea how they are ever going to get this thing past any sort of approval process.  No one working on the project even seems to understand what is required.  

I guess I'm a bit frustrated by the lack of organization.  I'd like to step away, but the person acting as a leader seems to want me in the group.  

There is some work of my own I should do, so maybe I'll stick around to get to rev 2 of the board and then step out.  

I guess I'm used to working on my own. 

-- 

  Rick C.

  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209

[toc] | [next] | [standalone]

#29765

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> Wow!  Designing in a group is strange.  I'm helping with the design of
> a ventilator and it is a unique experience.

Sounds like fun, but why a ventilator?  Is the ventilator shortage still
happening and are there more urgent shortages?  I thought there were
already a bunch of ventilator projects.

What is the software going to be like, and is it being taken care of?
This sounds like a good opportunity to write some Ada code.

[toc] | [prev] | [next] | [standalone]

#29766

On Tuesday, July 7, 2020 at 10:02:45 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.deletethisbit@gmail.com> writes:
> > Wow!  Designing in a group is strange.  I'm helping with the design of
> > a ventilator and it is a unique experience.
> 
> Sounds like fun, but why a ventilator?  Is the ventilator shortage still
> happening and are there more urgent shortages?  I thought there were
> already a bunch of ventilator projects.
> 
> What is the software going to be like, and is it being taken care of?
> This sounds like a good opportunity to write some Ada code.

Yeah, that was one of my first observations that there are tons of ventilator projects.  They nearly all are based on squeezing an Ambu-bag to push air into the patient.  The details of not harming the patient are tricky.  Ventilating a patient while conscious is harder and very few are doing that.  They seem to be having problems with the plumbing at the moment, getting all the right valves in the right places to do the right things.  At the moment there is a lot of hardware right at the patient's mouth.  I'm working to understand what is needed and what isn't.  

There's a valve called a Ruben valve which allows the patient to be connected to the inspiratory limb (branch from the ventilator) or to the expiratory limb (the path for exhaling) without a leak to the outside via a straight through path.  It's not entirely clear just how the details of this valve work.  I have concerns that the valve can be stuck in the inhale position by the pressure in the line.  It doesn't seem to have a way to leak out once pressurized.  

I'm not sure the software is too hard at the higher levels, but there are interface procedures that have to convert differential pressure to flow rate and monitor other marginal sensors.  The O2 sensor is only ~18% accurate.  The guy running the project doesn't seem to understand the difference between accuracy, resolution and noise when we were talking about increasing the resolution of a reading by averaging many samples.  Not that this was a big deal.  The real issue is I'm not sure improving the resolution of the measurement will give him what he wants.  The airflow measurement is very sensitive at the low end.  I'm wondering if there is an issue with the flow being more or less laminar at the low end so that it is not going to be an accurate reading.  The interesting part is they  verified the home brew flow rate sensor by using a commercial flow rate sensor that uses the same technique.  

Whatever.  I'm trying to help without being a drag.  I think sometimes my questions are not what they want to hear.  Maybe I'm too pessimistic.  

The software is C I believe.  I don't think anyone in this crowd is going to use Ada. 

-- 

  Rick C.

  + Get 1,000 miles of free Supercharging
  + Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#29771

On 08/07/2020 05:36, Rick C wrote:
> On Tuesday, July 7, 2020 at 10:02:45 PM UTC-4, Paul Rubin wrote:
>> Rick C <gnuarm.deletethisbit@gmail.com> writes:
>>> Wow!  Designing in a group is strange.  I'm helping with the
>>> design of a ventilator and it is a unique experience.
>> 
>> Sounds like fun, but why a ventilator?  Is the ventilator shortage
>> still happening and are there more urgent shortages?  I thought
>> there were already a bunch of ventilator projects.
>> 
>> What is the software going to be like, and is it being taken care
>> of? This sounds like a good opportunity to write some Ada code.
> 
> Yeah, that was one of my first observations that there are tons of
> ventilator projects.  They nearly all are based on squeezing an
> Ambu-bag to push air into the patient.  The details of not harming
> the patient are tricky.  Ventilating a patient while conscious is
> harder and very few are doing that.  They seem to be having problems
> with the plumbing at the moment, getting all the right valves in the
> right places to do the right things.  At the moment there is a lot of
> hardware right at the patient's mouth.  I'm working to understand
> what is needed and what isn't.
> 
> There's a valve called a Ruben valve which allows the patient to be
> connected to the inspiratory limb (branch from the ventilator) or to
> the expiratory limb (the path for exhaling) without a leak to the
> outside via a straight through path.  It's not entirely clear just
> how the details of this valve work.  I have concerns that the valve
> can be stuck in the inhale position by the pressure in the line.  It
> doesn't seem to have a way to leak out once pressurized.
> 
> I'm not sure the software is too hard at the higher levels, but there
> are interface procedures that have to convert differential pressure
> to flow rate and monitor other marginal sensors.  The O2 sensor is
> only ~18% accurate.  The guy running the project doesn't seem to
> understand the difference between accuracy, resolution and noise when
> we were talking about increasing the resolution of a reading by
> averaging many samples.  Not that this was a big deal.  The real
> issue is I'm not sure improving the resolution of the measurement
> will give him what he wants.  The airflow measurement is very
> sensitive at the low end.  I'm wondering if there is an issue with
> the flow being more or less laminar at the low end so that it is not
> going to be an accurate reading.  The interesting part is they
> verified the home brew flow rate sensor by using a commercial flow
> rate sensor that uses the same technique.
> 
> Whatever.  I'm trying to help without being a drag.  I think
> sometimes my questions are not what they want to hear.  Maybe I'm too
> pessimistic.
> 
> The software is C I believe.  I don't think anyone in this crowd is
> going to use Ada.
> 

It sounds like this group is opportunist (I don't mean that in a bad
way) - they see a potential market for a device, with a short time
frame, and they are trying to get something working as fast as possible
before the window closes.  So they grab the first off-the-shelf "rapid"
development kit they can find - an Arduino - and start banging out code
before they've even figured out what they want to do.

For some products, that's fine.  For something medical related, it is
not.  They appear (from your description) to be missing a fundamental
understanding of the task, and haven't got in experts to cover that
base.  And without paperwork covering everything from research, design
calculations, specifications (hardware and software), reviews, project
management, issue tracking, personnel qualifications, development,
testing, certification, production qualification, and a dozen other
topics, there is no way they can get any kind of approval.

I would guess that the group is used to small systems for small
customers who are happy with a demonstration that shows the device
works.  That's great for many things, and gives people solutions that
work when a serious high-level development process would be orders of
magnitude too expensive.

But making things that are relevant to life and death is a different
world entirely.  Some people think that the current Covid situation is
so desperate that /anything/ is better than nothing, so throwing
together a cheap and simple ventilator is helpful - that is very far
from true.

So I hope you get paid up-front, and keep your distance from the group -
be an external consultant, but don't take responsibility for anything
other than your reviews.

(And the choice of language for the software is the least of their
concerns!)

[toc] | [prev] | [next] | [standalone]

#29780

On Wednesday, July 8, 2020 at 3:31:55 AM UTC-4, David Brown wrote:
> On 08/07/2020 05:36, Rick C wrote:
> > On Tuesday, July 7, 2020 at 10:02:45 PM UTC-4, Paul Rubin wrote:
> >> Rick C <gnuarm.deletethisbit@gmail.com> writes:
> >>> Wow!  Designing in a group is strange.  I'm helping with the
> >>> design of a ventilator and it is a unique experience.
> >> 
> >> Sounds like fun, but why a ventilator?  Is the ventilator shortage
> >> still happening and are there more urgent shortages?  I thought
> >> there were already a bunch of ventilator projects.
> >> 
> >> What is the software going to be like, and is it being taken care
> >> of? This sounds like a good opportunity to write some Ada code.
> > 
> > Yeah, that was one of my first observations that there are tons of
> > ventilator projects.  They nearly all are based on squeezing an
> > Ambu-bag to push air into the patient.  The details of not harming
> > the patient are tricky.  Ventilating a patient while conscious is
> > harder and very few are doing that.  They seem to be having problems
> > with the plumbing at the moment, getting all the right valves in the
> > right places to do the right things.  At the moment there is a lot of
> > hardware right at the patient's mouth.  I'm working to understand
> > what is needed and what isn't.
> > 
> > There's a valve called a Ruben valve which allows the patient to be
> > connected to the inspiratory limb (branch from the ventilator) or to
> > the expiratory limb (the path for exhaling) without a leak to the
> > outside via a straight through path.  It's not entirely clear just
> > how the details of this valve work.  I have concerns that the valve
> > can be stuck in the inhale position by the pressure in the line.  It
> > doesn't seem to have a way to leak out once pressurized.
> > 
> > I'm not sure the software is too hard at the higher levels, but there
> > are interface procedures that have to convert differential pressure
> > to flow rate and monitor other marginal sensors.  The O2 sensor is
> > only ~18% accurate.  The guy running the project doesn't seem to
> > understand the difference between accuracy, resolution and noise when
> > we were talking about increasing the resolution of a reading by
> > averaging many samples.  Not that this was a big deal.  The real
> > issue is I'm not sure improving the resolution of the measurement
> > will give him what he wants.  The airflow measurement is very
> > sensitive at the low end.  I'm wondering if there is an issue with
> > the flow being more or less laminar at the low end so that it is not
> > going to be an accurate reading.  The interesting part is they
> > verified the home brew flow rate sensor by using a commercial flow
> > rate sensor that uses the same technique.
> > 
> > Whatever.  I'm trying to help without being a drag.  I think
> > sometimes my questions are not what they want to hear.  Maybe I'm too
> > pessimistic.
> > 
> > The software is C I believe.  I don't think anyone in this crowd is
> > going to use Ada.
> > 
> 
> It sounds like this group is opportunist (I don't mean that in a bad
> way) - they see a potential market for a device, with a short time
> frame, and they are trying to get something working as fast as possible
> before the window closes.  So they grab the first off-the-shelf "rapid"
> development kit they can find - an Arduino - and start banging out code
> before they've even figured out what they want to do.
> 
> For some products, that's fine.  For something medical related, it is
> not.  They appear (from your description) to be missing a fundamental
> understanding of the task, and haven't got in experts to cover that
> base.  And without paperwork covering everything from research, design
> calculations, specifications (hardware and software), reviews, project
> management, issue tracking, personnel qualifications, development,
> testing, certification, production qualification, and a dozen other
> topics, there is no way they can get any kind of approval.
> 
> I would guess that the group is used to small systems for small
> customers who are happy with a demonstration that shows the device
> works.  That's great for many things, and gives people solutions that
> work when a serious high-level development process would be orders of
> magnitude too expensive.
> 
> But making things that are relevant to life and death is a different
> world entirely.  Some people think that the current Covid situation is
> so desperate that /anything/ is better than nothing, so throwing
> together a cheap and simple ventilator is helpful - that is very far
> from true.
> 
> So I hope you get paid up-front, and keep your distance from the group -
> be an external consultant, but don't take responsibility for anything
> other than your reviews.
> 
> (And the choice of language for the software is the least of their
> concerns!)

Pay???  This is open source, volunteer labor.  They have a few companies donating fabrication services.  A sheet metal shop fabricated a few chassis.  I think they may even have a Chinese assembly house donating some board assembly work.  

I started on a different project which was doing a very similar thing and I questioned the need for yet another project.  In the end the guy leading that effort bailed and the group decided to merge with this project that was further along.  

I think I feel awkward because I don't have a defined roll.  It is hard for me to tell if/when my comments are welcome and when they are kibitzing.  

-- 

  Rick C.

  -- Get 1,000 miles of free Supercharging
  -- Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#29776

On 2020-07-08 Rick C wrote in comp.arch.embedded:
> Wow!  Designing in a group is strange.  I'm helping with the design of a ventilator and it is a unique experience.  We have people of many skill levels and talents, many I don't even know.

That is the good part of designing with a group. You can have many more talents
and skills than can be combined in a single person. For a medical product like
this you need medical, software, hardware, mechanical and lots more skills. Not
something that can be found in one person very often.

<snip, some project frustrations etc.>

> I literally have no idea how they are ever going to get this thing past any sort of approval process.  No one working on the project even seems to understand what is required.  
>

This is very worrying. As David already explained, documentation and approval
is a very large part of medical device development. There is this famous
Boeing quote about the weight of the paperwork required for a plane. I think
you can extend this to medical devices as well.

Did they at least have a look at some standards that apply to ventilators to
check what will be required? I would start off with IEC 60601-1, IEC 62304
and ISO 80601-2-12, make sure you use the latest versions. But there will be
more.

And this should have been done before the first schematic was drawn or line
of code was written. Some standards put requirements on the development
process and you can not comply with those if you start your certification
efforts after the development is completed.


> I guess I'm a bit frustrated by the lack of organization.  I'd like to step away, but the person acting as a leader seems to want me in the group.  
>
> There is some work of my own I should do, so maybe I'll stick around to get to rev 2 of the board and then step out.  
>

If there has indeed been done nothing on the certification side, my feeling
would be to step away as well.


> I guess I'm used to working on my own. 
>

Yes, than all is in your own hands. ;-)

But the advantage of a team is that you can concentrate on what you are good
at and let others do what they are good at. And if the team is diverse and
skilled enough (and properly led) the end result will be better that that of
a single developer.

And I think a lot of medical device stuff can not be done by a single
person. There are many cases where you need an (expert) reviewer in the
process. Reviewing your own work is less than optimal. ;-)


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

It seems that more and more mathematicians are using a new, high level
language named "research student".

[toc] | [prev] | [next] | [standalone]

#29781

On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote:
> On 2020-07-08 Rick C wrote in comp.arch.embedded:
> > Wow!  Designing in a group is strange.  I'm helping with the design of a ventilator and it is a unique experience.  We have people of many skill levels and talents, many I don't even know.
> 
> That is the good part of designing with a group. You can have many more talents
> and skills than can be combined in a single person. For a medical product like
> this you need medical, software, hardware, mechanical and lots more skills. Not
> something that can be found in one person very often.
> 
> <snip, some project frustrations etc.>
> 
> > I literally have no idea how they are ever going to get this thing past any sort of approval process.  No one working on the project even seems to understand what is required.  
> >
> 
> This is very worrying. As David already explained, documentation and approval
> is a very large part of medical device development. There is this famous
> Boeing quote about the weight of the paperwork required for a plane. I think
> you can extend this to medical devices as well.
> 
> Did they at least have a look at some standards that apply to ventilators to
> check what will be required? I would start off with IEC 60601-1, IEC 62304
> and ISO 80601-2-12, make sure you use the latest versions. But there will be
> more.
> 
> And this should have been done before the first schematic was drawn or line
> of code was written. Some standards put requirements on the development
> process and you can not comply with those if you start your certification
> efforts after the development is completed.
> 
> 
> > I guess I'm a bit frustrated by the lack of organization.  I'd like to step away, but the person acting as a leader seems to want me in the group.  
> >
> > There is some work of my own I should do, so maybe I'll stick around to get to rev 2 of the board and then step out.  
> >
> 
> If there has indeed been done nothing on the certification side, my feeling
> would be to step away as well.
> 
> 
> > I guess I'm used to working on my own. 
> >
> 
> Yes, than all is in your own hands. ;-)
> 
> But the advantage of a team is that you can concentrate on what you are good
> at and let others do what they are good at. And if the team is diverse and
> skilled enough (and properly led) the end result will be better that that of
> a single developer.
> 
> And I think a lot of medical device stuff can not be done by a single
> person. There are many cases where you need an (expert) reviewer in the
> process. Reviewing your own work is less than optimal. ;-)

It seems the UK has an abbreviated set of requirements for response to COVID-19 and that is what they are mostly working with.  I forget the name of it.  

They do get advice from time to time from professionals in the field.  My main concern is a direction they are currently going in where more and more valves, pressure relief, etc. is being added to the tubing right at the patient.  I'm not sure how it all will be held in place.  That and how they plan to get this through the approval process.  

I had a friend who worked on medical devices for a while before getting out.  He said they required that you "prove" your design will not hurt the patient in any way.  Hard to do with a ventilator.  

I don't mind working on the team.  It's seeing them go in odd directions that bugs me.  This thing will probably cost hundreds of dollars in the final BOM without anything like profit or overhead added in.  People were arguing against adding $0.10 for more pins on a processor.  Then later they decided to not only go with the larger pin count, but bump from an 8 bit AVR to an ARM CM4F adding several dollars.  That sort of inconsistency drives me nuts.  "Every dollar counts!"  Yes it does, so you need to justify the cost *rationally*.  

-- 

  Rick C.

  -+ Get 1,000 miles of free Supercharging
  -+ Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#29785

On 2020-07-08 Rick C wrote in comp.arch.embedded:
> On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote:
>> On 2020-07-08 Rick C wrote in comp.arch.embedded:
>> > Wow!  Designing in a group is strange.  I'm helping with the design of a ventilator and it is a unique experience.  We have people of many skill levels and talents, many I don't even know.
>> 
[...]

[Is there a way you could limit your line length to a more usenet friendly
number?]

> It seems the UK has an abbreviated set of requirements for response to COVID-19 and that is what they are mostly working with.  I forget the name of it.  

How long will this last? If you look at the new cases curves, the UK is well
over the initial peak. https://www.nytimes.com/ has nice graphs of world
cases on the front page.

>
> They do get advice from time to time from professionals in the field.  My main concern is a direction they are currently going in where more and more valves, pressure relief, etc. is being added to the tubing right at the patient.  I'm not sure how it all will be held in place.  That and how they plan to get this through the approval process.  
>

Sounds like they are moving to more and more features instead of sticking to a
simple emergency use device. Feature creep is not uncommon when getting advise
from several medical professionals. ;-)


> I had a friend who worked on medical devices for a while before getting out.  He said they required that you "prove" your design will not hurt the patient in any way.  Hard to do with a ventilator.  
>

That is not entirely true, it is more a risk/benefit analysis. Otherwise you
could not even get a scalpel approved, it will always hurt the patient.

> I don't mind working on the team.  It's seeing them go in odd directions that bugs me.  This thing will probably cost hundreds of dollars in the final BOM without anything like profit or overhead added in.  People were arguing against adding $0.10 for more pins on a processor.  Then later they decided to not only go with the larger pin count, but bump from an 8 bit AVR to an ARM CM4F adding several dollars.  That sort of inconsistency drives me nuts.  "Every dollar counts!"  Yes it does, so you need to justify the cost *rationally*.  
>

Does every dollar count in this case? If this is for solving short term
ventilator shortages, should development speed not count more than dollars?

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

A national debt, if it is not excessive, will be to us a national blessing.
		-- Alexander Hamilton

[toc] | [prev] | [next] | [standalone]

#29786

Stef <stef33d@yahooi-n-v-a-l-i-d.com.invalid> wrote:
> On 2020-07-08 Rick C wrote in comp.arch.embedded:
> > It seems the UK has an abbreviated set of requirements for response to
> > COVID-19 and that is what they are mostly working with.  I forget the
> > name of it.
> 
> How long will this last? If you look at the new cases curves, the UK is well
> over the initial peak. https://www.nytimes.com/ has nice graphs of world
> cases on the front page.

I think the UK competition is over:
https://www.gov.uk/government/news/ventilator-challenge-hailed-a-success-as-uk-production-finishes

Demand from the rest of the world is a different, unclear, question...

Theo

[toc] | [prev] | [next] | [standalone]

#29787

On Wednesday, July 8, 2020 at 1:00:04 PM UTC-4, Stef wrote:
> On 2020-07-08 Rick C wrote in comp.arch.embedded:
> > On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote:
> >> On 2020-07-08 Rick C wrote in comp.arch.embedded:
> >> > Wow!  Designing in a group is strange.  I'm helping with the design of a ventilator and it is a unique experience.  We have people of many skill levels and talents, many I don't even know.
> >> 
> [...]
> 
> [Is there a way you could limit your line length to a more usenet friendly
> number?]

Not without copying messages to some other editor and then pasting back into Google groups.  I know there is a spec for this, but I've switched newsreaders several times over the years and I'm just tired of trying to find tools that last the test of time.  So I've settled for ease of use over strict adherence to the spec.  

Why is your newsreader intolerant of longer line length?  


> > It seems the UK has an abbreviated set of requirements for response to COVID-19 and that is what they are mostly working with.  I forget the name of it.  
> 
> How long will this last? If you look at the new cases curves, the UK is well
> over the initial peak. https://www.nytimes.com/ has nice graphs of world
> cases on the front page.

As was the case for much of the US... until they started to open things up again.  My crystal ball is not working so well these days.  Seems it needs a lubricant that is also used in making protective gear and is in short supply. 


> > They do get advice from time to time from professionals in the field.  My main concern is a direction they are currently going in where more and more valves, pressure relief, etc. is being added to the tubing right at the patient.  I'm not sure how it all will be held in place.  That and how they plan to get this through the approval process.  
> >
> 
> Sounds like they are moving to more and more features instead of sticking to a
> simple emergency use device. Feature creep is not uncommon when getting advise
> from several medical professionals. ;-)

Don't know about "more and more" or "feature creep".  They are responding to the issue that virtually every other piece of gear is doing the same limited job of ventilating an unconscious patient because it is easier.  Kennedy promoted the space race to the moon "not because it is easy, but because it is hard".  So why not take on the harder task of being not just more useful, but safer.  I don't recall all the terms, but when the patient is only assisted in breathing there is less risk of harm from use of the machine.  So this is not just a less often implemented feature, it is an important feature.  

In particular, it was in a conversation with a medical professional that this need was pointed out. 


> > I had a friend who worked on medical devices for a while before getting out.  He said they required that you "prove" your design will not hurt the patient in any way.  Hard to do with a ventilator.  
> >
> 
> That is not entirely true, it is more a risk/benefit analysis. Otherwise you
> could not even get a scalpel approved, it will always hurt the patient.

That is a bogus comparison.  So nothing to discuss there. 


> > I don't mind working on the team.  It's seeing them go in odd directions that bugs me.  This thing will probably cost hundreds of dollars in the final BOM without anything like profit or overhead added in.  People were arguing against adding $0.10 for more pins on a processor.  Then later they decided to not only go with the larger pin count, but bump from an 8 bit AVR to an ARM CM4F adding several dollars.  That sort of inconsistency drives me nuts.  "Every dollar counts!"  Yes it does, so you need to justify the cost *rationally*.  
> >
> 
> Does every dollar count in this case? If this is for solving short term
> ventilator shortages, should development speed not count more than dollars?

It's not about rushing to the finish line for sure.  None of the goals are clearly stated.  That's my point.  

We meet using video tools and Zoom seems to work the best.  I have various latency and bandwidth issues and was not able to participate yesterday.  That's really frustrating, especially when everyone is missing an important point.  Today we had a one on one to test Google Meet and compare to Zoom (Google was a second runner).  So I had a chance to make clear what is and is not a problem in the plumbing.  Understanding what I was saying he agreed so the plumbing next to the patient is less cumbersome now.  

Maybe more 1 on 1s will help. 

-- 

  Rick C.

  +- Get 1,000 miles of free Supercharging
  +- Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#29789

On 2020-07-08 Rick C wrote in comp.arch.embedded:
> On Wednesday, July 8, 2020 at 1:00:04 PM UTC-4, Stef wrote:
>> On 2020-07-08 Rick C wrote in comp.arch.embedded:
>> > On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote:
>> >> On 2020-07-08 Rick C wrote in comp.arch.embedded:
>> >> > Wow!  Designing in a group is strange.  I'm helping with the design of a ventilator and it is a unique experience.  We have people of many skill levels and talents, many I don't even know.
>> >> 
>> [...]
>> 
>> [Is there a way you could limit your line length to a more usenet friendly
>> number?]
>
> Not without copying messages to some other editor and then pasting back into Google groups.  I know there is a spec for this, but I've switched newsreaders several times over the years and I'm just tired of trying to find tools that last the test of time.  So I've settled for ease of use over strict adherence to the spec.  
>
> Why is your newsreader intolerant of longer line length?  
>
Slrn may be a bit ancient, but so is usenet. ;-)
Slrn can handle long lines, but after quoting it does not wrap them anymore,
so I need to shift the screen to view the entire line. Luckily the editor for
replying does still wrap those. But hey, it's a minor inconvenience, just
asking.

>
>> > It seems the UK has an abbreviated set of requirements for response to COVID-19 and that is what they are mostly working with.  I forget the name of it.  
>> 
>> How long will this last? If you look at the new cases curves, the UK is well
>> over the initial peak. https://www.nytimes.com/ has nice graphs of world
>> cases on the front page.
>
> As was the case for much of the US... until they started to open things up again.  My crystal ball is not working so well these days.  Seems it needs a lubricant that is also used in making protective gear and is in short supply. 
>
>
>> > They do get advice from time to time from professionals in the field.  My main concern is a direction they are currently going in where more and more valves, pressure relief, etc. is being added to the tubing right at the patient.  I'm not sure how it all will be held in place.  That and how they plan to get this through the approval process.  
>> >
>> 
>> Sounds like they are moving to more and more features instead of sticking to a
>> simple emergency use device. Feature creep is not uncommon when getting advise
>> from several medical professionals. ;-)
>
> Don't know about "more and more" or "feature creep".  They are responding to the issue that virtually every other piece of gear is doing the same limited job of ventilating an unconscious patient because it is easier.  Kennedy promoted the space race to the moon "not because it is easy, but because it is hard".  So why not take on the harder task of being not just more useful, but safer.  I don't recall all the terms, but when the patient is only assisted in breathing there is less risk of harm from use of the machine.  So this is not just a less often implemented feature, it is an important feature.  
>
> In particular, it was in a conversation with a medical professional that this need was pointed out. 

So the aim is to create a new type of ventilator, not to cope with immediate
shortages? This is very big task indeed. This sort of thing usually takes
years of development and and clinical testing. They have certainly gone for
"not easy, but hard".

>
>> > I had a friend who worked on medical devices for a while before getting out.  He said they required that you "prove" your design will not hurt the patient in any way.  Hard to do with a ventilator.  
>> >
>> 
>> That is not entirely true, it is more a risk/benefit analysis. Otherwise you
>> could not even get a scalpel approved, it will always hurt the patient.
>
> That is a bogus comparison.  So nothing to discuss there. 

I don't agree. ;-)
The scalpel example is a bit extreme of course. But for every medical 
device there wil be a risk/benefit analysis. There are medical devices
that do some harm to a patient, but as long as the benefits outweigh
the harm it may still be a good thing to use those devices.

A ventilator is never good for your lungs, so it will do some damage,
the aim is to keep the damage as minimal as possible and as short term
as possible.

>
>> > I don't mind working on the team.  It's seeing them go in odd directions that bugs me.  This thing will probably cost hundreds of dollars in the final BOM without anything like profit or overhead added in.  People were arguing against adding $0.10 for more pins on a processor.  Then later they decided to not only go with the larger pin count, but bump from an 8 bit AVR to an ARM CM4F adding several dollars.  That sort of inconsistency drives me nuts.  "Every dollar counts!"  Yes it does, so you need to justify the cost *rationally*.  
>> >
>> 
>> Does every dollar count in this case? If this is for solving short term
>> ventilator shortages, should development speed not count more than dollars?
>
> It's not about rushing to the finish line for sure.  None of the goals are clearly stated.  That's my point.  

Well, get that point across and try to get the goals clear before
proceeding.

> We meet using video tools and Zoom seems to work the best.  I have various latency and bandwidth issues and was not able to participate yesterday.  That's really frustrating, especially when everyone is missing an important point.  Today we had a one on one to test Google Meet and compare to Zoom (Google was a second runner).  So I had a chance to make clear what is and is not a problem in the plumbing.  Understanding what I was saying he agreed so the plumbing next to the patient is less cumbersome now.  
>
> Maybe more 1 on 1s will help. 

Good luck.

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

root rot

[toc] | [prev] | [next] | [standalone]

#29790

On Wednesday, July 8, 2020 at 5:35:53 PM UTC-4, Stef wrote:
> On 2020-07-08 Rick C wrote in comp.arch.embedded:
> > On Wednesday, July 8, 2020 at 1:00:04 PM UTC-4, Stef wrote:
> >> On 2020-07-08 Rick C wrote in comp.arch.embedded:
> >> > On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote:
> >> >> On 2020-07-08 Rick C wrote in comp.arch.embedded:
> >> >> > Wow!  Designing in a group is strange.  I'm helping with the design of a ventilator and it is a unique experience.  We have people of many skill levels and talents, many I don't even know.
> >> >> 
> >> [...]
> >> 
> >> [Is there a way you could limit your line length to a more usenet friendly
> >> number?]
> >
> > Not without copying messages to some other editor and then pasting back into Google groups.  I know there is a spec for this, but I've switched newsreaders several times over the years and I'm just tired of trying to find tools that last the test of time.  So I've settled for ease of use over strict adherence to the spec.  
> >
> > Why is your newsreader intolerant of longer line length?  
> >
> Slrn may be a bit ancient, but so is usenet. ;-)
> Slrn can handle long lines, but after quoting it does not wrap them anymore,
> so I need to shift the screen to view the entire line. Luckily the editor for
> replying does still wrap those. But hey, it's a minor inconvenience, just
> asking.

I wish Google was amenable to requests regarding their software.  As far as I can tell they ignore any feedback and happily ignore rules for newsgroups as if they invented them.  I think it was Al Gore who invented the Internet, no?  So we can blame him perhaps for giving Google a license to drive on the cyber-highway. 

Thanks for understanding. 


> >> > It seems the UK has an abbreviated set of requirements for response to COVID-19 and that is what they are mostly working with.  I forget the name of it.  
> >> 
> >> How long will this last? If you look at the new cases curves, the UK is well
> >> over the initial peak. https://www.nytimes.com/ has nice graphs of world
> >> cases on the front page.
> >
> > As was the case for much of the US... until they started to open things up again.  My crystal ball is not working so well these days.  Seems it needs a lubricant that is also used in making protective gear and is in short supply. 
> >
> >
> >> > They do get advice from time to time from professionals in the field.  My main concern is a direction they are currently going in where more and more valves, pressure relief, etc. is being added to the tubing right at the patient.  I'm not sure how it all will be held in place.  That and how they plan to get this through the approval process.  
> >> >
> >> 
> >> Sounds like they are moving to more and more features instead of sticking to a
> >> simple emergency use device. Feature creep is not uncommon when getting advise
> >> from several medical professionals. ;-)
> >
> > Don't know about "more and more" or "feature creep".  They are responding to the issue that virtually every other piece of gear is doing the same limited job of ventilating an unconscious patient because it is easier.  Kennedy promoted the space race to the moon "not because it is easy, but because it is hard".  So why not take on the harder task of being not just more useful, but safer.  I don't recall all the terms, but when the patient is only assisted in breathing there is less risk of harm from use of the machine.  So this is not just a less often implemented feature, it is an important feature.  
> >
> > In particular, it was in a conversation with a medical professional that this need was pointed out. 
> 
> So the aim is to create a new type of ventilator, not to cope with immediate
> shortages? This is very big task indeed. This sort of thing usually takes
> years of development and and clinical testing. They have certainly gone for
> "not easy, but hard".

I would not say "a new type".  This is what commercial vents do.  But being the hard part, most of the quick turn projects leave it out.  I expect it will be the hardest to get approvals for too.  


> >> > I had a friend who worked on medical devices for a while before getting out.  He said they required that you "prove" your design will not hurt the patient in any way.  Hard to do with a ventilator.  
> >> >
> >> 
> >> That is not entirely true, it is more a risk/benefit analysis. Otherwise you
> >> could not even get a scalpel approved, it will always hurt the patient.
> >
> > That is a bogus comparison.  So nothing to discuss there. 
> 
> I don't agree. ;-)
> The scalpel example is a bit extreme of course. But for every medical 
> device there wil be a risk/benefit analysis. There are medical devices
> that do some harm to a patient, but as long as the benefits outweigh
> the harm it may still be a good thing to use those devices.

The trade off issues for a ventilator are well known, not something to be negotiated.  So there is no point in comparing to scalpels.  The rules are the rules and it will be hard to get approvals.  I'm sure it costs lots of money, not unlike FCC approval.  I believe the plan is to find a manufacturing partner to turn this design over to who will bear the brunt of approvals.  

This is not impossible, but I think that should be one of the early steps so they have some input to the process, guiding what comes out at the end rather than simply having to redesign it all over again potentially.  


> A ventilator is never good for your lungs, so it will do some damage,
> the aim is to keep the damage as minimal as possible and as short term
> as possible.
> 
> >
> >> > I don't mind working on the team.  It's seeing them go in odd directions that bugs me.  This thing will probably cost hundreds of dollars in the final BOM without anything like profit or overhead added in.  People were arguing against adding $0.10 for more pins on a processor.  Then later they decided to not only go with the larger pin count, but bump from an 8 bit AVR to an ARM CM4F adding several dollars.  That sort of inconsistency drives me nuts.  "Every dollar counts!"  Yes it does, so you need to justify the cost *rationally*.  
> >> >
> >> 
> >> Does every dollar count in this case? If this is for solving short term
> >> ventilator shortages, should development speed not count more than dollars?
> >
> > It's not about rushing to the finish line for sure.  None of the goals are clearly stated.  That's my point.  
> 
> Well, get that point across and try to get the goals clear before
> proceeding.

I have provided my input and the project moves forward.  The rev 1 of the main board is full of issues mostly because the guy doing it is donating his time while continuing to work full time.  There was no design review I assume because there was no one to conduct it with but also I think because no one recognizes the need.  "It's just an Arduino" plus some interfacing circuitry.  

The design includes window comparators for alarm settings.  I found that according to the labels and the polarity of the outputs the alarms will be guaranteed to be on all the time.  Fortunately the prototype uses pots for the set points so the max can be set to the min value and vice versa.  

I'm also concerned about the board layout.  The board is not at all dense but there are several parts that need copper area for heat sinking.  They are using a linear regulator to drop 12+ volts to 5V and 3.3V.  The back lights for the LCDs draw 300 mA!  So the 5V regulator gets quite warm, 70°C!!!  There is a motor controller that has to handle several amps of current.  Both of these parts had thermal breaks on the thermal pads on the rev 1 board.  So virtually no heat sinking. 


> > We meet using video tools and Zoom seems to work the best.  I have various latency and bandwidth issues and was not able to participate yesterday.  That's really frustrating, especially when everyone is missing an important point.  Today we had a one on one to test Google Meet and compare to Zoom (Google was a second runner).  So I had a chance to make clear what is and is not a problem in the plumbing.  Understanding what I was saying he agreed so the plumbing next to the patient is less cumbersome now.  
> >
> > Maybe more 1 on 1s will help. 
> 
> Good luck.

Thanks.

No small part of the problem is I don't have a defined roll.  Someone is doing the electronic design part time and I get to figure out what is wrong once in a while.  Not enjoyable really.  

-- 

  Rick C.

  ++ Get 1,000 miles of free Supercharging
  ++ Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#29791

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> also I think because no one recognizes the need.  "It's just an
> Arduino" plus some interfacing circuitry. ...

Frankly this project sounds like amateur hour.  If US FDA approval works
the way it's been explained to me, there is no chance of the device ever
getting it.  Other countries' mileage may vary.

There are other devices that they could build that would be much less
dangerous (therefore easier to get approval for), but that fill a need.
For example, polysomnography machines for sleep studies, or other
diagnostic equipment.  Compared to a vent, they are pretty safe, since
they only measure your body functions (heart and breathing rate, etc.)
rather than being an invasive intervention.  But having more of them
available could help people with underdiagnosed conditions like sleep
apnea.

[toc] | [prev] | [next] | [standalone]

#29826

On 2020-07-08 Rick C wrote in comp.arch.embedded:
> On Wednesday, July 8, 2020 at 5:35:53 PM UTC-4, Stef wrote:
>> On 2020-07-08 Rick C wrote in comp.arch.embedded:
>> > On Wednesday, July 8, 2020 at 1:00:04 PM UTC-4, Stef wrote:
>> >> On 2020-07-08 Rick C wrote in comp.arch.embedded:

[...]
>> >> > I had a friend who worked on medical devices for a while before getting out.  He said they required that you "prove" your design will not hurt the patient in any way.  Hard to do with a ventilator.  
>> >> >
>> >> 
>> >> That is not entirely true, it is more a risk/benefit analysis. Otherwise you
>> >> could not even get a scalpel approved, it will always hurt the patient.
>> >
>> > That is a bogus comparison.  So nothing to discuss there. 
>> 
>> I don't agree. ;-)
>> The scalpel example is a bit extreme of course. But for every medical 
>> device there wil be a risk/benefit analysis. There are medical devices
>> that do some harm to a patient, but as long as the benefits outweigh
>> the harm it may still be a good thing to use those devices.
>
> The trade off issues for a ventilator are well known, not something to be negotiated.  So there is no point in comparing to scalpels.

I don't think you got mu point here. I just commented on your (friends)
statement '"prove" your design will not hurt the patient in any way'. That
is simply not true. There is always a risk/benefit and as long as the
benefits outweigh the risks, some risk may be deemed acceptable. This
presentation highlights how important risk/benefit is in the new MDR (EU
medical deviceregulation).
https://www.bsigroup.com/meddev/LocalFiles/en-US/roadshow-resources-2017-fall/bsi-mdr-risk-and-clinical-requirements.pdf

And this goes for all medical devices, from complex (like ventilators or
MRI scanners) to simple. The scalpel being an example of the latter, not
a comparison to the ventilator.

> The rules are the rules and it will be hard to get approvals.  I'm sure it costs lots of money, not unlike FCC approval.

I'm not familiar with FCC, but if it's anything like EU CE marking to get
(non medical) electronic devices approved for sale, you might be in for a
shock when it comes to electronic medical devices, especially those that
include software.


> I believe the plan is to find a manufacturing partner to turn this design over to who will bear the brunt of approvals.  

Like has been said multiple times. You should start (preparation for) the
approval process before/during the design, not after.

And any idea who this manufacturing partner will be? It will need to be
a partner already familiar with medical devices, preferrably with
ventilators. And you have to come with something they could not have
done themselves.

[...]
>
> The design includes window comparators for alarm settings.  I found that according to the labels and the polarity of the outputs the alarms will be guaranteed to be on all the time.  Fortunately the prototype uses pots for the set points so the max can be set to the min value and vice versa.  
>
> I'm also concerned about the board layout.  The board is not at all dense but there are several parts that need copper area for heat sinking.  They are using a linear regulator to drop 12+ volts to 5V and 3.3V.  The back lights for the LCDs draw 300 mA!  So the 5V regulator gets quite warm, 70°C!!!  There is a motor controller that has to handle several amps of current.  Both of these parts had thermal breaks on the thermal pads on the rev 1 board.  So virtually no heat sinking. 
>

One hand, these problems are only minor and can be solved by any capable
electronics engineer. On the other this sort of thing would get me worrying
about the skills of the team. But if their skills are in medical and
regulations, an electronics engineer would be a good supplement to the team.


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

The whole earth is in jail and we're plotting this incredible jailbreak.
		-- Wavy Gravy

[toc] | [prev] | [next] | [standalone]

#29911

On 07/08/20 23:20, Rick C wrote:

> I'm also concerned about the board layout.  The board is not at all dense but there are several

parts that need copper area for heat sinking.  They are using a linear 
regulator to drop 12+ volts

to 5V and 3.3V.  The back lights for the LCDs draw 300 mA!  So the 5V 
regulator gets quite warm,

70°C!!!

You should be concerned. The whole thing about safety critical kit is
that it should be conservatively designed, with all parts running well
within their ratings. If the hw bod is happy with a regulator running
at 70c, he must be clueless. Sorry, but it needs to be said.

If you care about your professional career and any litigation
issues, you should either have enough influence on the project
direction to stop design errors like that, or just walk away from it...

Chris

[toc] | [prev] | [next] | [standalone]

#29912

On Thursday, August 6, 2020 at 7:01:55 PM UTC-4, Chris wrote:
> On 07/08/20 23:20, Rick C wrote:
> 
> > I'm also concerned about the board layout.  The board is not at all dense but there are several
> 
> parts that need copper area for heat sinking.  They are using a linear 
> regulator to drop 12+ volts
> 
> to 5V and 3.3V.  The back lights for the LCDs draw 300 mA!  So the 5V 
> regulator gets quite warm,
> 
> 70°C!!!
> 
> You should be concerned. The whole thing about safety critical kit is
> that it should be conservatively designed, with all parts running well
> within their ratings. If the hw bod is happy with a regulator running
> at 70c, he must be clueless. Sorry, but it needs to be said.
> 
> If you care about your professional career and any litigation
> issues, you should either have enough influence on the project
> direction to stop design errors like that, or just walk away from it...
> 
> Chris

It was a prototype board before I came on board.  I am involved in the design review of the next rev and I will be pushing for a design review of the layout as well.  Not sure how well that will be received.  

The project leader has indicated numerous times that he wants to get the board rolling in spite of us not having good requirements.  He brought someone on board to help with that, but this is very different from what I am accustomed to.  My experience with requirements analysis was on DOD projects and it had lots of formalities with each requirement being linked to a test.  

We just had a meeting today with the guy who has written a systems level requirements document.  He has indicated that he will be breaking requirements down further for the software, but not for the hardware.  I asked why and time was cited, not enough time to do that.  What???  

I don't have any specific duties at the moment.  I might participate in a design review of the schematic and layout, but I won't be doing any further design work.  

I just think it is crazy to try to push this design to completion without knowing what it is supposed to do in detail.  There seems to be an obsession with turning the machine off even though it has battery backup which would be depleted in an hour if left connected or in a couple of months if not.  There is an alarm for when the machine is unplugged and running off battery.  So what should turning the machine off do exactly?  I can't get an answer, but we need to complete the board design. 

Yeah, we are nearing the end of this road. 

-- 

  Rick C.

  ++- Get 1,000 miles of free Supercharging
  ++- Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#29918

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> Yeah, we are nearing the end of this road. 

It's ok, a group of Afghan schoolgirls is on top of it and seems to be
doing a more serious job:

https://www.reuters.com/article/us-health-coronavirus-afghanistan-ventil/afghan-all-girls-robotics-team-designs-low-cost-ventilator-to-treat-coronavirus-patients-idUSKCN24L0WO

[toc] | [prev] | [next] | [standalone]

#29913

On 2020-08-06 19:01, Chris wrote:
> On 07/08/20 23:20, Rick C wrote:
> 
>> I'm also concerned about the board layout.  The board is not at all 
>> dense but there are several
> 
> parts that need copper area for heat sinking.  They are using a linear 
> regulator to drop 12+ volts
> 
> to 5V and 3.3V.  The back lights for the LCDs draw 300 mA!  So the 5V 
> regulator gets quite warm,
> 
> 70°C!!!
> 
> You should be concerned. The whole thing about safety critical kit is
> that it should be conservatively designed, with all parts running well
> within their ratings. If the hw bod is happy with a regulator running
> at 70c, he must be clueless. Sorry, but it needs to be said.
> 
> If you care about your professional career and any litigation
> issues, you should either have enough influence on the project
> direction to stop design errors like that, or just walk away from it...
> 
> Chris

Hmm, interesting.  Most linear regulators I'm familiar with are rated to 
125 C junction temperature, and some higher.  What safety or regulatory 
issues have you run into that were caused by running some part 55C below 
its rated temperature?

Cheers

Phil Hobbs

-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

[toc] | [prev] | [next] | [standalone]

#29914

On Thursday, August 6, 2020 at 9:50:24 PM UTC-4, Phil Hobbs wrote:
> On 2020-08-06 19:01, Chris wrote:
> > On 07/08/20 23:20, Rick C wrote:
> > 
> >> I'm also concerned about the board layout.  The board is not at all 
> >> dense but there are several
> > 
> > parts that need copper area for heat sinking.  They are using a linear 
> > regulator to drop 12+ volts
> > 
> > to 5V and 3.3V.  The back lights for the LCDs draw 300 mA!  So the 5V 
> > regulator gets quite warm,
> > 
> > 70°C!!!
> > 
> > You should be concerned. The whole thing about safety critical kit is
> > that it should be conservatively designed, with all parts running well
> > within their ratings. If the hw bod is happy with a regulator running
> > at 70c, he must be clueless. Sorry, but it needs to be said.
> > 
> > If you care about your professional career and any litigation
> > issues, you should either have enough influence on the project
> > direction to stop design errors like that, or just walk away from it...
> > 
> > Chris
> 
> Hmm, interesting.  Most linear regulators I'm familiar with are rated to 
> 125 C junction temperature, and some higher.  What safety or regulatory 
> issues have you run into that were caused by running some part 55C below 
> its rated temperature?

That was the case temp via an IR gun.  So the die was hotter.  I would not approve a design with a part running so hot.  I believe the failure rate goes up quite quickly with temp.  The real point is this is because the layout was not correct using thermal breaks around the thermal pad!!!  Easy enough to fix lowering the temp probably by 30 °C.  

Did you not read the original post about this? 

-- 

  Rick C.

  +++ Get 1,000 miles of free Supercharging
  +++ Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#29915

On 2020-08-06 22:12, Rick C wrote:
> On Thursday, August 6, 2020 at 9:50:24 PM UTC-4, Phil Hobbs wrote:
>> On 2020-08-06 19:01, Chris wrote:
>>> On 07/08/20 23:20, Rick C wrote:
>>>
>>>> I'm also concerned about the board layout.  The board is not at all
>>>> dense but there are several
>>>
>>> parts that need copper area for heat sinking.  They are using a linear
>>> regulator to drop 12+ volts
>>>
>>> to 5V and 3.3V.  The back lights for the LCDs draw 300 mA!  So the 5V
>>> regulator gets quite warm,
>>>
>>> 70°C!!!
>>>
>>> You should be concerned. The whole thing about safety critical kit is
>>> that it should be conservatively designed, with all parts running well
>>> within their ratings. If the hw bod is happy with a regulator running
>>> at 70c, he must be clueless. Sorry, but it needs to be said.
>>>
>>> If you care about your professional career and any litigation
>>> issues, you should either have enough influence on the project
>>> direction to stop design errors like that, or just walk away from it...
>>>
>>> Chris
>>
>> Hmm, interesting.  Most linear regulators I'm familiar with are rated to
>> 125 C junction temperature, and some higher.  What safety or regulatory
>> issues have you run into that were caused by running some part 55C below
>> its rated temperature?
> 
> That was the case temp via an IR gun.  So the die was hotter.  I would not approve a design with a part running so hot.  I believe the failure rate goes up quite quickly with temp.  The real point is this is because the layout was not correct using thermal breaks around the thermal pad!!!  Easy enough to fix lowering the temp probably by 30 °C.
> 
> Did you not read the original post about this?
> 

I've designed a fair bit of stuff to work in ambients higher than that, 
from remote satcom stuff to downhole instruments running at 175C.

The amateur vent stuff is all March 2020 at this point, so I'm 
interested in the broader context.

Cheers

Phil Hobbs

-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web