- Thread starter
- #41
Here's the basics - which will also help @wildsmith a bit. More details later:Please a excuse a layman trying to understand how this works. The Teyes unit, Does it interface directly with the vehicle's can-bus wires, and you can send data to the can-bus through the OS? Does the Teyes retain the black AC amplifier mounted behind the factory screen?
The Teyes connects into the car in two ways. First, with direct wiring from the Teyes to the car's wiring harness. This is used to play audio to the speakers, detect the car's ACC turned on, provide power, etc. The second way it communicates with the car is via the canbus, which is a network communication system in the car that links all the ECUs together (kind of).
The Teyes doesn't connect to the CanBus directly because there are so many different types of cars with different types of canbus. Instead, each Teyes comes with a CanBus Decoder box. Those are made by a bunch of different companies that reverse engineer the CanBus communication in the vehicle and put all that logic into the CanBus Decoder box. The company that figured out the LC100 canbus and provides the decoder is Luzheng. That's why when you setup your Teyes canbus settings, you choose "LZ". That's the manufacturer of the canbus decoder. The Canbus decoder provides a serial interface to the Teyes and translates that to the two-wire canbus signal to the car.
There's not, as far as I know, a logical mapping between the data send from the Teyes to the Canbus decoder, and then from the decoder to the vehicle. For example, the canbus code for "Set the climate control to Auto" is 21. I'm not confident that 21 is also the code used between the decoder and the vehicle.
From the top, here's how the climate control app I built works:
1) It calls a system service running on the Teyes that provides CanBus notifications and commands. I send the command code 21 and command data "true" to set the climate system to Auto.
2) That service accepts the command and calls a JNI service, written in C++.
3) That JNI service has a serial port open to the canbus decoder box and sends the command code 21 and the data to the decoder.
4) The decoder translates that to the correct canbus command for our trucks and places the command on the canbus network
5) The truck accepts the command and sets the climate control to Auto. This will, in turn, result in the A/C turning on, for example.
6) The truck puts a "A/C is now on" notification on the canbus.
7) The canbus decoder sees that message and relays it over the serial port to the JNI service.
8) The JNI service relays it to the android service
9) The android service looks and says, "do any apps want to be notified of the A/C on notification?". It sees that my app is interested and sends the A/C on notificaiton to my app.
10) My app sets the A/C icon appropriately.
The interesting thing about all of this is that my app and the Teyes in general, is pretty "dumb". It doesn't know that turning the fan off also turns the A/C off. It doesn't know that going into defrost mode also disables the other vents. The truck climate ECU handles all of that. The teyes and the climate control app just send commands and interpret notifications.
Hope that provides some insight!