Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

2nd run of camera switch that show a front image on the touch screen

This site may earn commission on affiliate links.
Forget all this nuanced stuff. I want to know when you hw guys are going to fix the mirror image problem so my brain does not turn into the obstacle I am seeing on the screen using a rear view camera pointed forward.:eek:

There’s no fix, but you learn to live with it and that’s not very hard. On the touch screen you can see low-hanging obstacles that can do damage and it doesn’t matter much that they’re on the left or right side — you don’t want to get too close in any case.
 
There’s no fix, but you learn to live with it and that’s not very hard. On the touch screen you can see low-hanging obstacles that can do damage and it doesn’t matter much that they’re on the left or right side — you don’t want to get too close in any case.

Unless we add a FPGA on the switch board... hum... If only I could retire already and play all days
 
I mean, the camera's image sensor chipset does support mirroring the image... so we just need to figure out how to actually send the right commands to do it (which... is not so trivial unfortunately).

On the cameras that use the OV10630 sensor (which certainly the original model s backup cameras did, though I'm not sure about the current ones), you "just" need to change the value in register 0x381D on the chip's image sensor from 11 to 00:

https://media.digikey.com/pdf/Data Sheets/OmniVision PDFs/OV10633,OV10133.pdf

How to actually do that? No clue. Maybe disassembling the camera module and connecting to the chipset directly via I2C would be the most feasible. Then again, the camera uses a MAX9259 chip to serialize the LVDS signal from the camera. The I2C from the sensor *may* be connected to the serializer (and therefore be accessible via GMSL over the normal camera cable

https://www.maximintegrated.com/en/app-notes/index.mvp/id/5064

Is a bit over my head to figure out though!

Camera.jpg
 
I mean, the camera's image sensor chipset does support mirroring the image... so we just need to figure out how to actually send the right commands to do it (which... is not so trivial unfortunately).

On the cameras that use the OV10630 sensor (which certainly the original model s backup cameras did, though I'm not sure about the current ones), you "just" need to change the value in register 0x381D on the chip's image sensor from 11 to 00:

https://media.digikey.com/pdf/Data Sheets/OmniVision PDFs/OV10633,OV10133.pdf

How to actually do that? No clue. Maybe disassembling the camera module and connecting to the chipset directly via I2C would be the most feasible. Then again, the camera uses a MAX9259 chip to serialize the LVDS signal from the camera. The I2C from the sensor *may* be connected to the serializer (and therefore be accessible via GMSL over the normal camera cable

https://www.maximintegrated.com/en/app-notes/index.mvp/id/5064

Is a bit over my head to figure out though!

View attachment 311504
@verygreen, any thoughts here?
 
@verygreen, any thoughts here?
That’s very difficult to do that bcos the sensor init is done by the on board MCU

You can re-code the MCU by adding the mirror register provided by @appleguru . The point is : you can never get the source code.

Or you can write the OV10630 init code by yourself but the IQ would not be the same from the original one bcos IQ fine-tuning is the most time consuming part for a CMOS sensor (especially it is a WDR sensor)

The only possible solution is to make a small PCB with a MCU connected with the I2C of the sensor, and change the mirror register value after the sensor init process
 
I mean, the camera's image sensor chipset does support mirroring the image... so we just need to figure out how to actually send the right commands to do it (which... is not so trivial unfortunately).

On the cameras that use the OV10630 sensor (which certainly the original model s backup cameras did, though I'm not sure about the current ones), you "just" need to change the value in register 0x381D on the chip's image sensor from 11 to 00:

https://media.digikey.com/pdf/Data Sheets/OmniVision PDFs/OV10633,OV10133.pdf

How to actually do that? No clue. Maybe disassembling the camera module and connecting to the chipset directly via I2C would be the most feasible. Then again, the camera uses a MAX9259 chip to serialize the LVDS signal from the camera. The I2C from the sensor *may* be connected to the serializer (and therefore be accessible via GMSL over the normal camera cable

https://www.maximintegrated.com/en/app-notes/index.mvp/id/5064

Is a bit over my head to figure out though!

View attachment 311504

There is a SO-8 soldering pad in the PCB, try to see if there is any connection of I2C to the CMOS sensor.

What I know is there is an I2C connection between MAX9259 and the MCU but you cannot change the sensor register value thru the LVDS protocol. This is why I have to do all the video processing on my backend DSP
 
  • Informative
Reactions: JohnnyG
There is a SO-8 soldering pad in the PCB, try to see if there is any connection of I2C to the CMOS sensor.

What I know is there is an I2C connection between MAX9259 and the MCU but you cannot change the sensor register value thru the LVDS protocol. This is why I have to do all the video processing on my backend DSP

Looking at the MAX9259 datasheet and pinout (https://datasheets.maximintegrated.com/en/ds/MAX9259-MAX9260.pdf), it looks like I2C is connected:
TeslaCameraI2C.jpg


Not sure if those go to exposed test points (or that unpopulated SO-8 space) on the board or not, but I can certainly scrape some solder mask off tomorrow and try to see if I can talk to the MCU via I2C... Maybe I'll get my RPi out tomorrow and try it out. The MCU data sheet says it should be at I2C address
0x30.

I actually got a MAX9260 and soldered it to a breakout board to try and build a receive side of the circuit to talk to the camera, but quickly got past my skill level (I'm not an EE/don't know that much about making more complex circuit designs):
Maxim9260.jpg


Sounds like you've solved this problem at least though :)

Are you sure we can't talk to the I2C on the MCU via the GMSL link? If I read the Maxim app note correctly, there should be a "control channel" accessible to talk to "remote" i2c devices over the GMSL link (as long as the device has a different i2c address than the maxim chip(s)).
 
Last edited:
Looking at the MAX9259 datasheet and pinout (https://datasheets.maximintegrated.com/en/ds/MAX9259-MAX9260.pdf), it looks like I2C is connected:
View attachment 311558

Not sure if those go to exposed test points (or that unpopulated SO-8 space) on the board or not, but I can certainly scrape some solder mask off tomorrow and try to see if I can talk to the MCU via I2C... Maybe I'll get my RPi out tomorrow and try it out. The MCU data sheet says it should be at I2C address
0x30.

I actually got a MAX9260 and soldered it to a breakout board to try and build a receive side of the circuit to talk to the camera, but quickly got past my skill level (I'm not an EE/don't know that much about making more complex circuit designs):
View attachment 311559

Sounds like you've solved this problem at least though :)

Are you sure we can't talk to the I2C on the MCU via the GMSL link? If I read the Maxim app note correctly, there should be a "control channel" accessible to talk to "remote" i2c devices over the GMSL link (as long as the device has a different i2c address than the maxim chip(s)).
You can talk to the MCU (on camera board) thru the MAX serdes (they have control pin connected to the MCU) , however , the MCU is already programmed and it is likely not feasible to send command to the MCU to change the sensor value ( thru I2C? IRQ?)
I would suggest to have an extra MCU directly connected to the sensor and send I2C register value to change the mirror function

As long as you have the MAX9260 board , You can try all the possible solutions

Btw , remember to get the correct Bank in order to retrieve the mirror register. And yes, the I2C ID of OV10630 is 0x30
 
  • Like
Reactions: JohnnyG
You can talk to the MCU (on camera board) thru the MAX serdes (they have control pin connected to the MCU) , however , the MCU is already programmed and it is likely not feasible to send command to the MCU to change the sensor value ( thru I2C? IRQ?)
I would suggest to have an extra MCU directly connected to the sensor and send I2C register value to change the mirror function

As long as you have the MAX9260 board , You can try all the possible solutions

Btw , remember to get the correct Bank in order to retrieve the mirror register. And yes, the I2C ID of OV10630 is 0x30

I might need your help getting my MAX9260 up and running (I don't have the dev kit, just the raw IC at the moment). Are you saying that the
0x381D register is part of the chip's OTP memory and can only be programmed once? The data sheet isn't really clear on this (and I've never really worked with cameras before), so I'm not sure what to expect here... though It would seem like mirror would be a useful "user configurable" option?
 
  • Like
Reactions: JohnnyG
I might need your help getting my MAX9260 up and running (I don't have the dev kit, just the raw IC at the moment). Are you saying that the
0x381D register is part of the chip's OTP memory and can only be programmed once? The data sheet isn't really clear on this (and I've never really worked with cameras before), so I'm not sure what to expect here... though It would seem like mirror would be a useful "user configurable" option?
0x381D is the register address in OV10630 and there is no memory in the CMOS sensor itself. The sensor init must be done my any host processor thru I2C connection. This is why there is a MCU on the camera board

It’s so trouble and time consuming to make your MAX9260 board working as the mainboad has to be re-designed o as to make your MAX9260 board (we call it daughter board) working.

Currently all of my boards are all integrated with MAX9260, MAX9259, DSP, ASIC and I don’t think there is any testing spot to connect with your MAX9260 board. So the only solution is to re-design
 
  • Like
Reactions: JohnnyG
0x381D is the register address in OV10630 and there is no memory in the CMOS sensor itself. The sensor init must be done my any host processor thru I2C connection. This is why there is a MCU on the camera board

It’s so trouble and time consuming to make your MAX9260 board working as the mainboad has to be re-designed o as to make your MAX9260 board (we call it daughter board) working.

Currently all of my boards are all integrated with MAX9260, MAX9259, DSP, ASIC and I don’t think there is any testing spot to connect with your MAX9260 board. So the only solution is to re-design

Ah, I finally understand... You're saying there is another micro controller on the board that actually does the CMOS configuration at power up... and that unless we can change this micro's config, or figure out how to tell it to pass the right commands through to the CMOS, the easiest way is to add a second micro to the I2C (or whatever) bus is connected to the CMOS directly, and send the configuration command after power up/initial config.

Looking at the board, I see two other ICs... One is a PIC16F1829: http://ww1.microchip.com/downloads/en/DeviceDoc/41440B.pdf

The other is an unknown chip with 10 leads and an "AVV N BW" marking.

Based on the micro's data sheet, I have marked the possible I2C connections. I will test with a multimeter to see if I can figure out which one goes to the Maxim serializer, and then one of the other 2 must go to the CMOS.

I2CCameraMCU.jpg


AVV-N-BW.jpg


In related news, @artsci and team said we should be good to switch over the HSD connectors from the C coded blue ones to the universal Z coded ones. I am working with a few connector vendors now to get quotes and lead times.

I have an email into my local SC to get one of the black "A type" cables that I would need to test a "post" APE install on my AP2 model s as soon as it gets in and I mod my proto switch to accept it.

And a reminder: don't forget to PM me and get your deposits in for the CAN bus kit if you're interested in one. So far I have received 7 deposits, with interest expressed from another 6 of you. I have started ordering parts to build them so we can (hopefully) get them to you by the time the camera switches are ready. So if you want one, don't delay!

FYI, the long lead time items are the PCB, which @Kalud is currently working on the design/layout for, and the OBD connectors, which I have just ordered a pile of.

The most expensive component in the kit, the $99 comma panda, are in stock as of current writing. If we get enough preorders I might be able to organize a small bulk discount.
 
FYI, the long lead time items are the PCB, which @Kalud is currently working on the design/layout for,

If you can get GERBER files exported, I ordered a bunch of custom PCBs from Seeed Fusion (in China) for what ended up being about $1/board. Took about two weeks to get printed and delivered. Really worked great and the boards are perfect.
 
If you can get GERBER files exported, I ordered a bunch of custom PCBs from Seeed Fusion (in China) for what ended up being about $1/board. Took about two weeks to get printed and delivered. Really worked great and the boards are perfect.

Thanks, good tip. I was eyeing EasyEDA / JLCPCB too.. their "first order" promotion is very tempting. They're also in China; they use a group buy model, which makes them very cost effective, and lead times are supposed to be pretty good. I haven't tried them (yet) though!
 
  • Like
Reactions: JohnnyG
Appleguru tells me the CANBUS cable for the reverse signal is a go. There should be a pre-made kit and a DIY option. He tells me the pre-made kit will be about $200 and the DIY less. Final costs are not yet determined, as he’s thinking about ways to lower them...

And a reminder: don't forget to PM me and get your deposits in for the CAN bus kit if you're interested in one. So far I have received 7 deposits, with interest expressed from another 6 of you. I have started ordering parts to build them so we can (hopefully) get them to you by the time the camera switches are ready. So if you want one, don't delay!

@appleguru , can you share what the DIY solution would be, and approximate cost? Thanks!!
 
@appleguru , can you share what the DIY solution would be, and approximate cost? Thanks!!

As we get closer to finalizing the circuit design for the CAN bus "giraffe", I'm not sure I'd recommend the DIY approach, as the costs would end up about the same... But you're more than welcome to of course: DIY would be to buy your own panda ($99) from comma.ai, modify/flash the firmware with the required changes to support outputting the reverse signal via GMLAN (you can clone my GitHub repo: appleguru/panda ), and then build your own wiring harness to tap the Chassis CAN bus either from the OBD port on pins 1 and 9 or on the TDC connector under the main display. You would also need to make a small circuit for the GMLAN output on the panda to switch +12V for the camera switch input (natively, the port outputs ~4V, which isn't quite enough to reliably switch the switch).

For now I am only offering one version of the kit, which will include the panda and the circuit board to connect it to the OBD port. If you have your own panda already and just want the PCBA though, let me know.
 
  • Informative
Reactions: JohnnyG
As we get closer to finalizing the circuit design for the CAN bus "giraffe", I'm not sure I'd recommend the DIY approach, as the costs would end up about the same... But you're more than welcome to of course: DIY would be to buy your own panda ($99) from comma.ai, modify/flash the firmware with the required changes to support outputting the reverse signal via GMLAN (you can clone my GitHub repo: appleguru/panda ), and then build your own wiring harness to tap the Chassis CAN bus either from the OBD port on pins 1 and 9 or on the TDC connector under the main display. You would also need to make a small circuit for the GMLAN output on the panda to switch +12V for the camera switch input (natively, the port outputs ~4V, which isn't quite enough to reliably switch the switch).

For now I am only offering one version of the kit, which will include the panda and the circuit board to connect it to the OBD port. If you have your own panda already and just want the PCBA though, let me know.
Thanks for the quick reply!
With the fact that you are making bulk orders, I think the smart (less expensive) option would be to get your kit. :D
 
Ah, I finally understand... You're saying there is another micro controller on the board that actually does the CMOS configuration at power up... and that unless we can change this micro's config, or figure out how to tell it to pass the right commands through to the CMOS, the easiest way is to add a second micro to the I2C (or whatever) bus is connected to the CMOS directly, and send the configuration command after power up/initial config.

Looking at the board, I see two other ICs... One is a PIC16F1829: http://ww1.microchip.com/downloads/en/DeviceDoc/41440B.pdf

The other is an unknown chip with 10 leads and an "AVV N BW" marking.

Based on the micro's data sheet, I have marked the possible I2C connections. I will test with a multimeter to see if I can figure out which one goes to the Maxim serializer, and then one of the other 2 must go to the CMOS.

View attachment 311967

View attachment 311968

In related news, @artsci and team said we should be good to switch over the HSD connectors from the C coded blue ones to the universal Z coded ones. I am working with a few connector vendors now to get quotes and lead times.

I have an email into my local SC to get one of the black "A type" cables that I would need to test a "post" APE install on my AP2 model s as soon as it gets in and I mod my proto switch to accept it.

And a reminder: don't forget to PM me and get your deposits in for the CAN bus kit if you're interested in one. So far I have received 7 deposits, with interest expressed from another 6 of you. I have started ordering parts to build them so we can (hopefully) get them to you by the time the camera switches are ready. So if you want one, don't delay!

FYI, the long lead time items are the PCB, which @Kalud is currently working on the design/layout for, and the OBD connectors, which I have just ordered a pile of.

The most expensive component in the kit, the $99 comma panda, are in stock as of current writing. If we get enough preorders I might be able to organize a small bulk discount.

The other IC you mentioned from the picture is the power management IC. Add external MCU for changing the register value of OV10630 is feasible , but , pls be reminded that you need to wait the sensor init process finished by the on board MCU first. I didn’t go in-depth about this bcos I don’t use Tesla camera as Frontview camera
 
We went over the top on deposits this morning, so I authorized production immediately. The manufacturer is stating a 12-16 week production time, so it looks like we’ll be shipping sometime in September. We’ll be producing 75 units, as I suspect there will be more demand along the way. Once I know final production costs I’ll email all of those with deposits the final balance due.

Appleguru tells me the CANBUS cable for the reverse signal is a go. There should be a pre-made kit and a DIY option. He tells me the pre-made kit will be about $200 and the DIY less. Final costs are not yet determined, as he’s thinking about ways to lower them. Of course, there’s also the option of running a line to the taillights themselves to tap the reverse signal. If you’re a DIY, that costs nothing except your time.

I just got my Model S and am also interested in this camera kit. How can I submit a deposit? Thank you in advance