GoPro Hero 13 – WAKE not working on latest firmware versions (02_10_70 and 02_04_70)

[d-biagini]

The WAKE feature in the GoPro Labs firmware does not appear to work with the latest firmware versions (02.10.70 and 02.04.70).

The test procedure was as follows:

• Settings reset (https://gopro.github.io/labs/control/set/?cmd=mPfW0r0!RESET!10)
• Application of the relevant commands (https://gopro.github.io/labs/control/set/?cmd=!MWAKE=2!MTUSB=1)

I tested both with a battery and with a USB power source; in both cases the power input is detected (the rear LED briefly flashes), but the camera does not power on automatically.

I also tested WAKE=1 with the same results. The command works correctly after downgrading to firmware version 02.02.70.

From the changelog I see that there were changes to the WAKE function starting with version 02.04.70 — could this be related?

Thank you for your support.

[dnewman-gpsw]

Not the firmware, I tested again, it is working fine on 2.10.70. It is the power source or the cable is bad, or just on the edge. 100%.

[d-biagini]

Thank you @dnewman-gpsw for your reply and for your time. This is strange — I ran some additional tests to get to the bottom of it.

First of all, I removed the TUSB parameter since it is not particularly relevant for the current evaluation.
I tested both firmware versions 02.02.70 (the last one that works for me) and 02.10.70 (the latest release) using the following setup:

Enabled features: only WAKE=2
Starting conditions: Camera without USB power and without a battery
Tests:

1. Inserting the battery.
2. Plugging in the USB cable provided with the camera (USB-C to USB-C), powered via a Power Delivery laptop port.
3. Plugging in a high-quality USB-C to USB-A cable, powered via a good-quality hub with a BC 1.3-compliant port.

In all three cases, with firmware 02.02.70, after the power source is detected (rear LED blink) the camera powers on and becomes fully operational.

In all three cases, with firmware 02.10.70, after the power source is detected the camera does not power on; however, if I press the power button, it starts normally and is fully operational.

I would also like to point out that the camera never complains about an inadequate power source (I disabled TUSB specifically to make sure of this — and anyway, the behavior is the same when using only the battery). The fact that the camera always powers on when I manually press the button is, to me, further confirmation that this does not appear to be an issue related to the power source or the USB cable.

Below I’m attaching the qrlog.txt logs found in the MISC folder of the SD card in the three cases:

Firmware 02.02.70

[2025-11-21 09:33:40 83%   ] Labs:H24.01.02.02.70 
[2025-11-21 09:33:40 83%   ] Labs:Initialize 
[2025-11-21 09:34:07-dlyLabs 100%  ] Woke with POWER: 
[2025-11-21 09:34:09 83%   ] Labs:SD card ready 
[2025-11-21 09:34:09 83%   ] Labs:Display Messages 
[2025-11-21 09:34:13 83%   ] Features activated: 
WAKE=2: 
[2025-11-21 09:34:13 83%   ] Labs:H24.01.02.02.70 
[2025-11-21 09:34:13 83%   ] Labs:Initialize 
[2025-11-21 09:34:32-dlyLabs 100%  ] Woke with POWER: 
[2025-11-21 09:34:34 --%   ] Labs:SD card ready 
[2025-11-21 09:34:34 --%   ] Labs:Display Messages 
[2025-11-21 09:34:38 00%   ] Features activated: 
WAKE=2: 
[2025-11-21 09:34:38 00%   ] Labs:H24.01.02.02.70 
[2025-11-21 09:34:38 00%   ] Labs:Initialize 
[2025-11-21 09:35:03-dlyLabs 100%  ] Woke with POWER: 
[2025-11-21 09:35:05 --%   ] Labs:SD card ready 
[2025-11-21 09:35:05 --%   ] Labs:Display Messages 
[2025-11-21 09:35:09 00%   ] Features activated: 
WAKE=2: 
[2025-11-21 09:35:09 00%   ] Labs:H24.01.02.02.70 
[2025-11-21 09:35:09 00%   ] Labs:Initialize 

Firmware 02.10.70 – Power source connected, power button NOT pressed

[2025-11-21 09:45:17-dlyLabs ] wake reason:BOOT_REASON_POWER_ON_FROM_SCRATCH 
[2025-11-21 09:45:18 82%   ] Labs:SD card ready 
[2025-11-21 09:45:21 82%   ] silent:shutdown 
[2025-11-21 09:46:01-dlyLabs ] wake reason:BOOT_REASON_POWER_ON_FROM_SCRATCH 
[2025-11-21 09:46:02 00%   ] Labs:SD card ready 
[2025-11-21 09:46:05 00%   ] silent:shutdown 
[2025-11-21 09:46:58-dlyLabs ] wake reason:BOOT_REASON_POWER_ON_FROM_SCRATCH 
[2025-11-21 09:46:59 00%   ] Labs:SD card ready 

Firmware 02.10.70 – Power source connected, power button pressed after a few seconds

[2025-11-21 09:42:36-dlyLabs ] wake reason:BOOT_REASON_POWER_ON_FROM_SCRATCH 
[2025-11-21 09:42:37 82%   ] Labs:SD card ready 
[2025-11-21 09:42:40 82%   ] silent:shutdown 
[2025-11-21 09:42:44-dlyLabs ] wake reason:BOOT_REASON_RESET 
[2025-11-21 09:42:45-dlySD ] Labs:SD card ready 
[2025-11-21 09:42:45-dlySD ] Labs:Display Messages 
[2025-11-21 09:42:49 82%   ] Features activated: 
WAKE=2: 
[2025-11-21 09:42:50 82%   ] Labs:H24.01.02.10.70 
[2025-11-21 09:42:50 82%   ] Labs:Initialize 
[2025-11-21 09:43:04-dlyLabs ] wake reason:BOOT_REASON_POWER_ON_FROM_SCRATCH 
[2025-11-21 09:43:05 00%   ] Labs:SD card ready 
[2025-11-21 09:43:08 00%   ] silent:shutdown 
[2025-11-21 09:43:12-dlyLabs ] wake reason:BOOT_REASON_RESET 
[2025-11-21 09:43:13-dlySD ] Labs:SD card ready 
[2025-11-21 09:43:13-dlySD ] Labs:Display Messages 
[2025-11-21 09:43:17 00%   ] Features activated: 
WAKE=2: 
[2025-11-21 09:43:18 00%   ] Labs:H24.01.02.10.70 
[2025-11-21 09:43:18 00%   ] Labs:Initialize 
[2025-11-21 09:43:33-dlyLabs ] wake reason:BOOT_REASON_POWER_ON_FROM_SCRATCH 
[2025-11-21 09:43:34 00%   ] Labs:SD card ready 
[2025-11-21 09:43:36 00%   ] Labs:Display Messages 
[2025-11-21 09:43:40 00%   ] Features activated: 
WAKE=2: 
[2025-11-21 09:43:41 00%   ] Labs:H24.01.02.10.70 
[2025-11-21 09:43:41 00%   ] Labs:Initialize 

From what I can understand — without access to the firmware internals — the only thing that looks suspicious are those silent:shutdown messages appearing right after the camera reports BOOT_REASON_POWER_ON_FROM_SCRATCH.

I would be grateful if you could dedicate a bit more time to help me investigate this issue. At my company we currently use GoPro Hero 10 units integrated into equipment for services we provide to our clients, and we would like to migrate to the GoPro Hero 13 as soon as possible.

[dnewman-gpsw]

Do a !RESET on your camera. And maybe !FRESET Get the camera to baseline.

As here is what adding USB power looks like for me:

With Battery:
[2025-11-21 12:58:41-dlyLabs ] wake reason:BOOT_REASON_USB1_INSERTED
[2025-11-21 12:58:41-dlyLabs 100% ] chg reset reason:BOOT_REASON_USB1_INSERTED
[2025-11-21 12:58:41-dlySD ] Labs:SD card ready
[2025-11-21 12:58:42-dlySD ] Labs:Display Messages
[2025-11-21 12:58:46 >>70% ] Features activated:
WAKE,TUSB:
[2025-11-21 12:58:46 >>70% ] Labs:H24.01.02.10.70
[2025-11-21 12:58:46 >>70% ] Labs:Initialize

Without Battery:
[2025-11-21 13:02:13-dlyLabs ] wake reason:BOOT_REASON_POWER_ON_FROM_SCRATCH
[2025-11-21 13:02:14-dlyLabs 100% ] chg reset reason:BOOT_REASON_POWER_ON_FROM_SCRATCH
[2025-11-21 13:02:14-dlySD ] Labs:SD card ready
[2025-11-21 13:02:14-dlySD ] Labs:Display Messages
[2025-11-21 13:02:18 00% ] Features activated:
WAKE,TUSB:
[2025-11-21 13:02:18 00% ] Labs:H24.01.02.10.70
[2025-11-21 13:02:19 00% ] Labs:Initialize

[d-biagini]

Good morning @dnewman-gpsw,
I performed both the reset (!RESET) and the factory reset (!FRESET), but I did not observe any different behavior in my use case of interest (powering the camera without a battery inserted).

However, your message made me think and run additional checks. In particular, I noticed that the behavior is different if a battery is inserted in the camera at the moment USB power is applied.

Here is what I verified:

1. INITIAL STATE: Camera off, no battery inserted.
   ACTION: Insert battery.
   RESULT: The camera does not turn on.

2. INITIAL STATE: Camera off, no battery inserted.
   ACTION: Connect USB power.
   RESULT: The camera does not turn on.

3. INITIAL STATE: Camera off, no battery inserted.
   ACTIONS: Insert battery, then connect USB power.
   RESULT: The camera does not turn on (but the rear LED stays solid, as if the battery were charging).

4. INITIAL STATE: Camera off, no battery inserted.
   ACTIONS: Insert battery, connect USB power (same as case 3), disconnect and reconnect USB.
   RESULT: The camera turns on.

5. INITIAL STATE: Camera on, battery inserted, no USB power.
   ACTIONS: Power off manually with the button, then insert USB power once shutdown is complete.
   RESULT: The camera turns on.

6. INITIAL STATE: Camera on, battery inserted, USB cable connected.
   ACTIONS: Power off manually with the button, then remove the USB cable.
   RESULT: The camera turns on (???)

Indeed, when a battery is present the behavior changes, but it seems highly inconsistent (for example, the fact that the camera turns on when the USB cable is removed if a battery is installed is quite strange).

I want to emphasize that my use case of interest is case (2) — powering the camera via USB with no battery ever present.

If the test you performed earlier is the same and your camera does turn on, then we are observing two different behaviors, and I cannot explain that.

The fact that any manipulation of the camera prior to the test (inserting a battery, performing a manual power cycle, etc.) seems to alter the outcome makes me hope that this might be the reason why we’re seeing different results.

Thanks again for your support — I hope we can at least achieve consistent behavior across units.

[dnewman-gpsw]

And these tests are after you scanned WAKE=1TUSB=1? Try a different cable and different power source.

[d-biagini]

I can confirm that the only enabled features are WAKE=1 and TUSB=1.
I also followed your suggestion: in addition to trying several different cables (which I had already tested), I obtained a proper wall USB charger (Amazon Basics model B0773HDJYM).
Surprisingly, regardless of which cable I use, the camera does power on when connected to the wall charger.

This actually raises more questions than answers, because the only difference between a wall charger and a PC port or a BC 1.2–compliant hub is that the wall charger behaves as a DCP (Dedicated Charging Port), while a hub/PC port is a CDP (Charging Downstream Port). From the camera’s point of view, these should not behave differently.

I don’t believe this is a power-delivery issue: the hub I’ve been using can supply up to 2.4 A on its BC 1.2 port.
Nor does it look like a port-detection issue: if I connect the camera to an SDP (Standard Downstream Port, no BC 1.2), the rear LED does not blink and the camera does not turn on even when pressing the power button — which is expected.

Looking at the log produced when connecting to the wall charger, I can see the line:
chg reset reason:BOOT_REASON_POWER_ON_FROM_SCRATCH
—which matches what you shared.
So the question becomes: what exactly triggers this condition? Because it does not happen when the camera is connected to a logical USB port (CDP).

Could you let me know whether the tests you performed were done using a wall charger or a logical USB port?
If you used a logical port, I would be very interested in its specifications, because in our use case we need the data lines to be active — we control the camera via OpenGoPro over USB.

Finally, it’s worth noting that the behavior is indeed different compared to firmware versions prior to 02.04.70. On those versions, the camera works without issue when connected to BC 1.2 ports, including CDPs, which is exactly what we need.

Thanks again for your help — any insight you can provide will be extremely valuable for us.

[dnewman-gpsw]

I used a 5 year-old generic power bank in my testing (also worked with a random PC connected port.) No one else is reporting this. So I strongly believe it is on your end, as these are popular features.

[d-biagini]

I understand your point, and I agree that if no one else is reporting this, it suggests the issue may be specific to my unit or setup. However, before drawing any conclusions, I would like to point out a few observations that still seem inconsistent with this hypothesis:

The same setup works perfectly on firmware 02.02.70, and the issue appears only starting from 02.04.70.
This makes me wonder whether there might be a subtle edge-case regression that only affects certain USB hosts or detection paths.

The behavior is fully reproducible across all my test configurations, including:

• multiple high-quality cables
• two different BC 1.2 hubs
• two different laptops
• multiple USB-A and USB-C ports
• and power-only DCP chargers (which do work)

The results are consistent and repeatable.

The power bank you mentioned behaves as a DCP, which matches the only scenario in which the camera powers on reliably on my end.
The difference between DCP vs CDP is precisely where I’m currently seeing the divergence.

That said, if you can confirm that the laptop-port test you performed was done without a battery inserted, then this would indeed be a different behavior from what I’m seeing here. I will prepare a more structured test plan together with our electronics engineering team and try to identify how to reach a working configuration on my side.

If it’s not an issue for you, I’d prefer to keep this ticket open so that I can update it if I discover anything new — or so that other users who might encounter a similar situation can find it easily and possibly contribute additional data points.

Thank you again for all the support and for the quick responses.
Wishing you a great day.

[WhiteyFord]

Hi @d-biagini, I am experiencing the same issue with the latest firmware on both GoPro Hero 12 and 13. I have two of each of the camera's and have the exact same problem you describe. I can confirm that it does work for the Hero 12 with firmware 02_32_70 and on the Hero 13 with firmware 01_30_72.

[dnewman-gpsw]

Without a battery and CDP port, I have confirmed it will not boot. This is not what the WAKE is ever tested for. Curious why do you need that setup? Are you using Open GoPro for camera control?

[d-biagini]

Yes, exactly — we use GoPro Labs together with OpenGoPro to achieve fully automated camera control. Using this approach, over the past few years we’ve successfully built multi-camera rigs for a semi-industrial application, based on the Hero 10.

For this type of system, having reliable control over the camera “lifecycle” is absolutely essential. WAKE on USB power has been a pivotal feature for us, as it allows deterministic rebooting and automated recovery without any human interaction.

We are currently updating our product to support the latest-generation GoPro cameras, in order to benefit from the new and very valuable Labs features — and we are also planning to evaluate a version with a larger number of cameras. Because of this, continued access to this functionality is extremely important to us, and we really hope the issue can be investigated.

We strongly want to keep building on top of the GoPro ecosystem, and we would like to avoid being left out of future firmware features or hardware generations due to this specific dependency. WAKE behavior on USB power (with no battery) is a key requirement for our integration, and we would be grateful for any attention this can receive.

[WhiteyFord]

Our use case is similar where consistent WAKE on USB is a hard requirement for our deployments and also supports many other workflows.

[r3dpath]

Just to chime in as well we have a similar use case, with wake on usb and then control over Open GoPro. Working out how to power a GoPro has been a bit of a mission, it seems like there's a lot of edge cases with battery in vs out and the various BC 1.2 modes enumerated. Is this documented anywhere? I know it's a niche and unsupported use case, but I would imagine we aren't the only ones making hardware to connect GoPros to SBCs. Thanks!

[dnewman-gpsw]

After some more investigation, I'm not finding any recent change between 2.04.70 and 2.10.70. So I can't replicate your findings. However, I have determined that not all USB ports are the same. From my workstation, none of the USB ports will cause the camera to boot (red LED flash), yet from two USB C only laptops (PC and a Mac), the camera will LED flash. No full bootup yet, but that flash means Labs code can be run. No-flash means the MCU has rejected the power, and will not boot the main processor (I'm investigating this more.) Turns out this has been somewhat solved for one other GoPro camera, GoPro Bones, or any "naked" GoPro, as they can't have an authenticated battery. Bones has a boot on power function and no battery, although it did have a USB port either. You HERO13 is not a Bones camera, but there is a developer backdoor to emulate Bones boot logic with NAKE=1 (pretend to be a naked GoPro.) With WAKE=1NAKE=1TUSB=1 my camera will boot without a battery from some USB C laptop ports.

Maybe this is all you need. Please give it a try.

[Chester-at-dawn]

Hey @dnewman-gpsw, thanks for the reply.

I am working on this along side @r3dpath on this.

For some context, we are trying to use GoPro labs and OpenGoPro in combination with a raspberry pi to basically create a networked GoPro that we can fully control (settings, recording, file transfer etc). OpenGoPro does not support wake over their USB protocol, which is why we are trying to find a way to wake it on power using Labs. We are modifying the GoPros, and wont be using batteries as a weight saving / safety measure. It seems that we have a very similar requirements to @d-biagini with this project.

Our initial thinking was that we could just power the 5V USB rail and the GoPro would turn on, but that does not seem to be the case. There seems to be some enumeration that is required for it to turn on, which is what @r3dpath found testing various BC 1.2 modes. I think this is also what you're seeing with some ports not waking your camera. The wake behavior seems to be a lot more consistent with a battery attached, but this is not desirable for the application.

With just the rails powered, and a battery installed, the camera will wake normally. Without the battery installed, the camera will not wake. Observing the current measurement on the power supply, it will spend 1-2s at 60ma, and then drop-down to 6 when the power source is rejected. This is using the command *WAKE=1*TUSB=1. The power supply has the current limits set above 2A. It does boot when the DP/DN lines are connected to a battery bank, which I assume does some enumeration.

Trying the *WAKE=1*NAKE=1*TUSB=1 command has weird behavior with the GoPro, where it "corrupts" the GoPro Labs logic, and requires a reset to regain normal functionality. By "corrupts" I am not seeing any text on the screen. I wasn't able to get it to boot off any USB sources with the battery removed.

Regarding TUSB, it seems that it powering the rail should be enough to trigger a boot. Are there lower-level checks that means that its unable to 'fully' trust the USB power source? It would be nice to see a TUSB=2 or similar, where the GoPro is able to avoid all enumeration, and just simply try and boot when it sees a voltage on the USB line.

Appreciate the help so far,

Thanks.