-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IMU Detection draining too much battery #772
Comments
This is a good idea, but not easily supported with the current camera architecture. When the camera is on, it is ready to capture within a sub-second. This means the sensor is running, and autoexposure (AE) is happening. It is why your captures don't start in all white or all black images. It is the sensor and AE, and powering the GP2 to process the image, that is using that power. It is not encoding or capturing all the pixels, but it is work. So I don't know whether the IMU can be run with the sensor shutdown (they are attached), but GP2 has to remain running to test the IMU data. I will keep the ticket open as one day this might be possible. |
Thank you for the quick answer! I kind of understand the problem. Sounds like the IMU can't run independently from the sensor due to the hardware architecture. |
While this doesn't directly solve the problem, this is a IMU trigger using less power.
This will turn the camera off for 10sec when there is no motion, reboot, retest the IMU, and record only while the camera is in motion, stops capture when IMU motion stops, all repeats. It will use about a third of the standby power of the old IMU trigger. The downside, if the motion starts while the camera is sleeping, you can miss up to the first 10 seconds. Likely fine for many drone applications. |
This is very useful, big thanks! Will this remember the setting automatically once turned off? Another addition to this feature, which can be incredible to have, is that, I come home with a lot of small files that are a few seconds long only. This are triggered by some short motion or vibration, that were not meant to be recorded. Is there a possibility to not save the videos that were shorter than a certain length? This may not be worth the engineering time tough, as the existing feature works quite good already! |
The script is not currently set up to be saved, but is can be wrapped as a boot script like this !MBOOT="!Lbt"!SAVEbt==Aa!2N=Aa=A*4=A+g"IMU $A"<r0<A4!10R<r0!S+!R>r0<A1!E!R Auto deleting small clips seems risky. |
Hi,
I am using the IMU Detection for automatically starting and stopping the recordings for my Gopro 11 mini and it works great!
However, I realize that while the recording is not ongoing (theoretically only Gyro and ACCL should be computing), the battery is drained significantly (about 15% every half an hour) and the heat sink is getting warm.
I understand this is programmed to be sensor/screen on while the device is actively ready to start recording.
Can we at least have the option to turn off the sensor being active (it's not even useful in 11 mini) and initialize the sensor and start recording when the trigger is activated from the IMU sensors?
This would help us FPV drone pilots save a lot of battery and and save us a ton of stress while in the field filming!
Thank you in advance!
The text was updated successfully, but these errors were encountered: