horshack

Thanks, I appreciate that. I have a running thread on Fred Miranda soliciting submissions and so far the response has been good. To encourage participation I've been buying the Arduino boards on Amazon and having them shipped directly to members who have cameras I would like tested. Going forward my hope with the crowdsourcing is that the group interested in these kinds of measurements would be enthusiastic about having their own reliable method for measuring readout speeds whenever they need, so that the small investment in the Arduino board wouldn't be an impediment. Time will tell if that turns out to be true.

Thanks, I appreciate that. I have a running thread on Fred Miranda soliciting submissions and so far the response has been good. To encourage participation I've been buying the Arduino boards on Amazon and having them shipped directly to members who have cameras I would like tested. Going forward my hope with the crowdsourcing is that the group interested in these kinds of measurements would be enthusiastic about having their own reliable method for measuring readout speeds whenever they need, so that the small investment in the Arduino board wouldn't be an impediment. Time will tell if that turns out to be true.

I agree, the sensor speed is what it is. However there is a moderate amount of variability in the readout speeds posted online, owing to differences in methodology. I'm looking to avoid that variability in this repository of measurements.

FYI, I've started a GitHub project to create a repository for sensor readout speeds of all cameras, for both stills and video, using a standardized measurement method that involves a $17 USD Arduino board.
The project's homepage is:
https://github.com/horshack-dpreview/RollingShutter
The project has a link to the current database, a primer about rolling shutter artifacts, source code, and collection details for those who would like to contribute their camera's images to be measured and added to the database.
Direct link to current results:
https://horshack-dpreview.github.io/RollingShutter/
 

Nice! I have my own database of rolling shutter values that I can get to you. The one column I would add to the table is the ratio of the rolling shutter to the frame rate. That value normalizes the skew per frame.

FYI, I've started a GitHub project to create a repository for sensor readout speeds of all cameras, for both stills and video, using a standardized measurement method that involves a $17 USD Arduino board.
The project's homepage is:
https://github.com/horshack-dpreview/RollingShutter
The project has a link to the current database, a primer about rolling shutter artifacts, source code, and collection details for those who would like to contribute their camera's images to be measured and added to the database.
Direct link to current results:
https://horshack-dpreview.github.io/RollingShutter/
 

FYI, I've started a GitHub project to create a repository for sensor readout speeds of all cameras, for both stills and video, using a standardized measurement method that involves a $17 USD Arduino board.
The project's homepage is:
https://github.com/horshack-dpreview/RollingShutter
The project has a link to the current database, a primer about rolling shutter artifacts, source code, and collection details for those who would like to contribute their camera's images to be measured and added to the database.
Direct link to current results:
https://horshack-dpreview.github.io/RollingShutter/
 

Follow-up. After my earlier post I've determined the issue appears specific to the AAC audio codec, which is the codec utilized for all the lower bit-rate MP4 mode files. If I switch to LPCM the issue doesn't occur - LPCM is utilized for all of the higher bit-rate MOV mode files. Here's a new video comparing the two audio codecs:
 

Follow-up. After my earlier post I've determined the issue appears specific to the AAC audio codec, which is the codec utilized for all the lower bit-rate MP4 mode files. If I switch to LPCM the issue doesn't occur - LPCM is utilized for all of the higher bit-rate MOV mode files. Here's a new video comparing the two audio codecs:
 

Good call. Bought an 18Gbps cable and the noise is gone. Here's a side by side:
 

Good call. Bought an 18Gbps cable and the noise is gone. Here's a side by side:
 

That will probably be the HDMI cable. I had the same issue. Buy something that's rated for 8K, I use this one without problem:
https://www.amazon.co.uk/gp/product/B0B76YBHPP/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&th=1
 

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.

Any chance this cfexpress to nvme ssd could work? https://www.ebay.com/itm/184438464836

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. 

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. 

Just confirmed that the Date change "hack" is still live with New firmware on R5. 

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

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

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

UPDATE:
I have tried the date/time trick without defeating the battery door sensor. Just pull the battery as normal and it works.
https://www.eoshd.com/news/magic-lantern-users-create-practical-canon-eos-r5-overheating-timer-workaround/

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 🥵

This is Pictogram. I took a foto with my R5 close to that moment: 
Not pretty - but it should have the precious temperature reading you're looking for 🙂
Next time I will take that picture once I see the symbol again. It comes in red and also in white. And it disapeared seconds after I took out the CFExpress card.

Second run, one minute after shutdown due to overheating. Runing for seven minutes now. No overheating sign. Camera very warm on the back. So obviously the camera doesn't check any kind of temperature inside the camera. If it did, it would have had to shut down by now.