There are Idiots and There are Idiots...

[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

 

[Rick C]

On Tuesday, December 8, 2020 at 6:34:44 PM UTC-5, bitrex wrote:

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.

The issue is not the calculation. I was going to do that with iteration. The issue is the initial accuracy of the data becomes rapidly worse at the lower end of the scale so that it nullifies any attempt to maintain useful resolution at the low end of the square root. The square root reduces the resulting resolution and actually improves the accuracy, so I should not have mentioned that. The issue is we were focusing on improving the resolution when the real problem is the sensor accuracy is so poor at the low end.

I\'m trying to work on the parts that I am good at, but I keep finding where they have messed up so badly on the parts I need to have working for my stuff to work.

--

Rick C.

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

 

[Rick C]

On Tuesday, December 8, 2020 at 6:34:44 PM UTC-5, bitrex wrote:

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.

The issue is not the calculation. I was going to do that with iteration. The issue is the initial accuracy of the data becomes rapidly worse at the lower end of the scale so that it nullifies any attempt to maintain useful resolution at the low end of the square root. The square root reduces the resulting resolution and actually improves the accuracy, so I should not have mentioned that. The issue is we were focusing on improving the resolution when the real problem is the sensor accuracy is so poor at the low end.

I\'m trying to work on the parts that I am good at, but I keep finding where they have messed up so badly on the parts I need to have working for my stuff to work.

--

Rick C.

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

 

[Rick C]

On Tuesday, December 8, 2020 at 7:00:07 PM UTC-5, lang...@fonz.dk 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

Not sure where the miscommunication is. The sensor is linear, but has an error that is related to the full scale value rather than a percentage of the value read. At ±2.5%FS error, the relative error at a 10%FS reading becomes ±25%!

--

Rick C.

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

 

[Rick C]

On Tuesday, December 8, 2020 at 7:00:07 PM UTC-5, lang...@fonz.dk 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

Not sure where the miscommunication is. The sensor is linear, but has an error that is related to the full scale value rather than a percentage of the value read. At ±2.5%FS error, the relative error at a 10%FS reading becomes ±25%!

--

Rick C.

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

 

[server]

On Tue, 8 Dec 2020 18:34:35 -0500, bitrex <user@example.net> 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.

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.

In floating point normalize the value so that the exponent is even
i.e. the mantissa is between 1 .. 4. Use a polynomial for the mantissa
to calculate the square root, which will be between 1 .. 2.. A 3rd or
4th order polynomial should be enough for single precision accuracy.
Divide exponent by 2 and combine it with the polynomial result.

 

[server]

On Tue, 8 Dec 2020 18:34:35 -0500, bitrex <user@example.net> 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.

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.

In floating point normalize the value so that the exponent is even
i.e. the mantissa is between 1 .. 4. Use a polynomial for the mantissa
to calculate the square root, which will be between 1 .. 2.. A 3rd or
4th order polynomial should be enough for single precision accuracy.
Divide exponent by 2 and combine it with the polynomial result.

 

[bitrex]

On 12/8/2020 10:49 PM, Rick C wrote:

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.

The issue is not the calculation. I was going to do that with iteration. The issue is the initial accuracy of the data becomes rapidly worse at the lower end of the scale so that it nullifies any attempt to maintain useful resolution at the low end of the square root. The square root reduces the resulting resolution and actually improves the accuracy, so I should not have mentioned that. The issue is we were focusing on improving the resolution when the real problem is the sensor accuracy is so poor at the low end.

I\'m trying to work on the parts that I am good at, but I keep finding where they have messed up so badly on the parts I need to have working for my stuff to work.

I think John Doe is right for once you\'re mostly pissed that you signed
onto this project in the first place, there isn\'t an actual problem here
for anyone to help solve, at least not one anyone can get their head
around. You mostly bitchin\' like an old lady.

Either state a practical problem in a coherent way someone here can help
solve or grow a pair and walk out on this bullshit, one or the other. IMO

 

[bitrex]

On 12/8/2020 10:49 PM, Rick C wrote:

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.

The issue is not the calculation. I was going to do that with iteration. The issue is the initial accuracy of the data becomes rapidly worse at the lower end of the scale so that it nullifies any attempt to maintain useful resolution at the low end of the square root. The square root reduces the resulting resolution and actually improves the accuracy, so I should not have mentioned that. The issue is we were focusing on improving the resolution when the real problem is the sensor accuracy is so poor at the low end.

I\'m trying to work on the parts that I am good at, but I keep finding where they have messed up so badly on the parts I need to have working for my stuff to work.

I think John Doe is right for once you\'re mostly pissed that you signed
onto this project in the first place, there isn\'t an actual problem here
for anyone to help solve, at least not one anyone can get their head
around. You mostly bitchin\' like an old lady.

Either state a practical problem in a coherent way someone here can help
solve or grow a pair and walk out on this bullshit, one or the other. IMO

 

[bitrex]

On 12/8/2020 10:49 PM, Rick C wrote:

The issue is not the calculation. I was going to do that with iteration. The issue is the initial accuracy of the data becomes rapidly worse at the lower end of the scale so that it nullifies any attempt to maintain useful resolution at the low end of the square root. The square root reduces the resulting resolution and actually improves the accuracy, so I should not have mentioned that. The issue is we were focusing on improving the resolution when the real problem is the sensor accuracy is so poor at the low end.

I\'m trying to work on the parts that I am good at, but I keep finding where they have messed up so badly on the parts I need to have working for my stuff to work.

IOW it sounds like you\'re trying to rationalize or feel like you need
permission to walk on this job. You don\'t need permission from anyone
here bro just walk if it will relieve the stress and make you feel
better (probably.)

OTOH if there\'s a problem to solve the bitchin\' distracts from the
problem in posts that are half-problem, half-bitchin. Suggest putting
the bitchin\' about clients in an OT thread.

 

[bitrex]

On 12/8/2020 10:49 PM, Rick C wrote:

The issue is not the calculation. I was going to do that with iteration. The issue is the initial accuracy of the data becomes rapidly worse at the lower end of the scale so that it nullifies any attempt to maintain useful resolution at the low end of the square root. The square root reduces the resulting resolution and actually improves the accuracy, so I should not have mentioned that. The issue is we were focusing on improving the resolution when the real problem is the sensor accuracy is so poor at the low end.

I\'m trying to work on the parts that I am good at, but I keep finding where they have messed up so badly on the parts I need to have working for my stuff to work.

IOW it sounds like you\'re trying to rationalize or feel like you need
permission to walk on this job. You don\'t need permission from anyone
here bro just walk if it will relieve the stress and make you feel
better (probably.)

OTOH if there\'s a problem to solve the bitchin\' distracts from the
problem in posts that are half-problem, half-bitchin. Suggest putting
the bitchin\' about clients in an OT thread.

 

[Rick C]

On Wednesday, December 9, 2020 at 12:24:44 AM UTC-5, bitrex wrote:

On 12/8/2020 10:49 PM, Rick C wrote:
The issue is not the calculation. I was going to do that with iteration.. The issue is the initial accuracy of the data becomes rapidly worse at the lower end of the scale so that it nullifies any attempt to maintain useful resolution at the low end of the square root. The square root reduces the resulting resolution and actually improves the accuracy, so I should not have mentioned that. The issue is we were focusing on improving the resolution when the real problem is the sensor accuracy is so poor at the low end.

I\'m trying to work on the parts that I am good at, but I keep finding where they have messed up so badly on the parts I need to have working for my stuff to work.

IOW it sounds like you\'re trying to rationalize or feel like you need
permission to walk on this job. You don\'t need permission from anyone
here bro just walk if it will relieve the stress and make you feel
better (probably.)

OTOH if there\'s a problem to solve the bitchin\' distracts from the
problem in posts that are half-problem, half-bitchin. Suggest putting
the bitchin\' about clients in an OT thread.

You seem to be overly crude at times. I\'m certainly not looking for your approval. I weighing the options and how I feel about it. I am using my posts here as a sounding board, not so much as a way to get feedback, but by voicing my thoughts it helps me figure them out.. at least for the decision of staying or not.

But I am asking for any assistance you care to offer on the technical aspects. However, giving me advice on how to calculate a square root is not addressing the problem I am talking about. In fact, I\'m pretty sure at this point there is no solution with the present hardware setup. It is fundamentally flawed by the constant magnitude error as the signal reduces. This sensor will never be suitable for this particular use where high resolution and accuracy is needed at small signal levels.

When I think about this is when I realize that these sorts of mistakes have been a problem all along. The project lead has made choices after not fully understanding the issues. Then when problems are pointed out they are smoothed over with a band aid because of an extreme reluctance to change course. This festers and weeks or months later the real magnitude of the problem emerges and the hard decision has to be made. Now, however, it has a much larger impact, more work has to be tossed out and redone with a new approach.

Yeah, I\'m bitching about it. Is that a problem? It\'s one thing to have to toss work once in a while. But this is a recurring problem on this project and that is due to one thing only, poor planning. Very, very poor planning. Actually, this thread is about the bitchin. Didn\'t you read the subject?

I feel pretty settled on my decision to stay enough to complete the calculator design. I\'ve also decided to start designing in the digital flow sensor. That will make my work a bit easier and let me get it done and tested without tons of messing about with goofy formulas. I\'m also working with a kid, just a year or so out of school who is working on the interface to the MCU. The software guy wanted to use a CRC32 to protect the data we send back and forth. Seems like over kill to me (both chips are on the same board) but I\'m letting the kid learn the CRC32 algorithm. He\'s having some trouble with it. I think he needs to learn that the simulator is your friend. I\'m enjoying that.

--

Rick C.

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

 

[bitrex]

On 12/9/2020 2:25 AM, Rick C wrote:

On Wednesday, December 9, 2020 at 12:24:44 AM UTC-5, bitrex wrote:
On 12/8/2020 10:49 PM, Rick C wrote:
The issue is not the calculation. I was going to do that with iteration. The issue is the initial accuracy of the data becomes rapidly worse at the lower end of the scale so that it nullifies any attempt to maintain useful resolution at the low end of the square root. The square root reduces the resulting resolution and actually improves the accuracy, so I should not have mentioned that. The issue is we were focusing on improving the resolution when the real problem is the sensor accuracy is so poor at the low end.

I\'m trying to work on the parts that I am good at, but I keep finding where they have messed up so badly on the parts I need to have working for my stuff to work.

IOW it sounds like you\'re trying to rationalize or feel like you need
permission to walk on this job. You don\'t need permission from anyone
here bro just walk if it will relieve the stress and make you feel
better (probably.)

OTOH if there\'s a problem to solve the bitchin\' distracts from the
problem in posts that are half-problem, half-bitchin. Suggest putting
the bitchin\' about clients in an OT thread.

You seem to be overly crude at times. I\'m certainly not looking for your approval. I weighing the options and how I feel about it. I am using my posts here as a sounding board, not so much as a way to get feedback, but by voicing my thoughts it helps me figure them out.. at least for the decision of staying or not.

But I am asking for any assistance you care to offer on the technical aspects. However, giving me advice on how to calculate a square root is not addressing the problem I am talking about. In fact, I\'m pretty sure at this point there is no solution with the present hardware setup. It is fundamentally flawed by the constant magnitude error as the signal reduces. This sensor will never be suitable for this particular use where high resolution and accuracy is needed at small signal levels.

When I think about this is when I realize that these sorts of mistakes have been a problem all along. The project lead has made choices after not fully understanding the issues. Then when problems are pointed out they are smoothed over with a band aid because of an extreme reluctance to change course. This festers and weeks or months later the real magnitude of the problem emerges and the hard decision has to be made. Now, however, it has a much larger impact, more work has to be tossed out and redone with a new approach.

Yeah, I\'m bitching about it. Is that a problem? It\'s one thing to have to toss work once in a while. But this is a recurring problem on this project and that is due to one thing only, poor planning. Very, very poor planning.

Yeah because it distracts from the problem itself. If you\'re going to
post a wall of text it would be helpful to use it instead to recap what
the project is, what state the project is in now and just generally more
targeted info about the specific thing. Some of these posts start off in
media res like someone here is keeping notes on where you\'re or what
you\'re up to, now. Nobody keeping notes.

Took four paragraphs to start to get to something technical and it\'s:

\"All through this project they have been planning to measure flow rate
by means of detecting the differential pressure across an orifice.\"

Which project? What orifice? which pressure? What flow rate of what?
What the hell is going on? Nobody has a notebook that says \"Rick C\'s
Projects Technical Specifications\", dude!

Actually, this thread is about the bitchin. Didn\'t you read the subject?

Ok glad you admitted it at least. But bitchin\' and getting good answers
are at cross-purposes I think.

I feel pretty settled on my decision to stay enough to complete the calculator design. I\'ve also decided to start designing in the digital flow sensor. That will make my work a bit easier and let me get it done and tested without tons of messing about with goofy formulas. I\'m also working with a kid, just a year or so out of school who is working on the interface to the MCU. The software guy wanted to use a CRC32 to protect the data we send back and forth. Seems like over kill to me (both chips are on the same board) but I\'m letting the kid learn the CRC32 algorithm. He\'s having some trouble with it. I think he needs to learn that the simulator is your friend. I\'m enjoying that.

Ok

 

[bitrex]

On 12/9/2020 2:25 AM, Rick C wrote:

On Wednesday, December 9, 2020 at 12:24:44 AM UTC-5, bitrex wrote:
On 12/8/2020 10:49 PM, Rick C wrote:
The issue is not the calculation. I was going to do that with iteration. The issue is the initial accuracy of the data becomes rapidly worse at the lower end of the scale so that it nullifies any attempt to maintain useful resolution at the low end of the square root. The square root reduces the resulting resolution and actually improves the accuracy, so I should not have mentioned that. The issue is we were focusing on improving the resolution when the real problem is the sensor accuracy is so poor at the low end.

I\'m trying to work on the parts that I am good at, but I keep finding where they have messed up so badly on the parts I need to have working for my stuff to work.

IOW it sounds like you\'re trying to rationalize or feel like you need
permission to walk on this job. You don\'t need permission from anyone
here bro just walk if it will relieve the stress and make you feel
better (probably.)

OTOH if there\'s a problem to solve the bitchin\' distracts from the
problem in posts that are half-problem, half-bitchin. Suggest putting
the bitchin\' about clients in an OT thread.

You seem to be overly crude at times. I\'m certainly not looking for your approval. I weighing the options and how I feel about it. I am using my posts here as a sounding board, not so much as a way to get feedback, but by voicing my thoughts it helps me figure them out.. at least for the decision of staying or not.

This is not Phil A. crude, this is New England-direct. If what you
actually want is just opinions on if this is a project that is worth
sticking with or a sounding board why not just ask for that in the
title? ???

 

[Martin Brown]

On 09/12/2020 08:13, bitrex wrote:

Took four paragraphs to start to get to something technical and it\'s:

\"All through this project they have been planning to measure flow rate
by means of detecting the differential pressure across an orifice.\"

Which project? What orifice? which pressure? What flow rate of what?
What the hell is going on? Nobody has a notebook that says \"Rick C\'s
Projects Technical Specifications\", dude!

What sort of minimum flow rate do you need to measure?

You might be better off with a hot wire anemometer although such a
change might be difficult if you are already committed to hardware. eg

https://www.engineersedge.com/instrumentation/anemometer_hot_wire.htm

They can be made fairly sensitive (though Pt wire isn\'t cheap).

--
Regards,
Martin Brown

 

[Jasen Betts]

On 2020-12-09, Martin Brown <\'\'\'newspam\'\'\'@nonad.co.uk> wrote:

On 09/12/2020 08:13, bitrex wrote:

Took four paragraphs to start to get to something technical and it\'s:

\"All through this project they have been planning to measure flow rate
by means of detecting the differential pressure across an orifice.\"

Which project? What orifice? which pressure? What flow rate of what?
What the hell is going on? Nobody has a notebook that says \"Rick C\'s
Projects Technical Specifications\", dude!

What sort of minimum flow rate do you need to measure?

You might be better off with a hot wire anemometer although such a
change might be difficult if you are already committed to hardware. eg

https://www.engineersedge.com/instrumentation/anemometer_hot_wire.htm

They can be made fairly sensitive (though Pt wire isn\'t cheap).

It\'s cheap enough accurate enough and rugged enough to find use in
automotive mass air flow sensors.

--
Jasen.

 

[Rick C]

On Wednesday, December 9, 2020 at 4:39:17 AM UTC-5, Martin Brown wrote:

On 09/12/2020 08:13, bitrex wrote:

Took four paragraphs to start to get to something technical and it\'s:

\"All through this project they have been planning to measure flow rate
by means of detecting the differential pressure across an orifice.\"

Which project? What orifice? which pressure? What flow rate of what?
What the hell is going on? Nobody has a notebook that says \"Rick C\'s
Projects Technical Specifications\", dude!
What sort of minimum flow rate do you need to measure?

You might be better off with a hot wire anemometer although such a
change might be difficult if you are already committed to hardware. eg

https://www.engineersedge.com/instrumentation/anemometer_hot_wire.htm

They can be made fairly sensitive (though Pt wire isn\'t cheap).

That question is the sticky wicket. No one has figured that out yet. The error specification is on the tidal volume, how much the patient breaths in.. For volumes of 50 ml and above the error is ±(4 ml + 15% of the actual value). Breath flow rate varies from the peak rate to zero. The tidal volume is the integral of the flow rate, or in discrete terms, the sum of the flow measurements. The sensor measures pressure which are converted to a flow rate via a square root. The sensor has an error spec based on a percentage of full scale, or in other words, fixed numbers rather than percentage. Do the math and the flow rate will also have a larger error on the smaller values... but since the lower flow rate has a smaller impact on the tidal volume than the higher values of flow rate, it\'s a hard thing to numerically evaluate. Assume a constant flow totaling 50 ml (the smallest spec value) the error is huge. But even at a flow rate of 10% of full scale, the pressure error is 25% of the reading equating to an error of 12% for the flow rate. Lower values very quickly increase in error relative to the quantity measured.

Hmmm... I could prepare a spread sheet that would calculate the errors for a few example breaths based on a triangular flow rate or a constant slope on the flow rate. The real problem is the error might be acceptable for a breath with a typical volume and there is no way to assure the volume will be typical. The system controls pressure, not flow. Yeah, I need to do some spread sheeting...

--

Rick C.

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

 

[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.

I don\'t think I mentioned that the power supply doesn\'t need to be good to microvolts because the sensors are ratiometric to the supply. If the supply goes up the signal from the sensor goes up in kind. So the ADC reference needs to go up as well to compensate. So the issue here is not a hugely accurate fixed reference, but rather keeping noise out so the supply voltage is the same all around. Then the 17.3 bits is obtained by integration of the samples for 5 ms, which is a pretty awesome filter.

Not at all trying to get 17 bits of accuracy really, just good accuracy and good resolution, meaning something like an MCU provides. The integration period is set by the update rate so we get 17.3 bits of counting if we like it or not. The math logic is in 18 bit hunks, so this matches pretty well..

--

Rick C.

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