UPDATED.
On Friday, I received a message from the A1ex, developer at Magic Lantern to point me to an interesting theory suggested by one of their contributors, which he believed could defeat the so-called overheat timer on the Canon EOS R5. Initially I was skeptical as to whether it would work, especially because my first real-world test using the method did not seem to reset the timer.
But then, a break-through.
Magic Lantern just became Magic Screw!
Credit and sources
The original source for this battery door sensor theory is a contributor to Magic Lantern who goes by the name of Horshack. He tells me: “I developed the DotTune method (https://www.youtube.com/watch?v=7zE50jCUPhM) and wrote an early proof-of-concept ML implementation but full-credit to a1ex for writing the actual production ML implementation [of the DotTune module]. My [other]contribution to ML was resolving the bootflag hang issue on the 5DM3 way back when (https://www.magiclantern.fm/forum/index.php?topic=11017.0)”
The method and technique for getting it to work (below) is my own independent trial and error discovery, and I’ll outline this below. Defeating the 8K / 4K HQ timer stored in internal battery backed RAM has many variables and we’ve still yet to explore and test them all.
Disclaimer and reliability
As of now, I do NOT (yet….) recommend this as a practical, filmmaker-safe work-around. The camera’s behaviour during multiple successions of long 8K recordings has yet to be determined and temperatures will need to be monitored carefully. There’s much testing ahead.
If you are going to try this on your own EOS R5, I recommend proceeding at your own risk.
Timer defeated
As I spoke about in previous posts, my theory is that a timer locks you out of 8K and 4K HQ on the EOS R5, allegedly to segment it from the Cinema EOS professional camcorder line and that an ‘overheating problem’ does not really exist at 15 minutes in 8K mode and especially not for 1 hour during a recovery period which sees the record-time limitations lifted very slowly.
To test this theory:
According to Horshack and Magic Lantern, most digital cameras have two types of internal memory:
- RAM, which is volatile and fast memory. Volatile means it loses anything stored in it when power is removed.
- NVRAM, which stands for non-volatile RAM. This can store data permanently when the main camera battery is removed. It can take a number of forms – it could be battery backed RAM (a button-cell battery on the motherboard keeps it ticking over when the main battery is flat or swapped out) or it can take the form of an EEPROM which should not be written to regularly, because of a limited read/write lifespan.
For the EOS R5 to have a “cripple clock” timer to lock you out of certain video modes like 8K and 4K HQ after a certain amount of up-time has elapsed, the camera must remember the timing info even if the main battery is pulled out or the camera turned off and back on again.
Says Horshack, cameras typically don’t update the information in NVRAM until shut-down in an orderly fashion. So if you adjust a setting like aperture or ISO, the EOS R5 will not immediately remember these settings by putting them in NVRAM or internal battery backed RAM every time they change…. only to normal working RAM. These settings are lost if they are not written to NVRAM upon an orderly shut down.
So what about a disorderly shut down?
The battery door on the EOS R5 has a hidden switch which tells the camera in a controlled way, that the door is opened and thus to power down cleanly. This gives the camera prior warning that the battery may be about to be pulled.
The switch is also to prevent a user from unexpectedly removing power without it having the chance to cleanly finish saving a video clip or still frame it is recording to the card, to prevent data corruption, or memorising the current state it is in, such as the most recent shooting settings (ISO, aperture, etc.) and prior recording times.
But by lodging a small screw in the hidden switch, the camera now believes the battery door to be closed even when it’s not. Indeed you can remove the door very easily, for attaching a battery grip or a dummy battery with AC power lead.
I removed the door. Now, if you pull the battery out, with the door sensor switch lodged down by the screw, the camera will lose power immediately without having the chance to save any data in NVRAM.
As a result, the camera does not remember for how long it recorded in 8K or 4K HQ before the battery pull.
So if the limitation indeed works on a timer, we should jump back up to the full 15 minutes of 8K immediately after removing the battery and reinserting it, even if the camera has been recording 14 minutes of 8K just beforehand – and that is exactly what happened in my test.
It is a bit like having a conscious robot designed to work properly when powered on, but if incorrectly powered off or mistreated it forgets everything from short term memory and wakes up as if recent events didn’t happen.
In my first test which didn’t work – I started the camera from cold and it showed just 15 minutes of time remaining in 8K mode. I then recorded 8K for 10 minutes before stopping the clip and viewing the time remaining on the EOS R5’s screen. Sure enough this had reduced to a measly 5 minutes on the ‘overheating’ countdown clock. I pulled the battery with the screw in the latch and the door off – but upon reinserting the battery, the cripple clock still showed 5 minutes. Test failed.
So I went out for an ice cream.
However, returning to the camera later in the weekend, I decided to try again. This time, I pulled the battery at 14 minutes 30 seconds without first stopping the recording in 8K. After pulling the battery, I also then swapped the memory card. This time, when I reinserted the battery, the 8K remaining time had shot back up to the full 15 minutes again.
This completely reset the timer. Without doing this – the camera would have been on the verge of showing 0 minutes of 8K remaining and an overheating warning sign. It appears that if you stop the recording first, the camera snitches on you and stores metadata in NVRAM and possibly also on the memory card that you have been recording in 8K for XX minutes.
Unfortunately as this is not a clean shut down, the 14 minutes and 30 seconds of footage had vanished from the previous card when I reinserted it and went into playback mode. So it had corrupted the clip, or at least not finished writing the file headers or metadata. This is just one of the reasons why this technique is not yet a practical workaround for users or professionals.
I’ll test today to see if the clip is actually readable on a computer, for example by transcoding it in EditReady to ProRes, and how much of the recording time gets corrupted or truncated.
Timer defeated but further testing needed to make it practical
The technique and the way it is used, is everything. We don’t yet know whether it will turn into a viable workaround.
And nor, should users be expected to do these workarounds on a $4000 professional full frame camera.
But it proves something very important.
There is a timer.
It is the clearest indication yet that the so-called “overheating problem” operates primarily on a firmware clock instead of any real temperature measurement.
And Canon must now answer to their customers. I will await their reply from Japan with a full explanation of this camera’s behaviour.
I have also reached out to multiple people at Canon UK and Canon USA.
We deserve an explanation.
Further testing coming up
There is much further trial and error ahead to explore this fully and see what else can be discovered.
It could be that the camera writes to NVRAM at other times, or even gauging the length of previously recorded clips on the SD card as well. The little snitch that it is.
Clearly some menu operations also cause the timer to be remembered, and it’s even possible Canon forgot to stop the timer going down in the menus or in stills mode without a single frame of video recorded.
It is possible that the card swap has a lot to do with it, and not just the abrupt power cut itself.
So thank you Horshack and thank you to a1ex at Magic Lantern for letting me know about Horshack’s experiments. All credit goes to Horshack and A1ex for this discovery – I am only here testing it and trying to turn it into a viable workaround that works. As well as prove the existence of the timer, which my tests along with CDA-TEK’s app have hinted at all along.
I will make a proof of concept video and post this later, to show it working, after digging deeper into the various outcomes and techniques.
Here is Horshack’s original explanation (via Magic Lantern’s a1ex in a DM):
