Canon EOS R5 / R6

[names_are_hard]

Oh, direct USB link to the cam from phone?  That's probably what I didn't understand.  In that case you could maybe use the phone as a hotspot, it's VPN'd to some network you control, and then the camera talks to phone via wifi through MITM proxy...  but this is getting ridiculously complicated.

[horshack]

Oh, direct USB link to the cam from phone?  That's probably what I didn't understand.  In that case you could maybe use the phone as a hotspot, it's VPN'd to some network you control, and then the camera talks to phone via wifi through MITM proxy...  but this is getting ridiculously complicated.

Canon's REST API only runs over its WiFi interface. Using the phone as a hotspot so that an external site could gain access to the camera (ie, one of the existing CORS proxies available online) would require the phone to port-forward unsolicited incoming requests to the camera, the same as a router NAT would. iPhone's don't have NAT functionality for their hotspot feature as far as I'm aware. And if it did it wouldn't require a VPN.

[names_are_hard]

Okay, different than I was imagining but there might still be a way: phone VPNs to some server, and phone bridges VPN network and wifi network.  Cam connects to phone wifi, server can transparently see all packets from the phone because the networks are bridged.  No NAT required.

The python local solution still seems easier.

[horshack]

Okay, different than I was imagining but there might still be a way: phone VPNs to some server, and phone bridges VPN network and wifi network.  Cam connects to phone wifi, server can transparently see all packets from the phone because the networks are bridged.  No NAT required.

The python local solution still seems easier.

iOS's hotspot implementation doesn't support that configuration. If the demand is there the easiest solution is a standalone smartphone app. Canon actually provides the source for a fully-functional proof-of-concept CCAPI Android app. I have no interest in developing for Android though. It's likely a small effort to modify the source. Anyone interested can download the Android app source here: https://developercommunity.usa.canon.com/canon?id=sdk_download. You'll need to register on the site to gain access to the download - registration is free.

[names_are_hard]

Ugh, Apple.  They never let you do anything fun.

[EOSHD]

A poster on EOSHD got 75C (EXIF temp) after 38 minutes of 4K 120fps using @visionrouge.net's workaround. I think that's probably pushing it. It was hot enough to cause the R5's stills temp warning icon to show. He said the CFE was extremely hot when removed.

It might be safer to use a fast SD card instead for long 8K and stress test 4K recordings. CFExpress cards do get very hot.

[visionrouge.net]

I'm posting here as reference y best guess why my hack is working.
It may be useful for a possible software side app at one point.

Canon do a very simple calculation.
When camera is running, a counter is setup. When the counter reach a certain level, you have a warning logo.
If you keep recording, the Logo will become a shut down. This raise a flag that I will call "Fake Overheating flag"

At each of these step Canon is writing the exact time this occurs. Let's call it the "overheat start time".
This is done in an EEPROM that is kept even if you remove the battery. The writing occurs when you shut down with the power button. This is the mistake right there.

There are only one way of getting the camera to work again is to wait extra time.
Canon do a simple calculation between "actual time" and "overheat start time". This way, even if the camera is off without battery, they can keep the time running with the help of the RTC.
It's a way of doing coding something very fast.

They also put a conditional test on "Fake Overheating flag" to make sure changing the time during the overheat mode will not change this calculation. My best guess is that they modify the "overheat start time" with the same value the camera time is shifted in this condition only. So each tentative to play this way is not working.

But I have the impression that the new"overheat start time" is written ONLY when the camera is power down. The new real time is written immediately.
So by dropping the battery, you are avoiding the "overheat start time" to be written and only the last one is in the memory.

When the power is restored, there is the calculation to see if you have been waiting enough. But based on the old "overheat start time", not the one shifted by the time modification. BOOOOM.

So the "Fake Overheating flag" is now remove and the camera can start.
Even better, The camera is writing this new "Fake Overheating flag" value into the EEprom. So you can turn off the right way and it will restart without any problem.

You can now shift the time back, there is no check for a possible "overheat start time" cause we are not supposed to be in overheating mode.

So whatever card you are using, whatever R5 or R6, whatever firmware... it's working.
That was my idea at first when I noticed that the battery drop do not save all parameters. An yes, it works so beautifully.

[horshack]

It might be safer to use a fast SD card instead for long 8K and stress test 4K recordings. CFExpress cards do get very hot.

Agreed, SD is likely the better choice for video modes that don't require CFE's speed. It would be nice to see a well-controlled temperature comparison test between SD and CFE for a long-run 8K video (comparing EXIF temps).

[yourboylloyd]

Someone posted to EOSHD forum that they didn't need a dummy battery or a door closed hack to reset the timer. I can't confirm the test of the regular battery pull on the EOS R6. No matter how many times I try, the overheating light never goes away (even when I take it out super quickly). I have to use a dummy battery or a "battery door close trick hack."

It works:
15 mins recording 8K ALL-I to CFExpress, overheating icon
Day +1, pulled battery
Inserted battery 30 secs later
No overheating icon
Turn off camera
Turn on camera, change date to current date, no overheating icon.

I can confirm this hack on EOS R6. Set date +1 day, then battery disconnect, turn camera back on, date -1 day does work. The timer has officially been reset and I am able to have clips saved on at the correct time.

I was actually at the beach filming 4K 60fps all day. Of course I got the overheating warning but this hack has so far been able to practically save my life haha!

[71m363nd3r]

Someone posted to EOSHD forum that they didn't need a dummy battery or a door closed hack to reset the timer. I can't confirm the test of the regular battery pull on the EOS R6. No matter how many times I try, the overheating light never goes away (even when I take it out super quickly). I have to use a dummy battery or a "battery door close trick hack."

I can confirm this hack on EOS R6. Set date +1 day, then battery disconnect, turn camera back on, date -1 day does work. The timer has officially been reset and I am able to have clips saved on at the correct time.

I was actually at the beach filming 4K 60fps all day. Of course I got the overheating warning but this hack has so far been able to practically save my life haha!

Firmware version?

[dellfonic]

Firmware version?

Version 1.0

[EOSHD]

I can confirm this as well, no need to defeat the battery door sensor!

Just change the date and pull the battery as normal.

You can put the date back to the correct one upon reinserting battery.

Updated instructions:

https://www.eoshd.com/news/magic-lantern-users-create-practical-canon-eos-r5-overheating-timer-workaround/

[horshack]

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

[yourboylloyd]

Firmware version?

R6 v1.1.0 . That's the only firmware version for the R6 currently

I can confirm this as well, no need to defeat the battery door sensor!

Just change the date and pull the battery as normal.

You can put the date back to the correct one upon reinserting battery.

No I was literally saying that DOESN'T work for me. I CAN'T get that working on the EOS R6 no matter how many times I try or how fast I try it. I NEED a battery door hack or a dummy battery in order for it to work. It doesn't work on a regular battery pull.

[yourboylloyd]

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

Thanks Horshack. You're awesome

[Chainstone]

R6 v1.1.0 . That's the only firmware version for the R6 currently

I have checked and my R6 has software version 1.0.0

I am not technically involved in this topic. But if I can do something helpful, I'd love to!

[Walter Schulz]

I have checked and my R6 has software version 1.0.0

I am not technically involved in this topic. But if I can do something helpful, I'd love to!

Your PC: Mac or Windows or Linux?

And would you mind testing timer hack following the steps provided by EOSHD?

[Chainstone]

Your PC: Mac or Windows or Linux?

I have access to both.  Mac and Windows.
Not directly to Linux at the moment, but probably could be changed  if necessary.

[Walter Schulz]

No I was literally saying that DOESN'T work for me.

No offence but would you mind recording a video following the steps shown in video provided by EOSHD?

[yourboylloyd]

None taken Walter. Will do sometime tonight.

[Lars Steenhoff]

https://www.lensrentals.com/blog/2020/09/taking-apart-the-canon-r5-mirrorless-camera/

Teardown of the R5

[yourboylloyd]

I have checked and my R6 has software version 1.0.0

I am not technically involved in this topic. But if I can do something helpful, I'd love to!

Yes you can help if you have firmware version 1.0.0. I'll give you some steps below on how to perform a ROM dump.

1. Get a SD or a SDHC card on standby. An SDXC card won't work.
2. On a PC, download and install this program
3. Also download this link. It is an card image that you will write to your SD card.
4. Open Win32DiskImager. Insert your SD card and browse to the file that you downloaded.
5. Make sure that you backed up everything on the card. Click 'WRITE' and wait until the status bar finishes.
6. Remove the SD card from your computer and insert it into SLOT 2 of the EOS R6. Turn the camera on. Push the 'PLAY' icon and then push 'SET'. Wait until the RED LED stops flashing.
7. Remove the SD card from your camera and put it back into your computer. You should now have the rom dump files (boot00.bin, gang100.bin, and gang200.bin).
8. DO NOT POST THE ROMS PUBICALLY. Send them to me in a private message.

[Walter Schulz]

https://www.lensrentals.com/blog/2020/09/taking-apart-the-canon-r5-mirrorless-camera/

Teardown of the R5

I may be wrong but is there a yellow tape covering at least a small part of the UART port and therefore denying external access without disassembly?

[Ant123]

This shouldn't be a big problem for people who have decided to remove the rubber.

[Walter Schulz]

I have a little bit of trouble with the concept: Let's make a hole in the back, add a rubber plug into it. So we can access the UART and don't have to remove the back. Now add a tape to the back to cover this UART.
Just to confuse the russians? Is it cold war time again? ;-)