Wireless front parking camera with monitor for front bumper protection

[zeron]

If the camera module is the OV10630, it can't be in the touchscreen. The chip has the actual CMOS sensor (where the light comes in) on top of it, so it will be whereever the lens is.

(Which does confuse me as to how the flip switch in this sensor is the problem? It seems to me that you are switching between the actual raw image output, so the signal of your front camera doesn't go through this chip anyway?)

 

[artsci]

If the camera module is the OV10630, it can't be in the touchscreen. The chip has the actual CMOS sensor (where the light comes in) on top of it, so it will be whereever the lens is.

(Which does confuse me as to how the flip switch in this sensor is the problem? It seems to me that you are switching between the actual raw image output, so the signal of your front camera doesn't go through this chip anyway?)

The OV10630 is an image sensor. And you're right and I misunderstood -- it sits behind the camera lens. It's .43 inches square, very small. So we may be in luck, so it now appears that mirroring the image is done at the camera level.

Here's what it looks like. As the front camera we're talking about on this thread is the Tesla rear camera placed in the front, it works exactly the same as the rear camera. W'ere in a sense fooling the touchscreen by switching the image from rear to front.

 

[zeron]

I see. But you are not switching the serial lines that control the OV10630, just the high-frequency video output (from what I can tell from the PCB). So the touchscreen CPU can't talk to your front camera and instruct it to flip the image.
Or am I misunderstanding and you want to use the capabilities of this chip to correct some transformation that the touchscreen CPU applies to the image? In that case you could just hook some microcontroller to the I2C bus of your front camera, if it's not connected anyway.

(Sorry, I haven't been following this thread completely and it's difficult to piece the important information together from the last couple of pages)

 

[artsci]

I see. But you are not switching the serial lines that control the OV10630, just the high-frequency video output (from what I can tell from the PCB). So the touchscreen CPU can't talk to your front camera and instruct it to flip the image.
Or am I misunderstanding and you want to use the capabilities of this chip to correct some transformation that the touchscreen CPU applies to the image? In that case you could just hook some microcontroller to the I2C bus of your front camera, if it's not connected anyway.

(Sorry, I haven't been following this thread completely and it's difficult to piece the important information together from the last couple of pages)

Technically I'm in over my head here but you're pointing to the concern I raised a few threads earlier. When you say "Artsci... Could you get better/bigger/more-detailed photos of the camera module so that we can identify any unstuffed connectors/pads that might be able to get us access to the SCCB bus?" you're talking about the guts of the camera itself, right? If so I'm going to take those photos on Sunday.

 

[zeron]

Technically I'm in over my head here but you're pointing to the concern I raised a few threads earlier. When you say "Artsci... Could you get better/bigger/more-detailed photos of the camera module so that we can identify any unstuffed connectors/pads that might be able to get us access to the SCCB bus?" you're talking about the guts of the camera itself, right? If so I'm going to take those photos on Sunday.

I didn't say that, but it is what I would recommend as the next logical step I just hope there will be something useful to see, it's a BGA chip and it will be somewhat crowded in the camera assembly.

 

[artsci]

I didn't say that, but it is what I would recommend as the next logical step I just hope there will be something useful to see, it's a BGA chip and it will be somewhat crowded in the camera assembly.

Sorry, that was Ken830's post. I trust that's what he meant. I'm going to do it in any case.

 

[gctseng]

Technically I'm in over my head here but you're pointing to the concern I raised a few threads earlier. When you say "Artsci... Could you get better/bigger/more-detailed photos of the camera module so that we can identify any unstuffed connectors/pads that might be able to get us access to the SCCB bus?" you're talking about the guts of the camera itself, right? If so I'm going to take those photos on Sunday.

Yes. He means look for other connectors in the camera module itself, which would mean you have to further disassemble the module. Preferably you can take high enough resolution macro pictures where any other chips may be identified (you can see the printed labels).

My instinct says that it is that it's probably unlikely there are other jacks because the company that manufactured the camera would have not have included anything more hardware-wise to keep the module as small as possible. Actually, what is that ribbon cable for? If there are more than 4 wires on it then it have additional I/O (input/output) that may be useful.

The BEST suggestion I have heard so far is to find a third party vendor of a camera module that outputs LVDS. It may or may not be as high of a resolution, but that may not matter.

 

[ken830]

Yes, I dug up the datasheet and suggested the better photos. I'm looking forward to them as they can tell us where we stand and what to do next.

Also, please note that LVDS is simply an electrical signaling standard, not a video or data protocol at all. Assuming the Omnivision IC video is driving the video signal, then we need to determine if it's set to output YUV, separated RAW, or combined RAW.

If we can get to the registers, the "flip" feature will allow us to consider mounting the camera upside-down (or right-side-up) giving us more mounting options.

One thing I noticed is that this particular product doesn't have the "overlay" feature, so it's not something we can use to easily create our own backup-guidance lines as I was hoping for the rear-view camera.

 

[artsci]

Yes, I dug up the datasheet and suggested the better photos. I'm looking forward to them as they can tell us where we stand and what to do next.

Also, please note that LVDS is simply an electrical signaling standard, not a video or data protocol at all. Assuming the Omnivision IC video is driving the video signal, then we need to determine if it's set to output YUV, separated RAW, or combined RAW.

If we can get to the registers, the "flip" feature will allow us to consider mounting the camera upside-down (or right-side-up) giving us more mounting options.

One thing I noticed is that this particular product doesn't have the "overlay" feature, so it's not something we can use to easily create our own backup-guidance lines as I was hoping for the rear-view camera.

How and where do we get to the registers?

 

[DSurber]

How and where do we get to the registers?

I think this device will provide access to the registers if we can get access to the pins. Aardvark I2C/SPI Host Adapter - USB to I2C and SPI interface It's a I2C to USB adapter. I believe the SCCB bus is a version of I2C and the site suggests that this device can be used to access cameras via SCCB. Or I could be all wrong. Based on my conversation with the tech support guy finding out exactly what commands to send to set the registers may be harder. He suggested that Omnivision would require an NDA to get access to their programming data.

 

[WhiteP85]

The registers are in the OV10630. It has connections on the chip that allow another microcontroller or CPU to communicate with it using its SCCB protocol over a common interface standard called I2C. On the camera board there is probably a serializer chip that takes the parallel video lines as well as the control signals and that converts them to a two-wire serial LVDS data stream. Inside the display electronics there is likely a deserializer chip that converts the serial signal back to parallel video and control signals. The CPU inside the display electronics is able to communicate with the video camera and set various things including the image sense. Here is a block diagram:

If the display CPU is setting the image left right sense dynamically then we would need to intercept that command and send a different message to the video camera. This would require us to add a microcontroller and another pair of deserializer/serializer chips to get access to the I2C signal. This is getting rather complicated and would require a fair bit of effort to prototype and test. I am afraid that is beyond my capabilities.

If the display CPU does not set the image sense dynamically and if it is a one time camera setting then it might be possible to access the I2C lines and reprogram the registers. That will also require a fair bit of prototyping.

The other remote possibility that I am looking at is a specialized chip that can flip video using LVDS signal. I may have found one but even it if it is available and does what I think, it is a long shot and I will update when I know more.

 

[Akikiki]

You guys are the experts on this video stuff and video system engineering. I for one am in awe of your posts on this subject.

It seems its getting more complex and I wonder if there's another direction this can go? DSurber and hans have already found info that tells us other equip manufacturers or system integrators appear to be using this camera. For instance, hans found a data sheet on e-consystems. Their online store has a mount for the lens for this camera. They also appear to accept product requests.

Can we persuade one of you to contact a manufacturer such as e-consystems and ask them if they would sell a version of this camera that provides the front facing image we need? This might be more effective than gaining access to the Tesla sold camera and trying to change it. I hope I don't sound foolish because I missed something in the previous posts.

 

[WhiteP85]

Not foolish at all. That might be best particularly if the console is not setting the camera on the fly. Hopefully that is not the case which would make the aftermarket solution a good one if it is possible to identify and mimic Tesla implementation.

Besides the technical issues, the gotcha is likely going to be the engineering fees that a manufacturer/integrator will likely charge to engineer a compatible board. If there was a big market- 1000s at least and preferably tens of thousands - they might be interested but the market for this is likely not very big.

Do not want to be half empty but my fall back is to live with the camera reversal if I have to and add the nifty electromagnetic sensors that Artsci added. The flipped camera will be fine for curbs which is what I really want it for and the parking sensor will be good for true parking.

 

[Akikiki]

@WhiteP85, I hear and understand what you are saying about the "gotcha". I agree. However, reviewing some of the description of this camera and the sensor, its used in a variety of applications other than automotive. In those applications its used for surveillance, and surveillance would most likely not need a reversed image. So it appears the more common use could be forward/front facing in the first place. Bottom line: Some of those equipment manufacturers that are using Omnivision's product may already have it set the way we need it. Maybe. Maybe? Worth the effort to scout around?

 

[WhiteP85]

Definitely worth a call. I will call the companies identified early next week. They may know or have easy ways to work out the OV10630 settings that Tesla used as well as add LVDS and may not want to charge much. We might get lucky particularly if one of them owns a tesla ;-)

 

[artsci]

Definitely worth a call. I will call the companies identified early next week. They may know or have easy ways to work out the OV10630 settings that Tesla used as well as add LVDS and may not want to charge much. We might get lucky particularly if one of them owns a tesla ;-)

I appreciate your knowledge and efforts WhiteP85. If if this is possible I'm sure you'll find a way.

Of course, if reversing the image gets two complicated and another camera doesn't work, the fallback is settling for an image that's reversed. I've been ok with that from the start and I'd be very happy if that's the solution circumstances require us to accept.

 

[ken830]

How and where do we get to the registers?

When we have access to the SCCB bus, we just access the TIMING_CTRL1D register at address 0x381D, and reset bits 7 and 6 to a value 0.

I'm hoping when you look closer at the PCB inside the camera module, you'll see something connecting to the SCL and SDA pins. At that point, we can find a way to drive I2C signals to access the internal registers. The first hurdle would be to figure out which pins are the right ones. The OV10630 is an 11mmx11mm CBGA package while the OV10633 is a CLGA package, so it's guaranteed to have different pinouts. Figuring out what's connected to what will give us a strong clue as to which are the correct pins.

 

[artsci]

Here are my first close-up photos of the camera PCB's (yes there are two). I shot these in rather poor light but I'll shoot more tomorrow am in better light so I can get more detail. Having taken it almost completely apart, I may have sacrificed my camera to the cause

If you have questions or would like me to shoot greater detail of particular components please post here so tomorrow's shoot can be as helpful as possible.

 

[WhiteP85]

@ken830. What are you thoughts here? Are you suggesting we solder I2C breakout leads and write to those registers with a microcontroller? It might be a bit tricky to do this on more than a few. If we go down the programming route I am thinking that the only practical way to do this would be to connect to the LVDS lines and add a deserializer to break out the I2C. One could then use a microcontroller to write to the I2C and reprogram the video board. This would be easily repeatable as one could use the FAKRA connectors and not have to worry about trying to solder onto small traces.

What I do not know is if the console writes to the video card when it boots up and reconfigures it. If this is the case then even if we changed the register settings then they may be overwritten again. That would complicate things and would require a microcontroller to monitor the control messages, detect the flip setting messages, and translate them as required.

None of that is easy and will require hardware prototyping and firmware development for the microcontroller. I have written a few PIC programs but I would not call myself a firmware developer. Do you have that skill?

As Akikiki suggested the easiest route is an off the shelf solution. That is worth pursuing but I am not optimistic.

Fortunately for those that are okay with a mirrored image I think we have a path to a solution that is still within our reach.

- - - Updated - - -

@artsci. Whew. Thanks for ripping open your camera. I hope it goes back together. What we really need are the letter or parts numbers of the black integrated circuits. It will tell us what we are working with. I think we have a good sense but it would be good to confirm it.

 

[vfx]

... However, reviewing some of the description of this camera and the sensor, its used in a variety of applications other than automotive. In those applications its used for surveillance, and surveillance would most likely not need a reversed image....

It's simply easier to build in programmable or jumper-able Flip and Flop image options no matter the use. A camera built for a specific use for a customer like a consumer camera would be the only exception (maybe). These industrial application cameras are mostly used for robotics and changing the image in use is common.