Hello, I am trying to use 3 Qwiic thermocouple amplifier boards with one dattalogger IOT board. I have addressed the boards as 0x60, 0x61, and 0x67. So far I am only recieving data from the 0x67 board. i have cut the i2c traces on all the boards, I’m also using a GNSS board which doesnt have the i2c trace cut.
is there something im missing?
Hi Joel (@Joel_seerey ),
Did you open the “ADDR” jumper JP1 on the 0x61 and 0x67 boards?
I hope this helps,
Paul
yes i did, i even changed to 0x60 board to 0x67 and found that it worked like that but it wont work at all as 0x60
just tried 0x66 as well which doesnt work
Hi Joel,
I just checked with the guru, and, yes, the Datalogger should be able to connect to your three MCP9600’s provided they have individual separate addresses.
Forgive me for asking the dumb question, but you are soldering the R2 address change resistor to the board right?
Could you post photos of the front and back side of one of your modified MCP9600 boards?
Best wishes,
Paul
So looks like I was a bit dumb and used a 2.2 ohm resistor not a 2.2 kohm resistor due to an R that looked like a K on the strip so that hopefully will solve the 0x61 issue when I get new resistors. But I still have the issue with 0x60 which I also tested as 0x67and found to be working. Below is the 0x60
Yay for the other 2
The 0x60 unit’s ADDR solder blob looks like it might be floating atop the pads; you should be able to do a continuity test between the blob and the GND pin
It might be worth resoldering that one area
Were you saying you got the 0x60 unit to work as 0x67?
0x60 is getting continuity to ground and still not working but did work when i converted it to 0x67 (just to confirm the board was fine)
Well that’s mostly good news
If the other 2 are working and 0x60 isn’t it might be easiest to also change it to a non-default address (0x62 or similar, depending on what resistors you have)
Hi @Joel_seerey -
I took a look at this in detail and grabbed a Thermocoupler board for testing.
First - I can replicate the behavior you are seeing: 0x60 fails with the Datalogger, but 0x67 works.
It was also observed, testing the addresses with a simple Arduino I2C scan program, you’ll see the Thermocoupler device address once, but subsequent scans fail.
Talking this over with Paul, he noted that the Thermocoupler is “finicky” (not the best I2C device per se) and found this comment from the Artemis OpenLog firmware:
// Note: The MCP9600 (Qwiic Thermocouple) is a fussy device. If we use beginTransmission + endTransmission more than once
// the second and subsequent times will fail. The MCP9600 only ACKs the first time. The MCP9600 also appears to be able to
// lock up the I2C bus if you don't discover it and then begin it in one go...
// The following code has been restructured to try and keep the MCP9600 happy.
```
Basically you can ping the device once, but after that it won’t respond. Which is what we see with the scan program.
Looking at the DataLogger autodetect logic, the issue you are seeing is related to the above device behavior. To autodetect, the Datalogger calls a device driver “isConnected()” method. Most of these do a “ping”, and if they get response, perform further checks to see if the target device is there.
On the Thermocoupler device, some of the addresses are shared with other devices, and those device drivers are being called before the Thermocoupler device driver - these conflicting drivers fail to detect their target device, BUT they’ve sent a ping to that address - which is the Thermocoupler - so further attempts to identify the device fails. Hopefully that makes sense.
We currently can’t reorder the driver list in the datalogger - it’s complicated/determined at runtime.
BUT the addresses 0x64, 0x65, 0x66, 0x67 have no driver conflicts, so if you use those, your Thermocoupler devices will work with the Datalogger.
And if you’re interested in the driver list, select the “l” (“L”) option in the menu that shows in the serial console right when the DataLogger starts . It dumps out the internal list before it’s deleted to free up space.
If you have any other questions, let us know.
Thanks!
-Kirk
that worked thanks, the boards all show up now in the serial terminal but they all show up as mcp9600, is there a way to give them different names in the csv output? I was hoping that the address would appear in the header row.
There is an option to add the device address to the name to handle dup names like this…
It is (in the menu system):
Settings > Application Settings > Device Names
Turn that on/set to true and the i2c address is added to the name.
-Kirk
Looks like you need to upgrade your firmware - look for the update option on the main menu. You can update “over the air” or via firmware file off the SD card.
Related to updating, I found a straight forward method to “prioritize” the testing of the MCP9600 Thermocoupler device within the autoloader logic. With this in place, all addresses will work, since the auto loader will check that device first if multiple devices share the same address.
I published a Beta of this here:
From that release, you could download the file SparkFun_DataLoggerIoT_01.05.01b2.bin, copy it onto an SD card the Datalogger can use and then update the firmware from the SD Card.
The Update Instructions are for a later firmware I believe, but the process is the same (the menu entries might be different).
-Kirk
That worked, thank you very much for your help
Awesome!
Thanks for your patience as we figured this out.
-Kirk
