horshack

I can't think of many scenarios where a user shooting video with the camera locked down on a tripod would have to touch the camera for anything other than a momentary dive into the menu, the LCD for focusing, and perhaps the body during panning. Canon talked about low-temperature burns - the camera wont be a thermal risk if the user only touches it intermittently and for a few seconds at a time. It's not hot like a potato. Regarding CFE, Canon has multiple warnings in the R5 manual about handling hot cards that have been removed from the camera. That can occur for stills shooting as well, esp long duration burst-shooting.

If limiting skin exposure to heat is the primary goal of Canon's thermal management they should be able to easily distinguish between hand-held and tripod use via either the IBIS gyros or the camera level sensors, and use that information to establish the appropriate temperature thresholds. With some user warnings to handle the scenario of moving between tripod and hand-held use.

The last bullet point for today's R6 1.1.1 FW release is interesting: "The phenomenon in which the movie recording time available is not correctly displayed when the Date/Time/Zone is not set has been corrected." I wonder if the previous R6 firmware not only failed to displayed the available recording time when the clock wasn't set but also allowed it to bypass the thermal limits as a result.

I think it's a combination of point #3 (fatigue on the subject) and the slight recording-time improvements achieved with V1.1, which may have pacified some YouTuber's and R5 owners.

I've created a web-based javascript app that lets you quickly set the camera's clock to +1 day and -1 day to help automate visionrouge's workaround. It only works in browsers that allow you to disable CORS Policy Security. Unfortunately none of the mobile web browsers available support that option, so for now this is limited to home/office/studio use. Here is the link to the app: http://www.testcams.com/ccapi/datehack.html Full instructions including how to disable CORS Policy security are in the GitHub repository: https://github.com/horshack-dpreview/canondatehack.html

With FW V1.1 I think the gap between how hot Canon lets the camera run and how hot the camera should run (to avoid IC longevity issues) has narrowed. Canon's original thermal management firmware implementation was quite clumsy and too coarse for lots of scenarios. They addressed some of those scenarios with better ambient temp sensor integration into the algorithm. There's still room for improvement, which hopefully Canon will do eventually. Until then I think the new workaround is a great stopgap, including for situations where you absolutely have to get the shot and don't care about an occasional short-term temperature spike.

Thanks. It's 75C, a new high record for the R5 🥵

That's the overheat warning for stills operation. Page 284 of Canon R5 manual. Can you do me a favor and take a photo next time you see that stills warning? I'd like to check the camera's temperature for that threshold. It's embedded in the EXIF of stills images - you can send me a link to the out-of-camera image so I can extract it. Thanks!

Here's a Canomate script for automatically setting the camera's clock +1 day and then back: https://www.magiclantern.fm/forum/index.php?topic=24827.msg230542#msg230542

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.