Trouble with MCP9600

Qwiic System
1

This is my first attempt at using the MCP9600 thermocouple amplifier (SEN-16295) with K thermocouple (SEN-00251) via the pHAT 2.0 (DEV-15945) on a Raspberry Pi Zero. I have the pHAT and amplifier board connected. The Raspberry PI has I2C enabled (via raspi-config), installed I2C tools to verify device address. The problem I am having is that the device disappears after the first scan. The very first scan alway shows that the device is addressed 0x60. All subsequent scans shows nothing. See results below, very puzzled by this. I have to shut-down (sudo halt), power-down, and power-up to get the the device showing on 0x60 again, a simple reboot (sudo reboot) does not work. The problem is completely repeatable with a complete power cycle.

I believe this issue is preventing me for acquiring data from the MCP9600 via python. Seems to loose connection the moment one attempts to query the MCP9600. I only have the pHAT and MCP9600 connected to the Pi Zero, nothing else. No other devices on the I2C bus. The type K thermocouple is connected to the MCP9600. I have tried unseating the pHAT from the GPIO and reseating again to make sure it has a good connection. Tried using a different I2C connector on both the pHAT and MCP9600 board with exact same results.

Can anyone suggest what I might try next?

Should I try cutting the trace on the board to change the address to 0X67?

Could the MCP9600 require additional power? … how do I provide additional power?

Example of CLI commands and responses, after power cycle.

Three attempts one after the other immediately after login.

The first attempt always get the address, all subsequent attempts fail…

$ i2cdetect -y 1

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: – – – – – – – –

10: – – – – – – – – – – – – – – – –

20: – – – – – – – – – – – – – – – –

30: – – – – – – – – – – – – – – – –

40: – – – – – – – – – – – – – – – –

50: – – – – – – – – – – – – – – – –

60: 60 – – – – – – – – – – – – – – –

70: – – – – – – – –

$ i2cdetect -y 1

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: – – – – – – – –

10: – – – – – – – – – – – – – – – –

20: – – – – – – – – – – – – – – – –

30: – – – – – – – – – – – – – – – –

40: – – – – – – – – – – – – – – – –

50: – – – – – – – – – – – – – – – –

60: – – – – – – – – – – – – – – – –

70: – – – – – – – –

$ i2cdetect -y 1

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: – – – – – – – –

10: – – – – – – – – – – – – – – – –

20: – – – – – – – – – – – – – – – –

30: – – – – – – – – – – – – – – – –

40: – – – – – – – – – – – – – – – –

50: – – – – – – – – – – – – – – – –

60: – – – – – – – – – – – – – – – –

70: – – – – – – – –

2

I see 2 possible issues :

  1. After an address the MCP9600 is expecting a byte and does not get one. An I2C scanner only sending an address and checking for an ACK might confuse the MCP9600.

  2. The MCP9600 is using clock stretching. It is a known issue that the i2C on the Raspberry Pi (actually the I2C in the chip) is not performing clock stretching is proper manner. There are other libraries that can be used which perform bit-banging themself.

3

Thanks Paul. I managed to solve the issue. Here is the solution in case others have the same problem.

I changed the I2C baud rate on the Raspberry Pi down to 50K by adding the following line to /boot/config.txt (at the very end) and rebooting the Pi.

dtparam=i2c1_baudrate=50000

That made the i2c scan about 95% response rate. Mostly repeatable. Next, I tried collecting data via python MCP9600 code making sure to set the frequency=50000. Did not work, threw errors that it could not communicate.

So I set the baud down to 10K and rebooted.

dtparam=i2c1_baudrate=10000

The I2C tool now has 100% response with the address 0x60 always showing.

Now set the MCP9600 frequency to 10000 … and … now fully functional reporting thermocouple data.

4

thanks. By lowering the baudrate the MCP9600 clock-stretching will happen within the SCL timeslot and thus the RPI will not notice a clock-stretch happening.