Nick Wright

@Display Name The 152 should not interfere with other devices using the I2C bus on GPIO2/3 unless they happened to use the same I2C address as the 152. The I2C components on the 152 support up to 400 kHz, but we do not change the I2C speed from the default value in the library so it is likely running at 100 kHz. It is possible that the extra bus capacitance of having the 152s along with your devices is slowing the edges enough to have issues. Are you using any additional pull-up resistors on SDA / SCL? You could try capturing the I2C comms on a scope in both scenarios to see the difference, and adding additional pull-ups may improve the communications.

Yes, that is correct. For best accuracy read the CJC temperature reported by the USB-TC because it could be different from ambient.

I think the voltage reading function in mcculw only applies to the USB-TC-AI and not the USB-TC. I do not know of a way to get a voltage reading from the USB-TC directly. You may be able to get it in a roundabout fashion in this manner: Configure the USB-TC to a similar voltage range TC type such as J. Read the thermocouple temperature T1 and the appropriate CJC sensor temperature Tcjc Calculate the corresponding type J CJC voltage using the J thermocouple data (Vcjc) Calculate the thermocouple voltage using the J thermocouple data (V1) Calculate the raw thermocouple reading voltage Vraw = V1 - Vcjc You can then calculate the type C thermocouple temperature: Calculate the type C CJC voltage using Tcjc and the C thermocouple data (Vcjc2) Calculate the type C thermocouple voltage V2 = Vraw + Vcjc2 Calculate the thermocouple temperature T2 using V2 and the C thermocouple data

@Display Name could you also please capture an analog scope trace on one of the encoder signals to check for the voltage levels, spikes, etc?

The MCC 152 is different from the other MCC HATs in that it uses an I2C IO expander on the Pi I2C bus to implement the digital I/O. The other HATs all use SPI only. If the IO expander on a 152 gets damaged it can cause issues on the I2C bus, which would show up as problems communicating with other MCC 152s but not different models of HATs. The HAT detection is performed by reading the EEPROMs on a dedicated ID I2C bus (separate from the one used for the IO expanders) so a damaged board can still be detected but communications do not work. The most likely causes for damage to the IO expander are voltage related, due to things such as: Overvoltage on an IO pin (like connecting a 5V input signal when the MCC 152 is configured to 3.3V) Undervoltage on an IO pin (such as connecting signal and ground backwards)