Wireless front parking camera with monitor for front bumper protection

[artsci]

Thanks WhiteP85 for this incredible post. The corrected (with the right pin-outs) Fakra cables from China will be delivered by DHS on Monday. As soon as I can find the time I'll check how the camera connections and relay work with both cameras connected to my crude PCB. If possible, I'll shoot some video of the touchscreen image when the switch is made from rear to front camera.

 

[WhiteP85]

A few weeks ago I tried some front-surface mirrors and some prisms I had around, not really a workable solution as you showed and i'm sorry I did not post to save you the effort.

Another idea for switching. The CAN bus has the backup light. You could rig the front camera to be on the screen all the time and only switch to back facing camera when a triggered switch is thrown. This saves the whole Homelink two button push suggestion I had earlier.

thanks vfx. The current design approach is to use a microcontroller to switch the relays that is signalled by 4 channel RF decoder with an additional two wired inputs. The schematic is in the posted link. I chose an 18 series pic because I happen to have a swordfish basic compiler that I can use. I am not proficient in C. This should keep the design flexible and allow for various TBD switching modes. The decoder that I bought comes with two remote push button key rings that actually run off a 12 V battery. One of the key rings could optionally be hard wired to the reverse lights with one of the buttons on. When the microcontroller detects that particular decoder output it can switch to rear. Still got to work out where to get access to the reverse light power.

 

[brianman]

Thanks for your efforts.

Some questions:
1. Any thoughts on the option to record (one or both) camera feeds to some device?
2. What's your best guess at total cost (parts and installation) with existing nose cone?
3. What's your best guess at total cost (parts and installation) using a replacement nose cone purchased from Tesla? And (a) will a production nosecone "fit" on Sig or (b) do you know if Sig nosecones are still purchasable from Tesla?

Neat stuff, guys.

 

[artsci]

Thanks for your efforts.

Some questions:
1. Any thoughts on the option to record (one or both) camera feeds to some device?
2. What's your best guess at total cost (parts and installation) with existing nose cone?
3. What's your best guess at total cost (parts and installation) using a replacement nose cone purchased from Tesla? And (a) will a production nosecone "fit" on Sig or (b) do you know if Sig nosecones are still purchasable from Tesla?

Neat stuff, guys.

1. That's a goal down the road.
2. Tough to know now so this is a guess: $150 - $250 without the Tesla camera for DYI types. The camera' s about $360.
3. Nose cones are about $600 I think. Don't know about the sig cones but they are different.

 

[araxara]

Open Questions:

1. Is there a third-party supplier of a compatible LVDS output camera module?
2. Is there an easy way to mirror the rear camera image on the existing camera?
3. Is the block diagram shown correct? Anything missing?
   • Assuming that the control register shown controls the mirror
   • Is the I2C/SCCB slave interface set locally using the PIC or remotely using the console? i.e. is the SCCB included and used in the serializer as shown by some serializer datasheets
   • Is this set once and saved in memory or reset every time the camera is powered on?
4. What serializer chip is used?
5. What does the PIC do? SCCB control? Supply SVCLK and if so what frequency?
6. What are the critical register settings? i.e. format YUV, RAW settings etc?
7. We would love a schematic and all the register settings but that might be too much to ask.

Having worked on several OmiVision sensors in the past few years, I can give you some general information. The sensors I worked with were designed primary for digital camera applications and had MJPEG support. Different sensors had different SCCB command values, although the concept is the same for all their camera chips. The SVCLK is generally provided by a stable clock source, usually a crystal controlled oscillator, which may be shared with the PIC. The register settings are not saved on the camera chip and must be set each time the system is powered on. Since the PIC is the only processor connected to the sensor, there is probably initialization code that sets all the registers. The values are generally stored in a table and sent on power on, with specialized values being set at run time.

If you were to sign a non-disclosure agreement, you would get sample code for initializing the sensor. Sometimes, you can find open source software for Linux that has a driver for a particular sensor and look at the code there for the initialization sequence. There are camera boards for the OV10633 sensor which may include drivers (see LI-CAM-OV10633). An easy way to get the register settings is to attach a logic analyzer to the camera module and power it up.

You could also wedge some circuitry in there that disables the I2C path from the PIC to the sensor and substitutes your own processor, just to send the proper register setting (which you discovered above) to set the image to normal. If I were doing it, I would use something like an Atmel ATtiny and wedge it between the SCCB bus. I would pass the I2C data from the PIC to the sensor at power on. After a short while, I would then send the command to turn off the mirroring.

 

[WhiteP85]

Thanks for the info araxara. It really does look like there is really no easy alternative to some some reverse engineering using an actual camera. I plan to order mine soon and I will see if I can continue working on the schematic and perhaps analyze the I2C/SCCB bus using a logic analyzer. I think for this to be a practical kit we would probably need to reverse engineer the entire camera module sufficiently to be able to design or specify an equivalent since manually reworking the OEM camera for more than one or two is probably not realistic. Reverse engineering is a fairly big exercise so it will definitely be part of a later phase.

 

[zeron]

I don't think the serial control interface goes over LVDS, the video data goes directly from the OV chip to the serializer, the PIC simply can't push all of that data, and the serializer on the other hand knows nothing about the OV chips configuration interface, so it wouldn't know how to interleave that.

That leaves the PIC. From the pictures on page 30, it's pins are exposed, and while the firmware on it will be protected from reading, it could be possible to just reprogram it (1) with a firmware of our own making that supplies the same configuration as the original (as learned from recording the data exchanged on it with a logic analyzer or a small uC, it's just a very slow serial interface) plus flipping the image. Now the PIC used here by Tesla seems overkill for just supplying a fixed configuration at startup, but then again it has no connection to the outer world (the touchscreen) or any insight into the video data so it can't really be dynamically adjusting things.

1: there might even be test points on the board that go directly to the PICs programming interface, but it's not possible to see that from the pictures.

 

[santana338]

Has anyone reached out to Tesla engineering to see if they might be able to provide a way to turn off the image mirroring? In the best case they might be able to provide a quick solution. If there isn't a quick solution, then at least they may see the value in what Artscii and WhiteP85 are doing and modify the camera design to make the mirroring easy to change. Or do we know if this is an off-the-shelf solution that Tesla did not have custom made for them (which would make it harder for Tesla to ask for design changes)?

After all, it would be in Tesla's interest to take this design and integrate it into future versions of the MS.

 

[WhiteP85]

I don't think the serial control interface goes over LVDS, the video data goes directly from the OV chip to the serializer, the PIC simply can't push all of that data, and the serializer on the other hand knows nothing about the OV chips configuration interface, so it wouldn't know how to interleave that.

That leaves the PIC. From the pictures on page 30, it's pins are exposed, and while the firmware on it will be protected from reading, it could be possible to just reprogram it (1) with a firmware of our own making that supplies the same configuration as the original (as learned from recording the data exchanged on it with a logic analyzer or a small uC, it's just a very slow serial interface) plus flipping the image. Now the PIC used here by Tesla seems overkill for just supplying a fixed configuration at startup, but then again it has no connection to the outer world (the touchscreen) or any insight into the video data so it can't really be dynamically adjusting things.

1: there might even be test points on the board that go directly to the PICs programming interface, but it's not possible to see that from the pictures.

Although it is quite likely that the PIC is setting the OV registers, the reason why I have not ruled out the possibility of I2C being set by the console is this type of serializer from TI that passes I2C down the twisted pair: http://www.ti.com/lit/ds/symlink/ds90ub901q-q1.pdf

- - - Updated - - -

Has anyone reached out to Tesla engineering to see if they might be able to provide a way to turn off the image mirroring? In the best case they might be able to provide a quick solution. If there isn't a quick solution, then at least they may see the value in what Artscii and WhiteP85 are doing and modify the camera design to make the mirroring easy to change. Or do we know if this is an off-the-shelf solution that Tesla did not have custom made for them (which would make it harder for Tesla to ask for design changes)?

After all, it would be in Tesla's interest to take this design and integrate it into future versions of the MS.

Tesla could change the camera mirror settings easily if they wanted to. What makes this difficult for us is that we do not have the design files or the firmware or even know if this is a Tesla design or third-party provided part. Either way changing the mirror is simply a setting change in the firmware that is not complicated if you are the designer or manufacturer.

I have no Tesla engineering contacts. Anyone on this forum with some better Tesla contacts willing to volunteer to chase down this option?

 

[artsci]

Continuing to have problems with the Chinese cable supplier, rfsupplier.com. The cables supposedly with the correct pinouts arrived yesterday, but when I tested them only one was correct. The other two hadn't been changed. I read them the riot act in an email reply. Fortunately I have a full set of the Tesla cables arriving today so I'll be able to go ahead with the test of my homemade PCB switch in a day or two.

As for the Chinese cables, I will hook up the one that's correct to the pcb and give it a final test. When rfsuppliers has them all correct I'm going to insist that they send me a bulk supply to replace all the incorrect cables they've shipped. I'll check them all then ship the replacements to each of you who has made a purchase from them. That way you'll know that they'll work.

Then, moving forward, once we have a kit developed, we'll include the cables with the kit, and they'll all be pre-checked.

 

[Akikiki]

artsci, your PM store if full. Did you know that already?

 

[artsci]

artsci, your PM store if full. Did you know that already?

Just cleaned it out so please PM me.

 

[artsci]

I now have all of the correct cables to connect both cameras to the PCB and the touch screen and switch from one to the other. I tested all of the connections today for continuity and all is well. Next step is to hook it all up in the car and see how it works. That likely will be tomorrow although I'm together with two other owners on Saturday and may wait until then.

 

[artsci]

Here's a status update.

My PCB failed -- the touchscreen would not detect the rear or front camera when they were connected through PCB. WhiteP85 has been providing expert technical advice and support and based on his oscilloscope analysis of the system he's concluded that with my PCB and/or wiring that is not properly shielded that either the screen does not see the camera or the camera is seen intermittently. i.e. it cycles on and off as the data comes through and then does not make it. The means that my relay approach will not work and may not be a reliable solution. Even if it works in one case it may not in another.

WhiteP85 thinks a safer bet is for him to spend the time designing a high quality switch using integrated circuits designed for the purpose. He's doing that. He also told me that the camera uses a sophisticated Gigabit Maxim MAX9259 serializer that makes it possible for the camera to be configured by the console and set mirror etc. He cannot yet tell if Tesla is using that capability. The serializer type also gives Tesla the flexibility to add another two cameras and display them simultaneously. He notes that we may not be able to take advantage of that but that is's interesting Tesla made that design choice.


He also noted that these guys do not use simple electronics and it's thus very unlikely that there is an off the shelf equivalent camera.

 

[zeron]

Getting more interesting by the minute
Makes me wonder what the PIC is doing...

 

[WhiteP85]

Getting more interesting by the minute
Makes me wonder what the PIC is doing...

I will post a more details later. It looks like the PIC is providing clock and converting from UART over LVDS to I2C.

For the technical geeks like me here is the proposed schematic and layout for the switch. The board is designed in a Newageenclosures case.

 

[jpasqua]

You guys rock! Thank you for your unrelenting determination and creativity. I have no doubt that you'll make it happen.

 

[artsci]

You guys rock! Thank you for your unrelenting determination and creativity. I have no doubt that you'll make it happen.

It's WhiteP85 who deserves the thanks. This is way beyond my capabilities and if it weren't for him there would be no prospect of a solution.

 

[Shumdit]

Thanks to all of you putting in all of this time and effort.

 

[Panacea]

You guys rock! Thank you for your unrelenting determination and creativity. I have no doubt that you'll make it happen.

+1000

I dont understand a lick of it but I can express my gratitude for the achievements to date!