Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
M16 SHT31 sensor disconnected
#1
Bug 
I've identified an issue with my M16 board whereby the SH31 sensor becomes disconnected after the setup() function and can no longer be read.  I've tried a number of variations on the bus settings, but there seems to be no effect.  The relevant setup() code is this:

PHP Code:
    Wire.begin(45);
//    Wire.setClock(100000);
    
Wire.setClock(10000);
    
Wire.setTimeOut(1000);
    
sht.begin();
    
sht.read();
    
temperature sht.getFahrenheit();
    
humidity sht.getHumidity();
    
int error sht.getError();
    if (
error != 0) {
        
uint16_t stat sht.readStatus();
        
ESP_LOGW("kincony""Temperature sensor Error status: 0x%04x, read status: 0x%04x",
                
errorstat);
        
logSHT31BitStatus(stat);
    } 

This works, however, once inside the loop(), attempts to read the SHT31 fail as disconnected and cannot be reset, even using the HARD option.

PHP Code:
        if (sht.isConnected()) {
            
sht.read();
            
temperature sht.getFahrenheit();
            
humidity sht.getHumidity();

            
int error sht.getError();
            if (
error != 0) {
                
uint16_t stat sht.readStatus();
                
ESP_LOGW("kincony""Temperature sensor Error status: 0x%04x, read status: 0x%04x",
                        
errorstat);
                
logSHT31BitStatus(stat);
            }
        } else {
            
int error sht.getError();
            
ESP_LOGE("kincony""Temperature sensor connection failure, HARD resetting...");
            
ESP_LOGW("kincony""Temperature sensor Error status: 0x%04x"error);
            
sht.reset(true);
        } 

Could this be a conflict with the U8G2?

Full code is available via Github: https://github.com/LouPaloma/KinconyM16-...ter/Source
Reply
#2
yes, maybe have conflict, because all are i2c device. you can test code work only with SHT31 or only with SSD1306. check whether sensor work well. if OK, you can modify your code. it's a software problem.
Reply
#3
My M16 is deployed, so I have limited ability to make code changes of significant magnitude, i.e., solely testing the SHT31.  However, I do have a couple of questions/thoughts:

- The loop() method does contain a U8G2 update.  Would moving that out to a periodic task, e.g., every 30s, remove/reduce the I2C conflict and allow the SHT31 time to respond?

- The sample code I got from this board defined the SSD1306 as U8G2_SSD1306_128X64_NONAME_F_SW_I2C ("Full buffer mode") , but uses the do-while loop... looking at the docs (from my novice understanding) this approach looks to work best with a sendBuffer() approach .  Would defining the SSD1306 as U8G2_SSD1306_128X64_NONAME_1_SW_I2C ( "Page buffer mode") + do-while work better?  Or is this irrelevant?
Reply
#4
we have checked if M16v2 work by ESPHome yaml running SSD1306+SHT31 is ok.
Do you want a arduino demo code to compare with your source code?
Reply
#5
It most certainly is an I2C conflict.  I've modified the code to update the SSD1306 every ~60s and query the SHT31 every ~35s.  I'm seeing about a 60% failure rate on the SHT31, but given the higher read frequency one should still be able to get a reading every 90s or so.

This HACK is "good enough", but I'm open to suggestions on a configuration that would achieve near 100%.

The Github code has been updated with the recent fixes.
Reply


Forum Jump:


Users browsing this thread:
2 Guest(s)