Author Topic: Canon EOS R5 / R6 (Read 106364 times)

kitor · « **Reply #25 on:** May 04, 2020, 08:10:46 AM »

Quote from: yokashin on May 03, 2020, 12:04:44 PM

I think it's about sata, not ata ... The last standard of sata is sata3 (750 MB/s)

In case of R5 it's not even SATA (CFast), but Canon skipped directly to PCI Express / NVME (CFexpress).

Quote from: Aperture Science on May 03, 2020, 12:13:54 PM

Oh yeah lol, I miss understood. However there are many examples doing CFexpress to SATA on YouTube. Shouldn't be a big deal.

Are you sure? CFast to SATA do exists, as CFast uses SATA protocol. But CFexpress is NVME (PCI Express), that's why I wonder if there will be similar trick possible.
But even if possible - probably a little harder due to PCIe signalling requirements.

By the way - there are three types of CFexpress cards - A, B, C. They differ in physical dimensions and number of PCIe lines. I can't find any information which one will be supported here, but I bet for type A, which is physically similar to SD card.

Frayfray · « **Reply #26 on:** May 04, 2020, 09:22:02 AM »

Most likely type b since Canon is using it on c500ll

Luther · « **Reply #27 on:** May 04, 2020, 08:00:47 PM »

This camera can potentially kill C300 and C500.

Frayfray · « **Reply #28 on:** May 04, 2020, 08:25:34 PM »

i wish that was true but no canon just announced a new c300 mark3 https://www.canonrumors.com/canon-officially-announces-the-cinema-eos-c300-mark-iii/
they are to clever about the way they market cameras and cine cameras i have been dealing with them since 1980s they want you to buy all the models.. crippling features is canon's speciality

Aperture Science · « **Reply #29 on:** August 14, 2020, 07:27:58 AM »

Quote from: kitor on May 04, 2020, 08:10:46 AM

In case of R5 it's not even SATA (CFast), but Canon skipped directly to PCI Express / NVME (CFexpress).

Are you sure? CFast to SATA do exists, as CFast uses SATA protocol. But CFexpress is NVME (PCI Express), that's why I wonder if there will be similar trick possible.
But even if possible - probably a little harder due to PCIe signalling requirements.

By the way - there are three types of CFexpress cards - A, B, C. They differ in physical dimensions and number of PCIe lines. I can't find any information which one will be supported here, but I bet for type A, which is physically similar to SD card.

Of course SATA line do not contain the pcie lolololol, I was just saying there are things like that by change pcie into SATA

Filmmaking_Dude · « **Reply #30 on:** August 14, 2020, 11:13:26 PM »

There's some interesting discoveries on the R5 to suggest that the overheating is actually a software limitation imposed by Canon. I wonder what it would take to develop ML to remove them.

https://www.eoshd.com/news/eoshd-testing-finds-canon-eos-r5-overheating-to-be-fake-with-artificial-timers-deployed-to-lock-out-video-mode/

Walter Schulz · « **Reply #31 on:** August 14, 2020, 11:22:19 PM »

Yes, thought about creating a topic about this, too.
This could be a great opportunity to make paid ML development work. In my opinion it looks like there are some people willing to donate some amount to disable/bypass artificial software limitations for R5.
On the other hand: Terrible timing. Covid-19 and whole industries in a turmoil.
Really don't know if this could be a way to obtain sustainable cash-flow for upcoming ports.

Another one: I think there might be a niché market for a company modifying R5 with some kind of cooling system. Which could do great for Canon users looking for reliability but would be rather useless if they are unable to bypass said artificial software limitations.
But this is a hen-egg-issue.

Filmmaking_Dude · « **Reply #32 on:** August 15, 2020, 12:23:22 AM »

Tilta actually announced a cooling system for the R5 already, but the problem is that if the overheating is software based timers it will have no effect. https://tilta.com/2020/07/tiltaing-camera-cage-for-canon-r5/

EOSHD findings do correlate with many reviewers saying that the ambient temperature made no difference to the recording and cooldown times. That they were exactly the same in both hot and cool environments, and removing the battery and even adding ice etc had no effect. I think I even heard that it overheated in Antarctia or somewhere really cold, so the software based timers would actually explain this behavior.

names_are_hard · « **Reply #33 on:** August 15, 2020, 01:38:25 AM »

This could be a software limit and still not be artificial market separation, but instead a lazy way to pass certification. For consumer electronic devices, they're not allowed to get too hot to touch (defined as something like external temp of 45 or 50C I think, don't recall all the details).

If you want your camera to work in UAE and Alaska, the lazy way is measure it at highest load in the worst conditions, then put a timer in so it passes certification. That way you don't need fancy temperature sensors in the cam, or conditional code to check and perform different actions in different conditions. Timers are simple and reliable.

Ant123 · « **Reply #34 on:** August 15, 2020, 09:58:56 AM »

About EOSHD findings: who knows, the value of which temperature sensor is reported by Canon API? Maybe average?

If it's software limit it probably can be resetted by resetting all camera settings. However, timer values can be stored in battery-backed memory (RTC) and not affected by a reset.

kitor · « **Reply #35 on:** August 19, 2020, 07:02:19 PM »

There's already another post from EOSHD:
https://www.eoshd.com/news/canon-eos-r5-overheated-in-my-fridge-after-just-60-jpegs-4-c-ambient/

This is getting even more interesting.

Walter Schulz · « **Reply #36 on:** August 19, 2020, 07:18:35 PM »

As I said: IMO this would be *the* opportunity to make transition to pay-for-ML-feature-development work. Alas: Timing is just off the charts.

names_are_hard · « **Reply #37 on:** August 19, 2020, 07:18:57 PM »

Nice testing. That info makes it sound much more like something that can be patched in software, whatever their reason for putting it in.

yourboylloyd · « **Reply #38 on:** August 20, 2020, 07:31:30 PM »

Canon took 12 months to enable 24p into the EOS RP. They won't care to fix this in any kind of rush. They just don't care about us.

names_are_hard · « **Reply #39 on:** August 20, 2020, 07:47:00 PM »

I wasn't saying Canon would be the ones fixing it in software

ML is software.

Avenger 2.0 · « **Reply #40 on:** August 21, 2020, 08:20:49 AM »

Looks like if you take out the backup battery the overheating timer resets and you have full record time

Danne · « **Reply #41 on:** August 21, 2020, 08:42:59 AM »

Info from what source?

yokashin · « **Reply #42 on:** August 21, 2020, 09:02:55 AM »

Quote from: Danne on August 21, 2020, 08:42:59 AM

Info from what source?

https://www.eoshd.com/8k/removing-internal-battery-resets-eos-r5-overheat-timer-are-canons-pants-now-completely-down/

Walter Schulz · « **Reply #43 on:** August 21, 2020, 09:47:51 AM »

Begins to look like one of the sloppiest thermal management implementations ever.

12georgiadis · « **Reply #44 on:** August 21, 2020, 11:22:25 AM »

there is aa hardware button to reset the timer. Hope we can do something with the software ! And add a thermal pad to get seomething a bit more reliable. I would love so switch to Panasonic, s5 for exemple but they have DFD autofocus. Someone is working on a TOF module, but I think a software timer reset could be more simple =)

kitor · « **Reply #45 on:** August 21, 2020, 01:27:25 PM »

Oh wow. I really want to know how Canon people thought this will slip. With all the marketing that R5 received.

Thankfully this time I didn't preorder

You know, IBIS, wheel is back, but I'll stay with first R till the prices drop a bit.

yourboylloyd · « **Reply #46 on:** August 21, 2020, 01:51:31 PM »

This is actually exciting news! I was worried that the camera actually gets too hot. But believe this, I'm going to figure out a way to uncripple my R6 whenever it comes in. If I have to make a battery hack or if I have to learn C for the next couple of weeks I will do it!

I've never been more fired up in my life.

kitor · « **Reply #47 on:** August 21, 2020, 03:10:30 PM »

With hacking R and up, remember that they changed firmware encryption.
I was running stuff on mine, but had to enable bootflag via serial console first.

visionrouge.net · « **Reply #48 on:** August 23, 2020, 04:25:42 AM »

I'm wondering how hard it could be to run a very simple hack as magic lantern with only one simple task: Reset the overheating counter?
It seem they are writing it into eeprom as it kept from reset even without battery. Only removing the RTC coin cell reset it for now.

Walter Schulz · « **Reply #49 on:** August 23, 2020, 07:45:50 AM »

Little update at EOSHD with a little help from a1ex and Horshack:
https://www.eoshd.com/news/canon-eos-r5-so-called-overheat-timer-defeated-by-a-single-screw-in-battery-door/#more-24156

EDIT: Thoughts (better not be discussed at EOSHD for obvious reasons) on

Quote

The 14 minutes and 30 seconds of footage seemed to have vanished from the previous card and was not visible in playback mode when I reinserted that card. It is possible that the abrupt power cut had corrupted the clip.

1) It's logical file won't show up. Hasn't been closed properly by Canon.
Q: Shouldn't it be possible to manipulate the file by adding proper bits and bytes?
Yes, I know: This is not a proper procedure and there is a chance card gets corrupted if battery is pulled during write operations. Still interested if it might be possible. May be useful for critical footage rescue operations in the future.

2) That's one every R5 owner *can* try at home without the battery pull part ...
Does EOS R5 support FAT32 as file system for high-res recording? If so: This would generate chunks that have to be visible. Only last recording leg (up to 4 GB) should be invisible and lost (at least for the moment. See item above ...).
And yes, chance of card corruption exists, too!

News:

Author Topic: Canon EOS R5 / R6 (Read 106364 times)