Insane Hydraulics

Site theme image

Recovering an Old Parker Flow-Meter, Part Three - New MCU, Wet Tests and Calibration

This is the third and final part of my "flow meter recovering saga".

At usual - the "status quo":

I found out (details in part one and part two) that the AT89C2051 microcontroller in the signal converter board of my Parker flow-meter developed a "dead pin syndrome", and set out to replace it with a more recent ATtiny4313, that is available in the same SOIC-20 package, and uses the same pins for Vcc, Gnd, Rst, and the external crystal oscillator, which allows me to use it as a drop-in replacement with but minor changes to the original board.

Here's the schematic with the new MCU and my notes (download pdf version here):

Apparently, the damned COVID-19 pandemic disrupted the electronic parts supply chain bad enough for my usual source - the Mouser Europe - to be out of stock on the MCUs I was looking for, but in the end, I managed to source them on eBay for 1.89 eur a pop plus shipping (twice the normal price, if you care to know, but still cheap).

The plan for "hardware" modifications:

This is how the board looks after the "overhaul":

The 6-pin programming connector is tiny, and it fits nicely into the original housing. With the hardware part done, now I needed software to be able to measure the pulses with precision. Luckily, the task was simple because the "frequency range of interest" was so narrow.

The best way to measure such a low frequency with high resolution is to use the so-called reciprocal frequency measurement method, and so I developed a tiny program (once again - using another free and amazing tool - the Microchip Studio) that does exactly that - it measures the exact amount of time that passes between a known number of pulses, and then calculates the frequency. This is the best way to measure low-frequency sources if you need both sub-Hz resolution and a high refresh rate, and the fact that the MCU clock is driven by a crystal oscillator makes it a very precise time measuring device. The original board feeds the pulses into the D2 pin, and this was very handy because this pin happens to activate the INT0 interrupt, which I used to count the pulses.

I also wrote the DAC "driver" module, and included a linearization procedure in the main so that I could "calibrate at will". If you are interested in the C code - I created a GitHub repository for this project. The license is MIT, of course, so feel free to use and abuse!

But this is not a coding blog, this blog is about oil hydraulics - so you want to know if it worked or not, don't you? And I promise you - It worked like a charm, it did! Let me show you the tests. Since I had a general idea about the flow rate to pulse frequency relation from my previous experiments, I used the data I had to establish a set of 9 data points for the linearization procedure. The minimal frequency to measure was set at 3.00 Hz, and the maximal to 843.57 Hz. Then I uploaded the program to the MCU and tested it with my signal generator. My main objective was to see the precision and resolution. The result was surprising:

The pictures show the signal generator screen and the voltage measured at the output pin of the DAC chip. As you can see, at 3.0 Hz it reads a stable 10 millivolt, and at 2.9 Hz it switches to zero volt - exactly as my linearization function tells it to. The same happens at the other end of the measurement range - at 843.5 Hz the DAC outputs its maximum voltage of 2.0459 V, and a tenth of a Hz below - at 843.4 Hz it drops 0.0004 V to 2.0455 V, which is exactly one bit for the DAC. I am (pleasantly) surprised that I managed to achieve such precision with no crystal calibration whatsoever. The resolution was also as expected - at about every 0.2 Hz frequency change the DAC would shift one bit (0.0005 V). I was worried about racing conditions in the routines, but the readings were dead stable throughout the whole frequency range. This is just great!

With the system operational, it was time for the wet tests. So, I connected another 600 l/min flow turbine in series with this one, and also my beloved volumetric oval gear meter, and connected both flow sensors to the same Serviceman SCM-152 display. This model can display two channels at the same time, which is great for comparison.

Initial "wet test" produced the following:

The blue line represents the readings of the SCFT-600-02-02 turbine with an original flow sensor with built-in signal conditioning, the yellow line corresponds to the readings of the volumetric flow meter, and the red line is readings of the DIY signal converting solution. The flow rate starts at 6 l/min, and maxes out at 92 l/min, horizontal points 2 to 10 correspond to 10 l/min increments. Unfortunately, I don't have a higher flow rate source at my disposal right now, so wet tests with a higher flow will have to wait, but still - the max. deviation I registered was 2.6 l/minute, and as you can see - the first half of the flow curve actually coincides with the volumetric one - which I believe to be more precise. A 2.6 l/min deviation on a 600 l/min scale is not bad for theoretical data points. My curve seems to drop after a certain point in comparison to the other two - but hey, I have arbitrary linearization at my disposal, so I can draw whatever flow rate to frequency curve I want! (see how great a DIY solution is?)

Then I used the new data to adjust the point values in the linearization routine to see if I could match the two lines, and here are the wet test results after the "calibration":

Impressive, don't you agree?! I used 12 points in the points table (and these are 4-byte and 2-byte integers) - and the 256-byte RAM microcontroller didn't complain! I wonder where's the breaking point?

But that's not all. Since the program is custom and I can re-program the MCU as I wish, I could do all sorts of other things, if I wanted. Like adjusting the refresh rate (after some trials, I ended up with a variable refresh rate, with the period of about 0.8 seconds at the lowest frequency and 0.35 seconds above 50 Hz), or adding a temperature sensor, for example, the good old DS18B20, and applying temperature compensation, and even a separate output for temperature!

So, my friends, I can proudly say that now I have another working flow meter at my disposal, and, most importantly - I believe I got very lucky when the signal converter board failed the way it did because fixing it turned into a project that taught me so much!

See what I just did here? Something very expensive broke down on me, I and said I was lucky it did! Yep - that's my philosophy in regards to break-downs. Our life is full of them. Things break all the time. Even people break. This is life. I prefer looking at stuff that "goes south" as an opportunity to learn and grow, rather than misfortune or adversity! It is that simple.