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

Determine reason for communication interruptions when running for a long period of time (10 min +) #4

Closed BentleySettin closed 8 months ago

BentleySettin commented 9 months ago

I am currently running the firmware for a long period of time to see if there are any issues. Looks like right now when this ran for about 10 minutes it printed "feeling restless" and collects flood or no flood sporadically. This is for about 3 minutes and then it seems to "come back to life" and run as normal. And to no apparent pattern it will not print flood/no flood at all. Seems to be a power issue but I am also wanting to see if it is a comm issue. Maybe the repetitions are so close to each other they struggle to run on sync?

Current step: I set runs for every 6 minutes, which would happen in the field, instead of every 1 minute. I want to see if this helps with this issue.

Next possible steps: Use USB for both devices (remove power wire) to determine if it is a power issue.

BentleySettin commented 9 months ago

6 minute intervals worked 4 times (total of 24 minutes) before no longer reporting flood/no flood. When the two devices seem to be out of sync I can see the Boron turn on, wait 2 seconds, turn off, and then the blue LED from the OpenMV which signifies it ran through its loop. The blue light after the Boron turns on and off shows a possible descripency in time. However, with the 6 minute test the openmv did not even flash blue.

BentleySettin commented 9 months ago

Update: Retried this trial and it ran successfully for 42 minutes.

BentleySettin commented 8 months ago

These issues do not occur when the interval time was increased to 6 minutes.