Jump to content

horshack

Members
  • Posts

    151
  • Joined

  • Last visited

Everything posted by horshack

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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
  6. 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.
  7. 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!
  8. 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
  9. Can you please confirm the camera lets you record after the procedure for the full indicated time?
  10. 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.
  11. 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.
  12. 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
  13. 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
  14. 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.
  15. Any chance you could check if the battery-pull workaround for the thermal timer still works?
  16. 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.
  17. 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.
  18. 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
  19. 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.
  20. 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).
  21. FYI, I started a new dpreview thread about all the experiments here, which is a continuation of my original thread here.
  22. 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.
  23. 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.
  24. Thanks for the .CSV data. Here's your data plotted. The running elapsed time was calculated from the EXIF timestamps:
×
×
  • Create New...