Standard Terminology

[DeeEmm]

Yes, I understand what you say about the negative values and the depression heading, being a double negative!!!! Personally I would prefer the GUI "Title" to say something like Pressure 1 and Pressure 2 as I think this will help keep the code less confusing when reverse flow is implemented etc as the code for the tasks PRef and PDiff are used for, invert PRef will be doing the job of PDiff and vice versa, possibly consider changing the labelling for the sensors on future PCBs too.

• I think currently the "Title" should match what is on the PCB currently.

Need to consider that in V3 the additional Temp sensor needed for reverse flow and its naming too, possibly a new naming convention for example T1, P1 and T2, P2. Temp and Pressure at location 1 & location 2.

Yeah, in agreement about SI units, I think they must of been thought up by someone with a bit of common sense 👍

---

Thinking forward a little too in relation to reverse flow. What we see currently as a leak, is a gain in CFM. With reverse flow the leak will be a loss in CFM and in theory should be the same absolute value, but in reality will be slightly different due to the reverse flow testing will create a positive change for the reverse flow "increased Baro Pressure", where as the corrections for the normal flow direction see a "decreased Baro Pressure"

From Calculations.cpp

  // TODO validate reference pressure adjustment - do we add it or subtract it? Should be baro pressure less vac amount
  double refPressurePascals = sensorVal.BaroPA - this->convertPressure(sensorVal.PRefKPA, PASCALS) ;

Originally posted by @KirikauKiwi in https://github.com/DeeEmm/DIY-Flow-Bench/issues/224#issuecomment-2469522076

[DeeEmm]

Personally I would prefer the GUI "Title" to say something like Pressure 1 and Pressure 2 as I think this will help keep the code less confusing when reverse flow is implemented etc as the code for the tasks PRef and PDiff are used for, invert PRef will be doing the job of PDiff and vice versa,

This is an interesting consideration and one I had not thought of. I think that pRef and pDiff retain the same function, but the signs swap with the direction change i.e. vac to pressure.

• I think currently the "Title" should match what is on the PCB currently.

Also very valid. This is pDiff / pRef / pitot - same as per the code. However it is not exactly a brilliant and inspired choice lol

Need to consider that in V3 the additional Temp sensor needed for reverse flow and its naming too, possibly a new naming convention for example T1, P1 and T2, P2. Temp and Pressure at location 1 & location 2.

And herein is part of the problem. Initial code development has set some of these descriptions, but without consideration to things like the requirements for reverse flow. Back when I started this I was more concerned with actually making something that worked, so language choices were perhaps not the best.

As I mentioned before there is definitely room for improvement and use of common language i.e. same functional descriptors as used on traditional benches, is the way to go.

I did think of a way that the description for 'Depression' could be retained. It is possible to simply change the text when the bench is running in reverse. i.e. change it to 'Pressure' or similar. The associated code changes for dealing with the sign of the data and how offsets are handled will also ned to be changed but there is definitely value in aligning language with industry norms.

I think we should break this discussion out into a dedicated issue an review it for V3. Currently the language in the GUI is not 'broken' as such, but I will concede that there is a lot of room for improvement. That way we can agree on some standard terminology and then implement it properly.

I am also pushing back on this at this time because I know how much work it will involve.

[KirikauKiwi]

Personally I would prefer the GUI "Title" to say something like Pressure 1 and Pressure 2 as I think this will help keep the code less confusing when reverse flow is implemented etc as the code for the tasks PRef and PDiff are used for, invert PRef will be doing the job of PDiff and vice versa,

This is an interesting consideration and one I had not thought of. I think that pRef and pDiff retain the same function, but the signs swap with the direction change i.e. vac to pressure.

Yes this is true regarding the change from vac to pressure. However DIYFB is using a ratio metric formula for getDifferentialFlow(),code snippet below for the normal flow direction. When reversing the flow won't the two values retrieved by the formula need to be inverted, because the sensorVal.PDiffKPA is actually being measured by PRef sensor in the case of reverse flow situation and vice versa

getDifferentialFlow()

    // Calculate flow rate based on calibrated orifice data, ref pressure and current pressure drop
    flowRatio = sensorVal.PDiffKPA / sensorVal.PRefKPA;
    flowRateCFM = flowRatio * orificeFlowRate;

[KirikauKiwi]

Or another thought is that the "Titles" for these readings become dynamic, so what ever word is used for the titles gets placed/displayed depending on the use of the bench. e.g. for a Normal flow situation the "Title" for the PRef sensor could stay as "Depression" as long as the absolute of the sensorVal.PRefKPA is used and then that same block "Title" changes to "Pressure" for reverse flow situation and would be displaying the value from sensorVal.PDiffKPA.

That way the GUI would not appear any different to the end user other than the "Titles" changing for the "Depression/Pressure" and then the "Diff pressure" only needs to display the absolute sensorVal.PDiffKPA sensor when in Normal flow and display the sensorVal.PRefKPA for reverse flow mode.

This would keep the language used as industry/accepted norms and remove the problem of the "Depression" currently displaying a negative value, thus eliminating the double negative discussed.

Food for thought.

[KirikauKiwi]

Had the thought whilst in #224 that currently the DIYFB GUI is a mix of imperial and metric units and that when you switch to Fahrenheit that the Baro Pressure should switch to inHg or millibars which is the same as hPa 😂 as this is what is typical in the USA, not sure if hPa would be understood in the USA compare to millibars. I really need to look at the GUI 😂 you already have millibars so Temp °C / °F is the only thing needed which is already included. 🤦‍♂️

I get that CFM is pretty much the global standard for Engine Flow benching.

I find it odd here in the UK, originally from NZ. That the UK is essentially metric other than when it comes to distances and speeds being in miles and mph. 🤷‍♂️

In V3 it would be good to have a metric view too, given the prevalence of ECU's and the tuning community's familiarity with MAF sensors and flow rates viewable in vehicle CAN data etc.

[DeeEmm]

Haha, yes, we went metric back in 1971, although we still used imperial weights and measures for produce up until the 90's, when Brussels forced everyone to switch to g + kg. Some shops still work in thou (mine included) mostly as there is still a lot of imperial machinery still around (that stuff lasts forever).

CAN generally reports in mg/sec, g/min or kg/h depending on the manufacturer (we currently don't support frequency)

MAF ECU maps generally display the values from the transfer function, so what you see is a range of arbitrary Y axis values. There is no standard as such because all transfer functions are different, some are mg/sec, some g/min, kg/h and some are frequency based. So it looks different in each case. Much like speed density tuning it's just an arbitrary load versus RPM (although admittedly MAP is a little easier to comprehend). Tuning is never actually carried out in terms of flow.

For CAN we already have the metric output which is the unconverted MAF value in kg/min. We could add in other units as these are already present in the code

We can also add in m3/min or cc/sec or whatever other units are required but would need to add the conversion code.

[KirikauKiwi]

Whilst getting involved with DIYFB, I have started to ponder Calibration vs. Compensation and how they could be used in side DIYFB

Here is a summary from ChatGPT.

The terms **calibrated** and **compensated** are often used in the context of test equipment, but they refer to different concepts. Here's a breakdown of the key differences: ### 1. **Calibrated Test Equipment** **Calibration** refers to the process of adjusting and verifying a piece of equipment against known standards to ensure that its measurements are accurate and within specified tolerances. - **What it means**: When test equipment is **calibrated**, it has been tested and adjusted to ensure its readings match a reference standard. The equipment is checked against a known and accurate source (like a reference device, national standards, or a certified calibration source). - **How it works**: Calibration involves comparing the equipment’s readings to a standard and making adjustments (if necessary) to ensure the equipment produces accurate measurements. - **Purpose**: Calibration is performed to guarantee that the test equipment gives accurate and reliable results over time. It also helps maintain traceability to national or international measurement standards. - **Example**: A **digital multimeter (DMM)** might be calibrated by comparing its voltage reading to a known reference voltage source (e.g., a precision voltage standard). **Key Characteristics**: - Ensures accuracy. - Done at regular intervals. - Typically involves adjustments or verification to bring the instrument in line with standard measurements. - Equipment is issued a **calibration certificate** to show it is within specifications. --- ### 2. **Compensated Test Equipment** **Compensation** refers to the adjustment made to the equipment to account for known measurement errors or deviations in specific conditions (e.g., temperature, humidity, voltage, or other environmental factors). - **What it means**: When a test instrument is **compensated**, it is adjusted for known factors that could affect its performance. This might be a setting or correction that adjusts the instrument's readings based on environmental factors, or it could mean pre-setting certain parameters to reduce measurement errors. - **How it works**: Compensation might not involve the same full verification process as calibration. It often deals with known environmental or operational conditions that affect the equipment's behavior, and software or hardware adjustments are made to correct for these. - **Purpose**: The goal of compensation is to account for predictable variables that may affect measurements, such as **temperature** or **drift over time**, to keep the equipment within acceptable operational limits. It's a way to mitigate errors without needing to recalibrate. - **Example**: A **thermometer** might be compensated for its **temperature coefficient** (i.e., how its accuracy drifts with temperature) by including a correction factor in the readout. **Key Characteristics**: - Adjusts for specific, known conditions or factors (e.g., temperature, drift, or non-ideal conditions). - Does not necessarily ensure overall accuracy across all measurements. - Compensation can be done manually by the user (e.g., entering a correction factor) or automatically by the equipment. - Does not necessarily involve full verification against standards, unlike calibration. --- ### Key Differences Between Calibration and Compensation: | Feature | **Calibration** | **Compensation** | |---------------------------|------------------------------------------------------------|---------------------------------------------------------------| | **Purpose** | To ensure overall measurement accuracy according to a standard | To adjust for known environmental or operational effects (e.g., temperature, drift) | | **Process** | Involves verifying and possibly adjusting the equipment using known standards | Involves applying corrections to account for specific errors | | **Effect** | Ensures the device gives accurate readings in all conditions | Adjusts for specific conditions but does not guarantee absolute accuracy | | **Verification** | Requires comparison to a reference or standard | May or may not involve standard comparison | | **Frequency** | Typically done periodically or after repairs | Can be done regularly or dynamically (e.g., real-time compensation) | | **Example** | Calibrating a digital voltmeter against a precision reference | Compensating a temperature sensor for ambient temperature effects | --- ### Practical Examples: - **Calibrated Test Equipment**: A **calibrated oscilloscope** might be checked against a precision time base to ensure that its frequency measurements are accurate. The calibration process ensures that the oscilloscope is operating correctly and can be trusted to measure time and voltage correctly. - **Compensated Test Equipment**: A **compensated power supply** might adjust its voltage output based on the load resistance to maintain consistent output, even though the exact voltage might drift under different conditions. This "compensation" helps the device maintain its performance across various operational environments. --- ### Conclusion: - **Calibration** is a process of ensuring the accuracy of the equipment by adjusting or verifying its readings against a known standard, ensuring overall correctness. - **Compensation** is a process of adjusting the equipment's output or readings to account for known or predictable conditions that might affect its performance, without necessarily guaranteeing full accuracy across all conditions. Both processes are important for maintaining the performance of test equipment, but calibration is typically more comprehensive and tied to standard measurement accuracy, while compensation is about correcting known variables.

[DeeEmm]

TLDR

The software currently does both.

• We calibrate to a known reference standard (even if that standard is of dubious quality lol)

• We compensate for temperature, humidity & barometric changes. Also in the case of Adjusted Flow, we compensate for fluctuations in reference pressure.