search

TinyCamML / Boron-and-OpenMV

This repo is continued progress between Boron and OpenMV as a self contained device that can successfully monitoring flooding on roadways.
MIT License
0 stars 0 forks source link

Apparent power supply issue with OpenMV on solar power #7

Closed SUPScientist closed 1 month ago

SUPScientist commented 6 months ago

Opening a new issue in this repo based on issue described here: https://github.com/TinyCamML/OMVmodel/issues/11. Issue pertains to setup where Boron and OpenMV are connected and powered by solar panel/battery and belongs in this repo.

@BentleySettin writes:

The OpenMV is displaying a variety of LEDs when connected to a variety of power sources. When the Boron and OpenMV are connected to solar panel and battery there is an indefinite white light. When the Boron and OpenMV are connected USB via my computer and battery there is a flashing white light. When both devices are connected to USB there are no LED's besides an occasional green flashing that lasts for a few seconds.

@BentleySettin, is the following accurate?

Expected behavior:

Actual behavior:

Steps to reproduce behavior:

SUPScientist commented 2 months ago

Update following email from @efarq on 16-Jul-24 titled "TinyCamML Update":

Issue not resolved but not necessarily related to (solar) power supply.

Expected behavior:

"Flood" or "No Flood" to show up in transmitted data string from Boron.

Actual behavior

"Flood" or "No Flood" shows up for first 17 samples (96 minutes) then ceases. See screenshot of data from Sheets: image

Other symptoms: Photos cease to be saved to SD card at the same time that "Flood" or "No Flood" no longer reported, and images that were saved appear to be a combination of two different frames. Appears to indicate problem with OpenMV side.

Suggested tests

  1. Restart and run everything "fresh" again to see if failure timing is deterministic
  2. See https://forums.openmv.io/t/sleep-mode-wakeup-with-external-interrupt/767/2. Especially

Anyway, you shouldn’t put code… in your call back. Instead, just have a very simple method that immediately exits. What will happen is that after standby the camera will wake up again and continue to execute code. Note that you need to completely re-init the camera after this happens.

I'm not the OpenMV expert (@ebgoldstein, can you take a look at this hypothesis?) but wonder if our OpenMV (re)initialization is happening above the callback and that is causing the issues. If you move https://github.com/TinyCamML/Boron-and-OpenMV/blob/1b7a30e41cd7efd28e730982d60f455be0a2741b/Firmware/OpenMV/PublishOpenMV.py#L22-L23 up to immediately after the import statements, does that make a difference?

ebgoldstein commented 2 months ago

I am also interested in what @SUPScientist mentioned, if it is a deterministic time..

In #26 I updated the image save routine, the text file generation, and added a line to the txt file to make sure to track memory growth..

@efarq , I recommend checking out the PR, and using this new firmware to retest the openMV...

ebgoldstein commented 2 months ago

i think what i want to see is the Boron google sheet and the OpenMV csv/txt sheet for this new test.... as well as the photos, to see if they have that half/half error

SUPScientist commented 2 months ago

If #26 doesn't resolve the issue, I'd still be interested in following code structure closer to https://forums.openmv.io/t/sleep-mode-wakeup-with-external-interrupt/767/2. Specifically, sensor.reset() and other config details in the while loop. I'm admittedly less familiar than I'd like with how micropython and openmv handle the wake from interrupt/callback when sleeping.

ebgoldstein commented 1 month ago

I'm going to close this for now...