How is your rear camera after MCU1 to MCU2 upgade (dark?)

[appleguru]

Add me to the list. Finally upgraded to MCU2; backup camera that used to work fine is now useless at night. Thought dashcam was broken because all of the rear videos from being parked in my driveway were just all black. Brought clips into VLC and boosted brightness / contrast and can just make out a few shapes, so there is something there.

To follow up on this: on MCU1, the backup camera feed is overlaid on the screen directly so that the (slow) Tegra doesn't need to decode anything.

The Model S/X use Maxim 9259/9260 SERDES to essentially send the "raw" CMOS signal from the camera sensor to your MCU. From there, an FPGA on MCU1 essentially drops the pixels directly into the image feed coming from the Tegra into the "correct" location on the screen .

I wonder if MCU2 is instead taking an encoded (i.e, lossilly compressed with something like H264) feed from the APE? (It definitely is for the non-backup camera feeds, as those physically only go to the APE). Perhaps they're using the "wrong" encoding settings (settings optimized for other cameras) and applying them to the MS feed?

A good test: Someone with AP1 (or no AP) that upgraded to MCU2... would be interesting to see if they have different (better) results with their backup camera image in low light...

[edit] just got confirmation that apparently the backup cam still works when directly connected to MCU bypassing APE, so that debunks that theory... really at a loss for a technical explanation for why the feed is so much darker on mcu2...[/edit]

 

[Battpower]

Someone with AP1 (or no AP) that upgraded to MCU2... would be interesting to see if they have different (better) results with their backup camera image in low light...

[edit] just got confirmation that apparently the backup cam still works when directly connected to MCU bypassing APE, so that debunks that theory... really at a loss for a technical explanation for why the feed is so much darker on mcu2...[/edit]

So if the cameras are not replaced as part of an MCU 1 to 2 upgrade then whatever is different is internal to the MCU.

If MCU 1 just produces a video overlay not processed by the Tegra then however that video feed is processed produces a very similar image to the other three video feeds used for Tesla cam / reversing cam.

I have read / been told by a variety of sources that a) dark MCU 2 image is due to image rendering and b) the video path for rear cam is different on MCU 2 (connects to different bus).

@AWDtsla pointed out 'black crushing' effect, which I don't think contradicts this:

Brought clips into VLC and boosted brightness / contrast and can just make out a few shapes,

I haven't tried messing with levels on a recorded clip, but I doubt that increasing brightness will result in same image as you get from MCU 1 reversing cam.

 

[KyleDay]

So if the cameras are not replaced as part of an MCU 1 to 2 upgrade then whatever is different is internal to the MCU.

If MCU 1 just produces a video overlay not processed by the Tegra then however that video feed is processed produces a very similar image to the other three video feeds used for Tesla cam / reversing cam.

I have read / been told by a variety of sources that a) dark MCU 2 image is due to image rendering and b) the video path for rear cam is different on MCU 2 (connects to different bus).

@AWDtsla pointed out 'black crushing' effect, which I don't think contradicts this:



I haven't tried messing with levels on a recorded clip, but I doubt that increasing brightness will result in same image as you get from MCU 1 reversing cam.

The cabling path for backup camera is exactly the same between mcu1 and mcu2. Mcu2 has a different FPGA chip that for whatever reason renders the backup camera feed differently on mcu2 (darker).

 

[Battpower]

Mcu2 has a different FPGA chip

I understood physical connection was the same. Does anyone know anything about that chip? Does it do the video processing then put a digital stream onto a data bus?

Begs the question if it is fixable if the processing is hard coded on that chip.

And.... any clues as to why the design would change for something that on the face of it performs worse?

Although you would think there must be software control of settings, but if it's that easy, why isn't it getting fixed?

 

[appleguru]

I understood physical connection was the same. Does anyone know anything about that chip? Does it do the video processing then put a digital stream onto a data bus?

Begs the question if it is fixable if the processing is hard coded on that chip.

And.... any clues as to why the design would change for something that on the face of it performs worse?

Although you would think there must be software control of settings, but if it's that easy, why isn't it getting fixed?

Doing a bit of digging into this...

On MCU1 the path from camera to the screen is (roughly; the CMOS sensor I think is different now but that doesn't really matter):

Inside the backup camera module: Omnivsion OV10630 CMOS sensor -> Maxim 9259 serializer, like this:

From the backup camera -> Rosenberger HSD/LEONI Dacar 535 cable.

For AP1 or pre-ap cars, that cable plugs directly into the blue HSD connector on the back of the MCU.

For AP2+ cars, that feed goes to the APE first, and then to the MCU. For AP HW2.5 and HW3 ("FSD computer"), there is a daughterboard that looks like this:

That board passes the serialized camera feed through to the MCU via the black connector, but also taps it off for the APE. It deserializes it with a Maxim 9260 and feeds it into a TI DS90UB913A-Q, which re-serializes it as FPD-Link III on the purple connector. A cable connects from the purple connector here to the purple connector on the APE board, where it gets handled the same as the backup camera feed on the Model 3/Y (deserialized via a DS90UB954-Q on the APE).

The MCU provides 12V to the backup camera via two pins on its blue HSD connector. The other two pins are for the serialized feed from the camera.

Internal to the MCU, for MCU1, it looks like this:

Blue HSD connector on the back of the MCU -> Maxim MAX9260 deserializer -> Altera (Now Intel) Cyclone IV EP4CE40 FPGA -> LVDS display connector -> LCD screen.

Internal to the MCU, for MCU2, it looks like this:

Blue HSD connector on the back of the MCU -> Maxim MAX9260 deserializer -> Toshiba TC358746AXBG

That Toshiba chip converts the backup camera sensor's raw parallel "DVP" signal into a MIPI CSI-2 signal, which I assume the Intel Atom SoC has an input for (but I haven't sorted out that connection yet).

It does *not* overlay the feed directly on the screen / into the LVDS feed like the MCU1 does. The screen on the MCU2 shares the same LVDS interface, but uses an Analogix ANX1122 eDP to LVDS chip to connect the Intel SoC.

 

[appleguru]

What (I think) we know: For all non-backup cameras, the APE decodes the FPD-Link III signal from the camera(s) and encodes them as H264 streams sent over ethernet to the MCU. We do not know if it also does this for the backup feed, but it certainly could for AP2+ vehicles. H264 is lossy, and can certainly result in a loss of color information and/or dynamic range.

The raw parallel backup camera feed is converted to MIPI CSI-2 and sent to the MCU for further processing. At this stage the data available is still "lossless" / raw, so there shouldn't be any loss of dynamic range or color information. But we don't (yet) know what happens in software from there, or if there is some other hardware in the chain before it gets ingested that I haven't found yet.

I still would love for someone that did an MCU2 upgrade with AP1 or pre-ap to share some video/images of the backup camera feed at night. Curious to see if it is "smooth" like the MCU1 or "stuttery" like the MCU2, and also curious to see if there is any difference in image brightness/nighttime fidelity.

 

[Nick70d]

My is AP1 with mcu2 , back up camera is dark, very dark compare to mcu1.

 

[appleguru]

What (I think) we know: For all non-backup cameras, the APE decodes the FPD-Link III signal from the camera(s) and encodes them as H264 streams sent over ethernet to the MCU. We do not know if it also does this for the backup feed, but it certainly could for AP2+ vehicles. H264 is lossy, and can certainly result in a loss of color information and/or dynamic range.

The raw parallel backup camera feed is converted to MIPI CSI-2 and sent to the MCU for further processing. At this stage the data available is still "lossless" / raw, so there shouldn't be any loss of dynamic range or color information. But we don't (yet) know what happens in software from there, or if there is some other hardware in the chain before it gets ingested that I haven't found yet.

I still would love for someone that did an MCU2 upgrade with AP1 or pre-ap to share some video/images of the backup camera feed at night. Curious to see if it is "smooth" like the MCU1 or "stuttery" like the MCU2, and also curious to see if there is any difference in image brightness/nighttime fidelity.

Ok, took a preliminary look at the software side of things to try and figure out what is going on here.

The Intel SoC indeed is capturing the CSI-2 feed directly. Tesla uses their drivers (intel/intel-camera-drivers) to make the feed available as a sysfs device at /sys/bus/media/devices/media0

From there, they use Video4Linux (v4l2) to configure a capture pipeline with media-ctl, capturing the pixel data as raw YUYV (YUV 4:2:2).

Presumably this is then displayed "directly" in their QtCar application when the user pulls up the backup camera. The repeater cams in the backup camera view are coming in via H264 UDP streams from the APE.

Interestingly, the video feed for the backup camera used with the dashcam/sentry feature *is* actually streamed in over Ethernet from the APE, (UDP/H264), and is muxed to an mp4 file using GStreamer.

So, presumably Tesla just needs to configure the exposure settings on their v4l2 video pipeline to completely fix this "too dark" issue...

 

[appleguru]

My is AP1 with mcu2 , back up camera is dark, very dark compare to mcu1.

Thanks for the confirmation. Looking at the software it does look like they're using the same code for displaying the backup camera for all model s/x regardless of AP type... so once they fix it it should be fixed for all. (Here's to hoping they actually fix it)

 

[random155]

Potential problem? Is there a way for them to deploy a fix for this that will not mess up MCU1 back up cameras with already good imaging? Could that be the hold up?

 

[beatle]

MCU1 and 2 use different firmware, so I don't see why they can't apply a fix to MCU2 and leave MCU1 alone.

 

[Snowstorm]

Ok, took a preliminary look at the software side of things to try and figure out what is going on here.

The Intel SoC indeed is capturing the CSI-2 feed directly. Tesla uses their drivers (intel/intel-camera-drivers) to make the feed available as a sysfs device at /sys/bus/media/devices/media0

From there, they use Video4Linux (v4l2) to configure a capture pipeline with media-ctl, capturing the pixel data as raw YUYV (YUV 4:2:2).

Presumably this is then displayed "directly" in their QtCar application when the user pulls up the backup camera. The repeater cams in the backup camera view are coming in via H264 UDP streams from the APE.

Interestingly, the video feed for the backup camera used with the dashcam/sentry feature *is* actually streamed in over Ethernet from the APE, (UDP/H264), and is muxed to an mp4 file using GStreamer.

So, presumably Tesla just needs to configure the exposure settings on their v4l2 video pipeline to completely fix this "too dark" issue...

Can you send this info over to Tesla for their consideration? A deal backup camera isn’t a show stopper but is disappointing knowing how good it used to be.

 

[appleguru]

Can you send this info over to Tesla for their consideration? A deal backup camera isn’t a show stopper but is disappointing knowing how good it used to be.

I’m sure their engineering team already knows everything I posted ;-)

I’m not a video4linux expert, but I’d love for anyone that is to chime in. It’s not immediately clear what controls the intel driver(s) support, though exposure/brightness does seem pretty basic. Is worth bearing in mind that these are all pretty low level systems though, designed and optimized to run in hardware. So if the hardware doesn’t support the adjustment, then we might be SOL without using a higher level library for image manipulation (which would in turn cost valuable CPU/GPU cycles and possibly introduce a slight undesirable video lag)

 

[Nick70d]

I will forward this to the feedback after upgrade email , hope they fix it.

 

[vthreee]

extremely dark! lol my street has no lights on it, im in a semi rural area, and its kinda annoying.. anyone got a fix?

 

[doctorwho]

I've had the problem intermittently since my MCU2 upgrade. It isn't consistent.

 

[Akikiki]

Well, I do not mean to disagree with anyone else opinion on the bright or darkness of their backup camera. But I am beginning to wonder if its not also perspective for - me mainly. I drove MCU1 cars for 8 years. Now its MCU2. I can't go back and compare it to my most recent former MCU1. I simply didn't pay much attention to how bright or dark it was.

Trying to create the same issue that people describe, I've sit in my garage at night with all the doors closed and all the lights off including the car's. Can't see anything from the rear camera. Hmm, maybe I am not supposed to? With parking lights on, with foot on brake, and with car in reverse (brakes on and brakes off) I can see - even in the garage.

If you go back and look (I think its this thread) I did a brief - easy test using the newest 2020/21 model rear camera on my '17 MCU2. Used it for those same "views". Nothing was different. I am of the opinion now, if there's an issue, the camera version doesn't make a difference. We have now confirmed from 2019 owners that their image is dark too. So MCU2 upgraded or factory MCU2 seems to be the same.

@appleguru has done some very thorough tracing of the camera issue and told us about it. I've made taken my best shot by trying a newer camera. I can put up "the problem" because the worse is when its completely dark no light anywhere and I simply don't drive without lights. So, with taillights, brake lights and/or backup lights, I can see well enough not to worry about this any more.

 

[Cybertrk]

I read on one of the reddit forums that a service center claimed 2021.4 or 2021.8 will fix this issue. I haven't received 2021.4 yet, can someone else who has confirm whether this issue got addressed?

 

[Akikiki]

@Cybertrk,

I got 2021.4.2 last night and installed it. Since you mentioned that you were told this fixed the issue, I thought I would take some pictures.
Bottom line, I don't think it mattered. Here's three.

This picture is with no lights. I got in the car, pulled up the camera didn't turn the headlights on. Garage is dark and doors are closed.

You be the judge. Did 4.2 help?

This picture is with my foot on the brake. Most lighting is coming from reflection of headlights from the white garage door.

Final picture. Foot off the brake. Car in Reverse (you can see the marker lines) and headlights still on.

 

[appleguru]

@Cybertrk,

I got 2021.4.2 last night and installed it. Since you mentioned that you were told this fixed the issue, I thought I would take some pictures.
Bottom line, I don't think it mattered. Here's three.

This picture is with no lights. I got in the car, pulled up the camera didn't turn the headlights on. Garage is dark and doors are closed.

You be the judge. Did 4.2 help?

View attachment 635610

This picture is with my foot on the brake. Most lighting is coming from reflection of headlights from the white garage door.

View attachment 635611

Final picture. Foot off the brake. Car in Reverse (you can see the marker lines) and headlights still on.

View attachment 635613

hard to say without before/after... but maybe. Looks like you can see the sensor artifacts in your first shot, which implies to me that you indeed can see way more than I can at the moment in low light.

Nobody expects the sensor to work with *no* light, but your photos provide some evidence that things are actually working better now. I’ll try and take some before / after shots in a semi controlled environment once I get the update staged.