Possibility of patching OpenLog Artemis to support TMP102 sensor?

Development Boards Artemis
1

I wanted to use the OpenLog Artemis with the lower cost TMP102 QWIIC
temp sensor. [In fact, we ordered 25 of them after I lost track of the fact that only
the TMP117 was supported.]

Before we return the TMP102’s, I wanted to ask how easy it would be to
update the OLA to support that device?

Is the OLA software open source such that I could add in support for a
new device?

Thanks,
Jay

2

You can, find the readme (it’s not a full fledged guide/howto, but lists all steps) here OpenLog_Artemis/ADDING_SENSORS.md at main · sparkfun/OpenLog_Artemis · GitHub
Keep in mind you just need to save/run the custom files locally to get yours goin

If you’ve never done anything like this previously just take your time and go step-by-step…should be(!) faster than swapping all of them out in the long run

3

Thanks, it looks to be a “simple matter of programming”. Are there any policy reasons it has not been done already (or just a lack of time/programmer effort?)

(I was surprised to find that the TMP102 wasn’t supported out of the box.)

I guess what I’m asking is: If I go to the effort of adding the TMP102 sensor support, would it be something that would get picked up and pulled back into the main branch, or would it only be useful for my project (because the maintainers did not want to implement it for some reason)?

Would that sensor somehow interfere with some other sensor(s) with the same default addresses or some how break something else (assuming I programed it correctly)?

Jay

4

Yea, time/effort/payoff. We carry hundreds of sensors, balance…

We never know for certain until after we’ve already done the work :stuck_out_tongue: I suspect it’d be added @ next update if you push working code (but make no promises)

Sometimes…it really depends. The 102 and 117 have the same default i2c address which is something to know going in, but easy to workaround

5

Ok, I’ve successfully set up the OLA development environment, and will give adding support for the TMP102 a shot.
Jay

1 Like
6

Ok, my OLA came with firmware 2.4, which saw something at address 0x48 but didn’t recognize it when I had the TMP102 plugged in.

However as of version 2.8, support for an A2D->I2C converter chip (ADC-ADS1015 also at address 0x48) was added to the code base. When I upgraded my OLA to version 2.8 with a TMP102 plugged in, it (falsely) detects it as an ADS1015.

“ADC-ADS1015 online at address 0x48”

(Because it has a low reliability check in the .begin() call…)

Obviously, I could put the auto detect code for the TMP102 before the ADS1015 code, but since the TMP102 has basically the same thing (i.e. no device ID) we would potentially run into the opposite problem of a ADS1015 being falsely detected as a TMP102.

[There MAY be a way to disambiguate the two chips still based upon their behavior…possibly.]

However, we may be running into the situation where there is no way to disambiguate those two sensors as they both appear to be low reliability detection relying on the bus address alone.

Before I put in a lot of work on TMP102 support, I’m looking for feedback on how to proceed, as while I’m confident I can make a local binary that supports TMP102 INSTEAD of ADS1015…I can certainly understand why that change might not get pulled into the main codebase, and I’d prefer to keep things so that others can follow along with the rest of my hardware project without having to patch their OLA binary directly.

[There is no issue with the TMP117 sharing the same address as it has a device ID so recognizing it has high reliability and can run first.]
Jay

7

Hi Jay (@summetj ),

Oh boy. This is a challenge…

Both the TMP102 and ADS1015 are made by TI. Both support the same four I2C addresses. Both have four 16-bit registers: Conversion, Config, Lo Thresh, Hi Thresh. It makes me think that they’re using almost the same silicon, except the TMP102 includes a temperature-to-voltage component.

Is it possible to disambiguate the two? Maybe…?

Configuration register reset values are different: 0x60A0 for the TMP102, and 0x8583 for the ADS1015. From a power-on cold start, you could use that to disambiguate. But once the register has been configured, all bets are off… You would need to power cycle the OLA and sensor to ensure reliable detection.

The two read-only converter resolution bits R1/R0 are always 1 on the TMP102. On the ADS1015, they are read-write and are two of the three MUX bits. It may be possible to disambiguate by writing 0’s to those bits, then re-read the register. If they’re still 1, you have a TMP102. Remember to restore the bits afterwards for the ADS1015. The ADS1015 library has public readRegister and writeRegister methods you can use.

When the TMP102 is put into 13-bit mode, the LSB of the conversion register is 1. 0 for 12-bit. On the ADS1015, that bit is always 0. Could you use that to disambiguate? Maybe. But it’s messy. You would need to: put the chip into EM mode, force a conversion, read the raw conversion result, check the LSB, restore the mode.

I think there’s a solution in there, with the R1/R0 vs MUX bits. But you would need to double check that R1/R0 really are read-only and always 1.

If you submit a Pull Request, we’ll happily merge it - thank you. I’ll leave it to you to decide how many menu options you want to add: temperature in C vs F, THIGH and TLOW support, Extended Mode, etc…

Best wishes,
Paul

8

Thanks for the comments @PaulZC . All of those methods sound more reliable than what I had initially considered:

I noted that when my TMP102 is falsely detected as a ADS1015, all 4 analog inputs read as the same value. [Something that may not occur with a real ADS1015, especially if all inputs are not tied to the same ground/signal, such as with the sparkfun breakout board where A3 is on a POT.] So I was thinking of just reading it as a ADS1015, and if all 4 analog inputs were equal aborting to the TMP102…

I have the TMP102 supported for basic tempC reading now in my fork:

My main blocker right now is that I don’t actually have a ADS1015 to test with, and the Sparkfun DEV-15334 is backordered. [I’d really prefer to not make my own breakout board…]

Jay

9

Hi Jay,

I did my ADS1015 development using the Adafruit board. (I’m in the UK. It can be quicker and more environmentally friendly for me to order an equivalent Adafruit stemma QT board from Pimoroni, than to ask SparkFun to ship the SF one over… :laughing:)

All the best. Please shout if you need more help with this,
Paul

1 Like
10

Nice, Thanks for the pointer, I ordered one!

11

Thanks for the advice and pointers @PaulZC & @TS-Russell,

I received my ADS1015 to test and got it working on my system… Probing R0/R1 as read only 11 vs MUX[2:1] read/write allows me to detect the difference between TMP102 and ADS1015 chips.

Currently for the TMP102 I’m just reading degC only without adding support for any of the alerts or other features like extended mode etc…

Pull request submitted here:

Jay

P.S. I also identified a randomly set variable (logTemperature) in the TMP117 data structure that is set to true, but never changed after that, although it is checked in several IF statements that don’t appear to be needed. It appears to be vestigial code from wherever the TMP117 code was copied from, or perhaps somebody was going to add a feature but ended up not doing so. I highlighted that variable with comments in a few places, but didn’t change any of the TMP117 code.

1 Like