1
votes

I'm trying to run the code below on an ESP32 TTGO T-display running micropython from loboris. (It's esp32 pre-loaded with display drivers for TTGO Display) I have attached a GY-906 temp sensor through i2c for testing. i2c.scan() finds it without issue on 0x5a [80] like it is supposed to, but when I request temperature data, the response is always 0xFF instead of proper temperature readings.

When I run the exact same code on a WeMos D1 (only difference is the pin numbers) I get temperature data returned. I am attaching both logic analyzer screenshots hoping someone can tell me what I need to do differently. Both are directly wired from 3.3, gnd, and the 2 i2c pins.

Things I have tried: adding pull up resistors to SDA, SLC (10k, 1k, 100). Switching to different i2c pins. Result seems to be the same. What am I missing? Is there supposed to be a resistor somewhere I don't know about? Other hardware? The screenshots make me think that the GY906 is responding, just the wrong response value.

Main Code

import temp_sensor
Pin = machine.Pin
I2C = machine.I2C


i2c = machine.I2C(0, scl=Pin(22), sda=Pin(21), freq=100000)
temp1 = temp_sensor.Temp.init(i2c)
print(temp1.read_object_temp())
time.sleep(1)
print(temp1.read_object_temp())
time.sleep(1)
print(temp1.read_object_temp())
time.sleep(1)
print(temp1.read_object_temp())

temp_sensor.py

import mlx90614 ##From https://github.com/mcauser/micropython-mlx90614

class Temp():
    
    def init(i2c):
        try:
            sensor = mlx90614.MLX90614(i2c)
        except:
            print('couldnt connect to an i2c temp sensor')
            sensor = False
        else:
            print('temp found')
            #return sensor
        finally:
            return sensor

bad esp32 TTGO T-Display: esp32 - not working, 0xFF good 8266: esp8266 - working, returns temperature reading

1
There's a missing import machine, display, time that I didn't copy in. It's there.Joey Levy
I've tried slowing down the i2c clock and speeding it up. It hasn't helped. 50k all the way through 400k. The WeMos works at most of those speeds.Joey Levy
On the working unit, the write and read portions of the overall I2C transaction were joined via a repeated START condition. On the non-working unit, the write transaction was ended via a STOP condition, and a little while later there was an entirely separate START for the read transaction. Some I2C devices simply don't work with the transactions split that way - I couldn't find any explicit statement to that effect in the datasheet for this sensor, but the example transactions all used a repeated START.jasonharper
That said, I'm not sure what you can do to affect how the I2C transaction is performed. I would guess that you have an outdated or buggy module on that unit - but it could be either machine.I2C or mlx90614 that has the problem.jasonharper
@jasonharper thank you. I think machine.I2C from the pre-compiled image by loboris doesn't work right. I reflashed the non-working device with standard esp32 image (esp32 v1.13), and it reads temperature fine. So both mlx90614.py and the i2c hardware and pins seem fine. I am working on compiling a new version of the firmware with the display library that I need (the reason I used that image). Will report back.Joey Levy

1 Answers

1
votes

For anyone receiving 1037.55 responses from your gy-906 or MXL90614 sensor, that translates to 0xFF, 0xFF or all high (ones) from the sensor. This seems to happen when the sensor doesn't understand how to respond. (Thank you, @jasonharper for helping me understand this)

Here's how the math works:

  • The 0xFF, 0xFF in decimal is 65535.
  • The sensor resolution is 1/50 of a degree which means you divide 65535 x 0.02 to convert to Kelvin, or 1310.7 (K)
  • Kelvin to Celsius (subtract 237.15) gets you 1037.55 C
  • Celsius to Fahrenheit gets you 1899.59 F

Bottom line, your sensor is hiccuping because it doesn't like the stop bit between the write and read, or you have a problem with your I2C bus, either the protocol is doing the request wrong or you have a cabling issue (length or wire gauge or connection, etc). If it's the protocol like it was for me, see if anyone has updated the I2C system library recently and try a different version if possible.

I traced this issue down for days. Luckily I had a number of different MicroPython capable chips and was able to narrow it down to an old version of the machine.I2C library adding that stupid "stop" above.

I bought a $10 protocol analyzer on amazon to make that image above, and I tried loading the code on each of these: Wemos D1, HitLego ESP32S and TTGO T-Display. By trying the code on each, I was able to narrow it down to only the T-Display not working, which needed an custom old firmware version to get the ST7789 display working. The next step is to try to update and recompile the display library from loboris to work with the most recent Micropython firmware. If I make it work, I will reply below.