Automotive WiFi Controller Brent Chroninger and Tom Wood Bully Dog Technologies American Falls, Idaho Tom Wood and Brent Chroninger both work for Bully Dog Technologies. Bully Dog Technologies designs aftermarket automotive electronics. These electronic modules primarily reprogram engine computers to add horsepower, and monitor real-time engine data such as RPM and speed. This project became an interest because we are always in the need for vehicles of which we don’t not have locally in the same geographic location. It would also be nice on some days to work from the office desk and not have to run out to the truck to test a few simple commands. University of Idaho ECE 504R Spring 2011

Introduction Project Overview Hardware Software Setup Demonstration Conclusions University of Idaho ECE 504R Spring 2011

Project Overview Establish the ability to communicate wirelessly to an automobile via the OBD2 port. Transmit CAN protocol commands from PC to vehicle via wireless connection. Receive CAN protocol commands on a PC from a vehicle via wireless connection. Control engine RPM remotely using CAN commands through OBD2 The main purpose the project is to transmit and receive OBD2 commands remotely for product development purposes. Functionality verification was achieved in three steps: 1. Transmit Message. 2. Receive Message. 3. Finally demonstrated by sending an RPM command to control engine speed. CAN protocol is one of many OBD2 protocols, and was chosen because it is the most common protocol currently. University of Idaho ECE 504R Spring 2011

Project Overview – OBDII OBDII – On board diagnostics, since 1996 required on all vehicles sold in US. Source: <http://en.wikipedia.org/wiki/Obd2#OBD-II_Diagnostic_connector> 1. Manufacturer discretion. GM: J2411 GMLAN/SWC/Single-Wire CAN. 9. - 2. Bus positive Line of SAE-J1850 PWM and SAE-1850 VPW 10. Bus negative Line of SAE-J1850 PWM only (not SAE-1850 VPW) 3. Ford DCL(+) Argentina, Brazil (pre OBD-II) 1997-2000, USA, Europe, etc. Chrysler CCD Bus(+) 11. Ford DCL(-) Argentina, Brazil (pre OBD-II) 1997-2000, USA, Europe, etc. Chrysler CCD Bus(-) 4. Chassis ground 12. - 5. Signal ground 13. - 6. CAN high (ISO 15765-4 and SAE-J2284) 14. CAN low (ISO 15765-4 and SAE-J2284) 7. K line of ISO 9141-2 and ISO 14230-4 15. L line of ISO 9141-2 and ISO 14230-4 8. - 16. Battery voltage All vehicles sold in the US have the OBD2 (On-Board Diagnostics) port. Shown is a diagram of a OBD2 plug, and common protocols assigned to each pin. Not all vehicles are populated with all protocols, for our test the CAN High (pin 6), CAN Low(pin 14), Chassis and Signal ground (pins 4 and 5), and Battery Voltage (pin 16) are used. Source: <http://en.wikipedia.org/wiki/Obd2#OBD-II_Diagnostic_connector> University of Idaho ECE 504R Spring 2011

Project Overview – CAN CAN – Controller Area Network ISO 15765 NRZ Non Return to Zero 500 Kbits/second Shown here is a snapshot of the two CAN (controller area network) lines on an oscilloscope. In particular we are using the 500Kbits per second CAN protocol (High Speed CAN). CAN is commonly used to provide diagnostic data in vehicle networks. It is used in diagnostic procedures for troubleshooting issues, and is also used to bootload firmware updates. Source: < http://marco.guardigli.it/2010/10/hacking-your-car.html > University of Idaho ECE 504R Spring 2011

Hardware Bully Dog Triple Dog – Firmware Two PC’s with WiFi connection CAN Transceiver on DSPIC 30F6011 USB through FTDI USB transceiver Firmware Microchip C30 USB communications to PC CAN protocol handling Two PC’s with WiFi connection One PC must have USB connection to connect to triple dog hardware. To facilitate the CAN protocol we chose to use existing hardware from Bully Dog Technologies. We used a Bully Dog Triple Dog downloader, marketed for horsepower modifications, that had modified firmware that broadcast CAN messages to USB. It was also modified to receive commands via USB for CAN message transmission. The Triple Dog uses a Microchip dsPic 30f6011 as the microcontroller, and an FTDI USB transceiver. It connects to the vehicle through a 15 pin serial to OBD2 cable. The firmware was written in C30 using Microchips IDE and C-compiler. The USB from the triple dog was then connected to a PC that simply ran an C-sharp application that translated the USB packets into a WiFi packet to be sent to another PC. It also translated WiFi received packets to the USB format for transmission to the triple dog. University of Idaho ECE 504R Spring 2011

Software C# development using Visual Studio 2008 Develop PC to USB communications Develop PC to PC wireless communications Packet Format – USB to PC and PC to PC packets the same. The software was written in C sharp using Visual Studio 2008. This single piece of software can be used on either of the two PC’s, and can be configured to be either the client(remote pc) or the server (pc connected to triple dog). The server portion of the software listened for a connection from a remote client. Once connected it would connect to the USB device(triple dog). The server then acted as a buffer between the remote PC and the triple dog. It basically encoded and decoded the USB and WiFi messages respectively. The client end of the software decodes the received messages and prints them to a message panel. It also can be used to create and send messages to be transmitted on the CAN bus. University of Idaho ECE 504R Spring 2011

Software – Packet Format This is a diagram of our USB packet format. The first byte is used for the module ID, which identifies the message as CAN protocol (and can be expanded in the future for other protocols). It has a single byte for the total packet length, and the data length. Next the header which is the CAN message ID, a timestamp, the message data, followed by a checksum. For simplicity this packet is simply tunneled to an Ethernet packet for the WiFi transmission/reception. We used the built in C-sharp .net socket framework for implementation of the socket client. These functions handled all of the wireless communications. University of Idaho ECE 504R Spring 2011

Setup Install SnoopDog on two separate Wifi enabled PC’s Connect Triple Dog to PC 1 via USB Connect Triple Dog to OBD II port on any CAN vehicle Establish Client Server connection with PC 1 to PC 2 via WiFi This describes how we setup our test. We first installed our software (tentatively called SnoopDog) on two separate PC’s. We then connect the triple dog to the server PC via USB. Next the triple dog is connected to the OBD2 port of the test vehicle. Finally to achieve the remote access the client must connect to the server PC (through IP address identification). University of Idaho ECE 504R Spring 2011

Demonstration CAN transmission CAN reception Command Execution Next is a short video demonstrating our project. This demonstration consists of a CAN message transmission, CAN message reception, and finally a CAN command being executed to modify the idle RPM for an audible and visual verification of functionality. University of Idaho ECE 504R Spring 2011

Demonstration http://www.youtube.com/watch?v=3LhepM2-pZY Please play video of the demonstration. http://www.youtube.com/watch?v=3LhepM2-pZY University of Idaho ECE 504R Spring 2011

Demonstratrion – Server Setup PC1 (server) The video isn’t completely clear with regards to the PC app so the following photos display some screen captures of our SnoopDog C-sharp application. This particular menu is the client/server configuration menu, specifically this is configured as the server. Notice the Client-Server enable check box and radial buttons to configure as client or server. The Server IP address is displayed in a text box and has a button to begin listening for clients. University of Idaho ECE 504R Spring 2011

Demonstration – Client Setup PC2 (client) This screen capture is the same client/server menu, but configured as the client. The server IP address and port must be known, as well as entered here. Once they are entered in their respective text boxes, simply pressing the “connect to server” button will connect the client to the server. University of Idaho ECE 504R Spring 2011

Demonstration – USB Connect PC1 Once the client/server connection has been established, the server can connect to the USB device (TripleDog). The screen capture shown here displays the available COM ports. By simply highlighting the correct port and pressing the connect button will connect the server application to the Triple Dog. This connection will remain until the disconnect button is pressed or the USB device is unplugged. University of Idaho ECE 504R Spring 2011

Demonstration – Message Setup PC2 (client) This screen capture displays the menu to configure a CAN transmit message. CAN messages consist of a standard 11 bit or extended 27 bit SID, and 8 bytes of data. Here we use the standard 11-bit ID, and 3 bytes of data. Notice we have a dropdown menu that selects a hotkey to be used to transmit the message. This transmit message menu can be accessed from the transmit menu shown on the next slide. University of Idaho ECE 504R Spring 2011

Demonstration – Message Setup PC2 (client) The transmit menu allows you to add and modify multiple transmit messages. Shown above are the four messages we used in our test. The first message sets the vehicle into diagnostic mode, and the other three are used to set the idle RPM to 800, 1200 and 1600 RPM. 0x64 is equivalent to 800 RPM, 0x96 is 1200 RPM, and 0xC8 is 1600 RPM (you can see this by looking at the column B4) University of Idaho ECE 504R Spring 2011

Demonstration – Message Display PC2 (client) This screen capture displays the message menu. This menu displays the messages on the CAN bus. The messages are assigned a count, the CAN SID, a timestamp followed by the data. This also has an option for the which network the message is on (primarily for future use with other protocols.) Not displayed here is the selection button that will allow to either scroll the messages, or simply non-scroll the messages sorted by the CAN SID (ArbID/Header). University of Idaho ECE 504R Spring 2011

Conclusions Passively monitor CAN bus via WiFi connection. Transmit CAN messages remotely. Server can eventually be put on a WiFi enabled embedded device. Scripts can be implemented to integrate a series of CAN bus transactions. In conclusion we demonstrated that we were able to passively monitor, and actively control an automobile’s diagnostic features remotely. This consisted of remote transmissions, and receptions through WiFi. For future work we would like to remove the server PC and run the server side of the application on a WiFi enabled embedded device. We would also like to add a scripting functionality. This would allow us to run a script that sent and received a pre-defined set of communication for more complex diagnostic features. University of Idaho ECE 504R Spring 2011