Just like you, we like upgrading and tinkering with our systems. There’s always something we feel we can improve (and there usually is) with the systems we use, it’s why we got into testing in the first place. When it comes to our testbeds, however, we have to take a much more cautious approach. Any change to the testbed and you lose the ability to compare future results with past results, so when a testbed is upgraded, it has to be really worthwhile. When I went from CPU Block Testbed v1 (hereafter called VaporBench v1) to CPU Block Testbed v2 (VaporBench v2), I made huge changes for the quality and repeatability of the data. I implemented water temperature sensors, I greatly increased the range of tested flowrates, I went to Dwyer flowmeters, I split my radiators out of the CPU block subloop (so that flowrate through the radiators is always the same, regardless of the flowrate through the CPU block), and I removed quick disconnects and replaced them with external clamps and rotary G1/4 fittings at the block.
VaporBench v1 was a solid initial build and I definitely got a lot of things ‘right’ on my first try that I wanted to maintain for later. But overall, it was amateurish and the transition to VaporBench v2 was mostly to improve the quality of results and data. VaporBench v3 is keeping most of the same function and form from VaporBench v2, but I’m making it more friendly to me. Overtime, I’ve noticed a few undesirable qualities of VaporBench v2…most notable is the noise from Dwyer flowmeters. While they’ve been a great addition to my testbed (from a quality of data point of view), they are cumbersome, very loud (it’s an obnoxious rattling noise), and require manual logging. Manual logging isn’t such a bad thing, but a reliable way to automatically log is better. I previously deemed the Koolance FM17 flowmeters “unprofessional” but now I’m taking that back. When used right, they’re capable of producing flow readouts as good as my Dwyer flowmeters. They’re also automatic in use (logging another RPM readout can be implemented really easily) and inaudible.
The key is using them the right way–they’re not great at high flowrates (they begin to get cranky above ~2GPM and very cranky above ~2.5GPM) and that needs to be taken into account. The easiest way to reduce the flowrate through a specific component (and not reduce flowrate elsewhere in the loop) is to provide a parallel flowpath. The problem with doing that for a flowmeter is that you aren’t metering all the flow, so you fix that by adding a second flowmeter on the second flowpath. The problem with that is at extremely low flowrates (below .4GPM), you’re only moving .2GPM through each flowmeter, which is basically out of range for what it can measure. So you fix that by adding a third flowmeter before the split to the two parallel flowpaths. You end up with three flowmeters in a Y configuration and can reliably measure the flowrate from .25GPM to somewhere between 4-5GPM. And it does it silently and automatically
This small write up is about detailing the process of testing the flowmeters, confirming their viability, and calibrating their output. First thing on the agenda: get them in my current testbed and compare their individual outputs compared to each other and my Dwyer .2-2.2GPM flowmeter.
What we see here is pretty basic: all three have good metering relative to my Dwyer 2.2GPM flowmeter. FM17-1 and FM17-3 track basically identically to a little above 2GPM and FM17-2 is the oddball of the group. I take the equations from the trendlines and use them to ‘correct’ the data off the FM17s to read as identically to the Dwyer as possible, and I get this:
My hunch, at this point, is that I should use FM17-1 and FM17-3 as the two parallel flowmeters since they both meter nearly identically and have no ‘glitchiness’ showing. Using the FM17-2 as one of the parallel flowmeters would lead to glitching results as low as 3.5GPM. So I loop it up with the FM17-1 and FM17-3 each coming after a Bitspower Y splitter and test further. From here on out, things get a little more complicated, but I’ll do my best to put it into English as plainly as possible.
First, there are a few reasons it’s getting more complicated: 1) my two Dwyer flowmeters, for the portion that their readouts overlap, do not read identically. Throughout all my testing I’ve used my Dwyer 2.2 at 2.2GPM and lower and the Dwyer 7 from 2.2GPM to 7GPM, but because they don’t read identically I have to make choices on how I want to use as reference for calibration. 2) I won’t be converting the raw output from the FM17s to calibrated output until the very end of the process. 3) I have to choose which portions of the flow spectrum the various FM17s are assigned to and that requires visibility of ‘glitches’ which can sometimes be hard to see on the following charts; I’ll try to point them out when appropriate.
The first test I ran was observing the FM17-2 and FM17-1/3 combo from .3GPM (minimum I can achieve with a single block) to 2.2GPM. Also in the chart is how the Dwyer 7 meters over the same range (it starts reading at .8GPM).
Not too, too much to see here, but the differences in the Dwyer 2.2 and Dwyer 7 are pretty evident. The FM17-2 ‘glitches’ a little lower than it did in the prelim testing. What I gleaned from this? The FM17-2’s usable range (range with full granularity) is probably from .3 to 1.6GPM. The FM17-1/3 combo has its usable range start at roughly .6GPM and there’s ambiguity as to what is the true flowrate–which will actually give me flexibility with my calibration.
Same situation as above, but we do see the FM17-1/3 combo tracking well to 4GPM, which was the max I was able to hit in this config. The FM17-2 has pretty severe glitching above 2.5GPM–it couldn’t tell the difference between 2.6GPM and 2.8GPM (and above that things only got worse). Next step is to combine the two ranges and see how things track from .3GPM to 4GPM.
Overall, it’s not bad. At 2.2-2.4GPM (reference, so the Y axis), we actually have an abrupt jump because that’s when I switch reference flowmeters from the Dwyer 2.2 to the Dwyer 7 (which, again, ready slightly differently). At this point, I have 5 flowmeters all telling me slightly different variations of the truth. The real flowrate at every point? I really don’t know. That does provide some flexibility though. It allows me to calibrate my FM17 setup to any reference alignment.
I chose to split the difference between the Dwyer combo setup and the FM17 combo setup and call that my reference. I compare that to the raw output of the FM17s and add a trendline and I get an equation for converting the raw FM17 output to my desired calibration. The trendline is a really good fit, with an R^2=1, which is a a great sign. All that’s left now is to apply the conversion to the raw data and measure the absolute error at each reference point.
And I ultimately like what I see here: the largest error vs. reference is <.02GPM and the error is always less than 1% (the reference calibration line also doubles as a 1% error line–the error line never touches the 1% line). Readouts won’t be comparable to older flowrate tests, but that’s not a huge deal since this is just one change of many for VaporBench v3. If I wanted to calibrate the FM17s to the Dwyer combo reference, it’d be as easy and dropping in a new conversion equation (which is really easy), but considering the Dwyers never agreed on flowrate, I feel I’m at liberty to use a different reference calibration.
Again, this just one change of many coming for VaporBench v3. This is probably the biggest functional change on the list and why I decided to document and post a write-up about the details of the change. The results from this testing are really promising–I get smooth metering from .3GPM to above 4GPM, I get automation, and I get silence, which is golden.