crwper wrote:I would be concerned that the pump characteristics wouldn't be exactly the same as the spec, or that they would change over time.

As you mentioned, characterizing the pump could address the first issue quite well. You would need to control for temperature due to its effect on water's density. Flow meters would have the same issue with temperature, mind you.

Once characterized I would simply test the pump's maximum pressure regularly. If it hasn't moved, each piston stroke is still well sealed and is unlikely to be pushing a different volume of water, meaning your initial characterization should be valid. A pump showing signs of wear would have a diminished ability to pressurize the fluid.

I mention all this mostly because, from experience on larger (water treatment) systems, flow measurement is one of the least reliable measurements due to calibration issues, pipe/instrument fouling issues, installation errors (turbulence) and temperature variation. You have the added challenge of a very limited choice if technologies due to the very low flow rates here.

randytsuch wrote: That's better for low flow rates than any of the digmesa meters I've seen. I was looking at the 932-9505-B, but it only does 2382 pulses/l

Not sure how they come up with the min and max flow rates, so I started looking at pulses per liter.

Each Digmesa Nano model comes in two versions, with and without a 16:1 pulse divider. For example, the Digmesa Nano #9NB-0100/01A does 39,900 pulses/l and moves 0.025 ml per pulse. Presumably the pulse divider accommodates meters or microprocessors that can't keep up with the native pulse rate. My Arduino Uno would have no trouble keeping up with the higher pulses/l (the flow meter code is interrupt-driven.)

Note that .025 ml per pulse compares with about .45 ml per pulse produces by the stock Gicar flow meter in my GS/3. That's a big difference in resolution.

The flow rate range is determined by the measured linearity of the device. The device will operate at lower flow rates, but linearity isn't guaranteed. The charts in the Digmesa datasheet show that, depending on the model, linearity of +/- 1% or 2%, is maintained between the stated min and max flow rates. They don't show what happens below or above the range. You'd have to measure that yourself. It's possible to do that and add a fudge factor in the measurement code for flow rates below the stated range. AssafL does that in his code by using a different ml/pulse factor for preinfusion, though he measured a difference of only .001 ml/pulse (his measurements also showed that the actual flow rate within the stated range was .001 ml/pulse lower, and compensated for that in his code.)

randytsuch wrote: I wonder if my ESP32 could keep up? Well for now I'm going to keep what I have. May see if I can tweak it for better accuracy. Might look into changing the conversion factor at low rates as you suggested.

Arduino (Mega) has no problem keeping up so I don't think an ESP should have any issue. Obviously you'd want to map it to an interrupt pin so you don't miss a pulse and because it is very wasteful to run a loop for counting pulses (very short code! something like
void flowPulseReceived(bool preInfusion) // receives flow pulses from the Gicar flow sensor
{
g_flowPulseCount++;
g_flowPulseMillis = millis();
}
and then attach to interrupt:
// Attach flowmeter interrupt...
EIFR = _BV (INTF4); // clear a cached interrupt (not very important)
attachInterrupt(digitalPinToInterrupt(FLOW_COUNT_INPUT), flowPulseReceived, FALLING);

At high flow pulse counts, just counting the pulses may be enough. To make it more accurate I captured the millis() of the pulse.

Capturing millis() It also enabled higher resolution with the Gicar using the T=1/f relationship, just the same way a frequency counter expands its resolution at low frequencies. Albeit for that you'd also want a safety timer as the system won't otherwise identify a stall.

I ran calibration (two steady flow rates, one at PI rates, and the other at pull rates), Digmesa proved to be much more linear than the Gicar:
//Flowmeter Selection
//#define GICAR_FLOWMETER
#define DIGMESA_FLOWMETER // #9NB-0100/01A http://www.digmesa.com/wp-content/uploa ... 1_x_GB.pdf
#ifdef GICAR_FLOWMETER
double mlPerFlowMeterPulse = 0.48d; // 0.42f;// ml/pulse
double mlPerFlowMeterPulsePreInfusion = 0.34d; // 0.42f;// ml/pulse
#endif
#ifdef DIGMESA_FLOWMETER
double mlPerFlowMeterPulse = 0.0240d; // Calibrated values.... Spec is 0.025ml/pulse
double mlPerFlowMeterPulsePreInfusion = 0.0230d;
#endif

I'm not familiar with the ESP32 but with the Atmega328 you can feed the pulses into a timer as a clock so that no interrupt is needed. You just read the clock count every so often. Perhaps the ESP32 offers a similar functionality.

The ESP32 appears to be a much more powerful processor than an Atmega328 and you could very likely just use a simple interrupt handler to count pulses that arrive no more frequently than 20us or so. But it sure looks to me like it has at least the same level of functionality with regard to counting pulses in hardware:

https://docs.espressif.com/projects/esp ... /pcnt.html


Here's a guy who used an ESP32 with a flow meter:
https://medium.com/@ricardo_66479/count ... b0d8dd2829

If you want just dosimetric/volumetric trigger then a simple count will work.

I was trying to calculate flow (to do flow control) so it has to be something along the lines of number_of_Pulses * ml/Pulse * 1/(unit_of_time).

For that, having an amply "accurate" time is more important. By accurate time I mean a repeatable window of time.

If the pulses are really fast (at least 10's of pulses captured per processing loop) the exact timing that a pulse is received is inconsequential and the loop timer is sufficient.

If, however, the pulses occur slowly (say 1 or less than 1 per loop), and you calculate the flow each processing loop, you will want to capture the time or your flow reading will fluctuate quite a bit.

For those interested in a Digmesa Nano, the sample purchase website only offers model 9NB-0120/01A, which has slightly lower resolution than the 9NB-0100/01A that AssafL has. I contacted sales and they said the website is a work in progress, and that I could order the 9NB-0100/01A directly for the same price and securely pay with a credit card.

The price is the same, 78 CHM, but the shipping is another 25 CHM, for a total of 113 CHM, which today comes to $129.07 USD including the currency conversion fee of 3.95%. A little pricey, but not in the context of the cost of an espresso machine and grinder (not to mention the cost of the gear pump upgrade.)

The hardest part of the project will be figuring out how to connect it. The Gicar flow meter has 1/4" BSPP fittings, while the Nano has 1/8" BSPP fittings. I believe AssafL made his own custom tubes to replace the stock GS/3 tubes. I'm thinking about an easier approach: PTFE tubing and adapters, ala the Jake valve and solenoid bypass valve I installed some time ago. That'll make almost the entire input path PTFE!