Posts made by dda

@mati I have mentioned this to Jimmi, and his answer basically was, well don't use wifi and OLED. Not exactly a practical answer. I'd rather have a long hat, isolating the DHT and BMP from the heat.

A screenshot or full text of the error would be helpful...

If you have the OLED and WiFi on, the heat they produce will skew the results. I connect the ENV hat to my Stick C with wires, and I get different, lower-temp results.

MOSI/MISO is the SPI equivalent of Tx/Rx for UART (except the lines are not crossed: MOSI connects to MOSI, and MISO to MISO). The other difference is that's it's a bus, like I2C, with one master and one or more slaves. So you can connect a screen and a LoRa chip, for instance. However, you need a separate SS (Slave Select) line per device. You're going to have difficulties finding enough pins for this. As suggested, it'd be much better to use a managed chip (MCU + LoRa chip).

I've tried a few things but it's too cumbersome. I switched back to M5Stack for this.

In my code I was using Wire instead of Wire1... So by changing that it worked.

The datasheet has most of the registers explained. I have the Chinese version, so it requires a little squinting (my Chinese is ok but nowhere near the level required to read datasheets with a smile pasted on my face ;-).

However I recently spent some quality time with the source code and the datasheet, so I have that more or less nailed down.

Register 46H is IRQ Status 3. Bits 0/1 are for the button:

// 0 not press, 0x01 long press, 0x02 press
uint8_t AXP192::GetBtnPress() {
  Wire1.beginTransmission(0x34);
  Wire1.write(0x46);
  Wire1.endTransmission();
  Wire1.requestFrom(0x34, 1);
  uint8_t state = Wire1.read();
  if (state) {
    Wire1.beginTransmission(0x34);
    Wire1.write(0x46);
    Wire1.write(0x03);
    Wire1.endTransmission();
  }
  return state;
}

In Wire1.write(0x03); 0x03 is the two bits 0 and 1 set.

There are many more registers, and the best would be to get a datasheet in English and read the registers description.

It should be 34. From MPU9250.cpp:

// Configure Interrupts and Bypass Enable
// Set interrupt pin active high, push-pull, hold interrupt pin level HIGH until interrupt cleared,
// clear on read of INT_STATUS, and enable I2C_BYPASS_EN so additional chips
// can join the I2C bus and all can be controlled by the Arduino as master
writeByte(MPU9250_ADDRESS, INT_PIN_CFG, 0x22);
writeByte(MPU9250_ADDRESS, INT_ENABLE, 0x01); // Enable data ready (bit 0) interrupt
delay(100);

0x22 = 34.

Nice list.

Espressif recommends you turn off BT, ADC and WiFi yourself before going to deep sleep, as the ESP32 doesn't do it "gracefully". Something like this:

esp_wifi_stop();
esp_bluedroid_disable();
esp_bluedroid_deinit();
esp_bt_controller_disable();
esp_bt_controller_deinit();
esp_bt_mem_release(ESP_BT_MODE_BTDM);
adc_power_off();
esp_deep_sleep_start();

I have a lot of different LoRa chips and setups. I have one board, at 230 MHz, that I can connect through the hat connector (I need 3 pins + Vcc/GND). I have transceivers, both at 230 and 433 MHz, I connect to via RS485 (I bought a hat for that, and also some RS485 for my M5Stack cores). etc etc. The smaller the better :-)

@ws1088 Funny enough I bought my M5StickC with the watch strap and all, but not because I wanted a watch – I don't wear them – but because it enables me to tie it up to my backpack when I do LoRa range tests :-)

I did a simple test: with only REG 28H the screen stays slightly warm. With both 28H and 10H, the screen cools off after a while. Hardly a scientific test, I know, but seems to point to the need to set both registers.

To be tested but I think this turns off OLED_VDD, ie the current to the OLED. Register 10H is said to be for OLED_VPP so setting it to zero could help too.

While I'm at it, an explanation about M5.Axp.ScreenBreath(x);. The code is:

void AXP192::ScreenBreath(uint8_t brightness) {
  Wire1.beginTransmission(0x34);
  Wire1.write(0x28);
  Wire1.write(((brightness & 0x0f) << 4)); //Enable LDO2&LDO3, LED&TFT 3.3V
  Wire1.endTransmission();
}

What it does is it takes the value you passed, cuts it to 4 bits (0-15) and moves those 4 bits to bits 4-7. Register 28H is voltage control for LDO2 (bits 4-7) and LDO3 (bits 0-3). So the OLED is connected to LDO2.

What that 0-15 value represents is a voltage of 1.8 to 3.3V, in 100mV/steps. So M5.Axp.ScreenBreath(0); sets voltage to 1.8V, and M5.Axp.ScreenBreath(15); to 3.3V. Not what we really want – as the goal was to set voltage to zero... :-)

Whereas register 12H controls the state (ON/OFF) of a bunch of wires, including LDO2 (bit 2). Hence the code above.

After a little bit of poking around I managed to turn off the screen:

Wire1.beginTransmission(0x34);
Wire1.write(0x12);
Wire1.write(0b01001011);  // LDO2, aka OLED_VDD, off
Wire1.endTransmission();

This turns off LDO2, and thus the backlight. To turn it back on:

Wire1.beginTransmission(0x34);
Wire1.write(0x12);
Wire1.write(0x4d); // Enable LDO2, aka OLED_VDD
Wire1.endTransmission();

I poked around the APX192 code, and around a datasheet found here. First, there's this code:

void AXP192::begin(void) {
  Wire1.begin(21, 22);
  Wire1.beginTransmission(0x34);
  Wire1.write(0x10);
  Wire1.write(0xff);  //OLED_VPP Enable
  Wire1.endTransmission();
  Wire1.beginTransmission(0x34);
  Wire1.write(0x28);
  Wire1.write(0xff); //Enable LDO2&LDO3, LED&TFT 3.3V
  Wire1.endTransmission();

A peek at the datasheet says that REG 28H is power management for LD02 and LD03. Sure thing. That's what the comment in the code above says – along with a hint that LD03 is for the TFT.

Meanwhile, REG 10H is two ON/OFF switches, for EXTEN and DC-DC2 – commented in the code as VPP_Enable. Bueno.

I am not sure which of EXTEN or DC-DC2 is connected to the OLED (both?), but turning either or both off will cut off the current to the OLED.

Moreover there's this code later:

  Wire1.beginTransmission(0x34);
  Wire1.write(0x12);
  Wire1.write(0x4d); //Enable DC-DC1, OLED_VDD, 5B V_EXT
  Wire1.endTransmission();

And REG 12H seems to do more of the same as 10H:

Bit 3 turns ON/OFF LD03, which, as we saw above, is supposed to be the OLED. Good odds that setting bit 3 of REG 12H to zero would work too.

I don't have time to test it now, but I'll try later tonight.

First, your code is badly indented (remember to press ^T in the Arduino IDE to format it properly) and thus unreadable. After proper formatting, here is what loop() looks like:

void loop() {
  new_time = millis(); /* check if to run this time */
  if (new_time >= next_time) {
    /* Calculate distance */
    echotime = GetEchoTime();
    /* only scale valid readings 0 is timeout or 1 is no echo
       realistically minimum accurate or physical range is 3cm */
    if (echotime > MAX_ERROR) {
      // Valid number convert to cm
      distance = echotime;
      distance += SCALE_CM_ROUND; // add in half bit rounding
      distance /= SCALE_CM;
    }
    /* catch errors first */
    if (echotime <= MAX_ERROR || distance > MAX_RANGE) {
      if (echotime > 0 && echotime <= MAX_ERROR)
        Serial.println("MAX");
    } else if (distance < MIN_RANGE)
      Serial.println("MIN");
    else
      Serial.println(int(distance)); // In range output distance
    next_time = new_time + INTERVAL; // save next time to run
  }
}

Now the simplest answer as to why "MAX" is never displayed is because the conditions are not reached. However, I'm not sure that the logic in your ifs is correct. You have an if/else if/else main test, and inside the if another if, and that doesn't make much sense. Work on that logic first.

Alright so after discussing this with Jimmy, turns out the ENV hat uses Wire1, not Wire, so the I2C scanner was poking in the wrong place. After fixing a couple of issues in code, it is working. Case closed :-)

@wikistik been there done that. I have everything needed.

As I said the I2C addresses listed by the I2C scanner are plain odd, which makes me think that the ENV hat (or the SickC) is defective. Which is why I was asking whether anyone had a similar experience.

Hi,

I am trying out the M5Stick-C with an ENV hat, and the Arduino IDE ENV.ino sketch isn't working. Says it can't find the BME and BMM. Humidity data from DHT12 is also wrong (0%).

So I ran an I2C scanner sketch, and I get 3 devices on the bus (that's good!) but the addresses are plain wrong – or anomalous, if you will...

It lists devices on 0x34, 0x51 and 0x6C... Not exactly what one would expect... Has anyone seen anything like that? I'm thinking the ENV hat is fubared...

TIA

@0x1abin The prebuilt firmware doesn't work for me either. I get this:

I (362) heap_init: Initializing. RAM available for dynamic allocation:
I (369) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (375) heap_init: At 3FFB9E48 len 000261B8 (152 KiB): DRAM
I (381) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (387) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (394) heap_init: At 400907AC len 0000F854 (62 KiB): IRAM
I (400) cpu_start: Pro cpu start user code
I (194) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
E (306) camera_demo: Camera probe failed with error 0x20001

Faulty device?