horshack

Can you please confirm the camera lets you record after the procedure for the full indicated time?

Awesome job! I agree with your follow-up comments on the ML forum - based on your workaround working the camera is storing a future-based RTC timestamp for the available recording/cooldown (current time + interval) rather than a relative time or a simple flag. I'm guessing this wont work in V1.1 firmware since Canon changed the logic to sample the temp more frequently during the active session, which would give preference to the actual temp sampled rather than the previous session's timer setup. However it's still worth a shot because maybe Canon was a bit clumsy with the change.

I doubt Canon's thermal management logic relies on the interval timer/interrupt functionality of the RTC. Nearly all SoCs like DIGIC have extensive internal timer functionality, including programmable interval timers and interrupts. Every embedded design I've worked on only uses the RTC to keep time in between power-on sessions; at start-of-day firmware reads the RTC to establish real time and then uses the SoC's timers to maintain time for the duration of the power-on session. The RTC's programmable interval timers are mostly used to trigger wakeup logic on devices that need to periodically power-up to do useful work.

Canon admitted to Gordon Laing the camera uses a timer in coordination with its temperature sensors https://www.youtube.com/watch?v=3bOeoYI6EYs#t=51s

I've just published a utility that allows for the automation of camera functions on newer Canon cameras like the R5/R6. It can be used to automate the thermal tests. Here's my thread on Dpreview with all the details: https://www.dpreview.com/forums/post/64307212

Why is the FAT32 workaround not viable? The only situations it's not suitable are video modes where the data rate is too high for SD cards, like 4K120P and raw shooting.

Any chance you could check if the battery-pull workaround for the thermal timer still works?

Hoka didn't try the hack on the original firmware so someone else will need to check if it's been patched. Hopefully Canon didn't have time to do so since it only started being widely discussed over the past few days. I'm guessing the firmware they released today has been in regression testing for at least a few weeks and they wouldn't want to make a last-minute change to patch the hole.

Only because it's the home base for my camera-related tech posts for the past 12 years. I started my involvement in the R5 technical investigation there so it would be odd to not continue the discussion there.

The most interesting aspect of today's release are the details Canon provide Gordon Laing on what temperature information is available to the R5's thermal management and from which parts of the camera it's obtained. And how the thermal management behavior was altered with today's firmware. I posted some initial thoughts on it here: https://www.dpreview.com/forums/post/64302450

Let's hope Canon was already too far along in the testing/release cycle to plug the battery-pull hack in this V1.1.0 release.

Some said the HDMI w/o card long-recording workaround was a bug. I didn't believe it. Looks like they were right. Shaking my head. This also implies the thermal management isn't to protect the cards, otherwise why would they still throttle the camera without cards installed (assuming this update throttles both with and without cards).

FYI, I started a new dpreview thread about all the experiments here, which is a continuation of my original thread here.

Joking aside it's nice to have a new tech-savvy contributor working on this! Not sure the camera will let you do 4K120 on the SD card - the R5 manual states 4K120 only supports ALL-I, at a data rate of13447 MB/minute, which works out to ~224 MB/s.

Rereading this I'm thinking maybe the 24P made the difference for the newer 62C plateau vs the earlier's 30P at 72C. That's a lot more data being read off the sensor and pushed through DIGIC.

Thanks for the .CSV data. Here's your data plotted. The running elapsed time was calculated from the EXIF timestamps:

Odd that stills would get hotter. Would really like to see that verified with measurements one day. That's either the sensor (14-bit readouts for stills vs likely 12-bit operation for video), the CFE card (total data rate, or perhaps peak rate during long bursts), DIGIC (more processing for stills, which seems unlikely vs handling/compression for video), the fact you're holding the camera for stills and not video (conduction), etc... One way to eliminate the sustained rate difference is to try 8K raw.

Thanks. So the only difference between this run peaking at 62C and earlier one at 72C was the camera being on the desk? Ambient temps in your room the same as before? How warm does the bottom of the camera get? If that's a thermal conduction point maybe the desk was inhibiting it whereas it would be available to the air on your tripod.

The amount of seconds lost will depend on how much video fits into each 4GB split, which will depend on the data rate for what you're shooting. The R5 manual has a chart of the data rates for all movie modes on page 901 and 902. Pulling the battery in the middle of the writes has the potential to leave NAND cells and/or the filesystem in an indeterminate state, so a high-level format is recommended if not a full-capacity wipe. Try to time the battery pull in between the card-access pulses to minimize the risk to NAND at least. The R5 manual has several warnings about handling hot media cards - they actually recommend waiting a bit before removing the cards after powering on the camera.

A workaround that keeps the video files has already been found and tested:

Btw, regarding running out of buffer and what the effective CFE throughput is on the R5, DIGIC's throughput would play a role in that. I did a deep-dive onto the Nikon Z's relatively slow CFE performance and found that its DIGIC-equivalent (Expeed) was the bottleneck. I'm guessing DIGIC is much faster but there still might be limits. Here's a link to the conclusion from that deep-dive: https://www.dpreview.com/forums/post/63645424

Right, but such bursts are typically short-lived unless someone is holding the shutter down for inordinate periods of time. Shooting 8310 photos in 53 minutes would certainly qualify as inordinate 😀

What's the highest EXIF temp you saw shooting stills for that sequence you noticed it slowing down? If we are seeing such throttling even shooting stills then my theory that the thermal management is to protect the cards / data rates becomes much more plausible. A continuous stills burst slowing down is manageable - a video dropping frames would be more problematic for users - which may explain why the R5 continues to allow stills but not video in hotter situations.

Yep exactly, it's to get the final temperature, although with the 8K clips chopping up at only 47.5 seconds it's probably not needed. It would be more useful for the other long-run tests though, like 4K HQ. I haven't established whether the EXIF temperature in the video files is sampled at the start or end of the recording - I would presume it's at the end when all the EXIF is built but I don't know for sure. I'm going to do an experiment on my RP today to determine this.

The slowdown may have been related to internal garbage collection rather than thermals - I would be surprised if a CFE card throttled shooting just stills. But again it's something to keep an eye on. Just sent you a PM about getting the .CSV data in text form.