Posts made by hague

The problem can be solved with a delay(20); at the end of the loop() function. 10ms was not enough on my system, but 20 does not show any more ghost keystrokes.

@ajb2k3 No it's not a Grove pin.
Check here:
https://github.com/m5stack/m5-docs/blob/master/docs/en/core/fire.md

@zontex OK, you're right, without code it's hard to help. Sorry, my mistake.
In the meantime, I tried a little more to understand the problem better. It's not that the 1-Wire connection doesn't work anymore at all. It's just that the devices are no longer found immediately on the bus after a lot of data has been written to the SD card.
In detail, this call does not find any devices after I have previously written a large block of data to the SD card:

DS18B20.begin();
device_count = DS18B20.getDS18Count();

But if I call DS18B20.begin() twice, all devices are found. Therefore I have placed the function in a loop:

int trial_count = 0;
int device_count = 0;
do{
  DS18B20.begin();
  device_count = DS18B20.getDS18Count();
  trial_count++;
} while (device_count == 0 && trial_count < 10);
M5.Lcd.printf("\nDevices found: %i\nafter %i tries\n\n", device_count, trial_count);

Now all devices are found after one call, if I did not write any data to the SD card before. However, if I write a larger amount of data to the SD card in between, then 2 attempts are needed until all devices are found.

I think the 1-Wire bus is somehow disturbed by the transfer of the large amounts of data. This does not happen with small data. Anyway, the solution is OK and makes sense.

You are using the GPIO 26 for the I2C connection to the BMP280 and SHT30 sensors. Then you can't use this pin as GPIO to switch the relay at the same time.
For the Relay, you will need a GPIO pin. For the BMP280, you will need I2C. This puts you in a dilemma if you only want to use the Grove connector. You can use the peripheral pins on the bottom side of the ATOM lite. Check this pin mapping:
https://docs.m5stack.com/#/en/core/atom_lite?id=peripherals-pin-map
There you can find 5V, GND and some free GPIOs. That should work.

Alternately you can buy the EXT.IO GPIO Expander:
https://m5stack.com/products/official-extend-serial-i-o-unit
Then, you can address 8 additional GPIOS via I2C.

Hello,
I have the problem that I can no longer address 1-Wire DS18B20 sensors when I have accessed the SD card. I have already tried connecting the sensors to different pins (2, 5 and 26). Without accessing the SD card, I can query the sensors without any problem.
What can be the reason for this?
I have used several libraries for the DS18B20 sensors in combination with the oneWire library from Paul Stoffregen

Maybe it would be an idea to use an I2C to 1-Wire converter? Like the DS2482-100. Then you can have several I2C devices on the bus and also 1-Wire devices. I have not tried the chip yet. But I will do that soon.

The I2C address of the VL53L0X can be changed by a software command. But this is only possible, if only one sensor is connected, because all sensors have the same address, when they are switched on.
You can first connect one of the sensors and change the address of this sensor. Then you can connect the second sensor. Now you have two sensors with different addresses.
Unfortunately the sensor forgets the changed address at a restart. Or more precisely, when it loses its supply voltage.
I hope this helps.

@kylebuttress Same as for the M5StickV
M5StickV_Firmware_v5.1.2.kfpkg
and
maixpy_v0.5.0_98_gbd7c7ab_m5stickv.bin

downloaded here:
https://dl.sipeed.com/MAIX/MaixPy/release/master

Hi, Maybe flipping the sensor image will fix this:

sensor.set_vflip(1)

This was the solution for my problem with april tags and QR-Codes.

OK, I found the cause: The image from the camera was mirrored. So the tag could not be detected. I found the error when I tried to detect QR codes:

Then I added the following line of code to mirror the image:

sensor.set_vflip(1)

After that, the QR code was detected correctly:

Now, also april tags are working:

In addition to the code, here are some screenshots:

M5StickV with the above code:

As you can see, the april tags are detected correctly (output in the serial terminal)

UnitV with the same code:

No tags are detected...

Same firmware, same MaixPy version, same code... But a different behavior...

I can detect april-tags with the StickV, but not with the UnitV AI camera. For the UnitV I use the same code, but without the LCD calls. Here's the code:

import sensor
import image  
import math

print("start script")

sensor.reset()
sensor.set_pixformat(sensor.RGB565)
sensor.set_framesize(sensor.QQVGA) # 160 x 120 pixel
sensor.run(1) 
sensor.skip_frames(30)

print("start loop...")

while True: 
    img=sensor.snapshot()
    tags = img.find_apriltags() # defaults to TAG36H11 without “families”.   
    if len(tags) > 0:
        for tag in img.find_apriltags(): # defaults to TAG36H11 without “families”. 
            #img.draw_rectangle(tag.rect(), color = (255, 0, 0))
            #img.draw_cross(tag.cx(), tag.cy(), color = (0, 255, 0))
            degress = 180 * tag.rotation() / math.pi
            print(tag.id(),degress)

I have uploaded the latest firmware. What can be the reason that no april-tags are detected?

@puijkh Same for me with april tags. Did you found a solution?

Hello,
On one of my M5Stack devices the battery in the bottom module is swollen. That worries me!
I have used the M5Stack with the additional battery module. Then both batteries are connected in parallel, right?
Can that be the cause? Has anyone ever observed this when using the extra battery module?

@m5stack Many thanks for the quick help. With the spare part the BALA now works perfectly!

It also took me a little while to get the BALA up and running. Then I made a little video as a kind of manual. Maybe it helps the one or the other.
https://youtu.be/iYmJmg_pJ74
If it does not behave this way at all, for example if the green LEDs on the motors do not light up at all, then it is possible that the motor driver is damaged.

I have achieved quite good results with the Seeed Studio Grove 3-Axis Digital Compass V2.
https://wiki.seeedstudio.com/Grove-3-Axis_Digitial_Compass_v2.0/

Hi,
I also never saw any flickering, but I used the M5.dis.displaybuff() method with predefined patterns.
You can check the code here: https://github.com/electricidea/M5ATOM/tree/master/Tilt-Game

Hope that helps.
Hans-Günther

I can confirm that it is related to the radiation from the M5StickC. When I connect the ENV-HAT with cables away from the stick, the sensor measures reasonable values.

Incorrect values if the ENV-HAT is directly connected:

Correct values if the ENV-HAT is connected via a cable extension:

My balancing robot has an identical problem. But not from the beginning: At first it worked. But then the motor board failed. I can't tell if it's related to a connection via USB for loading the battery or if it just happened. But it is definitely the board that is broken.

I have noticed that the case gets warm when I try to charge it. The red LED lights up continuously, indicating a fully charged battery, but the unit won't turn on. There are no green LEDs on the motors. As I said, it worked in the beginning.

I have noticed that the IMU on the core unit no longer provides data when the motor unit is connected. It looks as if the I2C bus is blocked.

If a USB cable is connected for charging, the IC 5306 gets hot above 90°C:

By the way: Now, the red LED is no longer lit at all!

I think the board is broken. I measured the voltage of the battery when the battery is connected to the board but it shows 0V. Maybe the short circuit protection shuts down? Good to know, otherwise my flat would be on fire now....

The battery is working fine inside another M5Stack Core unit, so the battery is not broken.

I measured the Current consumption of the board without a connected battery:

Again, a further indication that the board is damaged.

Looks like I will need a new board...

Does anyone else have a problem with the board?