I come from a background of little code and lots of head-smashing-against-keyboard with PIC processors, which normally do anything I ask them to do, in their own little quirky way.
But they suck at floating point math. Really, they do. And I suck at coding enough to not want to bother with doing floating point in assembly. And I've been looking for an excuse to play with one of these things.
So, here's what I need this thing to do. I need to use a mass flow sensor, pressure sensor, and temperature sensor, to derive volumetric flow rate across a test oriface, at a defined pressure drop.
Take 3 analog inputs in the 0 to 5v range, and perform at least 10 bit ADC
One input is temperature, one input is mass flow rate per second, and one input is absolute pressure.
Do some math based on the ideal gas law, Pv=nRT
Output the resulting volumetric flow rate and the pressure to an LCD display.
This can be done using a PIC micro; fairly easy right up until I get to the whole mass flow conversion part...I was going to use a lookup table and just pre-compute all the data, and have the micro look it up as needed. But the table would be very large...bigger than my available code space.
Can any of the Arduino systems do this kind of data handling?
The Arduino's internal ADC is ten bit so your 'at least' might require you to use an external ADC.
Reading some analog values and doing simple arithmetic on then doesn't necessarily imply any use of floating point, and in general I'd shy away from using floating point anyway because the 32-bit floating point gives very poor resolution, and it's relatively slow, and you lose control and visibility over the rounding/accuracy. I'd much rather use fixed point arithmetic for this sort of problem. (For example if you're using a value in meters, storing it in millimeters gives you three decimal places.)
PeterH:
I'd much rather use fixed point arithmetic for this sort of problem.
Agreed. You can use fixed-point for all internal math and then a simple display output function can put the decimal where it needs to go.
void displayFlow(const unsigned long rate)
{
lcd.print(rate / 100); // print all but last two digits
lcd.print(".");
lcd.print(rate % 100); // print only last two digits
}
Then again, Pv=nRT doesn't appear to be too hairy of a computation, at 16MHz you probably even wouldn't notice the performance hit of using FP. Update too fast and your LCD will "jitter" anyway, you probably don't want to display more than 4 to 10 times per second which leaves plenty of time for FP math.
void displayFlow(const unsigned long rate)
{
lcd.print(rate / 100); // print all but last two digits
lcd.print(".");
lcd.print(rate % 100); // print only last two digits
}
Some slight modification is required to this code to make it work properly.
The hard floating point stuff comes in when we start converting the voltage input from a hot-wire mass flow sensor to a value in kg/hr or lbs(mass)/hr. (or grams/second, or whathaveyou.)
It's a wicked looking formula that I just do not have the desire to use...I let a computer work it out for me once I test the sensor at 10 known rates. The voltage versus airflow curve appears to be a log curve...but it is not and every model of sensor has its own characteristic curve.
I planned to solve this issue in the PIC I normally work with by using a lookup table...but in this case the table would be too large, so I need a processor with a little more horsepower.
After all, the end result is a tool I use to warm up engines to produce more horsepower...and is available commercially for about ten grand.
Essentially, the system needs to read in ambient air temperature, barometric pressure (one-shot for cals), then the baro sensor is used after the initial calibration to display the pressure UNDER the device under test (cylinder head for an auto engine) so I can adjust the airflow to the industry standard test pressure. Once the test pressure is reached, the mass flow sensor output will be read in, converted to volumetric flow using the calculated air density, and displayed on the screen alongside the current test pressure.
So, I could use a "start test" button, or a more flexible option would be having the unit always reading at whatever rate I can support, then "home in" on the standard test pressure. Display outputs would be 0.0 to 999.0 CFM, and 0 to 99 Inches H2O.
I picked up an Arduino Micro today, and intend to get the LCD working the way I need it to.