The signal switching still does not look ideal: there are quite some CMOS switches in the critical signal path and thus possibly a higher leakage current than needed. Instead of parallel MUX chips and using the OE pin one could better cascade them, so that the less critical signals (e.g. the ref. levels, temperature,..) go through one more chip and only 1 mux chip for the leakage critical paths.
I debated whether to have the two muxes in series or parallel. My feeling was that keeping the input series-resistance the same for the various inputs (even if dedicated to secondary importance signals) was the lesser evil. Particularly as it might affect the distribution of charge-balance during PC switching. Although thinking some more, the secondary-importance signals will be lower-impedance inputs anyway (refs, TIA, TEMP etc) so it matters less.
3458a has many parallel jfets for input muxing, although that probably reflects the component choices available at design time (no low leakage/multiple-throw switches) .
If the parallel hi-mux organization was kept, an additional relay could work to switch between them. This would remove all potential leakage from secondary inputs, unless actually selected.
max328 should probably be used for the muxes. But their price is annoying, and couldn't be justified for initial tests
It's not clear if a charge-cap for charge-injection tests, or leakage tests as you suggest, could work without another parallel mux/relay. .
With the MUX before the precharge circuit and bootstrapp buffer the bottstrapping of the zener clamps is only working when the DCV input is actually selected. With a different input selected the input could see a little extra input current.
It is not ideal, but also not too bad as the input can be isolated via the FETs from the protection and the extra relay
I hadn't considered this. DCV could be at +-11V from user terminal input, with the selected mux input at 0V and BOOT at the same voltage.
That isn't very good for leakage.
Even with the protection fets switched off, fet leakage is in the order of nA, so they won't help much.
It is a bit strange to have 2 x PV coupler in series. Most of the PV couplers give some 6-9 V out and thus sufficient to turn on the FETs. The voltage is already limited by the forward direction of the photodiodes.
I found the measured PV voltages to be a bit on the low-side - around 6V with a single opto-coupler.
From memory, I made a judgement to use two, based on an actual RDS(on) measurement of the fets at the driven gate voltage, but don't remember the detail. Cost of the extra part is marginal, although maybe it looks too unorthodox.
Connecting the ACAL signals directly to the input is nice to include all the protection, but it kind of defeats the protection. So ACAL would need the user to isolate the input.
Yes. I really like the idea of feeding in signals right at the front. And am not sure about duplicating them again at the input muxes. Being able to run ACAL/diagnostics without the user having to worry about the state of terminal connections would be nice. So perhaps more relays are justified.
For the ACAL part for the divder (+-10 V or GND to the divider) one could use the same relay as to connect the divider. So the divider would either see the input or the ACAL signal.
This means one doesn't get the DC-source (+-10V, GND) right at the input, that could be useful calibrate/do self-diagnostic tests for the protection/fet leakage. But it frees a relay that could isolate the input terminals to keep protection active, and so the operator doesn't have to do it, during acal.
And it could isolate the terminal input, when non-DCV inputs are selected via the muxes.
schematic pic added for clarity.