Only got a little of the testing done today (too many non-bike things happened that I hadn't planned for).
Using the Sorenson DCS-55-55 lab PSU, I tested first the CA's calibration for current and voltage, and it appears at lower currents (just under 5A) to be close enough to my Fluke 77-III DMM that I would trust it. I got interrrupted so didn't get the chance to setup a higher 40-50A load like I'd planned, just a single car headlight. It also matches everything else I have close enough, though the Turnigy Watt Meters do read high (which is about what I remember).
CA vs Fluke vs Sorenson meters for current:

- DSC06726.JPG (49.29 KiB) Viewed 1040 times
Simulataneous current readings, seriesing all the meters. In order from PSU to load: WU, Fluke, TWM1, TWM2, CA (note slight voltage drop on each succedding unit, with 16.0V at Sorenson source):

- DSC06727.JPG (59.51 KiB) Viewed 1040 times
Voltage readings, no load, Sorenson, WU, Fluke, CA.

- DSC06728.JPG (54.42 KiB) Viewed 1040 times
So I think the CA's readings can be trusted just fine, vs those of the Fusin controller and "analyst", whcih I don't have a way to check as directly as this right now. (I have a test I could do, running a known current from the Sorenson thru the shunt while the controller is on but not running the motor, simultaneously verifying the current with the Fluke, the Sorenson's meter, and the CA, but I have to wheel the bike in there again to do it, and I think open up the controller so I can access each side of the shunt).
Then I can see what wattage the Fusin "analyst" display shows, and see if that matches with the calculated wattage I should get based on the known current times the actual battery voltage on the Fusin at that moment.
Next up was some oscilloscope probing of the controller-to-display lines. It has 5 lines, the Pack Voltage In from keyswitch, Pack Voltage Out to the controller enable line, Ground, Rx from controller, and Tx to controller, for serial data transfer of displayable information and button presses for selections.
Scope is set to 1V/cm and 1ms/cm on all of the pics and vids below, with 0v at bottom of screen, except the dual-trace vid of both data lines, which is 2V/cm and 1ms/cm, with 0v for Rx on bottom of screen and 0v for Tx at center of screen.
Rx line is lower voltage (~3V p-p)

- DSC06732.JPG (34.74 KiB) Viewed 1040 times
than the Tx line (about 5Vp-p),

- DSC06751.JPG (37.46 KiB) Viewed 1040 times
even at the connector at the controller end. But it is also cleaner, with virtually no noise at the "resting voltage" of 3V, while the Tx line has a saw waveform (presumably ripple in the internal SMPS of the "analyst" display) overlaid on it's "resting voltage" of 5V.
Another noise is overlaid on that saw wave when the backlight is turned on. Neither of them is a very "deep" noise, meaning they aren't likely low enough even at minimum to trick the receiver in the controller into thinking any of the noise pulses are bits in teh data stream.

- DSC06753.JPG (38.17 KiB) Viewed 1040 times
However, I suppose it is possible that the only-3Vp-p Rx line (where data is going from controller into display) isn't high enough voltage to reliably be read by the display unit. I still have to open the display unit and check the signal at the PCB inside it, to make sure it isn't degraded by the time it reaches there).
Strings of data are sent only once every second or so, maybe a bit quicker than that (you can see their timing in the video below), whcih explains the too-infrequent displayed-information updates. Means that the MCU in the controller is doing all its' usual work plus sending out these data pulses, so maybe it isn't fast enough to update more often than that (but I sure wish it did).
Since there's no way for the display unit to get any of the power or speed data directly, the controller must be sending it in the data stream. So when those two things fail to update, either the controller is not sending it, or the display is not receiving it.
I dont know if the display directly detects battery level and displays that (as it does have it on the keyswitch input), or if it is detected by the controller and displayed there. Simple enough to test, by disconnecting the analyst from the controller, and just inputting battery and ground to it's connector, and seeing if the meter responds. We'll see next time I get the chance to do testing.
The wheel sensor is definitely always working, even when the display fails to update or just plain reads wrong. Tested with teh scope on the controller-motor connector at the controller end. Two vids here, one continuation of the other. Haven't gotten to hooking the motor's internal speed sensor to the CA yet, as experiment to see if that would work. (it should).