So here's the wiring diagram. I still need to identify an appropriate humidity sensor to add to the mix. With that added, the device can calculate real-time DA during a run. These are tiny, think 2 postage stamps next to each other in size. The final puzzle piece is converting the Crank Position Sensor signal into a 0-5v analog output to feed to the Feather. I'll likely need a 2nd controller dedicated to that due to the time intervals involved.
This is where it becomes helpful for this effort. If I know the DA, exactly, as experienced by the bike, I can account for it with fueling and timing. The rest of the information is just to gain more fidelity of the information I already have through the PC-V. With better data + DA, it becomes possible to adjust the bike to a higher level of precision.
The PC-V or ECU, I'm not sure which, is using a biased voltage. What that causes is a miss-match in data, limiting accuracy of tuning efforts.
Example: With throttle opened to some point, ECU reports 1.1v and PC-V reports 1.14 volts (arbitrary numbers), but they never match, on any sensor, and the offset is not linear. Even the 12v base measurements don't match despite sharing a common ground point, so there's some pull down/up going on, and I expect it's the PC-V itself.
Why do I need to account for DA when the stock ECU is supposed to do that already (that was the WHOLE point of EFI in the first place)? Because without a feedback loop, aka O2 signal, the ECU becomes nothing more than a "dumb" electronic carburetor with no information on the effects the preprogramed correction factors made. From experience I can definitively say, the Keihin ECU is absolutely ****e at calculating the correct correction factors on Mufasa. The bike runs lean as altitude increases, more than 1 full AFR number e.g. a 13:1 area at sea level is 14:1 (or worse) by 7000 ft.
With a custom logger, I can calibrate each sensor input offset to exactly match the ECU values, which lets me tune exactly for what the ECU observes and gain predictability. Additionally, this provides a dead accurate GPS signal that I can poll and average over a set number of samples to give an accurate GPS Speedo output. That can then be fed to a display for Justdad to keep an eye on. The other piece of info he needs, RPM, will be provided by the Healtech Shiftlight Pro. The OEM Tach is quite a bit off, particularly so over 7000 RPM and mine full stops at about 7800, so that last 700 RPM is pure mystery until you bang the limiter. The Healtech doesn't do this, it's true RPM (if configured as such).
EDIT: Code now complete without errors, all that remains is to test/verify no bugs, looks like 10 samples/second aka 10hz, will be easy to achieve.