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

Wireless front parking camera with monitor for front bumper protection

This site may earn commission on affiliate links.
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.

View attachment 35806

View attachment 35807

WhiteP85 (and artsci).... These are not criticisms, but just some questions/concerns I have... What trace impedances are you targeting? it's difficult to tell from the small image, but are those traces length-matched within the pair? The LVDS pairs look like they are tightly-coupled, and the traces look very wide. In tightly-couple traces, the traces should be in-phase (length matched per segment). Since board space doesn't appear to be an issue, switching to loosely-coupled pairs can ease-up on a lot of restrictions and make length-matching and routing better. Do you want to provide the trace length measurements, PCB stack-up, and mechanical dimensions so that some of this can be verified? If artsci's board failed due to poor signal-integrity, then this must be done right. Do you (or anyone else with the cable in-hand) have access to a TDR to measure the characteristic impedance of Tesla's OEM cable? Or is that specified/labeled on the insulator? Are there published specs on those connectors as well?
 
WhiteP85 (and artsci).... These are not criticisms, but just some questions/concerns I have... What trace impedances are you targeting? it's difficult to tell from the small image, but are those traces length-matched within the pair? The LVDS pairs look like they are tightly-coupled, and the traces look very wide. In tightly-couple traces, the traces should be in-phase (length matched per segment). Since board space doesn't appear to be an issue, switching to loosely-coupled pairs can ease-up on a lot of restrictions and make length-matching and routing better. Do you want to provide the trace length measurements, PCB stack-up, and mechanical dimensions so that some of this can be verified? If artsci's board failed due to poor signal-integrity, then this must be done right. Do you (or anyone else with the cable in-hand) have access to a TDR to measure the characteristic impedance of Tesla's OEM cable? Or is that specified/labeled on the insulator? Are there published specs on those connectors as well?

I can't speak for WhiteP85 but I'm pretty sure he's aware of what you've pointed out and is taking it into account in his board design.
 
WhiteP85 (and artsci).... These are not criticisms, but just some questions/concerns I have... What trace impedances are you targeting? it's difficult to tell from the small image, but are those traces length-matched within the pair? The LVDS pairs look like they are tightly-coupled, and the traces look very wide. In tightly-couple traces, the traces should be in-phase (length matched per segment). Since board space doesn't appear to be an issue, switching to loosely-coupled pairs can ease-up on a lot of restrictions and make length-matching and routing better. Do you want to provide the trace length measurements, PCB stack-up, and mechanical dimensions so that some of this can be verified? If artsci's board failed due to poor signal-integrity, then this must be done right. Do you (or anyone else with the cable in-hand) have access to a TDR to measure the characteristic impedance of Tesla's OEM cable? Or is that specified/labeled on the insulator? Are there published specs on those connectors as well?

Ken,

I share your concern.The current board design uses differential microstrip. The crosspoint switch and sockets have been placed to attempt to create close to equal length traces.

The current specs are:

Differential microstrip.JPG


Using inexpensive FR4 with assumed relative permeability of 4.3. High frequency board would be better of course but I am trying to keep the cost of prototyping and manufacturing down and I think we can get away with 2-layer FR4. Some of my test jigs that were not 100 ohm differential worked at times so I think we are close.

I unfortunately have no decent test equipment as this is not something I do in a day job but the Tesla cable is designed to be 100 ohm differential and I am pretty sure of that.

My trace measurements (mm) are:

Screen 18.55/20.02
Rear 29.78/29.64
Front 65.22/65.14

I guess I could run separated 50 ohm traces that I calculate should be 3mm wide but I think the differential trace lengths are close enough.

Open to verification of these numbers and further suggestions. I have not yet finished the layout and ordered the prototype boards.

- - - Updated - - -

I guess I could run separated 50 ohm traces that I calculate should be 3mm wide but I think the differential trace lengths are close enough.<br><br>Open to verification of these numbers and further suggestions. &nbsp;I have not yet finished the layout and ordered the prototype boards.

Cable specs are here: http://rosenberger.com/documents/headquarters_de_en/ba_automotive/HSD_Concept_Pinning.pdf
 
Last edited:
Hi WhiteP85,

I had no sense of scale in your image so thanks for the additional information. With that, it's clear that your trace dimensions are correct. I would still say that it is slightly preferable to route loosely-coupled pairs. The current tightly coupled pairs are length matched from end-to-end, but are not matched at each segment. This will negatively affect the differential signal as it propagates and becomes skewed mid-way through. BUT with a 2-layer, 1.6mm-thick PCB, the 3mm trace widths and at least 5- to 6- mm spacing may not be practical. Plus, with trace lengths as short as they are, I don't foresee a major problem with leaving it as is. I'm assuming a solid, well-connected ground plane underneath the pairs.

I did a general check of your logic in the schematics and all seems correct and reasonable to me! Great job!
 
Hi WhiteP85,

I had no sense of scale in your image so thanks for the additional information. With that, it's clear that your trace dimensions are correct. I would still say that it is slightly preferable to route loosely-coupled pairs. The current tightly coupled pairs are length matched from end-to-end, but are not matched at each segment. This will negatively affect the differential signal as it propagates and becomes skewed mid-way through. BUT with a 2-layer, 1.6mm-thick PCB, the 3mm trace widths and at least 5- to 6- mm spacing may not be practical. Plus, with trace lengths as short as they are, I don't foresee a major problem with leaving it as is. I'm assuming a solid, well-connected ground plane underneath the pairs.

I did a general check of your logic in the schematics and all seems correct and reasonable to me! Great job!

Thanks for the feedback Ken. I noticed an error with MCLR connected to 5V instead of 3V and fixed that. I also added some test circuitry to make my life easier when testing the circuit and developing the firmware. I think I am close to ordering and assembling a couple of PCBs and seeing if they work.

Tesla Camera PCB alpha 6 schematic.png
Switch alpha 6.JPG
Differential traces.JPG
 
I placed the order to have a couple of PCBs manufactured. They should take a week or so to arrive. I will order the parts next and will hopefully have something to start working within a couple of weeks. My initial test will be to verify the operation of the video and power switches. If that goes well then I will start work on the microcontroller firmware to manage the switching.

I do have some very preliminary info on the guts of the camera that I will share as soon as I get it written up.
 
For those in states that require a front license plate, we're also going make for the kit a 3D printed cradle to hold the front camera. It will attach with small screws to the lower part of the standard Tesla front license plate holder.

Will there be an option for those that mounted the license plate in the lower (no drill) position?
Front Plate.jpg

Mounting on the lower portion of the plate bracket is probably too low and mounting in the nose cone would cause the image to be blocked by the plate.
 
Thanks for all the support and encouragement. The two PCBs I ordered arrived faster than expected and fit inside the enclosures they were designed for. Still waiting for the parts to arrive and if I get them soon I might be able to perform some initial testing this weekend.

Here is a photo of two of the boards and the enclosure with some of the parts that I have already.

PCBs.JPG


Hopefully we will be lucky and this will work first time. The case is from Newageenclosures and they will likely make run a batch or 100 or so (does not pay to do fewer) with custom cutouts for the connectors. Their turn around is about 6 to 8 weeks.
 
Last edited:
Hey WhiteP85 any luck with switching the front camera to NORMAL view, and not reversed?

Hi Jerry,

I have put that on the back burner as a second phase while I build and test the switch. It is not at all easy to do this as the setting is done in software and it appears that the console likely communicates with the camera each time it it switched on. The communication (custom protocol over UART) is likely sent down the same wires as the video signal that is very very high speed. There is a microcontroller inside the camera that then likely translates these messages to a different format (I2C) to talk to the camera module set the image flip and other settings. I have opened up the camera and have started to work out what is inside. It is small and the circuit has traces that cannot be seen as they are embedded in the board. The board uses rigid-flex PCBs and the only way to really reverse engineer the circuit is to carefully rip apart and destroy the $400 camera module.

So the image flip is a big exercise. These are the likely steps:

1. Finish trying to reverse engineer the circuit as far as possible
2. Connect a piece of test equipment to the traces inside the camera (tiny tiny) and see if they can be read and decoded to confirm operation
3. Attempt to copy the camera using the same or similar circuit. (There are many many software settings and we might be stumped if the console is expecting communication back that we may not be able to replicate), or
4. See if it is possible use the same serializer/deserialiser chip to break out the communication signal and put a microcontroller inline that echos everything except the message that flips (or do the opposite). This might be something that can be built into a later model switch although 3. above would be cheaper.

Anyway that was probably more detail than you wanted. Suffice to say unfortunately that I am a long way from a solution here. This is unfortunately not your father's video camera technology ;-)