No data or enumeration from Quiic MCP9600 thermocouple amplifier

Hi There. I’ve just starting out with this stuff, so point me in a direction if I’m incorrect - I don’t have much experience, but have done my best to search these issues without coming to a resolution.

I recently got a Openlog Artemis, and a bunch of sensor boards to try out. When I connect to the serial port on the openlog, it seems to enumerate the Quiic bus and start logging all the sensors I’ve tried, with the exception of the thermocouple board (SEN-16294, batch # 129149). This even occurs when the other enumerated sensors are downstream of the thermocouple board from the Openlog (for example, Openlog → MCP9600 → CCS811/BME280 or GPS or any of the other boards I have…)

The power LED on the board does illuminate, but that’s it.

If I add a device that the openlog doesn’t support (ie the Quiic Micro oled breakout) it shows me that there is an unidentified device on the bus, so if the thermocouple amp was appearing on the bus incorrectly, I’d see something like that I imagine… Short of getting some other I2c device that can actually show me the raw traffic on the bus, is there anything I’ve missed / should try?

Thanks

So a bit further with this today: (alot is for my own tracking of the issue, but if anyone has some insight, I’d love to hear it, as I said, I’m new to this)

managed to compile and upload the Openlog Artemis project from Github… no luck with that specifically, but people should be aware that there are old library names for SparkFun_PHT_MS8607_Arduino_Library.h (issue submitted on github)

Using the I2CScanner sketch from the Openlog Artemis master, I usually see the thermocouple address (0x60) pop up, but only immediately after a fresh power up / upload of the I2C scanner, upon a second upload, or a very dealyed upload after power-up, the address dissappears

I got a Artemis Nano, and it very reliably connects to the thermocouple device regardless of time since power up… so this problem seems to be something specifically to do with an interaction with the OLA.

Getting even further into the weeds…

Forcing the quiic bus speed down to 100000 seems to allow the device address to steadily appear on the OLA, but it still doesn’t detect it and start logging it. Seems to not be setting quiicAvailable.MCP9600 to true (for some reason the call to thermoSensor_MCP9600.begin in Sensor.ino and menuAttacheddevices isn’t evaluating to true)

There seems to be an aborted attempt at handing the event that both a VCNL4040 and an MCP9600 appear with the same address, but the code for the MCP is commented out. I went through and instead changed the address of what’s called ADR_MCP9600_1 (the bypass for the aborted attempt) to 0x60 but for some reason thermoSensor_MCP9600.begin still isn’t evaluating to true…

Finally, a third note - when using the !2C_Detector test sketch on the OLA, the thermocouple device seems to keep presenting it’s address on the bus scan (calling thermoSensor_MCP9600.begin still results in failure), but ONLY if it keeps power-cycling the qwiic bus (If I comment out the qwiicPowerOff() at the beginning of the main loop in that sketch, it doesn’t appear)

So it looks as though the device is coming up when connected to the OLA, but only briefly before becoming unresponsive.