There are Idiots and There are Idiots...

[Rick C]

This design group I am in is being led by a mechanical engineer who has his limitation. Initially I thought it was just that he didn\'t know much about electronics. Then I found his thinking for mechanical issues to be a bit lacking in sophistication. Now I realize he doesn\'t understand fundamental principles of analysis.

I was not involved in the project from the start. They had built a revision 1 of the board which was essentially an arduino with a motor controller chip and some comparators. I realized they were not very skilled at electronics design and figured I could help.

What I didn\'t realize was the extent of ignorance in project development and management. The entire project has moved along in fits and spurts and many, many backflips because of a lack of initial analysis and specification of requirements.

All through this project they have been planning to measure flow rate by means of detecting the differential pressure across an orifice. They had a guy who seemed to have that as his sole task so I expected it was covered. There were concerns about the resolution at the low end so a separate circuit was added to provide more gain for the low end giving more resolution. Again, I expected they had it under control.

I am designing much of the FPGA that reads the differential sensor and other inputs to calculate the flow rate. The ADC will be a delta-sigma built in the FPGA with over 17 bits of resolution. I\'m thinking that is enough, but to be sure I ask for a number for the resolution in flow rate required....

No one could provide that simple piece of data. It has gone on for weeks with every excuse in the book for not providing it. Instead they talk about having to take into account all manner of errors and could not explain what they were talking about. Today I finally found out they want to determine the resolution based on it\'s contribution to accuracy. Once I had that data it took me about 15 minutes to do the calculations that show even if they assume no other source of error the resolution required would be about 1 part in 15,000 or 14 bits of ADC. That\'s great, but this worst case happens at the low end of the scale and the error of the pressure sensor itself is pegged to the full scale value and so is enormously large at this close to zero.

I think they are now trying to rationalize continuing down this road by picking a higher value as the minimum to be measured. Trouble is they don\'t have control over that.

Months ago I suggested they go with a flow sensor that was cheap, available and produced a digital output of 14 bits, adequate for this purpose. That was rejected because they were new and in short supply. However, the pressure sensors used in ventilators are all in short supply. So it doesn\'t matter much which device you pick if they are all in short supply.

I\'m about fed up with this project. We can replace anyone on the project, except for the guy running it, the one we need to replace. Sounds like many of the jobs I\'ve had.

--

Rick C.

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

 

[Lasse Langwadt Christensen]

tirsdag den 8. december 2020 kl. 00.03.08 UTC+1 skrev gnuarm.del...@gmail.com:

I am designing much of the FPGA that reads the differential sensor and other inputs to calculate the flow rate. The ADC will be a delta-sigma built in the FPGA with over 17 bits of resolution. I\'m thinking that is enough, but to be sure I ask for a number for the resolution in flow rate required....

I\'d be skeptical about how much those 17bits are worth, most MCUs with build ADCs can bare do 10-12bits

 

[Rick C]

On Monday, December 7, 2020 at 6:19:21 PM UTC-5, lang...@fonz.dk wrote:

tirsdag den 8. december 2020 kl. 00.03.08 UTC+1 skrev gnuarm.del...@gmail..com:

I am designing much of the FPGA that reads the differential sensor and other inputs to calculate the flow rate. The ADC will be a delta-sigma built in the FPGA with over 17 bits of resolution. I\'m thinking that is enough, but to be sure I ask for a number for the resolution in flow rate required....

I\'d be skeptical about how much those 17bits are worth, most MCUs with build ADCs can bare do 10-12bits

The more I learn about the FPGA ADC the more I like them. The FPGA only contains the comparator (on a separate Vcc from the rest of the chip) and the digital logic. I took the precaution of using an external CMOS driver for driving the analog portion of the ADC which is all external to the FPGA.

I dug around quite a bit and I never found a work that actually shows the limitations of these ADCs in the context we will be using them. Unfortunately no one actually did an error analysis on the flow rate sensor until I started being a PITA about the required resolution. This eventually showed we were not able to meet the accuracy spec with the device we had picked months and months ago. In fact, this episode might be the straw that breaks the camel\'s back. I really can\'t continue working when each couple of weeks we find something significant that isn\'t working.

I would like to see the result of the 17.3 bit ADC and I would like to complete the calculator design in the FPGA. But what\'s the point when there\'s a 50/50 chance of tossing it all to start over on a new approach.

--

Rick C.

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

 

[John Doe]

Off-topic troll...

--
Rick C <gnuarm.deletethisbit@gmail.com> wrote:

X-Received: by 2002:a05:620a:66d:: with SMTP id a13mr9122772qkh.357.1607382183010; Mon, 07 Dec 2020 15:03:03 -0800 (PST)
X-Received: by 2002:a05:620a:1441:: with SMTP id i1mr26268186qkl.454.1607382182825; Mon, 07 Dec 2020 15:03:02 -0800 (PST)
Path: eternal-september.org!reader02.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: sci.electronics.design
Date: Mon, 7 Dec 2020 15:03:02 -0800 (PST)
Complaints-To: groups-abuse@google.com
Injection-Info: google-groups.googlegroups.com; posting-host=204.148.35.130; posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 204.148.35.130
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <9ab6a931-9f87-43dc-a7fb-871af5ca5fd0n@googlegroups.com
Subject: There are Idiots and There are Idiots
From: Rick C <gnuarm.deletethisbit@gmail.com
Injection-Date: Mon, 07 Dec 2020 23:03:03 +0000
Content-Type: text/plain; charset=\"UTF-8\"
Content-Transfer-Encoding: quoted-printable
Xref: reader02.eternal-september.org sci.electronics.design:615429

This design group I am in is being led by a mechanical engineer who has his limitation. Initially I thought it was just that he didn\'t know much about electronics. Then I found his thinking for mechanical issues to be a bit lacking in sophistication. Now I realize he doesn\'t understand fundamental principles of analysis.

I was not involved in the project from the start. They had built a revision 1 of the board which was essentially an arduino with a motor controller chip and some comparators. I realized they were not very skilled at electronics design and figured I could help.

What I didn\'t realize was the extent of ignorance in project development and management. The entire project has moved along in fits and spurts and many, many backflips because of a lack of initial analysis and specification of requirements.

All through this project they have been planning to measure flow rate by means of detecting the differential pressure across an orifice. They had a guy who seemed to have that as his sole task so I expected it was covered. There were concerns about the resolution at the low end so a separate circuit was added to provide more gain for the low end giving more resolution. Again, I expected they had it under control.

I am designing much of the FPGA that reads the differential sensor and other inputs to calculate the flow rate. The ADC will be a delta-sigma built in the FPGA with over 17 bits of resolution. I\'m thinking that is enough, but to be sure I ask for a number for the resolution in flow rate required...

No one could provide that simple piece of data. It has gone on for weeks with every excuse in the book for not providing it. Instead they talk about having to take into account all manner of errors and could not explain what they were talking about. Today I finally found out they want to determine the resolution based on it\'s contribution to accuracy. Once I had that data it took me about 15 minutes to do the calculations that show even if they assume no other source of error the resolution required would be about 1 part in 15,000 or 14 bits of ADC. That\'s great, but this worst case happens at the low end of the scale and the error of the pressure sensor itself is pegged to the full scale value and so is enormously large at this close to zero.

I think they are now trying to rationalize continuing down this road by picking a higher value as the minimum to be measured. Trouble is they don\'t have control over that.

Months ago I suggested they go with a flow sensor that was cheap, available and produced a digital output of 14 bits, adequate for this purpose. That was rejected because they were new and in short supply. However, the pressure sensors used in ventilators are all in short supply. So it doesn\'t matter much which device you pick if they are all in short supply.

I\'m about fed up with this project. We can replace anyone on the project, except for the guy running it, the one we need to replace. Sounds like many of the jobs I\'ve had.

--

Rick C.

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

 

[dalai lamah]

Un bel giorno Rick C digitò:

I\'d be skeptical about how much those 17bits are worth, most MCUs with
build ADCs can bare do 10-12bits

The more I learn about the FPGA ADC the more I like them. The FPGA only
contains the comparator (on a separate Vcc from the rest of the chip)
and the digital logic. I took the precaution of using an external CMOS
driver for driving the analog portion of the ADC which is all external
to the FPGA.

As far as I know (which is not much), the main problem of ADCs implemented
in this way is not the resolution, but rather the absolute accuracy.

I suppose that for the comparator you are using the inputs normally used
for LVDS/LVPECL. Even if you use a \"clean\" Vref, your feedback will run
through digital I/O buffers, and therefore also the Vccio supply will
contribute to the system accuracy.

You will need an insanely accurate power supply in order to get 17 bits, we
are talking microvolts here. Even if you achieve it, the (very small)
fluctuations due to the I/O switching will slightly change the output
voltage of the buffers.

I\'m quite interested, let us know how it goes if your project leader does
not screw up everything.

--
Fletto i muscoli e sono nel vuoto.

 

[Rick C]

On Tuesday, December 8, 2020 at 9:47:07 AM UTC-5, dalai lamah wrote:

Un bel giorno Rick C digitò:
I\'d be skeptical about how much those 17bits are worth, most MCUs with
build ADCs can bare do 10-12bits

The more I learn about the FPGA ADC the more I like them. The FPGA only
contains the comparator (on a separate Vcc from the rest of the chip)
and the digital logic. I took the precaution of using an external CMOS
driver for driving the analog portion of the ADC which is all external
to the FPGA.
As far as I know (which is not much), the main problem of ADCs implemented
in this way is not the resolution, but rather the absolute accuracy.

I suppose that for the comparator you are using the inputs normally used
for LVDS/LVPECL. Even if you use a \"clean\" Vref, your feedback will run
through digital I/O buffers, and therefore also the Vccio supply will
contribute to the system accuracy.

You will need an insanely accurate power supply in order to get 17 bits, we
are talking microvolts here. Even if you achieve it, the (very small)
fluctuations due to the I/O switching will slightly change the output
voltage of the buffers.

I\'m quite interested, let us know how it goes if your project leader does
not screw up everything.

Yes, accuracy is hard to obtain. I had the impression they had done a proper analysis of accuracy, precision and resolution.

However, the ADC will have characteristics that can be compensated for. I\'ve done an initial analysis of the errors and most will be correctable with a scale factor and offset which is done for the equivalent errors of each sensor. The remaining error will be a curve due to charge injection, largest in the center of the range and approaching zero at the scale ends. There is also error from the accuracy of the two resistors which can be minimized, but not eliminated due to temperature drift. The important factor is the ratio, so mounting them so the temperature variation is minimized helps.

I\'m still processing the realization of how bad the leadership is, trying to determine if it is worth continuing to contribute to the development. He did manage one thing... he has found a company in Brazil who is interested in considering our machine for productization. I suggested that rather than wait for our efforts to be completed (and making any number of decisions they will end up changing) that we allow them to review our project now and have some input to the decisions we are making. In spite of the fact that everything we are doing is licensed, open source materials he feels getting any feedback from this company would open us to liability.

I need to knock out the calculator code. Once I have something that simulates I can leave the project and not feel that I\'ve left them in the lurch. They can maintain it as they continue to reinvent the same designs over and over.

 

[Rick C]

On Tuesday, December 8, 2020 at 9:47:07 AM UTC-5, dalai lamah wrote:

Un bel giorno Rick C digitò:
I\'d be skeptical about how much those 17bits are worth, most MCUs with
build ADCs can bare do 10-12bits

The more I learn about the FPGA ADC the more I like them. The FPGA only
contains the comparator (on a separate Vcc from the rest of the chip)
and the digital logic. I took the precaution of using an external CMOS
driver for driving the analog portion of the ADC which is all external
to the FPGA.
As far as I know (which is not much), the main problem of ADCs implemented
in this way is not the resolution, but rather the absolute accuracy.

I suppose that for the comparator you are using the inputs normally used
for LVDS/LVPECL. Even if you use a \"clean\" Vref, your feedback will run
through digital I/O buffers, and therefore also the Vccio supply will
contribute to the system accuracy.

You will need an insanely accurate power supply in order to get 17 bits, we
are talking microvolts here. Even if you achieve it, the (very small)
fluctuations due to the I/O switching will slightly change the output
voltage of the buffers.

I\'m quite interested, let us know how it goes if your project leader does
not screw up everything.

Yes, accuracy is hard to obtain. I had the impression they had done a proper analysis of accuracy, precision and resolution.

However, the ADC will have characteristics that can be compensated for. I\'ve done an initial analysis of the errors and most will be correctable with a scale factor and offset which is done for the equivalent errors of each sensor. The remaining error will be a curve due to charge injection, largest in the center of the range and approaching zero at the scale ends. There is also error from the accuracy of the two resistors which can be minimized, but not eliminated due to temperature drift. The important factor is the ratio, so mounting them so the temperature variation is minimized helps.

I\'m still processing the realization of how bad the leadership is, trying to determine if it is worth continuing to contribute to the development. He did manage one thing... he has found a company in Brazil who is interested in considering our machine for productization. I suggested that rather than wait for our efforts to be completed (and making any number of decisions they will end up changing) that we allow them to review our project now and have some input to the decisions we are making. In spite of the fact that everything we are doing is licensed, open source materials he feels getting any feedback from this company would open us to liability.

I need to knock out the calculator code. Once I have something that simulates I can leave the project and not feel that I\'ve left them in the lurch. They can maintain it as they continue to reinvent the same designs over and over.

 

[server]

On Tue, 8 Dec 2020 15:46:58 +0100, dalai lamah
<antonio12358@hotmail.com> wrote:

Un bel giorno Rick C digitò:

I\'d be skeptical about how much those 17bits are worth, most MCUs with
build ADCs can bare do 10-12bits

The more I learn about the FPGA ADC the more I like them. The FPGA only
contains the comparator (on a separate Vcc from the rest of the chip)
and the digital logic. I took the precaution of using an external CMOS
driver for driving the analog portion of the ADC which is all external
to the FPGA.

As far as I know (which is not much), the main problem of ADCs implemented
in this way is not the resolution, but rather the absolute accuracy.

I suppose that for the comparator you are using the inputs normally used
for LVDS/LVPECL. Even if you use a \"clean\" Vref, your feedback will run
through digital I/O buffers, and therefore also the Vccio supply will
contribute to the system accuracy.

You will need an insanely accurate power supply in order to get 17 bits, we
are talking microvolts here. Even if you achieve it, the (very small)
fluctuations due to the I/O switching will slightly change the output
voltage of the buffers.

Right. Delta-sigma has continuously squiriming numbers of rising and
falling edges, at high rates, and any rise/fall rate differences
become errors. You can express, say, a 41% duty cycle lots of
different ways in a serial data stream.

I\'m quite interested, let us know how it goes if your project leader does
not screw up everything.

Or kill a lot of people.



--

John Larkin Highland Technology, Inc

The best designs are necessarily accidental.

 

[server]

On Tue, 8 Dec 2020 15:46:58 +0100, dalai lamah
<antonio12358@hotmail.com> wrote:

Un bel giorno Rick C digitò:

I\'d be skeptical about how much those 17bits are worth, most MCUs with
build ADCs can bare do 10-12bits

The more I learn about the FPGA ADC the more I like them. The FPGA only
contains the comparator (on a separate Vcc from the rest of the chip)
and the digital logic. I took the precaution of using an external CMOS
driver for driving the analog portion of the ADC which is all external
to the FPGA.

As far as I know (which is not much), the main problem of ADCs implemented
in this way is not the resolution, but rather the absolute accuracy.

I suppose that for the comparator you are using the inputs normally used
for LVDS/LVPECL. Even if you use a \"clean\" Vref, your feedback will run
through digital I/O buffers, and therefore also the Vccio supply will
contribute to the system accuracy.

You will need an insanely accurate power supply in order to get 17 bits, we
are talking microvolts here. Even if you achieve it, the (very small)
fluctuations due to the I/O switching will slightly change the output
voltage of the buffers.

Right. Delta-sigma has continuously squiriming numbers of rising and
falling edges, at high rates, and any rise/fall rate differences
become errors. You can express, say, a 41% duty cycle lots of
different ways in a serial data stream.

I\'m quite interested, let us know how it goes if your project leader does
not screw up everything.

Or kill a lot of people.



--

John Larkin Highland Technology, Inc

The best designs are necessarily accidental.

 

[bitrex]

On 12/7/2020 6:03 PM, Rick C wrote:

This design group I am in is being led by a mechanical engineer who has his limitation. Initially I thought it was just that he didn\'t know much about electronics. Then I found his thinking for mechanical issues to be a bit lacking in sophistication. Now I realize he doesn\'t understand fundamental principles of analysis.

I was not involved in the project from the start. They had built a revision 1 of the board which was essentially an arduino with a motor controller chip and some comparators. I realized they were not very skilled at electronics design and figured I could help.

What I didn\'t realize was the extent of ignorance in project development and management. The entire project has moved along in fits and spurts and many, many backflips because of a lack of initial analysis and specification of requirements.

All through this project they have been planning to measure flow rate by means of detecting the differential pressure across an orifice. They had a guy who seemed to have that as his sole task so I expected it was covered. There were concerns about the resolution at the low end so a separate circuit was added to provide more gain for the low end giving more resolution. Again, I expected they had it under control.

I am designing much of the FPGA that reads the differential sensor and other inputs to calculate the flow rate. The ADC will be a delta-sigma built in the FPGA with over 17 bits of resolution. I\'m thinking that is enough, but to be sure I ask for a number for the resolution in flow rate required...

What is the cause of the fucking feature-creep/spec changes in this
project? It went from an Arduino and comparators to 100 MHz FPGAs and 14
bit DACs. There are commercial ventilators saving lives every day with
less processing power than a 16 bit MSP430. In what universe does a
ventilator ADC need 14 bits of accuracy? They are trying to re-invent a
differential flow sensor? You can get those off the shelf with
current-loop signalling, the white paper I\'m looking at now says a
margin of error of 1/20th of a liter is fine.

No one could provide that simple piece of data. It has gone on for weeks with every excuse in the book for not providing it. Instead they talk about having to take into account all manner of errors and could not explain what they were talking about. Today I finally found out they want to determine the resolution based on it\'s contribution to accuracy. Once I had that data it took me about 15 minutes to do the calculations that show even if they assume no other source of error the resolution required would be about 1 part in 15,000 or 14 bits of ADC. That\'s great, but this worst case happens at the low end of the scale and the error of the pressure sensor itself is pegged to the full scale value and so is enormously large at this close to zero.

I think they are now trying to rationalize continuing down this road by picking a higher value as the minimum to be measured. Trouble is they don\'t have control over that.

Months ago I suggested they go with a flow sensor that was cheap, available and produced a digital output of 14 bits, adequate for this purpose. That was rejected because they were new and in short supply. However, the pressure sensors used in ventilators are all in short supply. So it doesn\'t matter much which device you pick if they are all in short supply.

I\'m about fed up with this project. We can replace anyone on the project, except for the guy running it, the one we need to replace. Sounds like many of the jobs I\'ve had.

Sounds like you should have walked a while back...

 

[bitrex]

On 12/7/2020 6:03 PM, Rick C wrote:

This design group I am in is being led by a mechanical engineer who has his limitation. Initially I thought it was just that he didn\'t know much about electronics. Then I found his thinking for mechanical issues to be a bit lacking in sophistication. Now I realize he doesn\'t understand fundamental principles of analysis.

I was not involved in the project from the start. They had built a revision 1 of the board which was essentially an arduino with a motor controller chip and some comparators. I realized they were not very skilled at electronics design and figured I could help.

What I didn\'t realize was the extent of ignorance in project development and management. The entire project has moved along in fits and spurts and many, many backflips because of a lack of initial analysis and specification of requirements.

All through this project they have been planning to measure flow rate by means of detecting the differential pressure across an orifice. They had a guy who seemed to have that as his sole task so I expected it was covered. There were concerns about the resolution at the low end so a separate circuit was added to provide more gain for the low end giving more resolution. Again, I expected they had it under control.

I am designing much of the FPGA that reads the differential sensor and other inputs to calculate the flow rate. The ADC will be a delta-sigma built in the FPGA with over 17 bits of resolution. I\'m thinking that is enough, but to be sure I ask for a number for the resolution in flow rate required...

What is the cause of the fucking feature-creep/spec changes in this
project? It went from an Arduino and comparators to 100 MHz FPGAs and 14
bit DACs. There are commercial ventilators saving lives every day with
less processing power than a 16 bit MSP430. In what universe does a
ventilator ADC need 14 bits of accuracy? They are trying to re-invent a
differential flow sensor? You can get those off the shelf with
current-loop signalling, the white paper I\'m looking at now says a
margin of error of 1/20th of a liter is fine.

No one could provide that simple piece of data. It has gone on for weeks with every excuse in the book for not providing it. Instead they talk about having to take into account all manner of errors and could not explain what they were talking about. Today I finally found out they want to determine the resolution based on it\'s contribution to accuracy. Once I had that data it took me about 15 minutes to do the calculations that show even if they assume no other source of error the resolution required would be about 1 part in 15,000 or 14 bits of ADC. That\'s great, but this worst case happens at the low end of the scale and the error of the pressure sensor itself is pegged to the full scale value and so is enormously large at this close to zero.

I think they are now trying to rationalize continuing down this road by picking a higher value as the minimum to be measured. Trouble is they don\'t have control over that.

Months ago I suggested they go with a flow sensor that was cheap, available and produced a digital output of 14 bits, adequate for this purpose. That was rejected because they were new and in short supply. However, the pressure sensors used in ventilators are all in short supply. So it doesn\'t matter much which device you pick if they are all in short supply.

I\'m about fed up with this project. We can replace anyone on the project, except for the guy running it, the one we need to replace. Sounds like many of the jobs I\'ve had.

Sounds like you should have walked a while back...

 

[Rick C]

On Tuesday, December 8, 2020 at 1:01:14 PM UTC-5, bitrex wrote:

On 12/7/2020 6:03 PM, Rick C wrote:
This design group I am in is being led by a mechanical engineer who has his limitation. Initially I thought it was just that he didn\'t know much about electronics. Then I found his thinking for mechanical issues to be a bit lacking in sophistication. Now I realize he doesn\'t understand fundamental principles of analysis.

I was not involved in the project from the start. They had built a revision 1 of the board which was essentially an arduino with a motor controller chip and some comparators. I realized they were not very skilled at electronics design and figured I could help.

What I didn\'t realize was the extent of ignorance in project development and management. The entire project has moved along in fits and spurts and many, many backflips because of a lack of initial analysis and specification of requirements.

All through this project they have been planning to measure flow rate by means of detecting the differential pressure across an orifice. They had a guy who seemed to have that as his sole task so I expected it was covered.. There were concerns about the resolution at the low end so a separate circuit was added to provide more gain for the low end giving more resolution. Again, I expected they had it under control.

I am designing much of the FPGA that reads the differential sensor and other inputs to calculate the flow rate. The ADC will be a delta-sigma built in the FPGA with over 17 bits of resolution. I\'m thinking that is enough, but to be sure I ask for a number for the resolution in flow rate required....
What is the cause of the fucking feature-creep/spec changes in this
project? It went from an Arduino and comparators to 100 MHz FPGAs and 14
bit DACs. There are commercial ventilators saving lives every day with
less processing power than a 16 bit MSP430. In what universe does a
ventilator ADC need 14 bits of accuracy?

Actually, there is a commercial ventilator design made public as it is no longer produced. It has a high pin out MCU that is at least a high end MSP430 equivalent if not a lot more. It\'s one of the Asian company proprietary CPUs so I didn\'t look up the details. They had some very fancy dancy circuitry such as two back up batteries and a backup battery for the alarm or something like that. There were two speakers for the alarm and a current monitor to assure the speakers were passing the right current... ad infinitum almost. So don\'t tell me we are over designing...

You clearly are not familiar with the equations for obtaining flow rate from a differential pressure across an orifice. It uses a square root which gives a much steeper slope on the lower end than the upper making it very sensitive to measurement errors at the low end of the range. The problem is not that we don\'t need 14 bits of resolution, but that we also need that much accuracy and we won\'t even be able to approach that level of accuracy from the pressure sensor. The project lead is now trying to make an argument that my analysis of the error assumed the worst case, a constant flow rate over the longest inspiration time while the typical flow rate is well above that level and only low for a short interval. Since the requirement is on tidal volume and not flow rate he is saying our accuracy is much higher. Unfortunately the spec calls out the accuracy for any volume over 50 ml. So even if a flow pattern of other than even for the entire 3 seconds is assumed, there is no way to even approach the requirement because of the huge relative error in the sensor, ±2.5% of full scale which becomes ±25% of the measured value at a value of 10%FS. I just did some calcs that show the sensor error with an error fixed to the Full Scale value (increasing relative error as the value measured decreases), crosses the line of the allowed error in the volume measurement at a bit under 500 ml/s flow rate. This does assume a constant flow rate over a 3 second period and a sloping flow rate does improve the accuracy, but the slope can not be assured to be any particular pattern. There is no spec on the flow rate shape.

The other side of the coin is that there is literally no reason to use such high resolution in the ADC if we are measuring a sensor with such poor accuracy at the low end where we were looking for the high resolution. So the entire conversation becomes moot in selecting the ADC and the dual signal path.

They are trying to re-invent a
differential flow sensor? You can get those off the shelf with
current-loop signalling, the white paper I\'m looking at now says a
margin of error of 1/20th of a liter is fine.

Don\'t know what sensor you are talking about, but try buying them. All appropriate sensors are on allocation (as well as the pressure sensors) and there is also an issue of being suitable for use in a ventilator. Materials have to be approved. 1/20th of a liter is otherwise known as 50 ml. I don\'t know what paper you are looking at, but the UK MHRA spec we are designing to says ±(4 ml + 15% of actual value) accuracy.

No one could provide that simple piece of data. It has gone on for weeks with every excuse in the book for not providing it. Instead they talk about having to take into account all manner of errors and could not explain what they were talking about. Today I finally found out they want to determine the resolution based on it\'s contribution to accuracy. Once I had that data it took me about 15 minutes to do the calculations that show even if they assume no other source of error the resolution required would be about 1 part in 15,000 or 14 bits of ADC. That\'s great, but this worst case happens at the low end of the scale and the error of the pressure sensor itself is pegged to the full scale value and so is enormously large at this close to zero.

I think they are now trying to rationalize continuing down this road by picking a higher value as the minimum to be measured. Trouble is they don\'t have control over that.

Months ago I suggested they go with a flow sensor that was cheap, available and produced a digital output of 14 bits, adequate for this purpose. That was rejected because they were new and in short supply. However, the pressure sensors used in ventilators are all in short supply. So it doesn\'t matter much which device you pick if they are all in short supply.

I\'m about fed up with this project. We can replace anyone on the project, except for the guy running it, the one we need to replace. Sounds like many of the jobs I\'ve had.

Sounds like you should have walked a while back...

Yeah, I was going to look for another project a while ago when it looked like the schematic was being wrapped up. But then someone had the idea of using an FPGA instead of the MCU for the alarm functions and I was the guy with the back ground to do it. Meanwhile of course it has grown tremendously.. Like I\'ve said, I\'m finishing the calculator and then I\'m out.

--

Rick C.

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

 

[bitrex]

On 12/8/2020 3:03 PM, Rick C wrote:

On Tuesday, December 8, 2020 at 1:01:14 PM UTC-5, bitrex wrote:
On 12/7/2020 6:03 PM, Rick C wrote:
This design group I am in is being led by a mechanical engineer who has his limitation. Initially I thought it was just that he didn\'t know much about electronics. Then I found his thinking for mechanical issues to be a bit lacking in sophistication. Now I realize he doesn\'t understand fundamental principles of analysis.

I was not involved in the project from the start. They had built a revision 1 of the board which was essentially an arduino with a motor controller chip and some comparators. I realized they were not very skilled at electronics design and figured I could help.

What I didn\'t realize was the extent of ignorance in project development and management. The entire project has moved along in fits and spurts and many, many backflips because of a lack of initial analysis and specification of requirements.

All through this project they have been planning to measure flow rate by means of detecting the differential pressure across an orifice. They had a guy who seemed to have that as his sole task so I expected it was covered. There were concerns about the resolution at the low end so a separate circuit was added to provide more gain for the low end giving more resolution. Again, I expected they had it under control.

I am designing much of the FPGA that reads the differential sensor and other inputs to calculate the flow rate. The ADC will be a delta-sigma built in the FPGA with over 17 bits of resolution. I\'m thinking that is enough, but to be sure I ask for a number for the resolution in flow rate required...
What is the cause of the fucking feature-creep/spec changes in this
project? It went from an Arduino and comparators to 100 MHz FPGAs and 14
bit DACs. There are commercial ventilators saving lives every day with
less processing power than a 16 bit MSP430. In what universe does a
ventilator ADC need 14 bits of accuracy?

Actually, there is a commercial ventilator design made public as it is no longer produced. It has a high pin out MCU that is at least a high end MSP430 equivalent if not a lot more. It\'s one of the Asian company proprietary CPUs so I didn\'t look up the details. They had some very fancy dancy circuitry such as two back up batteries and a backup battery for the alarm or something like that. There were two speakers for the alarm and a current monitor to assure the speakers were passing the right current... ad infinitum almost. So don\'t tell me we are over designing...

You clearly are not familiar with the equations for obtaining flow rate from a differential pressure across an orifice. It uses a square root which gives a much steeper slope on the lower end than the upper making it very sensitive to measurement errors at the low end of the range. The problem is not that we don\'t need 14 bits of resolution, but that we also need that much accuracy and we won\'t even be able to approach that level of accuracy from the pressure sensor. The project lead is now trying to make an argument that my analysis of the error assumed the worst case, a constant flow rate over the longest inspiration time while the typical flow rate is well above that level and only low for a short interval. Since the requirement is on tidal volume and not flow rate he is saying our accuracy is much higher. Unfortunately the spec calls out the accuracy for any volume over 50 ml. So even if a flow pattern of other than even for the entire 3 seconds is assumed, there is no way to even approach the requirement because of the huge relative error in the sensor, ±2.5% of full scale which becomes ±25% of the measured value at a value of 10%FS. I just did some calcs that show the sensor error with an error fixed to the Full Scale value (increasing relative error as the value measured decreases), crosses the line of the allowed error in the volume measurement at a bit under 500 ml/s flow rate. This does assume a constant flow rate over a 3 second period and a sloping flow rate does improve the accuracy, but the slope can not be assured to be any particular pattern. There is no spec on the flow rate shape.

In fixed-point at least sqrt(ab) = sqrt(a)sqrt(b) so you could isolate
the cases where your square root result exceeds the error budget, shift
up n bits, take the square root, divide by two and shift back down.

In floating-point you could isolate and solve the associated polynomial
equation implicitly by using a binary search or some other more
appropriate root-finding algorithm for the domain.

 

[bitrex]

On 12/8/2020 6:34 PM, bitrex wrote:

In fixed-point at least sqrt(ab) = sqrt(a)sqrt(b) so you could isolate
the cases where your square root result exceeds the error budget, shift
up n bits, take the square root, divide by two and shift back down.

Shift down by n/2, rather.

 

[bitrex]

On 12/8/2020 6:34 PM, bitrex wrote:

In fixed-point at least sqrt(ab) = sqrt(a)sqrt(b) so you could isolate
the cases where your square root result exceeds the error budget, shift
up n bits, take the square root, divide by two and shift back down.

Shift down by n/2, rather.

 

[Lasse Langwadt Christensen]

onsdag den 9. december 2020 kl. 00.34.44 UTC+1 skrev bitrex:

On 12/8/2020 3:03 PM, Rick C wrote:
On Tuesday, December 8, 2020 at 1:01:14 PM UTC-5, bitrex wrote:
On 12/7/2020 6:03 PM, Rick C wrote:
This design group I am in is being led by a mechanical engineer who has his limitation. Initially I thought it was just that he didn\'t know much about electronics. Then I found his thinking for mechanical issues to be a bit lacking in sophistication. Now I realize he doesn\'t understand fundamental principles of analysis.

I was not involved in the project from the start. They had built a revision 1 of the board which was essentially an arduino with a motor controller chip and some comparators. I realized they were not very skilled at electronics design and figured I could help.

What I didn\'t realize was the extent of ignorance in project development and management. The entire project has moved along in fits and spurts and many, many backflips because of a lack of initial analysis and specification of requirements.

All through this project they have been planning to measure flow rate by means of detecting the differential pressure across an orifice. They had a guy who seemed to have that as his sole task so I expected it was covered. There were concerns about the resolution at the low end so a separate circuit was added to provide more gain for the low end giving more resolution. Again, I expected they had it under control.

I am designing much of the FPGA that reads the differential sensor and other inputs to calculate the flow rate. The ADC will be a delta-sigma built in the FPGA with over 17 bits of resolution. I\'m thinking that is enough, but to be sure I ask for a number for the resolution in flow rate required...
What is the cause of the fucking feature-creep/spec changes in this
project? It went from an Arduino and comparators to 100 MHz FPGAs and 14
bit DACs. There are commercial ventilators saving lives every day with
less processing power than a 16 bit MSP430. In what universe does a
ventilator ADC need 14 bits of accuracy?

Actually, there is a commercial ventilator design made public as it is no longer produced. It has a high pin out MCU that is at least a high end MSP430 equivalent if not a lot more. It\'s one of the Asian company proprietary CPUs so I didn\'t look up the details. They had some very fancy dancy circuitry such as two back up batteries and a backup battery for the alarm or something like that. There were two speakers for the alarm and a current monitor to assure the speakers were passing the right current... ad infinitum almost. So don\'t tell me we are over designing...

You clearly are not familiar with the equations for obtaining flow rate from a differential pressure across an orifice. It uses a square root which gives a much steeper slope on the lower end than the upper making it very sensitive to measurement errors at the low end of the range. The problem is not that we don\'t need 14 bits of resolution, but that we also need that much accuracy and we won\'t even be able to approach that level of accuracy from the pressure sensor. The project lead is now trying to make an argument that my analysis of the error assumed the worst case, a constant flow rate over the longest inspiration time while the typical flow rate is well above that level and only low for a short interval. Since the requirement is on tidal volume and not flow rate he is saying our accuracy is much higher. Unfortunately the spec calls out the accuracy for any volume over 50 ml. So even if a flow pattern of other than even for the entire 3 seconds is assumed, there is no way to even approach the requirement because of the huge relative error in the sensor, ±2.5% of full scale which becomes ±25% of the measured value at a value of 10%FS. I just did some calcs that show the sensor error with an error fixed to the Full Scale value (increasing relative error as the value measured decreases), crosses the line of the allowed error in the volume measurement at a bit under 500 ml/s flow rate. This does assume a constant flow rate over a 3 second period and a sloping flow rate does improve the accuracy, but the slope can not be assured to be any particular pattern. There is no spec on the flow rate shape.
In fixed-point at least sqrt(ab) = sqrt(a)sqrt(b) so you could isolate
the cases where your square root result exceeds the error budget, shift
up n bits, take the square root, divide by two and shift back down.

I\'d assume it is not taking the square root that is the issue but the non linear sensor response

 

[Lasse Langwadt Christensen]

onsdag den 9. december 2020 kl. 00.34.44 UTC+1 skrev bitrex:

On 12/8/2020 3:03 PM, Rick C wrote:
On Tuesday, December 8, 2020 at 1:01:14 PM UTC-5, bitrex wrote:
On 12/7/2020 6:03 PM, Rick C wrote:
This design group I am in is being led by a mechanical engineer who has his limitation. Initially I thought it was just that he didn\'t know much about electronics. Then I found his thinking for mechanical issues to be a bit lacking in sophistication. Now I realize he doesn\'t understand fundamental principles of analysis.

I was not involved in the project from the start. They had built a revision 1 of the board which was essentially an arduino with a motor controller chip and some comparators. I realized they were not very skilled at electronics design and figured I could help.

What I didn\'t realize was the extent of ignorance in project development and management. The entire project has moved along in fits and spurts and many, many backflips because of a lack of initial analysis and specification of requirements.

All through this project they have been planning to measure flow rate by means of detecting the differential pressure across an orifice. They had a guy who seemed to have that as his sole task so I expected it was covered. There were concerns about the resolution at the low end so a separate circuit was added to provide more gain for the low end giving more resolution. Again, I expected they had it under control.

I am designing much of the FPGA that reads the differential sensor and other inputs to calculate the flow rate. The ADC will be a delta-sigma built in the FPGA with over 17 bits of resolution. I\'m thinking that is enough, but to be sure I ask for a number for the resolution in flow rate required...
What is the cause of the fucking feature-creep/spec changes in this
project? It went from an Arduino and comparators to 100 MHz FPGAs and 14
bit DACs. There are commercial ventilators saving lives every day with
less processing power than a 16 bit MSP430. In what universe does a
ventilator ADC need 14 bits of accuracy?

Actually, there is a commercial ventilator design made public as it is no longer produced. It has a high pin out MCU that is at least a high end MSP430 equivalent if not a lot more. It\'s one of the Asian company proprietary CPUs so I didn\'t look up the details. They had some very fancy dancy circuitry such as two back up batteries and a backup battery for the alarm or something like that. There were two speakers for the alarm and a current monitor to assure the speakers were passing the right current... ad infinitum almost. So don\'t tell me we are over designing...

You clearly are not familiar with the equations for obtaining flow rate from a differential pressure across an orifice. It uses a square root which gives a much steeper slope on the lower end than the upper making it very sensitive to measurement errors at the low end of the range. The problem is not that we don\'t need 14 bits of resolution, but that we also need that much accuracy and we won\'t even be able to approach that level of accuracy from the pressure sensor. The project lead is now trying to make an argument that my analysis of the error assumed the worst case, a constant flow rate over the longest inspiration time while the typical flow rate is well above that level and only low for a short interval. Since the requirement is on tidal volume and not flow rate he is saying our accuracy is much higher. Unfortunately the spec calls out the accuracy for any volume over 50 ml. So even if a flow pattern of other than even for the entire 3 seconds is assumed, there is no way to even approach the requirement because of the huge relative error in the sensor, ±2.5% of full scale which becomes ±25% of the measured value at a value of 10%FS. I just did some calcs that show the sensor error with an error fixed to the Full Scale value (increasing relative error as the value measured decreases), crosses the line of the allowed error in the volume measurement at a bit under 500 ml/s flow rate. This does assume a constant flow rate over a 3 second period and a sloping flow rate does improve the accuracy, but the slope can not be assured to be any particular pattern. There is no spec on the flow rate shape.
In fixed-point at least sqrt(ab) = sqrt(a)sqrt(b) so you could isolate
the cases where your square root result exceeds the error budget, shift
up n bits, take the square root, divide by two and shift back down.

I\'d assume it is not taking the square root that is the issue but the non linear sensor response

 

[bitrex]

On 12/8/2020 6:59 PM, Lasse Langwadt Christensen wrote:

onsdag den 9. december 2020 kl. 00.34.44 UTC+1 skrev bitrex:
On 12/8/2020 3:03 PM, Rick C wrote:
On Tuesday, December 8, 2020 at 1:01:14 PM UTC-5, bitrex wrote:
On 12/7/2020 6:03 PM, Rick C wrote:
This design group I am in is being led by a mechanical engineer who has his limitation. Initially I thought it was just that he didn\'t know much about electronics. Then I found his thinking for mechanical issues to be a bit lacking in sophistication. Now I realize he doesn\'t understand fundamental principles of analysis.

I was not involved in the project from the start. They had built a revision 1 of the board which was essentially an arduino with a motor controller chip and some comparators. I realized they were not very skilled at electronics design and figured I could help.

What I didn\'t realize was the extent of ignorance in project development and management. The entire project has moved along in fits and spurts and many, many backflips because of a lack of initial analysis and specification of requirements.

All through this project they have been planning to measure flow rate by means of detecting the differential pressure across an orifice. They had a guy who seemed to have that as his sole task so I expected it was covered. There were concerns about the resolution at the low end so a separate circuit was added to provide more gain for the low end giving more resolution. Again, I expected they had it under control.

I am designing much of the FPGA that reads the differential sensor and other inputs to calculate the flow rate. The ADC will be a delta-sigma built in the FPGA with over 17 bits of resolution. I\'m thinking that is enough, but to be sure I ask for a number for the resolution in flow rate required...
What is the cause of the fucking feature-creep/spec changes in this
project? It went from an Arduino and comparators to 100 MHz FPGAs and 14
bit DACs. There are commercial ventilators saving lives every day with
less processing power than a 16 bit MSP430. In what universe does a
ventilator ADC need 14 bits of accuracy?

Actually, there is a commercial ventilator design made public as it is no longer produced. It has a high pin out MCU that is at least a high end MSP430 equivalent if not a lot more. It\'s one of the Asian company proprietary CPUs so I didn\'t look up the details. They had some very fancy dancy circuitry such as two back up batteries and a backup battery for the alarm or something like that. There were two speakers for the alarm and a current monitor to assure the speakers were passing the right current... ad infinitum almost. So don\'t tell me we are over designing...

You clearly are not familiar with the equations for obtaining flow rate from a differential pressure across an orifice. It uses a square root which gives a much steeper slope on the lower end than the upper making it very sensitive to measurement errors at the low end of the range. The problem is not that we don\'t need 14 bits of resolution, but that we also need that much accuracy and we won\'t even be able to approach that level of accuracy from the pressure sensor. The project lead is now trying to make an argument that my analysis of the error assumed the worst case, a constant flow rate over the longest inspiration time while the typical flow rate is well above that level and only low for a short interval. Since the requirement is on tidal volume and not flow rate he is saying our accuracy is much higher. Unfortunately the spec calls out the accuracy for any volume over 50 ml. So even if a flow pattern of other than even for the entire 3 seconds is assumed, there is no way to even approach the requirement because of the huge relative error in the sensor, ±2.5% of full scale which becomes ±25% of the measured value at a value of 10%FS. I just did some calcs that show the sensor error with an error fixed to the Full Scale value (increasing relative error as the value measured decreases), crosses the line of the allowed error in the volume measurement at a bit under 500 ml/s flow rate. This does assume a constant flow rate over a 3 second period and a sloping flow rate does improve the accuracy, but the slope can not be assured to be any particular pattern. There is no spec on the flow rate shape.
In fixed-point at least sqrt(ab) = sqrt(a)sqrt(b) so you could isolate
the cases where your square root result exceeds the error budget, shift
up n bits, take the square root, divide by two and shift back down.

I\'d assume it is not taking the square root that is the issue but the non linear sensor response

In that case I think the traditional method of improving accuracy is to
use multiple sensors (ideally not the same kind of sensor) and something
like Kalman filtering/predictor-corrector methods to estimate the true
value from a set of measurements that are corrupted by noise and/or
non-linearity, if the non-linearity can at least be profiled and
linearized over some domain of interest, that is to say it\'s not _too_
nonlinear.

 

[bitrex]

On 12/8/2020 6:59 PM, Lasse Langwadt Christensen wrote:

onsdag den 9. december 2020 kl. 00.34.44 UTC+1 skrev bitrex:
On 12/8/2020 3:03 PM, Rick C wrote:
On Tuesday, December 8, 2020 at 1:01:14 PM UTC-5, bitrex wrote:
On 12/7/2020 6:03 PM, Rick C wrote:
This design group I am in is being led by a mechanical engineer who has his limitation. Initially I thought it was just that he didn\'t know much about electronics. Then I found his thinking for mechanical issues to be a bit lacking in sophistication. Now I realize he doesn\'t understand fundamental principles of analysis.

I was not involved in the project from the start. They had built a revision 1 of the board which was essentially an arduino with a motor controller chip and some comparators. I realized they were not very skilled at electronics design and figured I could help.

What I didn\'t realize was the extent of ignorance in project development and management. The entire project has moved along in fits and spurts and many, many backflips because of a lack of initial analysis and specification of requirements.

All through this project they have been planning to measure flow rate by means of detecting the differential pressure across an orifice. They had a guy who seemed to have that as his sole task so I expected it was covered. There were concerns about the resolution at the low end so a separate circuit was added to provide more gain for the low end giving more resolution. Again, I expected they had it under control.

I am designing much of the FPGA that reads the differential sensor and other inputs to calculate the flow rate. The ADC will be a delta-sigma built in the FPGA with over 17 bits of resolution. I\'m thinking that is enough, but to be sure I ask for a number for the resolution in flow rate required...
What is the cause of the fucking feature-creep/spec changes in this
project? It went from an Arduino and comparators to 100 MHz FPGAs and 14
bit DACs. There are commercial ventilators saving lives every day with
less processing power than a 16 bit MSP430. In what universe does a
ventilator ADC need 14 bits of accuracy?

Actually, there is a commercial ventilator design made public as it is no longer produced. It has a high pin out MCU that is at least a high end MSP430 equivalent if not a lot more. It\'s one of the Asian company proprietary CPUs so I didn\'t look up the details. They had some very fancy dancy circuitry such as two back up batteries and a backup battery for the alarm or something like that. There were two speakers for the alarm and a current monitor to assure the speakers were passing the right current... ad infinitum almost. So don\'t tell me we are over designing...

You clearly are not familiar with the equations for obtaining flow rate from a differential pressure across an orifice. It uses a square root which gives a much steeper slope on the lower end than the upper making it very sensitive to measurement errors at the low end of the range. The problem is not that we don\'t need 14 bits of resolution, but that we also need that much accuracy and we won\'t even be able to approach that level of accuracy from the pressure sensor. The project lead is now trying to make an argument that my analysis of the error assumed the worst case, a constant flow rate over the longest inspiration time while the typical flow rate is well above that level and only low for a short interval. Since the requirement is on tidal volume and not flow rate he is saying our accuracy is much higher. Unfortunately the spec calls out the accuracy for any volume over 50 ml. So even if a flow pattern of other than even for the entire 3 seconds is assumed, there is no way to even approach the requirement because of the huge relative error in the sensor, ±2.5% of full scale which becomes ±25% of the measured value at a value of 10%FS. I just did some calcs that show the sensor error with an error fixed to the Full Scale value (increasing relative error as the value measured decreases), crosses the line of the allowed error in the volume measurement at a bit under 500 ml/s flow rate. This does assume a constant flow rate over a 3 second period and a sloping flow rate does improve the accuracy, but the slope can not be assured to be any particular pattern. There is no spec on the flow rate shape.
In fixed-point at least sqrt(ab) = sqrt(a)sqrt(b) so you could isolate
the cases where your square root result exceeds the error budget, shift
up n bits, take the square root, divide by two and shift back down.

I\'d assume it is not taking the square root that is the issue but the non linear sensor response

In that case I think the traditional method of improving accuracy is to
use multiple sensors (ideally not the same kind of sensor) and something
like Kalman filtering/predictor-corrector methods to estimate the true
value from a set of measurements that are corrupted by noise and/or
non-linearity, if the non-linearity can at least be profiled and
linearized over some domain of interest, that is to say it\'s not _too_
nonlinear.

 

[bitrex]

On 12/8/2020 9:42 PM, bitrex wrote:

On 12/8/2020 6:59 PM, Lasse Langwadt Christensen wrote:
onsdag den 9. december 2020 kl. 00.34.44 UTC+1 skrev bitrex:
On 12/8/2020 3:03 PM, Rick C wrote:
On Tuesday, December 8, 2020 at 1:01:14 PM UTC-5, bitrex wrote:
On 12/7/2020 6:03 PM, Rick C wrote:
This design group I am in is being led by a mechanical engineer
who has his limitation. Initially I thought it was just that he
didn\'t know much about electronics. Then I found his thinking for
mechanical issues to be a bit lacking in sophistication. Now I
realize he doesn\'t understand fundamental principles of analysis.

I was not involved in the project from the start. They had built a
revision 1 of the board which was essentially an arduino with a
motor controller chip and some comparators. I realized they were
not very skilled at electronics design and figured I could help.

What I didn\'t realize was the extent of ignorance in project
development and management. The entire project has moved along in
fits and spurts and many, many backflips because of a lack of
initial analysis and specification of requirements.

All through this project they have been planning to measure flow
rate by means of detecting the differential pressure across an
orifice. They had a guy who seemed to have that as his sole task
so I expected it was covered. There were concerns about the
resolution at the low end so a separate circuit was added to
provide more gain for the low end giving more resolution. Again, I
expected they had it under control.

I am designing much of the FPGA that reads the differential sensor
and other inputs to calculate the flow rate. The ADC will be a
delta-sigma built in the FPGA with over 17 bits of resolution. I\'m
thinking that is enough, but to be sure I ask for a number for the
resolution in flow rate required...
What is the cause of the fucking feature-creep/spec changes in this
project? It went from an Arduino and comparators to 100 MHz FPGAs
and 14
bit DACs. There are commercial ventilators saving lives every day with
less processing power than a 16 bit MSP430. In what universe does a
ventilator ADC need 14 bits of accuracy?

Actually, there is a commercial ventilator design made public as it
is no longer produced. It has a high pin out MCU that is at least a
high end MSP430 equivalent if not a lot more. It\'s one of the Asian
company proprietary CPUs so I didn\'t look up the details. They had
some very fancy dancy circuitry such as two back up batteries and a
backup battery for the alarm or something like that. There were two
speakers for the alarm and a current monitor to assure the speakers
were passing the right current... ad infinitum almost. So don\'t tell
me we are over designing...

You clearly are not familiar with the equations for obtaining flow
rate from a differential pressure across an orifice. It uses a
square root which gives a much steeper slope on the lower end than
the upper making it very sensitive to measurement errors at the low
end of the range. The problem is not that we don\'t need 14 bits of
resolution, but that we also need that much accuracy and we won\'t
even be able to approach that level of accuracy from the pressure
sensor. The project lead is now trying to make an argument that my
analysis of the error assumed the worst case, a constant flow rate
over the longest inspiration time while the typical flow rate is
well above that level and only low for a short interval. Since the
requirement is on tidal volume and not flow rate he is saying our
accuracy is much higher. Unfortunately the spec calls out the
accuracy for any volume over 50 ml. So even if a flow pattern of
other than even for the entire 3 seconds is assumed, there is no way
to even approach the requirement because of the huge relative error
in the sensor, ±2.5% of full scale which becomes ±25% of the
measured value at a value of 10%FS. I just did some calcs that show
the sensor error with an error fixed to the Full Scale value
(increasing relative error as the value measured decreases), crosses
the line of the allowed error in the volume measurement at a bit
under 500 ml/s flow rate. This does assume a constant flow rate over
a 3 second period and a sloping flow rate does improve the accuracy,
but the slope can not be assured to be any particular pattern. There
is no spec on the flow rate shape.
In fixed-point at least sqrt(ab) = sqrt(a)sqrt(b) so you could isolate
the cases where your square root result exceeds the error budget, shift
up n bits, take the square root, divide by two and shift back down.

I\'d assume it is not taking the square root that is the issue but the
non linear sensor response



In that case I think the traditional method of improving accuracy is to
use multiple sensors (ideally not the same kind of sensor) and something
like Kalman filtering/predictor-corrector methods to estimate the true
value from a set of measurements that are corrupted by noise and/or
non-linearity, if the non-linearity can at least be profiled and
linearized over some domain of interest, that is to say it\'s not _too_
nonlinear.

Rick C\'s Tesla autodrive-thing probably uses techniques like this, no
one sensor has the accuracy to judge another vehicle or object\'s
position to within a foot at 1000 feet away by itself but at 75 mph
having accuracy at range is important