1. 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

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

3. 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 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

4. Project Overview – OBDII
OBDII – On board diagnostics, since required on all vehicles sold in US.
Source: <
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) , USA, Europe, etc. Chrysler CCD Bus(+)
11. Ford DCL(-) Argentina, Brazil (pre OBD-II) , USA, Europe, etc. Chrysler CCD Bus(-)
4. Chassis ground
12. -
5. Signal ground
13. -
6. CAN high (ISO and SAE-J2284)
14. CAN low (ISO and SAE-J2284)
7. K line of ISO and ISO
15. L line of ISO and ISO
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: <
University of Idaho ECE 504R
Spring 2011

5. 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: < >
University of Idaho ECE 504R
Spring 2011

6. 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

7. 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 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

8. 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

9. 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

10. 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

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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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