Completely agree. Just wanted to give you some info so you weren't spinning your wheels if it didn't work.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Wireless front parking camera with monitor for front bumper protection
- Thread starter artsci
- Start date
-
- Tags
- Model S User Interface
Completely agree. Just wanted to give you some info so you weren't spinning your wheels if it didn't work.
Morristhecat
Member
How about approaching this from a different angle? If you are on v5.0 this may work...
Get a automobile wifi router. I saw a couple cheap ones on ebay, one even looks like a 12v lighter plug. Then get a cheap IP camera that is waterproof. Connect the tesla to your new router, map the web browser to the IP camera, and there you go...
I don't have v5.0 to test though....
Get a automobile wifi router. I saw a couple cheap ones on ebay, one even looks like a 12v lighter plug. Then get a cheap IP camera that is waterproof. Connect the tesla to your new router, map the web browser to the IP camera, and there you go...
I don't have v5.0 to test though....
deonb
Active Member
Tesla doesn't allow any video streaming format. So it will have to be bitmap updates, which is 1 or 2 per second at most. It's not practical to try and park at that update rate.
Morristhecat
Member
I don't know about Tesla's crappy browser, but a desktop browser can stream images faster than that. But another problem would be that you wouldn't be able to use the car's built in 3G connection while it's connected to the router.
I said the same thing 30 posts back, which is why he is not cutting into his cable but using connectors. However depending on the frequency and the noise immunity of the buffer and receiver, he may get lucky and have enough signal-to-noise to pull it off. artsci's doing the right thing first, and if it works all the other details can be worked out easily. Otherwise next steps are clear.
He is still breaking the coupling whether cutting the cable or using connectors, but I agree his is doing the right thing in the first test. Personally my experience with these types of systems at these speeds the noise immunity stinks. So one thing to be aware of is that even if this works on his setup that doesn't mean that it will work in all of them. But again I agree that trying the easy thing first is the best thing to do, people just shouldn't expect that if it works for artsci it will work for them.
I know that is why he is doing it, the way you wrote your response seemed to suggest that the signal integrity was the reason for the connectors. Guess I just interpenetrated it incorrectly.
Actually, and this is one of the glories of this web site, my thinking about how to do this has evolved based on all of the comments and suggestions made here. At first I wasn't even thinking about the signal integrity until it was pointed out here that it might be a serious problem. So using the Amphenol cable and connectors served two purposes -- preserving the functionality of the system as I attempted to modify it and preserving signal integrity as much as possible, recognizing that the switch might compromise it.
I'm an electrical/mechanical engineer working in robotics and I just found this thread. Very excited to see the progress so far. I came to offer a suggestion for integrating switching into the touchscreen. We can control a lot of other in-car devices this way too. With firmware 5.0, we finally have wifi access, so we can connect to a wireless network mounted inside the car. The network can then host web pages that essentially give us (almost) complete freedom to write web apps for the in-screen browser. If we're creating a PCB to switch the LVDS signals, it can simply receive signals from the wifi network to activate the switch. You'll have to pull up a web page with the controls, but you won't have to mount any external switches in the car. In the future I imagine a custom "controls" web page that has buttons and configurations for all the custom devices you've installed in the car.
Morristhecat
Member
@cybrown,
Could such a web interface be configured to show input from external devices as well? Say, from an aftemarket proximity sensor for instance?
Could such a web interface be configured to show input from external devices as well? Say, from an aftemarket proximity sensor for instance?
Great idea. I think it will work, but it depends on what the browser supports. Anyone know if it will display any kind of dynamic data? And will TeslaOS (is that what we're calling it?) 5.0 display local web pages?
- - - Updated - - -
I moved this discussion to a separate thread, so please reply there: http://www.teslamotorsclub.com/showthread.php/20771-Product-Idea-Control-external-hardware-through-the-touchscreen
Obtaining the Amphenol cables and connectors has proven to be more complicated than I thought. They don't sell to retail to consumers so I'll have to issue a PO through my web business. I'm still waiting for pricing from Amphenol, so this is likely to take more time than I first anticipated.
JerryNycom
Member
If the solution requires a switch it could be placed in the screen though the Homelink buttons.One (labeled) button switch for front camera and the next one for rear.
There are many companies that make remotes that switch lights on and off.
This one is for cars.
http://www.oraclelights.com/automot...ollers/Dual-Channel-Multi-function-Controller
There are many companies that make remotes that switch lights on and off.
This one is for cars.
http://www.oraclelights.com/automot...ollers/Dual-Channel-Multi-function-Controller
I think that homelink recognizes "home" and offers up, but is not disabled when away from that location. Simple test would be to program the car off site and then press the button when it is returned to the receiver location. I bet it would work.
