OBD2 Fuel Consumption Gauge

Picked up an STM32F103 micro, an ILI9341 and a ELM327 OBD BT dongle clone and off it goes!!!

Similar projects worth following
My car doesn't have an onboard computer but I want to monitor the fuel consumption.
I've tried to use a ELM327 Bluetooth dongle (china clone) and Torque app but the dongle doesn't support all the AT commands needed to read the fuel data from the OBD bus.
So I found a KW1281 arduino library, (im)ported/improved/modded it to STM32 running arduino IDE and added the ILI9341 code.

The first attempt at this project was using the ELM327 Bluetooth dongle.

But I came to find that the available OBD info provided by the dongle was insufficient. It only provided speed, RPM, water temperature and a couple other sensor readings.

But nothing relative to fuel consumption...

Then I switched to another approach: "what if I could drive the OBD bus directly?"

So I searched the web for OBD implementations using arduinos and found this web page (OBD2_KW1281) that described very well the KW1281 protocol (used by my Audi A4) and had the code for arduino too! Nice!

I'm using STM32 with the arduino IDE gathering the best of three worlds: good performance, low price and vast libraries/code available. You can check it out at


Block diagram v1

JPEG Image - 31.60 kB - 06/20/2017 at 13:25


  • 1 × STM32F103 Microprocessors, Microcontrollers, DSPs / Microcontrollers (MCUs)
  • 1 × ILI9341 2.8" 320x240 TFT LCD display
  • 1 × ELM327 Bluetooth Dongle OBD2 to Bluetooth dongle
  • 1 × MCP9801 Sensors / Temperature, Thermal
  • 1 × ESP8266 Might be using it as a TFT driver...

  • UART signals fixed

    Rui Rex07/18/2017 at 08:54 0 comments

    I finally turned the soldering iron on ;) and got some work done!

    I've pocked around the ODB adapter and managed to get an NPN transistor with the collector connected through a resistor to the 5V rail and connected the UART TX line to the base of it. Then connected the collector to the base of the NPN that drives the K-Line.

    This way I don't need to have the interrupt inverting "thing" that could ruin the UART timings.

    Need to take a photo to post... :)

  • ESP8266 ready

    Rui Rex07/18/2017 at 08:49 0 comments

    I finally got a new layout ready and the communication "API" defined.

    I was aiming for a structure with an ID, Value and checksum in binary format but for now, and to make debugging easier I made a simple API with all ASCII values: <ID>,<space>,<float><\n>.

    This way I can enter a serial console and set the values manually and check if everything is working ok.

    Now I have to get the STM32 code to send the values accordingly to this API.

    P.S. I haven't been able to do it yet but I'm going to test the OBD comunication above the 90Km/h mark with the VAGCOM software running on the PC. If it works than it's something buggy on the code, if not than I might have to rethink this whole thing...

  • Why 90? (part 2)

    Rui Rex04/20/2017 at 10:30 0 comments

    I've made some code optimizations to try to reduce the display printing times.

    Got it to a minimum still using only the STM32 but even at idle engine I got some connection fails and retries.

    So the "diy" "hacked" UART TX signal inverting using an interrupt might be ruining the communication. Either that or the long cable carrying the UART signals from the OBD plug location to the dash... :) I have to fix the inverting and retry...


    Meanwhile I got the ILI9341 to refresh at 60fps on the ESP8266 xD

    I'm able to run the display at 80Mhz SPI speeds!!!! xDDD

  • Why 90?

    Rui Rex04/12/2017 at 08:40 0 comments

    So, I've managed to get some cables on the car and route the K-line control signals from the OBD adapter to the dashboard. This way I can drive and look at the display without loosing sight of the road!!! Drive safely!! :)

    Then I hit the road and all was fine. An occasional reconnection here and there but all seems ok.

    But then I entered the highway and everything went crazy! I noticed that after 90Km/h the OBD seems to stop responding.

    When I come back under 90 it reconnects and everything is ok.

    The code is not very optimized because I read the OBD values (3 blocks) and then I update the display and also read the temperature sensor and also update the display with that. This takes around 130+90=220ms. From what I've seen using the VAG-COM software on the laptop and capturing the control signal, when the software is idling it sends ACK frames back and forth to the ECU. So this 220ms might be too long between communications and the ECU might drop the connection. Still have to investigate further...

    But I'm planning to add a ESP8266 to be in charge of the display control and leave the STM32 only with the OBD tasks. This way I can leave it reading the blocks at max speed and reporting them to the ESP through RS232 and leave it to display the data.

    More to come...

View all 4 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates