It's not that I didn't anticipate the FT-180 working- I evaluated and decided against that possibility before I came to post here, for reasons that are still true. The first one is that I don't have an FT-180 to test with, and don't want to conduct a $450 experiment just to see if it would work. The second one is that while the black cube has 50% less pressure loss at the internal passages than the gold cube, it still has a reduction from half inch lines (ID .430") down to quarter inch pipe thread fittings, which also lead to a further loss. Have you accounted for that loss in your calculations?
I appreciate your encouragement that it should work, but you also seem pretty sure that a single gold cube should work, which actual testing showed that it does not work. In the end I need an actual flow rate delivered out of the end of the fuel line, and while the theory helps get close to a final solution, the results are what matters. If anyone would like to loan me one I'm happy to test it. EI is not willing to loan me one, I didn't expect them to but did ask just in case they were.
So with the distractions hopefully out of the way and getting back to the reason for my post, there are three possible scenarios that I can think of to solve the question of feeding the input of two sensors into the Skyview.
Option 1: Maybe support is wrong and the thread is right, and the software can actually do it. Pin 19 is still listed in the install manual as a second fuel flow input. This would be somewhat easy to test at least, with a temporary wire initially.
Option 2: EI makes a separate piece of hardware (FFAM) that will consolidate the two sensors into a single output which can then run to the EMS as usual. It's $200 and seems to be only available from them, which isn't so bad if it works the first time and never needs to be replaced. If it breaks, it is a black box.
Option 3: It seems plausible to create an Arduino-based extra hardware device that could consolidate the two signals. The disadvantage is more development time vs the EI FFAM. The total materials cost with a name-brand processor is around $50 (half is the processor) which is much more favorable in explicit terms than the EI. The biggest advantage would be that I would know how it works in case it ever needed replacement, tweaking, or other repair, though I would hope that either option would be low risk for developing problems.
The one big downside of my current iteration, which delivers at total of 42 gph through the two gold cube sensors (one on each tank output), is that there is potential error if fuel flows across the valve from the left to the right tank. Since the sensor doesn't know whether fuel is flowing forward or backward, any cross-flowing fuel will be counted twice, in addition to any fuel that is going to the engine. This error would be momentary as it relates to the engine flow rate, but could end up being a factor in using the fuel flow to derive a fuel remaining on board solution and I'd probably end up breaking that widget. At least it would indicate lower than actual rather than the other way around.
One solution to that issue would be to route the output from the fuel valve into the two gold cubes parallel, but with all of the fittings and direction turns that this would require, I worry that the flow loss would be too impactful.