Skip to content

xerootg/esp32_tp20_datalogger

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

12 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

ESP32 based VW TP2.0 Datalogger

This is a port of JacekGreniger's stm32-vagcanlogger to the esp32. I have largely stripped the feature set down to only support TP2.0, as I have no use for K-Line diagnostics.

I am using a CAN32 for my implementation.

The original stm32 based project was published on ep.com.pl in the Januaray 2011 edition. I have translated it below:

For Volkswagen-Audi cars (manufacturers such as Volkswagen, Skoda, Seat and Audi), several diagnostic programs have been created using a simple interface connected to a serial port or USB. One of the more famous is VagCom. It allows you to read and erasing errors not only from the engine controller, but also from other components of the car (ABS, airbags, etc.). You can read measurement groups, as well as adaptations and coding of drivers. One of the more useful features is the recording to the file, the measuring blocks collected during the test ride of the car. A later analysis of such a dataset helps to diagnose the inefficiency of a particular engine component especially if the problem occurs occasionally or, for example, only at a high engine load. The resulting text file contains data groups separated by semicolons – a format read by most popular spreadsheets, which can be used to create a chart of a given value in a time function.

Due to safety, recording of data while driving requires the second person to support the laptop. In many cases, this is cumbersome, so I decided to develop a stand-alone device that would save the data read from the engine controller on the SD card. I put emphasis on an intuitive interface, reduced to an absolute minimum, service that does not distract the driver of the vehicle. The choice of login configuration, start, and stop work is controlled by using a single button. The condition of the device is signalled by a two-color LED. The developed tester communicates with the engine controller (ECU) using the KW1281 protocol. For this reason, diagnostics are limited to Volkswagen-Audi cars, which was on the market until 2003. After that, the manufacturer withdrew from engine diagnostics (as well as other components) over K-Line, and moved to CAN bus. It should also be mentioned that you can find volkswagen-audi cars, which, despite diagnostics using line K, use a protocol other than KW1281 or answers are incompatible with the expected (example is the Skoda Felicia 1.3MPI from 1997).

Construction At the heart of the device is the Cortex-M3 STM32F103CB family microcontroller, which is available in the PQFP48 housing. The microcontroller has 128 kB of program memory and 20 kB of RAM. It is clocked with an 8 MHz quartz resonator, the frequency of which is internally reproduced using PLL. The 32,768 kHz resonator and 3V lithium battery are used by the real-time clock. Communication with ECU is carried out through the UART2 port of the microcontroller. As a voltage converter, I used the easily accessible and affordable L9637D system. It requires two voltages: 12 V (taken from the car diagnostic connector) and 5 V. Because l9637D, unlike the microcontroller, works with only 5V voltage levels, it was necessary to lower the level on the RXD uart2 using voltage dividers. On the other hand, 3.3V microcontroller TX level is sufficient for L9637D. The 5 V voltage for L9637D, buzzer and 3.3V LDO stabilizer (microcontroller and SD supply voltage) comes from a typical 78M05 linear regulator. Low current consumption does not cause major losses on this regulator and I have not observed excessive heating of the system even during longer operation. Please note that turning off the ignition in the car does not cut off the power on the pin of 16 diagnostic connectors and the device must be disconnected each time it has finished operation. The Software was written in C and compiled with the GCC compiler. I used free peripheral libraries version 2.0.3 provided by STMicroelectronics. The FatFS file system is written by ChaN and is also available free of charge. Communication with the car driver Communication with the motor controller is made using a two-way single-wire K bus. one stop bit. The transmission speed is, for cars with a higher layer of KW1281, 9600 or 10400 baud. The exception is the connection initialization sequence. Communication of the tester with the controller consists in the exchange of messages with a length of 4 to 256 bytes.

A single message consists of the following fields:

  • message length, does not include the end tag of the message (1 byte)
  • another message number, incremented each time by 1 (1 byte)
  • message type (1 byte)
  • data block, can be empty (maximum maximum) the length of this field is 252 bytes)
  • the end-of-message mark always has a value of 0x03 (1 byte) Subsequent bytes of message (except end mark) must be confirmed by the other party each time by sending back the negated received value Byte.

I implemented support for the following types of messages:

  • confirming (ACK, 0x09)
  • request to read the measuring group (GROUP_REQUEST, 0x29)
  • reply with the content of the measuring group (GROUP_RESPONSE, 0xE7)
  • end of session (END_OF_SESSION, 0x06)
  • data ASCII (ASCII_BLOCK, 0xF6)

The connection initialization occurs by sending the tester the address of the driver to which you want to communicate. In the case of an engine, this is the address 01h. The initialization sequence is sent at a speed of 5 baud (the duration of a single bit is 200 ms). The addressed driver, with the correct transmission speed, corresponds to the sending of three bytes: 55h (syntax byte) and a two-byte code word indicating the protocol number (for KW1281, these are consecutive bytes with 01h and 8Ah values). When you measure the duration of the synchronising word (alternating sequence of zeros and ones), you can specify the transmission speed applied by the controller and properly program the UART microcontroller to correctly receive the next two bytes. As a confirmation, the tester refers to the denied value of the last received byte (for KW1281 it will be 75h).

After initialization, the controller (in this case the engine driver) transmits the first message. Typically, the first few messages contain ASCII text data (part number, driver model, etc.). The tester confirms the next messages received from the driver by sending 4-byte ACK frames (with a blank data field). When ECU sends all ASCII blocks, a mutual exchange of ACK messages will be exchanged (this is used to maintain the connection). When a further 8 ACK messages are received, the tester sends the first query for a measurement group (this is not a protocol requirement and only my premise). This type of message has a length of 5 bytes and its data field contains the number of the group requested (0 to 255). The answer from the driver's page is a GROUP_RESPONSE message with a 12-byte data field (for zero group, it is 8 bytes). Each measuring group contains four values (three bytes per each). The first byte of such a subgroup contains a type (type) value and tells you what procedure to use to convert two consecutive bytes to an actual value. Patterns for converting received values are available on the [3] page. The above does not apply to group number 0, this group contains eight values, one bag per value. At the same time, you can only send a query for one measuring group.

VAGlogger allows logging of up to three groups and requests for subsequent numbers are made sequentially. The communication with the controller can be terminated by sending the frame of type END_OF_SESSION. In the VAGlogger program, I assumed that not receiving a response from the driver within 500 milliseconds is treated as a connection failure.

Installation and programming of the VAGlogger microcontroller was carried out on a 60 × 41 mm double-sided board. The grommets have been placed outside the outline of the elements, thanks to which it can be made at home (without hole metallization). The tile was made by photochemical method on a finished laminate of the company Bungard with a thickness of 0.8 mm and irradiated with a UV lamp for tanning the face. The laminate is developed identically to the laminate coated with Positiv 20 photosensitive varnish, i.e. in sodium hydroxide solution. The plate was etched in solution B327. After etching the paths, the plate should be protected against oxidation - I personally use Contact Chemie Flux spray. Before installing the components, it is worth deselecting the holes for the mounting screws in the plug housing. If the plate does not have hole metallization, the installation should be started with grommets. They can be made e.g. from silver-plated wire 0.2 ... 0.3 mm in diameter. The U-shaped wire is put through two adjacent holes. The elasticity of the wire ensures that the vias are firmly seated before soldering and there is no risk of them falling out even after turning the board. Some vias are close to other soldering points, so you should shorten them only after soldering the rest of the elements. The microcontroller has a 0.5 mm pitch raster and its assembly was made using a thin soldering iron. The last elements to be fitted are through-hole elements (buzzer, lithium battery). The light emitting diode is mounted on shortened leads directly to the PCB, the button on short wires. As CON1 connectors (connection of the car diagnostic connector) and CON2 (UART1 microcontroller, used only for its programming) should be used angular pin strips. Please note that some leads must be soldered on both sides of the board (first from the bottom of the PCB and then after gently prying the plastic part of the strip at the top). The CON3 connector does not need to be installed - it is a SWD debugger connector.

After installation, check the board visually for short circuits. The next stage is programming the microcontroller. Before connecting the power supply, make a jumper between the R8 resistor (BOOT0 lead of the microcontroller) and +3.3 V - on the board it is the jumper marked SJ1-H, in order to force the microcontroller to start in bootloader mode. The system should be powered by connecting 12V voltage between pins 1 and 3 of CON1 connector. Through the 3.3V / RS232 converter connect the VAGlogger board (CON2 connector) to the serial port of the PC. As a converter you can use a typical MAX3232 application with 100 nF capacitors. The hex file with the program code should be loaded into the microcontroller using the Flash Download Demonstrator program available on the ST-Microelectronics website [2]. The default serial port settings suggested by the application are correct. If the programming was successful, disconnect the power supply from the system, remove the SJ1 jumper from the H position and install it in the L position (the BOOT0 lead of the microcontroller must be connected through the R8 resistor to ground). In this setting, after the reset, the microcontroller will execute the code from the FLASH memory. The circuit board is mounted in the OBD2 plug housing with three M2.5 screws with a countersunk head and a length of 15mm. Each bolt is attached to the housing with a nut bolted on the other side. The next two nuts fix the plate at the appropriate height (equal to the height of the half of the plug housing). Before final mounting of the plate in the housing, mark the places where the file will make holes for the SD card, light emitting diode and button. Device support For proper operation, VAGlogger needs a configuration file. You need to prepare an SD card with the FAT16 or FAT32 file system. Create a configuration file named config.txt in the root directory. The next lines of the file are the settings for subsequent configurations. A single configuration can contain one to three group numbers (separated by semicolons).

Example contents of the config.txt file: 1; 2; 5 115; 118 32; 33

VAGlogger has a real-time clock supported by a lithium battery. Time and date are set based on the contents of the settime.txt file located similarly to config.txt in the card's root directory. A correctly read file is then deleted from the file system.

The format of the settime.txt file is as follows: hh: mm.ss dd.mm.rr

The file with the following content will set the time 19:59:00 and the date on September 14, 2010: 19:59:00 14.09.10 The card should be inserted into devices before turning on the power, because its initialization and reading of configuration files takes place only once after the device reset. For the safety of electronics in the car, the system should be connected with the ignition off. After starting the engine, select the active configuration with long button presses. By default, the device starts in the first configuration (signaled by a steady green LED, in this case the groups given in the first line of the config.txt file are logged in). Successive configuration numbers are signaled by lighting up the red or orange LED respectively. At the same time, the configuration number is indicated by an appropriate number of short signals. A short press of the button starts the process of connecting to the engine controller. It is indicated by a fast flashing green LED and a single long beep.

After successful connection, the LED color changes to the color of the selected configuration, the LED flashing rate decreases and the user is informed acoustically about the number of the selected configuration (the appropriate number of short beeps). The process of polling the engine controller about subsequent measuring groups and saving them to a file begins. A single press of the button disconnects from the controller and closes the current file. No response from the controller, incorrect protocol number or communication interruption during logging in is signaled by a fast flashing of the red LED and two long beeps. After two seconds, the system returns to configuration selection mode.

Any error related to the file system both during device initialization and during the login process, such as: no card, no configuration file or its incorrect format, file saving error e.g. due to card overflow, communication error with the card, is signaled by three long signals sound and flashing orange diode.

A long hold of the button resets the device. In the logger design I used a regular SD slot without an ejector. The shocks present in the car may cause the card to eject in the slot and consequently the error described above. A simple solution is to put on a prescription eraser. A better solution would be to use a pushpull SD slot. Unfortunately, their disadvantage are much larger dimensions. Files created by VAGlogger have a three-digit name and a CSV extension (starting with 001.CSV). After starting the device, the card's root directory is always read to determine the number of the last saved file - the next saved file will have a number one greater than the largest found. Summary VAGlogger was created for cars built on the basis of Golf 4 (Seat Leon, Audi A3, Skoda Octavia). The KW1281 protocol was also present in other vehicles from those years, so its functionality is not limited to this family.

The operation of the device was tested on the following vehicles:

  • Audi A4 1.9TDI from 1996
  • Skoda Octavia 1.8T from 2005
  • Skoda Octavia 1.9TDI from 2000
  • Audi A3 1.6 from 2002
  • VW Polo 1.2 from 2003

About

VW TP 2.0 Datalogger for the ESP32

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published