MCP9600 on rpi - lost at sea

Sensors Environmental
1

Hi all,

I’m pretty new to all this and pretty lost. I was excited to use the MCP9600 w/ the qwiic system to avoid soldering while I just try and learn all of the interfacing side of this project. I hooked up 2 MCP9600’s to the pHat (in serial), and I think I can seem them over a gpio i2d scan. However since I can’t load the mcp9600 library, (shame on me I would not have probably gone this route if I had saw it was a library posted for arduino). I’ve searched around for a few days looking for some examples to help me. I have no were near the programing skills to convert a c++ program to python, although I guess I can run c++ stuff on the rp w/ the via wiringPI? I’m pretty lost. Honestly I just want to see a few values from the mcp9600s but I’m not finding any examples to build off of on this hardware setup.

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

00: – – – – – – – – – – – – –

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

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

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

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

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

60: 60 – – – – – – – – – – – – – – 6f

70: – – 72 – – – – –

2

seems there is a python library for Raspberry Pi. https://pypi.org/project/mcp9600/

3

Also, make sure you only have one connected at a time OR you have changed the I2C address on one of them. (You can’t have two devices on the same bus with the same address.)

4

ok, this makes some sense. I unplugged everything else off the pHat 2.0. I wasn’t sure I could use the suggested python library since it appeared to be directed at the pimoroni thermocouple under the same name.

I get errors attempting to use this MCP9600 driver however. Indicating that it cannot find the device at 0x66

pi@raspberrypi:~/mcp9600-python/examples $ python alerts.py

Traceback (most recent call last):

File “/home/pi/.local/lib/python3.7/site-packages/mcp9600/init.py”, line 194, in init

chip = self._mcp9600.get(‘CHIP_ID’)

File “/home/pi/.local/lib/python3.7/site-packages/i2cdevice/init.py”, line 230, in get

self.read_register(register)

File “/home/pi/.local/lib/python3.7/site-packages/i2cdevice/init.py”, line 183, in read_register

self.values[register.name] = self._i2c_read(register.address, register.bit_width)

File “/home/pi/.local/lib/python3.7/site-packages/i2cdevice/init.py”, line 288, in _i2c_read

for x in self._i2c.read_i2c_block_data(self._i2c_address, register, bit_width // self._bit_width):

OSError: [Errno 121] Remote I/O error

During handling of the above exception, another exception occurred:

Traceback (most recent call last):

File “alerts.py”, line 5, in

m = mcp9600.MCP9600()

File “/home/pi/.local/lib/python3.7/site-packages/mcp9600/init.py”, line 198, in init

raise RuntimeError(“Unable to find mcp9600 on 0x{:02x}, IOError”.format(self._i2c_addr))

RuntimeError: Unable to find mcp9600 on 0x66, IOError

I dug into the “driver” file init.py of this library and can see some discrepancies between the address assigning in the sparkfun arduino library vs this one. I’m not sure if I am looking at this apples to apples.

from https://github.com/sparkfun/SparkFun_MC … _MCP9600.h

#define DEV_ADDR 0x60 //device address of the MCP9600

#define DEV_ID_UPPER 0x40 //value of the upper half of the device ID register. lower half is used for device revision

#define DEV_RESOLUTION 0.0625 //device resolution (temperature in C that the LSB represents)

#define retryAttempts 3 //how many times to attempt to read a register from the thermocouple before giving up

from https://github.com/pimoroni/mcp9600-pyt … init_.py

CHIP_ID = 0x40

I2C_ADDRESSES = list(range(0x60, 0x68))

I2C_ADDRESS_DEFAULT = 0x66

I2C_ADDRESS_ALTERNATE = 0x67

the way these files are using 0x40 is not the same is that correct? I corrected the init.py file to a CHIP_ID =0x40 but i get the same error.

I am also not sure if this is related but if I run gpio i2cd i see the mcp9600 at 0x60 however if I run it a second time the address is empty. I have two of the so I swapped it out, cables too. Same issue. I dug a bit online and found this can be caused by overloading the i2c bus? Is there something wrong with using gpio i2cd like this?

Also If this is just terrible noobie questions please feel free to tell me so. I just haven’t found much of a solution searching so rather than keep pulling out my hair I’m here.

5

*sorry in the last paragraph I mean to say I corrected the CHIP_ID =0x60 per the sparkfun library address. I am not very concerned bout the i2c bus if I use gpio readall multiple times in a row I get to issue. if I use gpio i2cd or i2cdetect -y 1 the 0x60 is gone after the 1st cycle

6

I don’t have an MCP9600 and never worked with it. Looking at the Sparkfun library (SparkFun_MCP9600.cpp) you will find an interesting remark:

 // The MCP9600 is a fussy device. If we call isConnected twice in succession, the second call fails
  // as the MCP9600 does not ACK on the second call. Only on the first.
  //
  // The OpenLog Artemis routinely uses the same isConnected code twice: once to detect _anything_ that is on the bus;
  // and then again to detect an MCP9600. The second time fails.
  //
  // If there is a device with a lower address on the OLA Qwiic bus, that device responds first and satisfies
  // isConnected. Then the OLA code uses isConnected again to detect an MCP9600. That call is successful, as this time it is the first call.
  // However, the OLA then goes on to call this function to begin the sensor. Previously this was failing as isConnected
  // (12 lines above) was then being called for the second time...
  //
  // Long story short, we should not call isConnected here. We should only call checkDeviceID.

The isConnected routine does basically the same as an I2C scanner, send the address and expect an ACK from the device. Apparently, the MCP9600 expecting instructions after the address and will not respond otherwise. Sorry I can’t help you more. Maybe connect with the writer of the Python code or get an Openlog.

7

Interesting. I did not see this comment yet. This makes some sense. The i2cdetect -r -y 1 command (adding the -r) flag does not cause the mcp9600 to disappear. Thanks for the help, I’ll have to dove deeper into this library

8

the noobie that I am, i was editing the i2c address in the wrong file. Not the file which had been installed in the python3 root library. All the changes I thought I was making were having zero affect. :roll: :? thanks for the help all.

posting for anyone else that stubbles down this path, simply updating the pimorani specific file, you just need too update the address in the

/home/pi/.local/lib/python3.7/site-packages/mcp9600/init.py file with the following changes

original : I2C_ADDRESS_DEFAULT = 0x66 (for pimorani mcp9600 chip)

Updated: I2C_ADDRESS_DEFAULT = 0x60 (for sparkfun mcp9600 chip - per hookup guide)